🙂 Хочу провести сравнительный анализ курсов и обучающих материалов в сфере работы с данными: Data Analytics / Engineering.

Чтобы было честно, начну со своей программы.

🔸Ключевые моменты:

— Упор на современные и удобные тулы: Modern Data Stack
— Фокус на создание ценности (бизнес-результат), а не процесс
— Кульминация каждых 4-5 занятий - практическая задача (Lab) оформленная как репо в Github
— В целом это квинтэссенция моего опыта и знаний, которые я получил на практике в течение последних 8 лет

🔸5 модулей + Capstone project:

1. Data Integration: ELT
2. DWH Basics
3. dbt Deep Dive
4. Business Intelligence
5. Advanced Toolkit
6. Capstone project

Программа подробно: https://github.com/kzzzr/analytics-engineer

До недавнего времени я предлагал подобную обучающую программу на русском языке на площадке OTUS, но уже скоро закончу преподавание в OTUS.

#learning

🌐 @data_apps | Навигация по каналу

❓ Для кого программа Analytics Engineer:

— Те, кто ищет оптимальные способы решения задач и работет "вдолгую"
— Кто хочет использовать Modern Data Stack в своем проекте
— Кто готов и любит работать руками, погружаться, копать, разбираться
— У кого уже есть неплохой опыт (1-3 года, 1-2 компании/проекта)
— Кто хочет найти новый проект / место работы с более интересными задачами

🟢Особенности и плюсы

— Современная программа, топовые инструменты: dbt, Clickhouse, Airbyte, Datalens, Metabase, Cube.js
— Вы научитесь решать задачи самым оптимальным путем, это хорошая игра "вдолгую"
— Рабочие Labs в Github, половина Labs уже имеют автоматическую проверку правильности выполнения через Github Actions
— Опыт работы в смежных областях: DevOps, Data Ops, Cloud Engineering, Marketing

🔴 Слабые стороны:

— Стек не 100% релевантен для большинства корпораций РФ
— Довольно высокий порог входа - легко не будет
— Для многих ценность информации и возможность применить знания под вопросом

#learning

🌐 @data_apps | Навигация по каналу

Есть интерес к тому, чтобы посмотреть на рынок сегодня и сделать выводы, понять проблемные точки, выделить белые пятна.

❓Где учитесь вы и какие материалы используете?
❓Предпочитаете платить за информацию или собирать самостоятельно в открытых источниках?
❓За какую информацию в своём опыте платили и не пожалели потраченных средств?

Присылайте ответы и ссылки в комменты.

Салют,

💥 Многие видели письма от dbtLabs об очередном повышении цен на услуги.
Для кого-то это повышение будет многократным.

В связи с этим, мои рекомендации по альтернативам (для оркестрации dbt jobs):

1. Github Actions (если используете Github)
2. Gitlab CI (если используете Gitlab)
3. Prefect - удобно, приятно, лаконично
4. Paradime.io - с радостью бы попробовал на замену dbtCloud

🟢 Чем вы пользуетесь, что могли бы рекомендовать и почему?

🌐 @data_apps | Навигация по каналу

🙂 Datalens в Open Source

Отличная новость, теперь можно хостить этот BI on-prem.

Я пользуюсь Managed версией в Y.Cloud довольно давно.

🟢 Плюсы:
— Получается делать сложные вещи, например Period over Period аналитику (LAG([Принятые заявки (шт)], 52 ORDER BY [Неделя] BEFORE FILTER BY [Неделя]))
— Есть tabs на дашбордах (во многих BI этого нет! В т.ч. Looker)
— Удобный UI
— Достаточно богатые возможности для визуализации
— Готовые коннекторы для популярных СУБД: Clickhouse, Postgres

🔴 Из недостатков:
— Отсутствие code-based semantic layer - все метрики настраиваем руками в UI
— Для связи таблиц можно задать только условие равенства = (equi-join). Нельзя задать период для дат, например (dt >= date_start and dt <= date_end)
— Версионирование датасетов, чартов, дашбордов. Что-то вроде недавно появилось в этом отношении (drafts), но это всё равно не git
— Селектор (фильтр) действует только на 1 поле одного датасета. Возможно, есть workaround с alias, но это сложно

💬 Есть ли те, кто пользуется этим инструментом?
Какие преимущества и недостатки отметили?

🌐 @data_apps | Навигация по каналу

Snowflake Reports Financial Results for the Fourth Quarter and Full-Year of Fiscal 2023

Рост по всем показателям. Впечатляет, не правда ли?

Хотелось бы сравнить результаты с Databricks.
В частности больше всего интересует количество клиентов (в т.ч. $1M+ customers), а также динамику этих показателей по годам.

