Анализ моделей приема/потребления, включая PoC в дельте озера

1. Введение

Многие компании рассматривают возможность создания Enterprise Data Lake. Идея состоит в том, чтобы хранить данные в централизованном хранилище. Основными заинтересованными сторонами озера данных являются следующие две организации:

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

В этом сообщении блога в главе 2 обсуждаются четыре различных шаблона приема данных. Впоследствии в главе 3 подробно рассматриваются два шаблона потребления. В главе 4 обсуждается проверка концепции с использованием ADF и delta lake с использованием этого репозитория git adf-deltalake-ingestion-consumption, см. также рисунок ниже. Наконец, в главе 5 делается вывод.

2. Производитель данных: шаблоны приема

В этой главе различаются четыре типа моделей поглощения с использованием следующих двух параметров:

  • Необработанные данные по сравнению с агрегированием на конец дня: в случае использования необработанных данных все исходные данные передаются для таргетинга. В случае использования конца дня исходные данные агрегируются в осмысленной форме для таргетинга.
  • Моментальные снимки в сравнении с разностными: в случае использования моментальных снимков все исходные данные передаются в целевое каждый день. В случае использования дельт в целевые передаются только измененные исходные данные.

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

В следующих подпунктах шаблоны обсуждаются с плюсами и минусами.

2.1 Шаблон P1: необработанные данные — моментальный снимок

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

Анализ «за» и «против» выглядит следующим образом:

  • (pro) Самый простой шаблон для производителя данных; Нужно делать только дамп данных, не обязательно отслеживать изменения
  • (против) Невозможно для больших наборов данных; дорого отправлять набор данных каждый день. Большой набор данных также будет иметь удар по производительности (часы копирования). Это справедливо и для резервных копий.
  • (против) Потребитель данных должен отслеживать изменения. Поскольку потребители данных обычно имеют меньше знаний о данных, чем производители данных, это может быть подвержено ошибкам. Это может быть особенно сложно, когда данные копируются в собственную среду собственных потребителей (в случае, если копирование не выполняется и используется виртуализация данных, может помочь дельта-озеро).

2.2 Шаблон P2: необработанные данные — дельта

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

Анализ «за» и «против» выглядит следующим образом:

  • (pro) Более эффективный паттерн. Нет затрат на отправку больших наборов данных, производительность, вероятно, лучше, меньше вероятность ошибок/тайм-аутов при копировании больших наборов данных.
  • (против) Потребитель данных должен иметь доступ ко всем предыдущим приращениям данных. В случае отсутствия одного приращения набор данных поврежден.
  • (pro) Потребитель данных может легко идентифицировать изменения и вносить обновления в своей среде. Дельты также легко обрабатываются потоками данных ADF и дельта-озером.

2.3 Шаблон P3: конец дня — моментальный снимок

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

  • Потребители заинтересованы только в конечных результатах (и НЕ заинтересованы в N мутациях, которые приводят к этому конечному результату)

Для примера набора данных может быть так, что потребителей интересует только total_amount карты, см. ниже.

Анализ «за» и «против» выглядит следующим образом:

  • (против) происходит потеря данных, поскольку потребителям доступны только агрегированные данные.
  • (pro) шаблон данных может быть более эффективным, например, в случае, если потребители данных заинтересованы только в конечных результатах, а не в N мутациях, которые приводят к конечному результату.

2.4 Паттерн P4: конец дня — дельта

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

В основном тот же анализ плюсов и минусов применим для шаблона 3 и шаблона 4. Разница лишь в том, что дельты могут быть более эффективными, если агрегации все еще велики.

2.5 Заключение

Все четыре шаблона имеют свои плюсы и минусы. Однако для стандартизации озера корпоративных данных рекомендуется использовать Шаблон P2: необработанные данные — дельта по умолчанию. Причины следующие:

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

3. Потребитель данных: модели потребления

В этой главе обсуждаются две различные модели потребления:

  • Копировать данные: потребитель копирует данные из озера данных в свою среду.
  • Виртуализация данных: потребитель использует данные непосредственно в озере данных.

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

3.2 Шаблон C1: виртуализация данных

