Data Apps Design

✔️ Мой чеклист и рекомендации по документированию аналатических приложений с помощью dbt Docs 🟢 Источники данных - заполните максимум для себя и тех кто будет изучать документацию Примерный список атрибутов: — Source (Mobile Apps Events) — Type (JSON files) — Way of data integration (S3 table engine) — Description (Events tracked in Mobile Apps, single file for each event) 🟡Структурирование проекта на слои преобразований Мой пример: — Sources — Staging — Intermediate — Analytics (dims / facts) 🔵Цветовая схема на графе dbt Docs Ноды dbt (включая модели) можно окрасить в разные цвета на графе:

    staging:
      +docs:
        node_color: "#219EBC"

🔴Скрыть нерелевантные модели из документации

models:
  <resource-path>:
    +docs:
      show: true | false

🟤Блоки {{ doc() }}: Переиспользование блоков документации В целом, большие блоки документации стоит вынести в отдельные markdown-файлы. Возможно, с картинками и схеми. Также имеет смысл один раз описать атрибут (колонку), который присутствует в 1+ моделях, и впоследствие ссылаться на его описание:

models:
  - name: events
    description: '{{ doc("table_events") }}'

🩷Custom overview page - главная страница сайта с документацией Рекомендую грамотно использовать title page и разместить на нем самую важную информацию: — Используемые инструменты и сервисы — Архитектурная схема — Описание источников данных — Ссылки на JIRA (task trackers), Wiki pages, Operational systems, Contacts (@), etc.

{% docs __overview__ %}

## OVERVIEW
## INFRASTRUCTURE SCHEMA
## TOOLS USED
## DATA SOURCES
## USEFUL LINKS

{% enddocs %}

🟢Публикация вебсайта Т.к. сайт статический, его достаточно разместить в Object Storage с поддержкой Static website hosting: — Host on Amazon S3 (optionally with IP access restrictions) — Publish with Netlify — Use your own web server like Apache/Nginx 🟡Актуализация вебсайта с документацией - всегда Up to Date Чтобы вебсайт всегда отражал актуальное состояние, необходимо после каждого изменения в код (Merge Request), генерировать и загружать новую версию. Делать это можно с помощью Github Actions или аналогов, автоматизируя действия: — dbt docs generate — aws s3 sync ./target s3://my-website-bucket/ 🌐 @data_apps | Навигация по каналу

👑 Серию замечательных статей об Аналитике и Данных с фэнтези-аллегориями подготовил Алексей Сидоров из myBI Connect 🟤 Данные - путешествие Туда и обратно 🟤 Данные - путешествие Туда и обратно. Часть вторая. Рекомендую для структурирования и систематизации знаний: — Источники данных — Выгрузки и обращения по API — Основы моделирования — Витрины данных и визуализации — Семантический слой — There and back again 😏 Всё это с аллегориями и захватывающими иллюстрациями. Всем, кто любит Средиземье и вселенную LoTR это особенно понравится. 🌐 @data_apps | Навигация по каналу

🔵 ОСТРЫЕ ТЕМЫ: SALARY, PERFORMANCE REVIEW, ДЕГРАДАЦИЯ КУЛЬТУРЫ РАЗРАБОТКИ, ПОЗИЦИОНИРОВАНИЕ В ОТНОШЕНИЯХ С EMPLOYER Салют! Вчера осознал тот факт, что я в основно пишу сухие технические тексты, которые во многом отражают аспекты моей текущей деятельности, но игнорируют стратегическое видение. Есть мнение, что существуют гораздо более актуальные темы, которые читатели хотели бы услышать и обсудить. Среди тех, на которые я хотел бы высказаться: 🔢 Почему компании со скрипом повышают SALARY даже на 10% даже в том случае, если вы экономите (ЗАРАБАТЫВАЕТЕ) для нее $50K+ в год 🔢 Мое мнение насчет проведения PERFORMANCE REVIEW в компании и почему вы с высокой вероятностью получите "Ты молодец! Продолжай в том же духе!" 🔢 Что дает человеку чувство собственной власти и независимости от EMPLOYER, а равно и спокойствие, уверенность, и высокую производительность 🔢 Как дать понять МЕНЕДЖЕРУ и всем СТЕЙКХОЛДЕРАМ, что вы занимаетесь ключевой и важной работой, без должного выполнения которой их деятельность будет затруднена (НЕВОЗМОЖНА) 🔢 Почему даже в СТАРТАПАХ деградирует культура разработки и поставки качественных решений (кода), а стиль управления оставляет желать лучшего ❤ Помогите выбрать лучшую тему для ближайшего поста, а я пока займусь его написанием 🌐 @data_apps | Навигация по каналу

