Современное хранилище данных мертво?

Хранилище данных является основой современного стека данных, поэтому оно привлекло мое внимание, когда я увидел, как глава отдела данных Convoy [Чад Сандерсон] (https://www.linkedin.com/in/chad-sanderson/) заявил: « хранилище данных не работает” на Линкедин.

Конечно, Чад имеет в виду не технологию, а то, как она используется.

По его мнению, проблемы с качеством данных и удобством использования возникают из-за общепринятой передовой практики «сброса» данных в хранилище для последующей обработки и преобразования в соответствии с потребностями бизнеса. Это не противоречит общим усилиям таких поставщиков, как Snowflake и Databricks, направленных на то, чтобы их клиенты были эффективными (иными словами, экономили деньги и ресурсы) при хранении и потреблении.

Независимо от того, согласны ли вы с подходом Чада, описанным ниже, нельзя оспаривать то, что его мнение вызвало огромное количество споров.

«Один лагерь злится на меня, потому что они думают, что в этом нет ничего нового, и это требует длительных ручных процессов и архитекторов данных с 30-летним опытом. Другой лагерь злится на меня, потому что их современный стек данных принципиально не настроен таким образом, и они не так строят свои информационные продукты», — сказал Чад.

Я позволю вам решить для себя, является ли «неизменяемое хранилище данных» (или активный или пассивный ETL) правильным путем для вашей группы данных.

В любом случае, я убежден, что для продвижения нашей отрасли вперед потребуется нечто большее, чем обзоры таких технологий, как хранилища данных и [платформы для наблюдения за данными] (https://www.montecarlodata.com/blog-what-is-data- наблюдаемость/), но откровенные обсуждения и уникальные взгляды на то, как их развернуть.

Я позволю Чаду взять это отсюда.

Как неизменяемое хранилище данных сочетает в себе масштаб и удобство использования

Взгляд Чада Сандерсона

Современный стек данных имеет множество вариантов, но хранилище данных является его основополагающим компонентом. Чтобы упростить:

• Данные извлекаются через пассивные конвейеры (на самом деле просто «E» в ETL) и выгружаются в…

• Хранилище данных, где они обрабатываются и хранятся до того, как они будут…

• Преобразуется в формат, необходимый потребителям данных для…

• Специальное использование, такое как аналитические панели, модели машинного обучения или активация в системах записей, таких как Salesforce или Google Analytics…

• С такими технологиями или процессами, как наблюдаемость данных, управление, обнаружение и каталогизация, работающими в стеке.

Прежде чем углубляться в проблемы этого подхода и предлагаемую альтернативу, стоит изучить, как мы пришли к тому, что мы определяем как «современный стек данных».

Как мы здесь оказались?

На заре данных с пионерами, такими как [Билл Инмон] (https://www.linkedin.com/in/billinmon), оригинальный ETL ([извлечение, преобразование, загрузка] (https://hackernoon.com /how-to-design-scalable-and-maintainable-etls-bfd1664211a7)) процесс включал извлечение из источника и его преобразование перед размещением в хранилище данных.

Многие предприятия продолжают работать таким образом и сегодня. Для крупных компаний, где качество данных имеет первостепенное значение, этот процесс включает ручную, интенсивную структуру управления с тесной связью между инженерами данных и архитекторами данных, внедренными в разные области, чтобы быстро использовать данные для оперативного анализа.

Технологические гиганты, такие как Google, Facebook и другие, отказались от этого процесса и начали сбрасывать практически все в хранилище данных. Окупаемость логической организации данных была не так высока для быстрорастущих стартапов, как этот гораздо более быстрый и масштабируемый процесс. Не говоря уже о том, что загрузку («L» в ELT) стало намного проще интегрировать в облако.

Попутно популярные [инструменты преобразования] (https://hackernoon.com/solving-data-integration-the-pros-and-cons-of-open-source-and-commercial-software-523d3e24) сделали преобразование данных в склад проще, чем когда-либо. Модульный код и значительно сокращенное время выполнения сделали модель ETL радикально менее болезненной… настолько, что использование популярных инструментов преобразования расширилось от инженеров данных до потребителей данных, таких как специалисты по данным и аналитики.

Казалось, что мы нашли новую лучшую практику и были на пути к стандартизации де-факто. Настолько, что предложение альтернативы вызвало бы быструю и сильную реакцию.

Проблема с пассивным ETL или преобразованиями на складе

![Современная архитектура хранилища данных создает проблемы на многих уровнях. Изображение предоставлено Чадом Сандерсоном.] (https://cdn.hackernoon.com//images/yDiiZrP5VkgnvI5vdWkH3Sfer452-2022-04-14T20:02:35.043Z-cl1zfhhur00570as665bec4ds)

Существует несколько проблем с архитектурой и процессом, которые в значительной степени зависят от преобразования данных после их поступления в хранилище данных.

Первая проблема — разрыв, настоящая пропасть, которая возникает между потребителем данных (аналитиками/специалистами по данным) и инженером данных.

Менеджер проекта и инженер данных будут создавать конвейеры выше по течению от аналитика, которому будет поручено ответить на определенные бизнес-вопросы внутренних заинтересованных сторон. Аналитик неизбежно обнаружит, что данные не отвечают на все его вопросы и что руководитель программы и инженер по данным ушли дальше.

Вторая проблема возникает, когда ответ аналитика состоит в том, чтобы пойти прямо на склад и написать хрупкий SQL-запрос из 600 строк, чтобы получить ответ. Или специалист по данным может обнаружить, что единственный способ построить свою модель — это извлекать данные из производственных таблиц, которые служат деталями реализации сервисов.

Данные в рабочих таблицах не предназначены для аналитики или машинного обучения. На самом деле, сервисные инженеры часто прямо заявляют, что НЕ должны принимать критические зависимости от этих данных, учитывая, что они могут измениться в любое время. Тем не менее, наш специалист по данным должен выполнять свою работу, поэтому они все равно ее выполняют, а когда таблица изменяется, все ломается ниже по течению.

Третья проблема заключается в том, что когда ваше хранилище данных представляет собой свалку, оно становится свалкой данных.

[Ранее исследование Forrester] (https://www.forrester.com/blogs/hadoop-is-datas-darling-for-a-reason/), проведенное в эпоху Hadoop, показало, что от 60% до 73% всех данных в предприятие не используется для аналитики. Более [недавнее исследование Seagate] go-unlevered-pr-master/) обнаружил, что 68% данных, доступных предприятию, остаются неиспользованными.

В результате специалисты по данным и [аналитики] (https://hackernoon.com/what-are-the-best-data-analytics-tools) тратят слишком много времени на поиск контекста в стоге сена с чрезмерно обработанным производственным кодом. Как инженеры данных, мы должны делать упор на удобство использования данных в дополнение к их качеству.

Если ваши пользователи не могут надежно найти и использовать то, что им нужно, в вашем текущем хранилище данных, в чем смысл?

Другой подход: введение неизменяемого хранилища данных

Концепция неизменяемого хранилища данных (также называемая активным ETL) предполагает, что хранилище должно быть представлением реального мира через данные, а не запутанный беспорядок случайных запросов, сломанных конвейеров и дублированной информации.

Есть пять основных столпов:

• Бизнес нанесен на карту и назначены владельцы. Чтобы предприятия действительно извлекали выгоду из огромных объемов данных, которыми они обладают, командам необходимо сделать шаг назад и семантически смоделировать свой бизнес, прежде чем определять сущности и события с помощью кода для явной цели аналитики. Это может быть повторяющийся процесс, начиная с наиболее важных элементов бизнеса.

Диаграмма отношений сущностей (ERD) — это карта бизнеса, основанная на РЕАЛЬНОМ мире, а не на том, что существует сегодня в хранилище данных или производственных базах данных. Он определяет критические объекты, их отношения (количество элементов и т. д.) и действия в реальном мире, которые указывают на то, что они взаимодействовали. Для каждой сущности и события устанавливается технический владелец. Сквозная автоматическая родословная может помочь установить ERD и сделать его действенным.

• Потребители данных заранее определяют свои потребности, и заключаются контракты. Возможно, самым спорным моментом является то, что данные должны всплывать из потребностей бизнеса, а не просачиваться из неструктурированных конвейеров. Вместо того, чтобы аналитики данных и ученые прочесывали пыльные полки вашего хранилища, чтобы увидеть, есть ли набор данных, достаточно близкий к тому, что им нужно, никакие данные не поступают в хранилище, если они не будут предварительно запрошены и определены потребителем данных.

Никакие данные не поступают в хранилище без бизнес-вопроса, процесса или проблемы. Все специально создано для выполнения задачи.

Крайне важно, чтобы этот процесс был простым, поскольку потребности в данных постоянно меняются, а увеличение разногласий будет угрожать внедрению. В Convoy выполнение нового контракта занимает минуты или часы, а не дни или недели.

Затем пришло время составить контракт данных, который представляет собой соглашение между бизнес- и инженерными руководителями о том, какой должна быть схема события/сущности, а также данные, которые больше всего необходимы для того, чтобы этот актив был наиболее эффективным. Например, возможно, в существующем событии inboundCall отсутствует OrderID, что затрудняет привязку телефонных звонков к выполненным заказам.

SLA, SLI и SLO — это один из типов [договора о данных, который вы можете применить] (https://www.montecarlodata.com/blog-one-sla-at-a-time-our-data-quality-journey-at- red-digital/) к этой модели управления изменениями и согласования с заинтересованными сторонами.

• Рецензируемая документация в активной среде. Точно так же, как нам нужен процесс рецензирования кода (GitHub) или UX (Figma), который попадает в производство, должен быть эквивалент для активов данных. Однако правильный уровень абстракции для этого обзора — не код, а семантика.

Этот процесс проверки должен иметь тот же результат, что и запрос на вытягивание GitHub — контроль версий, подписание соответствующих сторон и т. д. — и все это обрабатывается через облако. Применяя современные облачные технологии, мы можем ускорить старые процессы, сделав их гораздо более жизнеспособными даже для самых быстрорастущих интернет-компаний.

Существует место для каталогов данных в качестве поверхности определения до хранилища данных, но проблема заключается в том, что у потребителей данных нет кнута и пряника, чтобы поддерживать метаданные в актуальном состоянии. Каков стимул для специалиста по данным, который использует процесс ELT и заканчивает свою модель, возвращаться и документировать свою работу?

• Данные передаются в хранилище в предварительно смоделированном виде, как это определено в контракте. Преобразования происходят вверх по течению от уровня потребления (в идеале в сервисе). Затем инженеры реализуют контракты данных в своей службе. Данные передаются в хранилище данных, и метаданные моделирования в идеале могут быть автоматически объединены и классифицированы.

• Упор делается на предотвращение потери данных, а также на обеспечение наблюдаемости, целостности, удобства использования и управления жизненным циклом данных. Шаблон исходящих транзакций используется для обеспечения того, чтобы события в производственной системе соответствовали событиям в хранилище данных, в то время как шаблон обработки журналов и смещений (который мы широко используем в Convoy -offsets-near-real-time-elt-with-apache-kafka-snowflake-473da1e4d776)) защищает от потери данных. Вместе эти две системы обеспечивают сохранение данных в полной целостности, поэтому неизменяемое хранилище данных является прямым представлением и источником достоверной информации о том, что происходит в бизнесе.

Качество данных и удобство использования требуют [двух разных подходов] (https://hackernoon.com/frontend-vs-backend-developers-all-you-need-to-know-5u3e3772). Качество данных по большей части является технической проблемой. Подумайте о «бэкэнд»-инжиниринге. С другой стороны, удобство использования данных — это инженерная задача «front-end», которая требует того же набора навыков, который используется для создания отличного клиента. опыт. Наконец, неизменяемое хранилище данных не подходит для соревнований по измерению петабайтов и извлечению вашей статистики больших данных. Устаревание и обслуживание так же важны, как и подготовка.

Этот подход использует преимущества технологии для достижения лучшего из обоих миров. Управление и ориентированный на бизнес подход традиционных подходов со скоростью и масштабируемостью, присущими современному стеку данных.

Как работает неизменяемое хранилище данных. Обработка данных как API.

![Уровни неизменяемого хранилища данных. Изображение предоставлено Чадом Сандерсоном.

Начнем с обзора полного стека, связанного с неизменяемым хранилищем данных.

1. Описательный уровень: В отличие от традиционных хранилищ, описательный уровень перемещает бизнес-логику выше уровня сервисов и ставит потребителя данных на место водителя. Потребитель может предоставить свои требования без необходимости технических навыков, поскольку инженер данных является важным требованием для переводчика кода. Эти контракты могут храниться в каталоге данных или даже в общем хранилище документов.

2. Хранилище данных: Хранилища функционируют в основном как «витрина данных» и базовый уровень вычислений.

3. Семантический уровень: потребители данных создают продукты данных, которые проверяются и передаются бизнесу. Активы на семантическом уровне должны быть определены, версионированы, проверены, а затем доступны через API для использования на прикладном уровне.

4. Прикладной уровень. Здесь данные используются для выполнения некоторых бизнес-функций, таких как эксперименты, машинное обучение или аналитика.

5. Сквозная поддержка: Решения, которые поддерживают операции с данными в стеке данных, такие как наблюдаемость данных, каталоги, тестирование, управление и многое другое. В идеале иметь идеальные, предварительно смоделированные, высоконадежные данные, как только они попадут в хранилище, но вам все равно нужно учитывать все перестановки, которые может предложить вам реальный мир (и иметь механизмы принудительного исполнения, когда процессы выходят за пределы).

Хранилище неизменяемых данных само по себе предназначено для потоковой передачи — проще перейти от потоковой передачи к пакетным данным, чем наоборот, — и поэтому поддерживается тремя различными типами API.

• Semantic Events API: этот API предназначен для семантических реальных событий уровня обслуживания, которые являются основными строительными блоками компании, а не событий из интерфейсных приложений. Например, в случае с Convoy это может быть, когда отправление создается или отправляется в режим ожидания. События из реального мира встроены в код сервиса, а не в SQL-запросы.

• API абстракции CRUD: потребителям данных не нужно видеть все производственные таблицы, особенно когда они просто представляют собой детали реализации службы данных, которую они используют для получения информации или принятия решений. Вместо этого, когда свойства ресурса данных в производственной таблице обновляются, оболочка API или уровень абстракции (например, dbt) раскрывает концепции CRUD, которые имеют смысл для потребителей данных в хранилище — например, независимо от того, данные свежие или объем строки находится в пределах ожидаемых пороговых значений.

• Frontend API: существует множество инструментов, которые уже обрабатывают определение и эмиссию внешних событий, например Snowplow, Mixpanel и Amplitude. При этом некоторые внешние события достаточно важны, поэтому командам необходимо иметь возможность обеспечить их доставку и целостность, используя длинный конвейер смещения. В некоторых случаях внешние события имеют решающее значение для рабочих процессов машинного обучения, и «достаточно близкие» системы просто не подходят.

Также должен быть уровень сопоставления, который находится за пределами хранилища, когда что-то меняется (возможно, один сервис должен стать многими) или если схема, которую имеет в виду специалист по данным, не соответствует тому, что происходит в реальном мире.

Сопоставление должно выполняться либо перед хранилищем через потоковую базу данных, либо в самом хранилище. На этом уровне BI-инженер сопоставляет то, что получается в результате разработки, с тем, что нужно потребителю данных, что может быть автоматизировано для создания [киосков данных Кимбалла] (https://www.astera.com/type/blog/data-warehouse). -понятия/).

У неизменяемых хранилищ данных тоже есть проблемы. Вот несколько возможных решений.

Я не заблуждаюсь, что неизменяемое хранилище данных — панацея. Как и у любого подхода, у него есть свои плюсы и минусы, и, конечно, он подходит не для каждой организации.

Подобно сетке данных и другим масштабным инициативам в области архитектуры данных, неизменяемое хранилище данных является идеальным состоянием и редко реализуется в реальности. Достижение цели или попытка ее достижения — это путешествие, а не пункт назначения.

Проблемы, которые следует рассмотреть и смягчить:

• Первоначальные затраты на определение описательного слоя

• Работа с объектами без явного права собственности

• Внедрение новых методов для быстрого экспериментирования

Хотя определение описательного уровня требует затрат, его можно значительно ускорить с помощью программного обеспечения и выполнять итеративно, расставляя приоритеты по наиболее важным бизнес-компонентам.

Это должно быть совместным проектным проектом с участием инженеров по данным, чтобы предотвратить распространение ответственности за качество данных между распределенными потребителями данных. Ничего страшного, если у вас не получится с первого раза, это итеративный процесс.

Обработка сущностей без четкого владения может быть сложной проблемой управления (и той, которая часто ставит в тупик сторонников сетки данных). Как правило, в компетенцию группы обработки данных не входит решение этих вопросов на стороне бизнеса.

Если есть основная бизнес-концепция, которая охватывает несколько команд и создается монолитом, а не микросервисом, лучший способ продвижения вперед — иметь надежную систему проверки и специальную команду, готовую внести изменения.

Инженерам данных по-прежнему можно позволить экспериментировать и обеспечить гибкость, не ограничивая рабочий процесс.

Один из способов сделать это — использовать отдельный промежуточный слой. Однако данные API из этих промежуточных областей не должны использоваться ниже по течению или между внешними командами.

Суть в том, что когда вы переходите от эксперимента к производству или делаете его доступным для пограничной группы, он должен пройти тот же процесс проверки. Как и в разработке программного обеспечения, вы не можете внести изменения в код без проверки только потому, что хотите двигаться быстрее.

Желаем вам удачи на пути к обеспечению качества данных

Существует множество вариантов современного стека данных, и как отрасль мы все еще проходим этап экспериментов, чтобы понять, как лучше всего организовать нашу инфраструктуру данных.

Ясно то, что мы быстро движемся к будущему, в котором более важные, внешние и сложные продукты будут «питаны» от хранилища данных.

Независимо от выбранного подхода, это потребует от нас, как специалистов по данным, повышения наших стандартов и удвоения наших усилий для получения надежных, масштабируемых и пригодных для использования данных. Качество данных должно лежать в основе всех хранилищ данных, независимо от их типа.

Суть с моей точки зрения: когда вы строите на большом аморфном фундаменте, все ломается, и его трудно найти. И когда вы его найдете, может быть трудно точно понять, что это за «вещь».

Неизменный или нет, может быть, пришло время попробовать что-то новое.

Также опубликовано Здесь