Помните историю, которую рассказывал в июле? 🚀 Ключевые метрики компании на дашборде - путь от hardcoded cube к live calculated measures. Она вовсе не закончилась, но активно продолжается.
WBR Dashboard
В компании есть ключевой дашборд WBR (just like Amazon has), который представляет из себя набор метрик (всего около 50), каждая из которых визуализируется как на недельном, так и на месячном графиках, включая целевые (target) значения, YoY абсолютные и относительные значения (% Change).
До рефакторинга 2023-07:
— Одна таблица, предварительно агрегированная на уровне базы данных (dbt).
— Отсутствие гибкости (слишком долго и слишком сложно что-то менять и добавлять)
— Расчет агрегированной таблицы занимает значительное время (около 1 часа, и может упасть с ошибкой)
После рефакторинга 2023-07:
— Дашборд на 100% сделан в LookML (в виде кода Looker)
— Каждый график - это Merge Query, объединяющий measures, target values, calculated fields для YoY (offset)
— Каждый график в запросе обращается к Витринам с детальными данными (1 строка = 1 транзакция и т.д.)
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3
Data Apps Design
В команде забыли про проблемы dev / release / dashboard errors, но мы потеряли в производительности:
— Время загрузки дашборда увеличилось до неприемлемых 30-120 секунд
— Cached версия - почти мгновенно, но! Просмотр дашборда с другими фильтрами (страна, город, сервис) - те же 30-120 секунд
— Количество запросов, необходимых для отображения дашбора выросло до 300
— Есть трудности со сбором объективной статистики по запускам дашборда (время загрузки)
Меры, которые я предпринимаю
— Ограничить количество строк в каждом запросе к БД, например
58 weeks ago for 6 weeks, 6 weeks ago for 6 weeks для Weekly + YoY— Установить политики кэширования (Looker datagroups), прогревать кэш перед встречей WBR (Looker schedules)
— Aggregate awareness - иметь мЕньшие, предагрегированные таблицы для быстро исполнения запросов
— Собрать статистику по запускам дашборда (из метаданных Looker):
# Dashboard Runs, Average Runtime, % Cached Queries
— Избавиться от Merge Queries там где это возможноЖелаемый результат
— Время загрузки дашборда 10-15 секунд (в том числе при изменении значений фильтров)
— Добиться того, чтобы значительная часть запросов использовала кэш (почти мгновенно)
— Производительность не снижается, если одновременно с дашбордом работают достаточно большое количество людей
Планирую сделать серию статей с подробностями, выводами и рекомендациями формата "Хабр".
🔥 Stay tuned
Please open Telegram to view this post
VIEW IN TELEGRAM
Google Cloud
Admin settings - Datagroups | Looker | Google Cloud
View information about, trigger rebuilds, and reset the cache of datagroups.
🔥13
Проблема:
— Вы строите отчетность, возможно, дашборды в BI
— Дашборды запускают агрегирующие запросы (типичный OLAP)
— Запросов много: разные метрики, разные измерения, фильтры
— Все запросы задействуют огромные таблицы фактов (1М+)
— Время отклика, стоимость и количество сканированных данных оставляет желать лучшего
Вы задумываетесь над тем, можно ли это как-то оптимизировать?
Решение:
— Делать предварительную агрегацию данных (миллионы строк -> тысячи строк)
— Всегда в запросах использовать мЕньшую таблицу там, где это возможно
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
В чем ценность решения?
— Performance: для ответа на вопросы используются таблицы, меньшие на порядки
— Cost savings: экономим ресурсы, эффект будет явно заметен на масштабе
— Reduced complexity: вместо хардкода и "отдельных" таблиц используем встроенные механизмы
Что необходимо учитывать:
Структура таблицы должна позволять получить ответ на вопрос
— Field factors: агрегат должен включать запрашиваемые dimensions, measures, filters
— Timeframe factors: дни можно агрегировать до недели, наоборот - не получится
— Measure type factors: складывать можно аддитивные меры (sum, count, average, min/max), неаддитивные складывать нелья (sum / count / average distinct, median)
👉 В комментах небольшой пример с использованием Looker от меня.
— Performance: для ответа на вопросы используются таблицы, меньшие на порядки
— Cost savings: экономим ресурсы, эффект будет явно заметен на масштабе
— Reduced complexity: вместо хардкода и "отдельных" таблиц используем встроенные механизмы
Что необходимо учитывать:
Структура таблицы должна позволять получить ответ на вопрос
— Field factors: агрегат должен включать запрашиваемые dimensions, measures, filters
— Timeframe factors: дни можно агрегировать до недели, наоборот - не получится
— Measure type factors: складывать можно аддитивные меры (sum, count, average, min/max), неаддитивные складывать нелья (sum / count / average distinct, median)
👉 В комментах небольшой пример с использованием Looker от меня.
👍1
Data Apps Design
— Вы строите отчетность, возможно, дашборды в BI
— Дашборды запускают агрегирующие запросы (типичный OLAP)
— Запросов много: разные метрики, разные измерения, фильтры
— Все запросы задействуют огромные таблицы фактов (1М+)
— Время отклика, стоимость и количество сканированных данных оставляет желать лучшего
Вы задумываетесь над тем, можно ли это как-то оптимизировать?
— Дашборды запускают агрегирующие запросы (типичный OLAP)
— Запросов много: разные метрики, разные измерения, фильтры
— Все запросы задействуют огромные таблицы фактов (1М+)
— Время отклика, стоимость и количество сканированных данных оставляет желать лучшего
Вы задумываетесь над тем, можно ли это как-то оптимизировать?
Варианты реализации:
— Materialized View in Clickhouse, Snowflake, Redshift
— Aggregate projections in Vertica, Clickhouse
— Aggregate awareness in Looker
— Pre-aggregations in Cube
💬 У кого были подобные трудности и как удалось их решить? Возможно есть другие способы и инструменты?
🌐 @data_apps | Навигация по каналу
— Materialized View in Clickhouse, Snowflake, Redshift
— Aggregate projections in Vertica, Clickhouse
— Aggregate awareness in Looker
— Pre-aggregations in Cube
Please open Telegram to view this post
VIEW IN TELEGRAM
👏2
Салют!
Задача:
— Отчетность по операционным метрикам Near Real Time
— Устойчивый стек, возможность роста и эволюции
Архитектура:
— Debezium + Kafka для NRT репликации данных в DWH
— Clickhouse + dbt как движок DWH
— Cube как Semantic layer + Cache Store
— Superset как BI
Вопросы:
— Как вам архитектура решения и Data Stack?
— Кто работал с Debezium + Kafka: какие рекомендации по Deploy + Operations
#kafka #clickhouse #realtime #debezium
Please open Telegram to view this post
VIEW IN TELEGRAM
Data Apps Design
И еще, всё это будет в Cloud и управлять этим тоже хочется в полу-автоматическом режиме.
Так что скорее всего Terraform + Ansible
Для окрестрации контейнеров K8S
Есть опыт, краткие рекомендации и pain points?
#kafka #clickhouse #realtime #debezium
Так что скорее всего Terraform + Ansible
Для окрестрации контейнеров K8S
Есть опыт, краткие рекомендации и pain points?
#kafka #clickhouse #realtime #debezium
🔹 Еще как минимум на год
— Со слов Sales Rep. продления On Demand (Month—to—month) нет
— Буду внимательно рассматривать альтернативы в течение этого времени
🔹 Текущие pain points в Looker
— Есть проблема с производительностью громоздких дашбордов (Company Wide KPI)
— SQL Runner только для лицензии Developer (дорого)
🔹 Есть уже такие привычные, но всё же Killer features
— Semantic Layer (LookML)
— Everything as Code (incl. dashboards!)
— Developer mode, sudo as user, rich API
🔹 Ценообразование странное и непрозрачное
— Есть базовая часть $USD = движок Looker + ряд лицензий (2 Dev + 10 Users)
— Количество остальных лицензий считаются по тарифам и добавляются к общей сумму контракта
Так вот, в моем случае, в прошлый год тот, кто занимался продлением, ошибочно заложил профицит этих лицензий.
Расcчитывали на рост штата, а фактически он поредел. В итоге, сумма платежей стала на 20—30% выше, чем могла быть.
Как оцениваете своё положение?
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Data Apps Design
🟡 Дайджест самых интересных публикаций по темам:
Data Integration
— ▶ Успешный SaaS на рынке Аналитики – cтановление и планы развития / Алексей Сидоров из mybi connect
— 👨💻 Сказ о том как я realtime replication чинил (Kafka + Debezium + Clickhouse)
—…
Data Integration
— ▶ Успешный SaaS на рынке Аналитики – cтановление и планы развития / Алексей Сидоров из mybi connect
— 👨💻 Сказ о том как я realtime replication чинил (Kafka + Debezium + Clickhouse)
—…
👍1
Data Apps Design
Я собираюсь сэкономить $20K на правильном сетапе и использовании лицензий.
К, примеру, мне пришлось порядка 30 пользователям поменять роль. Я сделал через API это довольно быстро.
Кстати, эти 30 кандидатов я взял из внутренней статистики пользования и активности Looker.
К, примеру, мне пришлось порядка 30 пользователям поменять роль. Я сделал через API это довольно быстро.
Кстати, эти 30 кандидатов я взял из внутренней статистики пользования и активности Looker.
🔥2
4 года я готовил программы и вел занятия в Analytics & Data в ОТУС. Пришло время развивать свои проекты.
Ключевые моменты:
— 9-10 связанных вебинаров на которых строим Analytics Apps
— True Modern Data Stack: удобно, функционально, красиво - как я люблю
— Slides, Live coding, Demos, Labs (ваша практика)
— Участие будет платное
— Группа не более 10 человек
В ближайшее время опубликую:
— Программа курса (темы, подходы, стек) и почему она лучшая
— Результаты: ваши знания, умения, портфолио
— Дальнейшее сотрудничество: кому-то предложу делать всё это для клиентов с деньгами
— Углубленные серии: DataOps (MLOps), Advanced Modeling
Оставить заявку: https://forms.gle/4vGfQhCFTwgUoHBo7
#learning
Please open Telegram to view this post
VIEW IN TELEGRAM
Google Docs
Building Modern Data Analytics Apps
👍16🔥12❤2
Вопрос больше относится к ведению записей, заметок, наблюдений (в т.ч. по рабочим проектам и задачам).
— Лет 5-7 назад я пользовался Evernote.
— Сегодня для личных заметок я использую Notes (Apple).
— Все записи, относящиеся к работе я веду просто в git-репозитории в markdown файлах.
На какие важные критерии я обращаю внимание?
— Кросс-девайс (рабочий, домашний компьютер, телефон)
— Разметка текста: предпочтительно Markdown
— Структура ведения: папки, ассоциативные модели (путешествия, работа, покупки, ...)
— Версионирование: история изменений
— Media: возможность вставить скан схемы с бумаги, фотографию, картинку
— Links: ссылки на другие записи, внешние ссылки, хештеги
— Расширенные возможности поиска и сортировки заметок (дата создания, изменения)
И еще очень важно - возможность bulk export / import записей! Если менять инструмент - это критично.
Сейчас присматриваюсь к Obsidian.
Please open Telegram to view this post
VIEW IN TELEGRAM
Obsidian
Obsidian - Sharpen your thinking
The free and flexible app for your private thoughts.
❤3👍3
😒 dbt Semantic Layer - сплошное разочарование 😒
Итак, попробовав несколько разных подходов, собрав результаты и отзывы, эволюционно я пришел к тому, что для ключевого KPI-дашборда компании (Weekly Business Review) лучше всего иметь все метрики в необходимых разрезах и гранулярностях в предрассчитанном виде в СУБД в одной небольшой таблице.
Сегодня в течение дня я экспериментировал с dbt Semantic Layer 2.0 (бывший Metricflow, который стал частью dbt Labs).
Напомню, что ранее массово были публикации и обсуждения dbt Semantic Layer 1.0. Коротко, его суть сводилась к следующему:
— В .yml файле декларативно описывались правила расчета метрик со ссылками на dbt-модели
— В виде dbt package устанавливался набор специализированных макросов
— Эти макросы могли быть использованы либо статически (материализация в dbt models)
— Либо динамически (через интерактивное обращение из BI и других инструментов)
Однако, с версии dbt-core 1.6.0 этот подход стал deprecated и дальнейшее его развитие и поддержка не подразумевались. Вразумительного объяснения, почему этот подход стал deprecated у меня нет. Есть только предположение, что на этом подходе недостаточно хорошо и много можно зарабатывать.
TO BE CONTINUED 🔻
#metrics #semantic_layer #dbt
🌐 @data_apps | Навигация по каналу
Итак, попробовав несколько разных подходов, собрав результаты и отзывы, эволюционно я пришел к тому, что для ключевого KPI-дашборда компании (Weekly Business Review) лучше всего иметь все метрики в необходимых разрезах и гранулярностях в предрассчитанном виде в СУБД в одной небольшой таблице.
Сегодня в течение дня я экспериментировал с dbt Semantic Layer 2.0 (бывший Metricflow, который стал частью dbt Labs).
Напомню, что ранее массово были публикации и обсуждения dbt Semantic Layer 1.0. Коротко, его суть сводилась к следующему:
— В .yml файле декларативно описывались правила расчета метрик со ссылками на dbt-модели
— В виде dbt package устанавливался набор специализированных макросов
— Эти макросы могли быть использованы либо статически (материализация в dbt models)
— Либо динамически (через интерактивное обращение из BI и других инструментов)
Однако, с версии dbt-core 1.6.0 этот подход стал deprecated и дальнейшее его развитие и поддержка не подразумевались. Вразумительного объяснения, почему этот подход стал deprecated у меня нет. Есть только предположение, что на этом подходе недостаточно хорошо и много можно зарабатывать.
TO BE CONTINUED 🔻
#metrics #semantic_layer #dbt
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - dbt-labs/metricflow: MetricFlow allows you to define, build, and maintain metrics in code.
MetricFlow allows you to define, build, and maintain metrics in code. - dbt-labs/metricflow
💔2👍1
😵💫 dbt Semantic Layer - сплошное разочарование ч.2 😵💫
Итак, с dbt Semantic Layer 2.0 я проделал следующие шаги:
— Обновил версию dbt-проекта до
— Создал простое описание семантического слоя в
— Добавил файл с описанием метрик
— Генерировал файл с артефактами командой
— Обращался к Metricflow через CLI:
— Настроил dbt Semantic Layer в dbtCloud (обратите внимание на количество шагов и их)
Имеем в сухом остатке:
— Весь процесс конфигурации чтобы начать использовать на примитивном примере стал сложнее
— Есть сомнения в возможностях получить сложные расчеты и метрики с текущим функционалом Metricflow (задать это декларативным способом, в т.ч. связи таблиц = joins)
— Неясный концепт и дальнейшее развитие, вся рабочая схема выглядит ненадежно
— Это только для пользователей dbtCloud Team / Enterprise (sorry dbt Core users)
— И как следствие только для адаптеров Redshift, Snowflake, BigQuery, Databricks (никаких Clickhouse и community adapters)
— Нет простого SQL API (есть что-то неказисто-сложное на
— И внимание! Метрики больше нельзя материализовать через dbt models в том же проекте (т.е. посчитать и записать значения в таблицу для дальнейшего чтения)
➡️ Итого: сложно, сомнительно, неудобно, с ограничениями и за плату.
Относительно всего вышеуказанного, такой инструмент как Cube смотрится гораздо привлекательнее и интереснее.
Это я уже не говорю о Looker, который на протяжении многих лет совершенствует свой Semantic layer. В плане feature parity, Looker - это топ, вершина, олимп. Основной минус Looker - это платный продукт, подразумевающий vendor lock-in.
😒 Более того, есть чувство, что dbt Labs теперь ставит своей задачей заработок денег, монетизацию через свой основной платный продукт - dbtCloud (включая Semantic Layer), при этом качество и продуктовая ценность новых предложений неуклонно падает.
Следующие планируемые посты по этой теме:
— Обзор подхода с расчетом метрик (On the fly vs. Pre-aggregated)
— Результаты и сравнение этих подходов на практике используя Looker
— Почему с учетом моих бизнес-требований лучше оказался всё же подход Pre-aggregated
— Обзор возможностей Cube для решения этих задач
💬 Задавайте вопросы, оставляйте комментарии - обсудим.
#dbt #metrics #semantic_layer
🌐 @data_apps | Навигация по каналу
Итак, с dbt Semantic Layer 2.0 я проделал следующие шаги:
— Обновил версию dbt-проекта до
1.7.X, добавил Metricflow в свой devcontainer (просто и удобно)— Создал простое описание семантического слоя в
semantic_layer.yml на базе одной из витрин dbt (отличается от Semantic Layer 1.0, и не в лучшую сторону)— Добавил файл с описанием метрик
metrics.yml с одной метрикой = # Journeys— Генерировал файл с артефактами командой
dbt parse— Обращался к Metricflow через CLI:
mf list, mf validate-configs, mf query— Настроил dbt Semantic Layer в dbtCloud (обратите внимание на количество шагов и их)
Имеем в сухом остатке:
— Весь процесс конфигурации чтобы начать использовать на примитивном примере стал сложнее
— Есть сомнения в возможностях получить сложные расчеты и метрики с текущим функционалом Metricflow (задать это декларативным способом, в т.ч. связи таблиц = joins)
— Неясный концепт и дальнейшее развитие, вся рабочая схема выглядит ненадежно
— Это только для пользователей dbtCloud Team / Enterprise (sorry dbt Core users)
— И как следствие только для адаптеров Redshift, Snowflake, BigQuery, Databricks (никаких Clickhouse и community adapters)
— Нет простого SQL API (есть что-то неказисто-сложное на
jdbc:arrow-flight-sql, что я не стал подключать через DBeaver - терпение кончилось)— И внимание! Метрики больше нельзя материализовать через dbt models в том же проекте (т.е. посчитать и записать значения в таблицу для дальнейшего чтения)
➡️ Итого: сложно, сомнительно, неудобно, с ограничениями и за плату.
Относительно всего вышеуказанного, такой инструмент как Cube смотрится гораздо привлекательнее и интереснее.
Это я уже не говорю о Looker, который на протяжении многих лет совершенствует свой Semantic layer. В плане feature parity, Looker - это топ, вершина, олимп. Основной минус Looker - это платный продукт, подразумевающий vendor lock-in.
😒 Более того, есть чувство, что dbt Labs теперь ставит своей задачей заработок денег, монетизацию через свой основной платный продукт - dbtCloud (включая Semantic Layer), при этом качество и продуктовая ценность новых предложений неуклонно падает.
Следующие планируемые посты по этой теме:
— Обзор подхода с расчетом метрик (On the fly vs. Pre-aggregated)
— Результаты и сравнение этих подходов на практике используя Looker
— Почему с учетом моих бизнес-требований лучше оказался всё же подход Pre-aggregated
— Обзор возможностей Cube для решения этих задач
#dbt #metrics #semantic_layer
Please open Telegram to view this post
VIEW IN TELEGRAM
Getdbt
MetricFlow commands | dbt Developer Hub
Query metrics and metadata in your dbt project with the MetricFlow commands.
👍9😢4
Data Apps Design pinned «🔥 Открываю сбор заявок на серию вебинаров Building Modern Data Analytics Apps 🔥 4 года я готовил программы и вел занятия в Analytics & Data в ОТУС. Пришло время развивать свои проекты. Ключевые моменты: — 9-10 связанных вебинаров на которых строим Analytics…»
Салют!
Запуск будет состоять из вебинаров на эти темы:
— Infra Deployment
Deploying Databases, VMs for Data Pipelines and Orchestrators with Terraform
— Start modeling with dbt
Project configuration, Adapters setup, Launching devcontainers
— Sync Data Sources
Types of source data, file formats, sync methods
— Marketing analytics
Combine ad platforms, website trackers, CRM data, build data marts
— Ensure Data Quality
Unit tests, Freshness tests, Automated Integration testing
— Configure Semantic Layer (metrics)
Define metrics declarative way, Debug it
— Deploy and configure BI tool
Build dashboards, visualize key metrics, enable drills
— Team work
Setup dev sandboxes, CI tests, PR reviews
— Production Deployment
Scheduling production workloads, Chaining jobs
— Open topic session
Q&A sessions, Deep into details sessions, Live coding
В каждом вебинаре буду делать акцент на проблематике, подходах, и практических решениях. То есть то, чего зачастую не пишут в документации.
#learning
Please open Telegram to view this post
VIEW IN TELEGRAM
Google Docs
Building Modern Data Analytics Apps
🔥10👍2❤1
Планируемый стек:
— Y.Cloud, Terraform (Ansible)
— Clickhouse
— dbt + packages
— One of BI tools: Metabase, Superset (Datalens, LightDash)
— Cube for metrics layer
— Github (Actions)
— One of EL tools: Airbyte, Meltano, Stitch
Вся практика планируется в Я.Облаке.
#learning
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Data Apps Design
🟡 Дайджест самых интересных публикаций по темам:
Data Integration
— ▶ Успешный SaaS на рынке Аналитики – cтановление и планы развития / Алексей Сидоров из mybi connect
— 👨💻 Сказ о том как я realtime replication чинил (Kafka + Debezium + Clickhouse)
—…
Data Integration
— ▶ Успешный SaaS на рынке Аналитики – cтановление и планы развития / Алексей Сидоров из mybi connect
— 👨💻 Сказ о том как я realtime replication чинил (Kafka + Debezium + Clickhouse)
—…
❤3
⚡️ Real time replication работает как в сказке! Но всё далеко непросто ⚡️
#kafka #clickhouse #realtime #debezium
Салют! Ранее рассказывал о проблематике и архитектуре решения. По этой задаче есть обновления:
🔸 Infrastructure deployment
— Это Kafka, Kafka Connect, Zookeeper
— Все сервисы в Docker-контейнерах
— Для Connect готовил custom Dockerfile с добавлением нужных JDBC-драйверов (Clickhouse) и плагинов (JDBC Sink)
— Развернул Clickhouse (пока single node deployment)
🔸 Source Connector (MS SQL)
— Первый источник - MS SQL
— Потребовалось применить конфигурации в самой базе-источнике (CDC configuration)
— Настройка Initial Snapshot
— Очень много операций с Kafka Connect REST API (создал - удалил - обновил конфиг - посмотрел статус и т.д.)
— Трансформация SMT - Topic reroute - топик должен называться так же как и таблица в Clickhouse
🔸 JDBC Sink Connector (Clickhouse)
— Для работы коннектора необходимо применить трансформацию ExtractNewRecordState ко всем событиям
— Очень много работы связано с Data Type Mapping (любой mismatch - ошибка и падение)
— Добавил ко всем топикам метаданные
— Научился использовать secrets в Debezium (
🔸Clickhouse configuration
— init dbt repository + devcontainer
— Разобрал Debezium Schema Changes topic c помощью jq + yq => получил .yml конфиг для источников dbt
— dbt macros для создания исходных таблиц в цикле согласно схеме данных .yml
— Макрос умеет DROP & CREATE, CREATE OR REPLACE, CREATE IF NOT EXISTS
Это кратко.
Сначала отработал всю схему на 1-2 таблицах, заглядывая в Kafka topics. Потом автоматизировал на 70+ таблиц и полных snapshot данных.
В целом, впечатления от Debezium + Kafka Connect строго положительные. Штука сложная, но функциональная и поставленную задачу решает - я вижу данные в Clickhouse в real time. Продолжу работу.
🔸На очереди:
— Postgres Source Connector
— Оркестрация контейнеров (k8s)
— Гибкое и простое управление конфигурациями Connectors
— Clickhouse Materialized Views для подсчета метрик в real time
💬 Что скажете? Есть вопросы?
Запилить полноценный пост-инструкцию на Хабр?
🌐 @data_apps | Навигация по каналу
#kafka #clickhouse #realtime #debezium
Салют! Ранее рассказывал о проблематике и архитектуре решения. По этой задаче есть обновления:
🔸 Infrastructure deployment
— Это Kafka, Kafka Connect, Zookeeper
— Все сервисы в Docker-контейнерах
— Для Connect готовил custom Dockerfile с добавлением нужных JDBC-драйверов (Clickhouse) и плагинов (JDBC Sink)
— Развернул Clickhouse (пока single node deployment)
🔸 Source Connector (MS SQL)
— Первый источник - MS SQL
— Потребовалось применить конфигурации в самой базе-источнике (CDC configuration)
— Настройка Initial Snapshot
— Очень много операций с Kafka Connect REST API (создал - удалил - обновил конфиг - посмотрел статус и т.д.)
— Трансформация SMT - Topic reroute - топик должен называться так же как и таблица в Clickhouse
🔸 JDBC Sink Connector (Clickhouse)
— Для работы коннектора необходимо применить трансформацию ExtractNewRecordState ко всем событиям
— Очень много работы связано с Data Type Mapping (любой mismatch - ошибка и падение)
— Добавил ко всем топикам метаданные
op,source.ts_ms:ts_ms_source,ts_ms:ts_ms_debezium— Научился использовать secrets в Debezium (
${file:/secrets/clickhouse.properties:url})🔸Clickhouse configuration
— init dbt repository + devcontainer
— Разобрал Debezium Schema Changes topic c помощью jq + yq => получил .yml конфиг для источников dbt
— dbt macros для создания исходных таблиц в цикле согласно схеме данных .yml
— Макрос умеет DROP & CREATE, CREATE OR REPLACE, CREATE IF NOT EXISTS
Это кратко.
Сначала отработал всю схему на 1-2 таблицах, заглядывая в Kafka topics. Потом автоматизировал на 70+ таблиц и полных snapshot данных.
В целом, впечатления от Debezium + Kafka Connect строго положительные. Штука сложная, но функциональная и поставленную задачу решает - я вижу данные в Clickhouse в real time. Продолжу работу.
🔸На очереди:
— Postgres Source Connector
— Оркестрация контейнеров (k8s)
— Гибкое и простое управление конфигурациями Connectors
— Clickhouse Materialized Views для подсчета метрик в real time
Запилить полноценный пост-инструкцию на Хабр?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍22❤1⚡1
Потому что это знания, которыми делятся лучшие эксперты в своих областях.
— В первую очередь это доступ к самым актуальным и интересным книгам в IT
— Это мероприятия и live sessions
Например, мне был интересен вебинар ChatGPT for Software Engineers
— Это Interactive Labs & Sandboxes
K8s, Databases, Machine Learning, Data Analysis. Готовые окружения и песочницы прямо в браузере.
Подписка на год стоит $499. Я успел воспользоваться предложением Black Friday и заплатил $299
#learning #books
Please open Telegram to view this post
VIEW IN TELEGRAM
Oreilly
Online Learning Features - O'Reilly Media
O'Reilly offers a powerful combination of highly trusted content and learning experiences so you and your teams have the tools to work smarter and stay ahead.
Салют!
В Data-сфере происходит много событий: появляются новые тулзы, фреймворки, фичи, обновления, компании продают и покупают друг друга и т.д.
День ото дня я сам решаю множество различных задач, о большей части я не успеваю рассказать.
⭐ Есть мнение, что пора включить режим турбо-блоггинга
Какие у вас ожидания? Что хочется видеть в канале? Голосуем.
В Data-сфере происходит много событий: появляются новые тулзы, фреймворки, фичи, обновления, компании продают и покупают друг друга и т.д.
День ото дня я сам решаю множество различных задач, о большей части я не успеваю рассказать.
Какие у вас ожидания? Что хочется видеть в канале? Голосуем.
Please open Telegram to view this post
VIEW IN TELEGRAM