⭐ Docker: перенести Volumes в другую Filesystem без потери данных 🔹 Ситуация Вы создали VM, разместили на ней свои сервисы в Docker, запустили, сервисы (например, Kafka + Kafka Connect) начали писать данные. Вдруг вы обнаруживаете, что disk volume заканчивается.

df -h

Что делать? Как перенести Docker Volumes и избежать ошибки Disk full? 🔺 Действия — Добавить новый Filesystem, на котором будет достаточно места — Остановить контейнеры — Отключить Docker services — Unmount docker overlay filesystems — Перенести данные в новый раздел — Внести изменения в конфигурационный файл Docker daemon.json — Включить Docker services — Запустить контейнеры 🟡 Скрипт

# Stop Docker containers
docker compose stop

# Stop Docker services
systemctl stop docker
systemctl stop docker.socket

# Unmount docker filesystems
umount /var/lib/docker/overlay2/*/*

# Move data
mv /var/lib/docker/ /mnt/${DESTINATION}/

# Edit Docker service configuration file:
nano /etc/docker/daemon.json

# Add or modify the data-root configuration option to point to the new directory:
{
  "data-root": "/mnt/path/docker"
}
# Save and close the file.


# Start the Docker service:
systemctl start docker
systemctl start docker.socket

# Start Docker containers
docker compose start

Также этот скрипт на Github Gist: https://gist.github.com/kzzzr/fef4c9c88f301c282275e6d451e080f5 Это сработало для меня, и должно сработать для вас. В частности, это позволило мне расширить дисковое пространство на VM, и позволить Docker писать в новую Filesystem БЕЗ повторного запуска full sync истории по 100+ коллекциям MongoDB (Debezium Connector + Kafka topics). 🌐 @data_apps | Навигация по каналу

🔹 Хочу устроить Real Time Data Sync — дайте критику и комментарии Привет! Последние пару недель плотно работаю над настройкой Data Pipelines через Debezium + Kafka Connect. 🔺 Общая схема будет выглядеть так: — Sources: MongoDB, Postgres — Source connectors: Kafka Connect + Debezium (CDC) — Kafka as intermediate storage — Sink connector: Snowflake connector for Kafka (Snowpipe streaming) — Snowflake as destination Упражнения, которые я проделываю: 🟡 Deploy services: Kafka + Kafka Connect (+ Zookeeper + Schema registry + REST Proxy) Вообще, готовые образы есть от: Confluent / Debezium / Strimzi. Я пока использую образы от Debezium + Strimzi. Модифицирую, добавляя нужные мне коннекторы указанных версий (JAR-файлы). У Strimzi есть операторы для K8s, которые я планирую использовать. А вот K8s deployment от Confluent входит в Enterprise plan и подлежит лицензированию. 🔵 Choose collections for replication Выбрал несколько несложных коллекций для тестирования и дебага. Несложные, потому что: — Небольшое количество колонок — Минимальное количество вложеных nested-структур — При этом частые обновления - получаю лог изменений CDC сразу. — Глазами можно отследить все применяемые изменения (либо то, что не получается) 🟢 Source connector (MongoDB) На выбор у меня было 2 Connectors: — MongoDB Kafka Connector — Debezium connector for MongoDB Несмотря на наличие отличной документации и даже поддержку snapshot с учетом фильтра (например, sync истории только за 1 год), выбор сделан в пользу Debezium Connector. Позже подробно напишу доступные возможности и пример конфигурации. 🩷 Metadata fields for events В каждое событие дополнительно пишу ряд метаданных: — ts_ms = metadata timestamp — op = c (create), u (update), d (delete), r (snapshot) 🔴 Message transformations: Topic route, New Document State Extraction — Topic route: Мессаджи направляю сразу в топики с целевыми названиями таблиц в Snowflake. — New Document State Extraction: этат трансформация позволяет перейти от сложного и детального формата события Debezium (schema, before, after) к упрощенному виду (только after), который мне и нужен в Snowflake. 🟤 Debug events Развернул devcontainer (docker-compose based), установил kcat + jq. Использую kcat для просмотра топиков, key-value значений, оффсетов. jq использую для форматирования ответов от REST API (Kafka Connect). Очень удобно проконтролировать изменения, которые вношу пунктом ранее. 🟡В следующем посте: — Externalizing secrets — Create a sink connector (Snowflake) — Set up monitoring (Prometheus + Grafana) — Use AVRO data format (io.confluent.connect.avro.AvroConverter) — Configure topics (compact + delete, etc.) — Configure incrmental snapshots loads via Debezium signals — Ensure PII data masking (message transformations, connector configuration) — Add HTTP bridge / REST proxy 🔻 Могли бы покритиковать / поделиться опытом / посоветовать что-либо? 🌐 @data_apps | Навигация по каналу

🔰 Быстро и просто устроить ENVs для Data: DEV, TEST, PROD (part 2) ✅ Как это сделать — Проще всего использовать единую СУБД и разделить ее на набор databases / schemas — Среда - это лишь совокупность connection details + role + target schema — В dbt это называется targets и задается в файле profiles.yml — В зависимости от используемой среды вы хотите модифицировать тот или иной код ✅ Давай примеры 🩷 profiles.yml для dbt с 3-мя средами. Вместо деталей для подключения используются переменные среды, которые задаются: — Локально на компьютере пользователя в DEV — В CI-инструменте (Github Actions) для TEST — В Orchestration tool (dbtCloud) для PROD Полностью по ссылке: https://gist.github.com/kzzzr/02d4f1f86d19df9c90210b177a561406 🩷 Limit rows for DEV and TEST with Jinja SQL:

    {#- prepare expression to limit rows depending on target.name and flags provided -#}
    {%- if target.name in ['prod'] and history_depth_days > 0 -%}
        {%- set watermark = 'DATEADD(days, ' ~ -1 * history_depth_days ~ ', CURRENT_TIMESTAMP::DATE)' -%}
        {%- set history_depth_expression = timestamp_column ~ ' >= ' ~ watermark -%}
    {%- elif target.name not in ['prod'] and limit_data_for_dev == true -%}
        {%- set watermark = 'DATEADD(days, ' ~ -1 * var('data_tests_depth_days') ~ ', CURRENT_TIMESTAMP::DATE)' -%}
        {%- set history_depth_expression = timestamp_column ~ ' >= ' ~ watermark -%}
    {%- else -%}
        {%- set history_depth_expression = '1 = 1' -%}
    {%- endif -%}

    {#- prepare final filter expression -#}
    where 1 = 1
        and {{ deleted_rows_expression }}
        and {{ history_depth_expression }}

🩷 Уровень серьезности (Severity) теста: ERROR для PROD, WARN для DEV:

        - name: timezone
          tests:
              - dbt_utils.not_null_proportion:
                  at_least: 0.95
                  severity: "{{ 'error' if target.name in ('prod') else 'warn' }}"

🩷 Используемый COMPUTE в зависимости от среды:

{{
    config(
        materialized='table',
        snowflake_warehouse='WH_LARGE' if target.name == 'prod' else target.warehouse
    )
}}

🩷 Запись артефактов dbt run в метаданные (только для PROD):

on-run-end:
    - "{% if target.name == 'prod' %}{{ dbt_artifacts.upload_results(results) }}{% endif %}"

✅ Какие преимущества — Все пользуются одними и теми же исходными наборами данных (data sources) - исключены расхождения и несогласованность — Zero effort - не нужно создавать среды как отдельные инстансы, разворачивать ПО, копировать датасеты и следить за актуальностью — Один проект = один репозиторий с кодом ✔ — Разница поведения и конфигураций для разных сред легко поддерживается с помощью шаблонизации Jinja SQL — Это экономически выгодно и целесообразно. Используя Snowflake вообще perfect, т.к. у вас decoupled storage & compute, при этом compute unlimited — Это быстро и безболезненно с точки зрения поставки кода и Time2Market ❤ Расскажите, как эти процессы реализуете вы? В чем недостатки и преимущества подхода? 🌐 @data_apps | Навигация по каналу

🔰 Быстро и просто устроить ENVs для Data: DEV, TEST, PROD Как устроен процесс разработки? Какие среды в наличии? Насколько быстро можно задеплоить изменения в прод? Часто общаюсь с людьми на эти темы. От многих слышу о белых пятнах и несовершенствах в установленных процессах. ✅ Зачем это делать DEV: Изолированная среда для каждого члена команды с правами владельца — Каждый пользователь - владелец своей среды (CREATE, INSERT, UPDATE, DELETE, DROP) — Интерактивная разработка - написал код, создал объекты в БД, проверил, сделал коммит, повторил — Люди не мешают друг другу - среды изолированы и независимы — Тот же набор данных, только в масштабе (1:100) TEST: независимые и беспристрастные автоматизированные проверки — Осуществляется запуск для законченного объема работы (Pull Request) — Sanity check: код работает и расчеты завершаются без ошибок — Advanced testing: data quality, unique, not null, reference, etc. — Без успешного завершения тестов код нельзя выводить в PROD PROD: основная среда, которую используют company wide: DWH, Semantic layer, BI dashboards, Pipelines — SLA - есть обязательства и ответственность перед пользователями и потребителями — Любые изменения прошли все этапы проверки — Важна производительность вычислений — Покрытие тестами и ожиданиями позволит обнаружить отклонения и ошибки 💬 Кто использует какие-то другие среды, расскажите что это и зачем? 🌐 @data_apps | Навигация по каналу

⭐ Apache Superset — продолжаю использовать и приятно удивлен Последнее время начал глубже погружаться в Superset – тул класса Business Intelligence для визуализации и дашбординга. 🔵Развертывание через Docker-compose тривиально

git clone --depth=1  https://github.com/apache/superset.git

export TAG=3.1.1
docker compose -f docker-compose-image-tag.yml up

Есть варианты с Kubernetes, PyPI 🟤 Доступна локализация Superset на русский язык Выполняется как добавление русского языка в список доступных:

LANGUAGES = {
    "ru": {"flag": "ru", "name": "Русский"},
    "en": {"flag": "us", "name": "English"}    
}

🟡Подключение к источнику данных Clickhouse Из коробки в Superset нет возможности подключиться к Clickhouse. В моем случае, я выполнил скрипт установки в одном из контейнеров:

pip install clickhouse-connect

Возможно собирать готовые образы с предустановленными драйверами и пользовательскими конфигурациями. 🔵 Использование семантического слоя Cube в качестве Database Connection Всё работает замечательно. Cube показывает Postgres-подобный SQL API, который можно использовать в Superset из коробки. 🔸 Однако, в случае, если вы хотите применять custom formatting для ряда метрик (.2% - доля в процентах до двух знаков после запятой), то вам придется задать METRICS (формула + название) и в Superset, т.е. по сути выполнить задать метрику дважды, что не очень хорошо. 🟫 Также новые метрики доступны к использованию только после явного Dataset metadata refresh. Т.е. даже в случае Continuous Deployment придется пройти и нажать все кнопочки явным образом. 🔴 Графики на Apache ECharts Почему Apache ECharts? Коротко: — large library of visualization types — high performance, ideally supporting canvas rendering — powerful declarative API for customizing and theming charts — internationalization support — an active and growing community ❤️ Уже заценил Mixed chart, где можно совместить несколько метрик различных типов (bar + line) с общей осью (X = Time). 🟢 Кастомизации графиков Итак, порой у пользователей дашбордов возникают странные и на первый взгляд неосуществимые требования 🟢: — Применение особенного форматирования - stacked bar chart values alignment (center) — Добавление строк, колонок в визуализацию (пустые строки-разделители Excel-like) - попробуем Custom CSS — Новые (недоступные из коробки) визуализации - обратимся к библиотеке Apache ECharts — Расширенное редактирование имеющихся графиков Мне еще многое предстоит выяcнить в этих моментах, но учитывая наличие материалов, думаю, что это будет осуществимо. 🩷 В Tg есть русскоязычное community @superset_ru — Многие вопросы находятся в поиске по ключевым словам — Ранее не обсуждавшийся вопрос можно сформулировать и задать коллективному разуму Не всё получается сделать сразу, быстро и просто. Но пока впечатления положительные. 👤 Поделитесь, какие ваши? Сталкивались с тем, что не получалось решить? Раздражало в Superset? 🌐 @data_apps | Навигация по каналу

▶️ SQL + dbt = God Mode Data Modeling / Подходы к созданию витрины корпоративных метрик — Бизнес-задача: Дашборд для Weekly Business Review (WBR) — Решение «Hardcore Cube» 🗿 — Решение «Direct Runtime» 🦅 — Aggregate awareness (Looker) как оптимизация производительности — Решение «Godlike modeling» 👑 — Как отразилась смена СУБД с Amazon Redshift на Snowflake на решении? ✅ Как всё это использовать у себя? — Находите повторяющиеся паттерны и переиспользуйте код (DRY) — Пишите универсальный код с dbt — Не изобретайте велосипед - используйте packages — Ищите баланс между материализацией и runtime queries — Чем меньше кода, тем лучше Слайды доклада: https://drive.google.com/file/d/1_KGuLGWksWBHz0SKUEOW1MO4Acxea0s3/view?usp=sharing 👑 Учиться со мной: https://forms.gle/uwETpSRA6ux7Gr1t7 🌐 @data_apps | Навигация по каналу