Однако, Databricks отчетность не публикует 🤔
Databricks is a privately held company and is not publicly traded on NYSE or NASDAQ in the U.S.

🌐 @data_apps | Навигация по каналу

Неоднозначная публикация.

А я считаю, что чем выше уровень maturity в компании, тем меньше должен быть sum of data work.

Что это значит?

— Все рутинные и повторяющиеся операции автоматизированы
— Исключена поддержка legacy решений и инструментов
— Для всех заинтересованных в data лиц в компании созданы идеальные условия: SQL access, self-service BI, A/B experiments

Метрику Data team as % of workforce в текущей компании, где я работаю я бы оценил в 2.5-3%

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

На протяжении 4-х лет я единственный Data Engineer в команде.
Говорит ли это о том, что sum of data work не изменилась?

🌐 @data_apps | Навигация по каналу

⭐ Single Person Team в Data Engineering

В предыдущем посте упомянул: На протяжении 4-х лет я единственный Data Engineer в команде.

Эта фраза вызвала вопрос в комментах, на который есть желание ответить развернуто.

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

🔸По типу деятельности:

— Support / Bugfixing

Поддержка текущих операций, исправление ошибок: dbt jobs, Data Integration, schema migration (backend changes), data mapping

— New features

Появление новых и эволюция текущих: витрины данных, метрики, интеграции (-> DWH, DWH ->)

— Refactoring

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

— Infrastructure & Tooling

В основном, это стратегические задачи: выбор новой database platform (Amazon Redshift -> Snowflake), прототипы дашбордов в новых BI-тулах (Looker -> ??), Semantic Layer (LookML -> Cube / MetricFlow), reverse-ETL PoC (Census / Hightouch)

🔸По сфере:

— Анализ требований

Обязателен перед тем как я берусь делать что-либо. Обычно сводится в уточняющим вопросам в Slack/Jira (зачем делать это? какие альтернативы? учтены ли будущие изменения?). В результате у меня есть понимание того, что должно получиться в результате, как и кем это будет использоваться, и возможные пути решения (2-3 альтернативных варианта).

— Интеграция данных

Стараюсь использовать централизованный подход. Максимально все источники данных через SaaS Hevo.

— Моделирование данных

Результат - цепочка преобразований в dbt-проекте, заканчивающаяся Data Mart. Моя задача - получить результат с минимальными изменениями (используя те преобразования, которые уже в наличии).

— Поставка данных (data services)

50% - это всевозможные дашборды и визуализации. Остальные - это работающие интеграции с внешними системами: CRM, Customer Engagement, Backend, etc.

— Поддержка инфраструктуры

Большая часть сервисов - managed: Hevo, Redshift, Census. Конфигурация нужно, но нет необходимости мониторить CPU, добавлять диски и т.п. Есть работа, связанная с security, privacy, access segregation.
С networking, VM provisioning, Container orchestration (k8s) помогает SRE (удивительно, но который тоже Single Person Team 😄)

🌐 @data_apps | Навигация по каналу

🙂 Please boost my channel so that I can post stories for you https://t.me/enthusiastech?boost

☄ Хочу 100 графиков на дашборде и чтобы отображались за 10 секунд

Помните историю, которую рассказывал в июле? 🚀 Ключевые метрики компании на дашборде - путь от 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 транзакция и т.д.)

🌐 @data_apps | Навигация по каналу

➡ Ключевые проблемы после рефакторинга

В команде забыли про проблемы 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

🌐 @data_apps | Навигация по каналу

🔼 AGGREGATE AWARENESS 🔼

Проблема:

— Вы строите отчетность, возможно, дашборды в BI
— Дашборды запускают агрегирующие запросы (типичный OLAP)
— Запросов много: разные метрики, разные измерения, фильтры
— Все запросы задействуют огромные таблицы фактов (1М+)
— Время отклика, стоимость и количество сканированных данных оставляет желать лучшего

Вы задумываетесь над тем, можно ли это как-то оптимизировать?

Решение:

— Делать предварительную агрегацию данных (миллионы строк -> тысячи строк)
— Всегда в запросах использовать мЕньшую таблицу там, где это возможно

🌐 @data_apps | Навигация по каналу

Варианты реализации:

— Materialized View in Clickhouse, Snowflake, Redshift
— Aggregate projections in Vertica, Clickhouse
— Aggregate awareness in Looker
— Pre-aggregations in Cube

💬 У кого были подобные трудности и как удалось их решить? Возможно есть другие способы и инструменты?

🌐 @data_apps | Навигация по каналу

🙂 Могли бы покритиковать архитектуру Data Stack? 🙂

Салют!

Задача:

— Отчетность по операционным метрикам 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

🌐 @data_apps | Навигация по каналу