Что такое dataCraft Core?

В рамках этого слоя объединяются в одну таблицу все стримы, которые есть для комбинации источник+пайплайн, за исключением пайплайнов Registry. Например, у AppMetrica для пайплайна events 5 стримов: deeplinks, events, install, screen_view и sessions_starts. На этом слое все они объединяются в таблицу join_appmetrica_events.

Помимо этого, перед объединением на этом же слое производится предобработка данных:

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

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

• в Яндекс Метрике поле с id кампании называется ‘CampaignId’;
• в VK Ads поле с id кампании называется ‘id’.

Оба поля нужно переименовать одинаково, в нашем случае как ‘adId’. Еще одно важное действие на слое Join — добавление новой колонки __link, содержащей название линка, к которому относятся данные. Этот столбец понадобится на этапе Hash.
Сейчас этап join полностью автоматизирован в dataCraft.
Макрос: {{ datacraft.join() }}
Способ объединения таблиц зависит от типа источника данных:

• Например, для AppMetrica схожие стримы объединяются в один пайплайн с помощью UNION ALL. Чтобы объединить таблицы таким способом, поля, содержащие одни и те же показатели, должны называться одинаково, а количество столбцов должно быть равным, и они должны располагаться в одинаковом порядке.
• Стримы других источников, например, VK Ads или MyTarget, объединяются с помощью JOIN по общему полю, например, id кампании.

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

Зависимости
Зависит от всех таблиц слоя Incremental, относящихся к одному источнику и пайплайну.
Файл моделиПравило наименования
Для всех пайплайнов, крооме Regestry, название состоит из трех частей:  join_{название источника}_{название пайплайна}.
Для Regestry название формируется следующим образом:
join_{название источника}_{название пайплайна}_{название линка}.
Правило создания
Создается один файл на каждую комбинацию источник+пайплайн. Исключение — пайплайн Registry. У одного источника может быть несколько справочников, и на каждый из них создается файл модели.
Правила материализации
Для всех join таблиц тип материализации ‘view’.

4. Объединение источников (Combine)

На этом слое происходит объединение всех одинаковых пайплайнов.

Например, пайплайн ‘events’ есть у двух источников: Яндекс Метрика и AppMetrica. Следовательно, данные по событиям из этих двух источников мы объединяем в одну таблицу.

Поскольку на этапе Join мы подготовили данные и переименовали одинаково столбцы в разных источниках, то объединение сводится к простому UNION ALL всех таблиц с одинаковым пайплайном. Если каких-то столбцов не хватает в одной из таблиц, то создается столбец:

• либо с пустыми значениями: » as utmSource,
• либо с нулевыми: 0 AS sales.

Исключение составляют таблицы, относящиеся к пайплайну Registry.
Сейчас этап combine полностью автоматизирован в dataCraft.
Макрос: {{ datacraft.combine() }}
Зависимости
Зависит от таблиц слоя Join c одинаковыми пайплайнами.

Файл модели
Правило наименования
Название файлов модели формируется так:

• combine_{название пайплайна} — для всех пайплайнов, кроме Registry;
• combine_{название пайплайна}_{название линка} — для Registry.

Правило создания
Создается один файл для каждого пайплайна. В случае пайплайна Registry для каждой комбинации пайплайн+линк.
Правила материализации
В данном случае мы указываем materialized=’view’.

5. Хэширование (Hash)

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

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

Процесс формирования бизнес-ключа и затем хэша включает несколько этапов:

1. Определяем, из каких полей состоит бизнес-ключ. В dataСraft Core используется специальный файл — metadata.sql. В нем описываются все сущности в данных, и какие поля уникально их идентифицируют, а также, какие сущности к каким линкам относятся.
2. Готовим поля, из которых формируется бизнес-ключ: применяем все технические преобразования, приводим строки к верхнему регистру, чтобы из-за разницы в регистре не менялся хэш, объединяем все компоненты бизнес-ключа через разделитель.
3. На основе подготовленного бизнес-ключа получается хэш с помощью специальной хэш-функции. Мы используем MD5.

Схематично получение хэша можно представить так:

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

Специальный макрос с помощью metadata.sql и колонки __link отбирает поля, необходимые для формирования бизнес-ключа, производит все необходимые преобразования и формирует поля с хэшами. В методологии мы выделяем две группы хэшей:

