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

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

В этой статье демонстрируется архитектура сетки данных в Google Cloud, вдохновленная отличным семинаром из двух частей, проведенным Самией Рахман от ThoughtWorks на Женщинах, которые кодируют в 2020 и 2021 годах, а также выступлениями команды DeliverHero об их сетке данных. вдохновенная установка.

Эта статья представляет собой набросок частей главы книги Сетка данных в действии в MEAP в Мэннинге, соавтором которой я являюсь. Считайте это кратким просмотром. И, конечно же, я буду рад отзывам, так как это сделает книгу намного лучше!

Ладно, хватит рекламы, приступим! Мы будем…

  1. Предоставьте эскиз архитектуры высокого уровня, используя пару воображаемых участников.
  2. Определите ключевые компоненты этой платформы
  3. Определите ключевые компоненты информационного продукта (это обычно трудно понять)
  4. Ознакомьтесь с типичными рабочими процессами для производителей и потребителей данных.
  5. А потом обсудить варианты/дополнения к этой архитектуре

Архитектура платформы данных с самообслуживанием

В нашей сетке данных есть пара участников.

  • Team Black – это команда разработчиков, которая также занимается созданием и обслуживанием информационных продуктов.
  • Команда White — это группа специалистов по обработке и анализу данных, которая создает и использует продукты данных.
  • Команда Grey владеет платформой данных самообслуживания. В этом случае команда Gray предоставляет настраиваемый шаблон терраформирования.
  • Наконец, потребители: у нас есть несколько бизнес-аналитиков и система рекомендаций, которые в основном потребляют данные.

На рисунке ниже изображена архитектура в первой версии. Мы рассмотрим несколько дополнений в следующем разделе. Посмотрите, как может работать техническая настройка продуктов Google Cloud Platform.

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

Идентификация компонентов платформы

Ключевыми компонентами платформы являются:

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

Первые два являются техническими компонентами.

В нашей архитектуре команда разработчиков платформы Gray предоставляет настраиваемый шаблон терраформирования. Они решили поместить последний шаблон в репозиторий Git. В этом случае репозиторий git вместе с его файлом README становится интерфейсом платформы. Шаблон становится ядром платформы.

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

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

Идентификация компонентов информационного продукта

Все продукты данных используют общие инструменты, основанные на Cloud Dataflow и связанном с ним временном хранилище. Это позволяет команде легко создавать продукты данных. Облачные потоки данных позволяют командам создавать конвейеры, которые выводят продукты данных на Java, Python или SQL.

В продукте данных, принадлежащем команде Black, команда решила напрямую подключиться к источникам, будь то PubSub или какой-либо набор данных BigQuery. В этом случае порт ввода данных, интерфейс, который передает данные в продукт данных, становится конвейером Cloud Dataflow. Его исходными источниками данных являются PubSub и набор данных BigQuery.

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

Поскольку эта платформа использует общую службу BigQuery, очень важно включить одну конкретную учетную запись службы Google в каждый продукт данных. Это позволяет управлять разрешениями на уровне продукта данных.

Первый продукт команды Уайта использует корзину Google Cloud Storage в качестве входного порта. Это ведро позволяет пользователям загружать файлы в предопределенной схеме. При загрузке конвейер потока данных начинает выполнять свою работу и преобразует данные в новый продукт данных внутри BigQuery.

Как видите, порты данных — очень неоднозначное понятие. Здесь у нас есть порт ввода push в виде корзины GCS, порт ввода pull в виде потока данных и восходящих наборов данных. Наконец, во втором продукте данных команды Уайта мы объединяем два продукта данных и снова берем в качестве входного порта Dataflow вместе с двумя вышестоящими продуктами данных, созданными первыми.

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

Рабочие процессы

Производители данных, желающие создать новый продукт данных, перейдут к интерфейсу платформы, репозиторию GitHub. Они читают README, загружают новейший шаблон terraform и применяют его для создания нового стека для своего нового продукта данных. Делая это, они, например, настраивают, хотят ли они использовать входное хранилище или нет.

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

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

Как объяснялось ранее, это все еще очень минимальная платформа.

Варианты для этой архитектуры

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

Другой набор вариаций изображен на картинке ниже. На этом рисунке показан только контекст платформы с возможными надстройками, которые можно использовать без определенной последовательности.

Например, инструмент под названием DataHub можно использовать и напрямую подключить к BigQuery, чтобы он служил центральным каталогом данных для распределенного набора продуктов данных. Этот компонент может работать изолированно без добавления каких-либо дополнительных компонентов. Это помогло бы потребителям быстро находить информационные продукты.

Во-вторых, платформа может быть дополнена «популярными наборами данных» или «наиболее часто используемыми данными» статистикой путем доступа к журналам BigQuery. Это можно сделать, используя GCP Logging и настроив Logging Router вместе с Log Sink в виде корзины GCS. Из корзины GCS пользовательский компонент может вычислить эту статистику и передать ее в DataHub.

В-третьих, другой пользовательский компонент с доступом ко всем продуктам данных может выполнять пользовательские проверки качества данных для компонентов, подсчитывая NaN или запуская пользовательские проверки, зарегистрированные командой, владеющей продуктами данных. Например, команда, надежная для продукта данных «клиент», может убедиться, что номера клиентов внутри этого продукта всегда в правильном формате. Затем этот тест и результат также будут представлены в DataHub.

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

Связь с идеями сетки данных

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

Принцип платформенного мышления заключается в том, чтобы облегчить жизнь всех участников платформы, не ограничивая при этом их свободу. Эта архитектура позволяет другим командам снимать нагрузку с их плеч. Например, это может иметь место, если все команды разработчиков внутри компании используют GCP и являются активными пользователями общих сервисов, таких как PubSub и BigQuery. В этом случае шаблон поможет командам быстро получить доступ к этим источникам с помощью потока данных и превратить их в наборы данных для продуктов данных.

В варианте, описанном выше, группы по производству данных, скорее всего, зарегистрируют новые тесты качества данных в центральном репозитории, чтобы затем позволить центральному компоненту качества запустить их. Это может стать узким местом, потому что это может привести к запросам на PR, которые требуют одобрения, и к отказам. В таком случае проверку качества следует сделать частью самой информационной продукции. Затем только результаты проверок будут отображаться, скажем, в местоположении GCS и извлекаться центральным компонентом для отправки в DataHub.

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

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

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

Краткая информация о настройке GCP

Эта архитектура платформы использует общие облачные сервисы, в основном встроенные в среду GCP. Он использует несколько компонентов, не относящихся к GCP, Git и Terraform, а также в вариациях пользовательского кода и DataHub.

Он предоставляет производителям данных набор инструментов для преобразования данных, но только один стандартизированный порт данных. Однако порты данных могут быть легко расширены для использования Google Cloud PubSub и Google Cloud Storage, а также предоставляют вам широкий спектр целевых форматов и удовлетворяют потребности большинства потребителей.

Установку можно перенести с небольшими отличиями на других крупных облачных провайдеров AWS и Azure. Поскольку они будут выглядеть очень похоже, мы решили не отображать их здесь как сопоставление 1–1.

Если вам понравилась эта статья, оставьте комментарий!

Заинтересованы в том, как создать отличные компании, работающие с данными, отличные продукты с большими объемами данных, стать отличной командой по работе с данными или как создать что-то замечательное с открытым исходным кодом? Тогда подумайте о том, чтобы присоединиться к моей бесплатной рассылке «Три точки данных по четвергам». Он стал надежным ресурсом для стартапов, венчурных капиталистов и лидеров данных.