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

В любой SaaS-компании в любой момент генерируется множество данных, будь то данные, относящиеся к клиентам, маркетингу, продажам или человеческим ресурсам. или лучше обучать наши модели ML/AI.

Проблема

Ниже приведены некоторые из основных бизнес-задач, которые мы пытаемся решить с помощью платформы данных:

  1. Собирайте показатели использования наших клиентов для выставления счетов.
  2. Инженеры машинного обучения хотят использовать значимые метаданные.
  3. Специалист по данным хочет получить представление о заказах продаж.
  4. Маркетингу нужны текущие рыночные тенденции для разработки целевых маркетинговых стратегий.
  5. Финансы и бухгалтерский учет хотят упростить сбор и прогнозирование доходов.
  6. Руководству высшего звена нужны панели отчетности с ключевыми показателями эффективности.
  7. Консолидация журналов приложений из микросервисов.

Решение

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

  1. Будьте устойчивыми, масштабируемыми и экономичными.
  2. Данные должны быть достоверными и доступными в (почти) реальном времени.
  3. Данные должны быть в безопасности.
  4. Платформа расширяет возможности пользователей посредством самообслуживания.

Платформа данных

Наша платформа данных состоит из множества компонентов, давайте рассмотрим каждый из них.

Озеро данных

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

Производный магазин

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

Потоковая передача

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

Уровень отчетов

Уровень отчетности используется аналитиками данных и инженерами бизнес-аналитики для создания отчетов и информационных панелей для своих вариантов использования. Здесь снова уровень отчетов отделен от производного хранилища, мы можем подключить любое приложение, которое захотим. Думайте о Metabase, Microsoft BI, Looker как о некоторых видных именах в этой области, мы предоставляем Metabase в качестве уровня отчетности для наших конечных пользователей.

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