В шаблоне виртуализации данных потребитель запрашивает непосредственно озеро данных, и данные не копируются в его собственную среду.

  • (pro) Единый источник достоверной информации, дубликаты данных не создаются
  • (pro) Простая модель для потребителей. Это особенно верно, если потребители не обладают достаточными техническими знаниями и просто хотят создавать отчеты (Power BI).
  • (pro) Delta Lake можно использовать для упрощения запросов к учетной записи хранения с помощью SQL.
  • (против) Невозможно для команд с жесткими требованиями к производительности (SLA)
  • (против) Может быть сложно объединить данные озера данных предприятия с данными, которые не являются частью озера данных (например, данные, находящиеся в собственной среде SQL потребителя).

3.2 Шаблон C2: копирование данных

В шаблоне копирования данных потребитель выгружает данные из озера корпоративных данных в свою собственную среду.

  • (pro) Потребитель имеет полный контроль над данными. Это особенно важно, если у клиента есть строгие требования к производительности (обслуживание веб-сайта 24x7) или строгие SLA (команда, обслуживающая озеро данных, может быть недоступна для вопросов в 03:00).
  • (против) Копирование может занять много времени, особенно если большие наборы данных должны быть скопированы в собственную среду потребителя.
  • (против) Потребитель должен иметь технические знания для настройки собственной среды (ADF, базы данных, сеть и т. д.).

3.3 Заключение

Оба шаблона имеют свои плюсы и минусы. Однако для стандартизации озера данных предприятия рекомендуется использовать Шаблон C1: виртуализация данных по умолчанию. Это можно объяснить следующим образом:

  • Это предотвращает ненужное дублирование данных и является наиболее экономичным.
  • Озеро Дельта также можно использовать для упрощения потребления данных, что будет подробно рассмотрено в следующей главе.
  • Если используется дельта-озеро, а потребитель все еще хочет скопировать данные в свою среду, для копирования данных из дельта-озера можно использовать ADF.

4. ADF, Delta Lake и Spark: доказательство концепции

В этой главе доказательство концепции построено с использованием следующей архитектуры:

  • Производитель данных. Данные из SQLDB передаются с помощью потоков данных ADF в дельта-озеро. Данные принимаются с использованием четырех шаблонов, описанных выше (необработанные данные и агрегированные данные, полные моментальные снимки и дельта-инкременты).
  • Потребитель данных.После поступления данных в delta lake потребители могут запрашивать данные с помощью Databricks и записных книжек Synapse с помощью Spark. Если потребитель хочет скопировать данные в свою среду, создаются два конвейера ADF, которые могут копировать моментальный снимок или последнюю дельту в свою собственную среду.

См. также изображение ниже:

Проект можно найти в репозитории git adf-deltalake-ingestion-consumption. Выполните следующие шаги для запуска PoC:

  1. Замените переменные и запустите scripts/deploy_resources.sh для развертывания ADF и deltalake.
  2. Запустите разные конвейеры производителей для приема данных в дельта-озеро.
  3. Тип потребителя 1: создайте рабочую область Databricks или рабочую область Synapse и запустите notebooksдля запроса данных в озере дельты.
  4. Тип потребителя 2: запуск конвейеров потребителей для использования данных в собственной учетной записи хранения.

5. Вывод

Многие компании рассматривают возможность создания Enterprise Data Lake. Основными заинтересованными сторонами озера данных являются производители и потребители данных. Производители данных обычно ищут способ легкого приема данных, тогда как производители данных — это сущность, которая создает ценность для бизнеса из данных. В этом сообщении в блоге утверждается следующее:

  • Производители должны обрабатывать данные в озере данных и делать это дельтами (инкрементами). Причина в том, что необработанные данные предотвращают потерю данных, а инкременты экономически эффективны и масштабируемы.
  • Потребители должны запрашивать данные напрямую из озера данных и создавать там продукты данных. Причина в том, что это предотвращает дублирование данных и является экономически эффективным. Возможным исключением является то, что когда потребителям требуется более высокая производительность/более высокие SLA (например, обслуживание круглосуточного веб-сайта), данные могут быть скопированы в собственную среду.
  • Дельта-озеро может помочь потребителям легко запрашивать данные, тогда как фабрика данных поддерживает дельта-приемник, который может помочь производителям автоматически добавлять данные в формате дельта-озера. Это реализовано на практике в этом репозитории git: adf-deltalake-ingestion-consumption