Вступление
00:00:00Карьерный путь и программа действий при выборе архитектуры данных Четырнадцать лет проработал в ИТ, уделяя особое внимание архитектуре данных, перешел от аутсорсинга к продуктовой компании, где продуктом были сами данные, и стал главным архитектором. Команда даже выиграла архитектурный конкурс, а позже заняла третье место, а также разработала курс обучения и наставничество. В ходе обсуждения будет рассмотрено, как выбрать современную архитектуру данных для внутренних ИТ: определите, что означает архитектура данных сегодня, определите ключевую проблему, которую необходимо решить, и сравните варианты решения.
Архитектура данных ориентирована на бизнес, социально-технические аспекты и соответствие требованиям В отличие от архитектуры программного обеспечения, ориентированной на функциональность, современная архитектура данных ставит во главу угла бизнес-результаты, а не инструменты. Она организует процессы управления данными на предприятии — кто вводит данные, кому они принадлежат и кто решает, где, зачем и как долго они хранятся. В нем работа с данными рассматривается как социально‑техническая система, состоящая из людей и систем, которые должны взаимодействовать. Соответствие требованиям стало ключевым фактором, поэтому архитектура должна отвечать тому, что может быть собрано, где оно может находиться и для каких целей оно может быть использовано, при этом технологии рассматриваются в последнюю очередь.
Меняющийся смысл: от складов к озерам и управлению Понятие "архитектура данных" пересматривается каждые несколько лет. Основное внимание было уделено не моделированию и хранилищам, а озерам данных, а затем управлению корпоративными данными. Сегодня речь идет не столько о выборе технологий или разработке моделей, сколько о структурировании способов получения, стандартизации и использования данных в организации.
Раннее складирование: объединение источников для получения описательной информации На начальном этапе данные из таких систем, как CRM, были собраны в единое хранилище, чтобы ответить на вопрос "что произошло?" для бизнес-отчетности. Навыки моделирования были необходимы, поскольку объемы данных часто превышали то, с чем могли справиться простые инструменты. Целью была надежная оперативная отчетность для поддержки принятия решений.
Региональные отделения и слияния и поглощения меняют представление о предприятии Многочисленные региональные склады и приобретенные компании создали несовместимые архитектуры и показатели. Штаб-квартира не смогла согласовать отчеты по регионам или дочерним компаниям. Предприятию потребовалась консолидация — один из видов бизнеса, который масштабируется глобально по всем процессам и географическим регионам.
Hadoop Собирает централизованные данные и выявляет несогласованность Хранилища данных объединили все данные в одном месте, что позволило руководителям получать отчеты на уровне предприятия. Однако централизация выявила противоречия: финансовые показатели, показатели продаж и маркетинговые показатели расходились из-за различий в логике и кодах. Наглядность выявила проблему интеграции, а не устранила ее, что привело к стремлению к согласованности.
Многоуровневая интеграция и основные данные Стандартизируют достоверность Необработанные зоны собирали исходные данные, интегрированные уровни создавали согласованные варианты, а данные о потреблении обрабатывались кураторами. Основные данные, такие как стандартизированный список клиентов, стали основой, связывающей домены. Благодаря общим идентификаторам корпоративные отчеты и отчеты по доменам наконец-то были согласованы, демонстрируя, что интеграция и стандартизация, а не только хранение, решают проблему согласования.
Архитектура как разделение работы между командами и системами Центральный интегрированный уровень не может быть создан силами одной команды или даже одной физической системы. Архитектура решает, как распределять "пирог" — по горизонтали, вертикали или диагонали, — поэтому ответственность и границы четко определены. Реальная работа начинается после создания высокоуровневой картины: назначение владельца и интерфейсов, обеспечивающих параллельную доставку.
Расширьте сферу применения платформы Данных, отдельно интегрируйте управление Платформа данных охватывает хранение и управление данными. Возможности управления — каталогизация, качество и связанные с ними инструменты — интегрируются с платформой, но остаются отличными от нее. Среды обработки данных также не входят в сферу ее применения. Основное внимание по-прежнему уделяется организации потоков данных и структур.
Два варианта использования: Внутренняя аналитика и данные как продукт Один из вариантов - внутренние ИТ, где корпоративные процессы, такие как продажи и поддержка, требуют отчетности и анализа. Другой вариант ‑ когда данные представляют собой продукт, продаваемый клиентам, например, аналитика в колл‑центре или более ранняя работа с данными как с продуктом. Приведенный ниже анализ нацелен на внутренние потребности предприятия, которые отличаются от требований, предъявляемых к продукту.
Зрелость аналитики: Описательная, диагностическая, прогностическая, предписывающая Организации переходят от объяснения "что произошло" к "почему", затем к прогнозированию "что произойдет" и, наконец, к рекомендациям по действиям. Кадровое планирование в колл-центрах является примером прогностической аналитики, позволяющей оценить, сколько сотрудников требуется в смену. Предписывающая аналитика предлагает конкретные действия с ожидаемым эффектом, такие как изменение контента для улучшения поискового рейтинга. Немногие предприятия достигают предписывающего уровня; большинство из них колеблется между описательным и диагностическим, иногда предпринимая усилия по прогнозированию для конкретных задач.
Сделайте данные доступными для обнаружения, Понятными и ценными Данные должны быть доступны для поиска в каталоге с четким описанием и способом запроса доступа. Хранение должно быть целенаправленным: сохраняйте то, что представляет ценность, за исключением случаев, когда нормативные акты требуют длительного хранения. Важно доверие; пользователи должны быть уверены в правильности данных и результатов анализа. Безопасность должна обеспечивать защиту от несанкционированного доступа и ограничивать использование только теми целями, для которых были собраны данные.
Принятие решений и их исполнение: подотчетность, ответственность и проверяемость Кто-то должен решать, что собирать, где хранить, как долго хранить, кто может получить к этому доступ и как это будет использоваться. Кто-то другой должен выполнять эти решения и обеспечивать соблюдение правил хранения, доступа и использования. Команды по соблюдению требований определяют, что разрешено, и требуют доказательств соответствия практики политике. Аудиторы ожидают доказательств того, что собираются только разрешенные данные, хранятся в утвержденных местах, к которым имеют доступ уполномоченные лица, и используются только в заявленных целях.
Вариант: Многослойный монолит с необработанными, серебристыми и презентационными зонами Платформа разделена по горизонтали на уровни raw, "silver/curated" и "presentation". Самообслуживание BI переносит интерфейс с отчетов на модели данных, которые используют бизнес‑пользователи. Теперь инженеры разрабатывают эти модели, а архитекторы распределяют обязанности между несколькими командами. Этот подход направлен на обеспечение быстрой отчетности на основе структурированного конвейера.
Где появляются слоистые монолиты и как они оцениваются Эта закономерность часто проявляется на ранней стадии, когда финансовый директор занимается аналитикой на стороне, стремясь минимизировать расходы. Оценка охватывает затраты на внедрение и эксплуатацию, накладные расходы на координацию, безопасность/соответствие требованиям и многое другое. Простая схема оценки предполагает, что меньшая координация способствует повышению скорости, в то время как большая - безопасности.
Результаты применения многослойного монолита: Низкая стоимость, быстрый старт, хрупкая эволюция Затраты на внедрение и эксплуатацию невелики, а инвестиции в платформу практически отсутствуют. Время выхода продукта на рынок отличное, но взаимосвязь растет, увеличивая радиус действия и время выполнения изменений. Пути эволюции становятся неясными по мере размывания границ, что часто приводит к необходимости параллельной перестройки.
Риски монолита: Узкие места, пробелы в праве собственности и ограниченный доступ Уровни приема и интеграции становятся узкими местами, которые ограничивают масштабирование, в то время как витрины данных проще распределять. Права собственности размываются, поскольку данные хранятся на трех уровнях, поэтому исправления передаются от одной команды к другой. Функции требуют скоординированных изменений несколькими командами, что приводит к накладным расходам и размытым границам. Качество данных страдает из‑за того, что проблемы устраняются ниже по потоку, а не в источниках, наблюдаемость неясна внутри, а строгая безопасность ограничивает прямой доступ к данным и истинное самообслуживание.
Вариант: Вертикальные фрагменты домена с центральной платформой и управлением Система разделена на бизнес-области и поддерживается платформой, созданной офисом CDO. Центральное управление предоставляет основные данные и корпоративные политики. Команды, ориентированные на конкретные области, в рамках таких функций, как продажи или маркетинг, владеют своими данными, создают отчетность и следуют общим правилам, чтобы обеспечить согласованность корпоративного представления.
Результаты модели предметной области: Четкое владение, Лучшее качество, Новая координация Бизнес-подразделения рассматривают данные как источник энергии и становятся ответственными владельцами своих доменов, что повышает ценность и позволяет исправлять ошибки в источниках. Междоменные потребности требуют согласования и координации, особенно в области финансов. Затраты на внедрение и эксплуатацию невелики при ненулевых, но разумных затратах на платформу, а доставка ускоряется после установки благодаря меньшему радиусу действия и более четким интерфейсам для масштабирования и эволюции. Улучшается наблюдаемость и четкость границ, в то время как безопасность и соответствие требованиям ниже, чем в закрытом монолите, поскольку более широкий доступ требует обучения и дисциплины.
Соответствие Требованиям Является Реальным; Данные Должны Предоставляться Непосредственно Пользователям Законы и обязательства по их соблюдению существуют даже тогда, когда команды не обращают на них внимания, и системы должны учитывать эту реальность. Когда данные создаются непосредственно для конечных пользователей, возникает более высокая планка в области ИТ. Идеал выглядит по-настоящему гибким: пользователи и производители работают как одна команда и постоянно согласовывают результаты. Гармония возникает, когда решения формируются в точке создания и использования данных.
Создание Сети Данных Требует Культуры И Инвестиций; Многие Останавливаются Раньше Платформа распределенных данных (data mesh) редко подходит для внутренних ИТ-служб без исключительной преданности делу. Это требует значительных инвестиций в платформу и зрелой, ориентированной на данные культуры, в которой люди ежедневно полагаются на данные. Если организация все еще задается вопросом “зачем это делать”, значит, она не готова. Большинство успешных компаний останавливаются на более ранних, достаточно хороших архитектурах.
Нет Сетки Без Реорганизации; Начинайте Только С Бизнес‑Бай-Ина Как и микросервисы, mesh не может работать без реорганизации команд и распределения обязанностей. Рассматривать это как чисто техническую инициативу - ошибка. Единственная практическая точка зрения, которую можно увидеть на практике, - это рассматривать основные данные как продукты с версиями и соглашениями об уровне обслуживания. Но даже это тормозит, потому что первоначальные инвестиции велики, а время до получения первоначальной прибыли велико.
Экономика платформы: Автоматизация, Обработка данных И Управление Версиями Продуктов Создание и эксплуатация платформы mesh являются дорогостоящими и требуют интенсивной автоматизации. Практика DataOps и версионные выпуски данных являются обязательными условиями. Вместо совместного использования изменяемых наборов данных новые требования приводят к созданию новых продуктов данных. Каждый продукт имеет свой собственный жизненный цикл, при этом новые разработки и обновления управляются явно.
Для Получения Прибыли На Предприятии Необходим Широкий Охват Для внутренних предприятий убедительные примеры использования встречаются редко. Преимущества проявляются только в том случае, если значительная часть данных упакована в виде продуктов. Производство нескольких продуктов из сотен не продвинет дело с мертвой точки. Расстояние до первого значения остается значительным, пока не расширится охват.
Версионные релизы Сокращают радиус распространения, но ускоряют миграцию Изменения происходят быстро, потому что новые версии могут быть выпущены, пока потребители мигрируют в своем темпе. Ни один производитель не блокирует потребителя, и наоборот. Радиус распространения меньше, но усилия по миграции сохраняются. Эволюция за пределами этой модели неясна, поскольку такие платформы, как правило, становятся самоподдерживающимися экосистемами.
Масштабирование По Продуктам, А Не По Собраниям: Право собственности, API И Границы Команды разрабатывают индивидуальные продукты, четко заявляя о своей принадлежности. Затраты на координацию остаются низкими, поскольку все документируется и доступно через API. Данные остаются изолированными внутри продукта за согласованными интерфейсами. Интерфейсная компоновка отражает шаблоны микросервисов с помощью портала микроядра, который встраивает модули с помощью iframes или объединения модулей.
Управление Повышает Качество; Безопасность В Масштабах Страны Хрупка Публикация информационного продукта требует соответствия опубликованным стандартам и предоставления качественных показателей. Наблюдаемость, преемственность и удобство использования важны по своей сути. Безопасность и соответствие требованиям, однако, становятся сомнительными в масштабе, поскольку в системе много движущихся частей. Без строгого контроля система рискует получить хаотичный доступ и нарушения.
Объем данных формирует Технологию, а не Структуру Общий размер редко влияет на архитектурную структуру; вместо этого он влияет на выбор технологии. Чрезмерная ширина — миллионы таблиц — создает проблемы с организацией и каталогизацией. Архитектура должна соответствовать решаемой задаче, а клиенту требуется нечто большее, чем просто размер.
Использование И ИИ Влияют На Форму, А Не На Содержание Потребление определяет формат представления — например, схемы в виде звездочек или плоские таблицы для удобства использования. Суть остается прежней: данные должны быть понятными, высококачественными и своевременными. ИИ ожидает, что для получения надежных результатов будут использоваться те же свойства, что и у людей. Некачественные исходные данные приводят к некачественным решениям независимо от того, кто их использует.
Правильный Выбор Архитектуры Начинается С Бизнес‑Целей Настройте архитектуру в соответствии с целями компании. Выберите цель в развитии аналитики и работайте над ее достижением. Чем масштабнее цель, тем в большей степени оправдана архитектура. Разрабатывайте решения, которые бизнес хочет получать с помощью данных.
Культура Определяет Инвестиции в Данные Если руководители по умолчанию полагаются на интуицию, архитектура с большим объемом данных приносит мало пользы. Когда решения невозможно принять без данных, инвестиции оправданы. Сделайте данные доступными для обнаружения и заслуживающими доверия, чтобы люди могли быстро действовать на их основе.
Контекст соответствия Определяет выбор дизайна Такие режимы, как HIPAA, налагают строгие ограничения на обработку, хранение и переподготовку данных. В отличие от этого, общедоступные веб-данные имеют минимальные ограничения. Архитектура должна соответствовать строгим требованиям к обрабатываемым данным.
Рассматривайте Архитектуру Данных как Корпоративную Архитектуру Используйте концепцию корпоративной архитектуры для принятия решений, связанных с данными. Идеи об организационной эволюции и задачах ИТ, сформулированные Грегором Хопе, применимы непосредственно к вам. Архитектура данных является составной частью более широкой корпоративной архитектуры и должна развиваться в соответствии с ней.
Используйте Искусственный Интеллект Для Повышения Производительности, А Не Для Выбора Архитектуры Архитектурный выбор зависит от разговоров и постановки проблем, а не от чат-ботов. Искусственный интеллект помогает составлять документы, предлагать первоначальные варианты и подводить итоги длительных обсуждений в Jira и совещаний. Заметки о совещаниях и подведение итогов в Slack‑thread сокращают время при сохранении контекста. Создание прототипов с помощью таких инструментов, как Copilot, позволяет архитекторам работать на практике.
Ограничения государственного сектора разрушают классические хранилища данных Строгие ограничения на объем хранилища сводят на нет идею хранения всего в data‑lake. Отдавайте предпочтение проектам в стиле хранилища и оперативным распределенным хранилищам, таким как стеки на базе Hadoop или Kubernetes. Когда требуется платная замена MinIO, используйте S3‑совместимые варианты с открытым исходным кодом, такие как NooBaa. Выполняйте очистку при загрузке, отправляйте данные во временное хранилище и выполняйте задания последовательно, когда не хватает вычислений.
Подсчитайте Пропускную Способность Или Переформулируйте Требования Смоделируйте скорость ввода, пропускную способность обработки, объем памяти и временного хранилища. Если обработка не может опережать поступление, концепция неосуществима. Определите количество требуемых ресурсов и сравните их с тем, что у вас есть. Если математические расчеты не помогают, повторно обсудите частоту и объем обновления с предприятием.
Решите, Что Трудно Изменить; Вернитесь К Этому, Когда Реальность Изменится Избегайте детализации всего заранее. Делайте осознанный выбор в отношении элементов, которые трудно изменить, таких как базы данных и языки. При изменении условий пересматривайте решения и объясняйте последствия и сроки. Рефакторинг отражает изменение требований, а не сбой.
Перекрытие - Это Функция В Mesh; Моделируйте По Событиям Домена Рассматривайте продукты данных как независимые единицы — события, API или наборы данных, а не только как табличные модели. В домене call‑центра службы, ориентированные на источник, генерируют события Kafka без истории, в то время как агрегаты, основанные на событиях, восстанавливают историческое состояние. Одни и те же факты позволяют создавать отчеты в режиме реального времени, историческую аналитику и веб‑приложения в виде отдельных продуктов, которые должны оставаться согласованными. Предотвращайте циклические зависимости с помощью каталогизированного происхождения и управления, а архитекторы устанавливают границы.