1. Для линков. Эти хэши рассчитываются только на основе main_entities и являются основными. По ним проводится дедупликация данных на следующем слое. Для формирования этой группы хэшей в основном макросе используется дополнительный — link_hash(). Колонка, содержащая эти хэши, называется __id.
2. По сущностям. Их можно разделить на 2 подгруппы:
3. По которым можно идентифицировать пользователя (например, номер телефона). В метадате такие сущности помечены меткой glue: yes. Эти хэши необходимы для графовой склейки.
4. По которым можно сделать JOIN между разными пайплайнами. Например, соединить данные по событиям (пайплайн Events) с каким-то справочником (пайплайн Registry). В этом случае хэш будет формироваться на основе пересекающихся сущностей, то есть если в одном линке сущность из main_entities или other_entities входит main_entities другого линка, относящегося к пайплану Registry, то создается хэш для данной сущности в табличке hash_ первого линка.

Вторая группа — дополнительные хэши, которые не всегда необходимы. Они используются на этапах, которые идут после слоя Link. Для формирования хэшей по сущностям внутри основного макроса используется макрос entity_hash().
Сейчас в dataСraft Core для этапа хэширования готова alpha-версия автоматизации. 
Макрос: {{ datacraft.hash() }}
Зависимости
Зависит от таблиц, полученных на этапе Combine.
Файл модели
Правило наименования
Название файлов модели на этом этапе:

• hash_{название_пайплайна} — для всех пайплайнов, кроме Registry;
• hash_{название_пайплайна}_{линк} — для Registry.

Правило создания
Для всех пайплайнов, кроме Registry, создается один файл соответственно каждому файлу слоя Combine. Так как на слое Combine происходит объединение всех данных в рамках одного пайплайна, получается одна модель Hash на каждый пайплайн.
Для пайплайна Registry создаются модели для всех комбинаций пайплайн+линк.
Правила материализации
Зависит от типа пайплайна:

• для Events и DateStat — инкрементальный тип. Инкрементальность идет по тем же полям, что и на слое incremental — по дате;
• для PeriodStat, Registry инкрементальности нет, в этом случае данные материализуются как `table’.

6. Дедупликация (Link)

Если не требуются дополнительные преобразования, то это последний слой, на котором происходит дедупликация данных. В link-таблицы попадают только уникальные строки.

Дедупликация проводится с помощью хэшей, которые мы рассчитали на прошлом слое. Оставляем уникальные строки:

1. По комбинации хэша и __date для пайплайнов с инкрементальным типом материализации (Events и DateStat).
2. По хэшу там, где инкрементальности нет (пайплайны Registry и PeriodStat). Данные группируются по значениям хэшей, выбирается максимальное значение для нечисловых полей и сумма (или другая агрегация) для числовых полей.

Зависимости

Зависит от таблиц, полученных на слое Hash.
Файл модели
Правило наименования
Название моделей на этом слое формируется из двух частей: link_{название
пайплайна}.
Правило создания
Создается по одной модели на каждую модель слоя Hash.
Правила материализации
Правило материализации аналогично предыдущему слою:

• для наборов данных, относящихся к пайплайнам Events и DateStat, используется инкрементализация: materialized=’incremental’;
• для всех остальных — материализация без инкрементализации с полной перезаписью: materialized=’table’.

7. Визуализация

На этом этапе необходимо выбрать инструмент для создания отчетных витрин, которые смогут полноценно закрыть потребности бизнес-процессов компании. Ключевой фактор — наличие мощной BI-системы, достаточно гибкой для построения отчетов и анализа данных. В рамках нашего подхода предлагается два варианта: dataCraft и Apache Superset.
Сравнение dataCraft и Superset
dataCraft — аналитическая система для работы с данными из множества источников, включая рекламные площадки, веб-трекеры, статистические сервисы и таблицы произвольной структуры. Система оптимизирована для работы с инструментами рынка РФ, имеет готовые коннекторы и шаблоны для работы с множеством источников данных.
Superset — open-source BI-платформа, предоставляющая базовые функции построения отчетов и визуализаций, доступных для самостоятельного использования и настройки.
Преимущества dataCraft

1. Единое управление данными: предоставляет возможность через интерфейс подключать, настраивать и удалять источники данных для актуализации аналитики при изменениях.
2. Единое управление данными: можно подключать, настраивать и удалять источники данных напрямую через интерфейс.
3. Добавление собственных KPI: позволяет легко создавать и добавлять в отчеты свои KPI с помощью знакомых формул.
4. Сравнение периодов: возможность отслеживать динамику показателей за разные периоды (день, месяц, год).
5. Локализация и удобный интерфейс: полностью русскоязычный интерфейс, адаптированный для удобной работы.
6. Поддержка от специалистов: эксперты dataCraft помогают с настройкой дашбордов и разработкой новых коннекторов.

Более подробное сравнение dataCraft и Superset.

Успехов в построении аналитической системы инхаус!

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