DE – Telegram
522 subscribers
312 photos
81 videos
15 files
405 links
Data Engineering Technologies.
SQL, Python, Kafka, Spark, Pandas, Airflow, Clickhouse, Greenplum, Postgres, dbt, LLM agentic systems, AI, robots, drones etc.

Boost channel - https://news.1rj.ru/str/boost/data_engi
Download Telegram
Иду вчера по Льва Толстого, смотрю в случайное окно, а там...

Спасите роботов из офиса Яндекса! Свободу железным пацанам! 🤖
Please open Telegram to view this post
VIEW IN TELEGRAM
😁7💯3
🔥 Почему у тебя в DWH вечный ад — и как из него выйти

Если твои пайплайны ощущаются так:
🔘всё надо вчера
🔘таблицы рождаются как попало
🔘техдолг растёт быстрее, чем зарплата
🔘каждую ошибку в данных чинят в пожарном режиме

то проблема чаще не в инструментах, а в отсутствии простых стандартов моделирования.

Представь жизнь дата-инженера, где:

1️⃣ Пайплайны собираются быстро, но при этом предсказуемо.

2️⃣Таблицы не ломаются от любого чиха продуктовой команды.

3️⃣Бизнес тебя воспринимает как инженера системы, а не "того, кто SQL крутит".

В ближайших постах — 6 конкретных техник, которые позволяют:
🟡строить продовые таблицы быстро
🟡при этом не закапываться в техдолге
🟡прозрачно показывать свою ценность бизнесу

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

〰️〰️〰️〰️〰️〰️〰️〰️

🔘Bus Matrix
🔘Data Contract
🔘Insert Only факты и snapshot-измерения
🔘4 проверки данных, которые дают 80% пользы
🔘Линейность (lineage)
🔘Единый источник правды
🔘Всё вместе

#dev #de #dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
211
⚡️ Bus Matrix — как одним артефактом показать бизнесу, зачем ты вообще нужен

Бизнесу пофиг на "fact_orders" и "dim_customer". Ему важны процессы: продажи, возвраты, конверсия, отток.

Bus matrix — это одна табличка, которая переводит:
мы сделали ещё одну факт-таблицу


в
мы покрыли ещё один бизнес-процесс, и вот какие разрезы вы теперь можете видеть


Пример (Bike Parts магазин, упрощённо):
🔘Строки — бизнес-процессы: Заказы, Возвраты, Скидки
🔘Колонки — измерения: Клиент, Товар, Дата заказа, Дата доставки, Регион, …
🔘Ячейка — есть связь или нет

То есть ты буквально показываешь:
🟢"Вот тут у вас появилась аналитика по возвратам по регионам"
🟢"Вот здесь — скидки по клиентским сегментам"

Что даёт bus matrix:

1️⃣ Ты говоришь на языке бизнеса: «процессы и разрезы», а не «джойны и ключи».

2️⃣ Легко демонстрируешь прогресс: было 3 процесса, стало 7.

3️⃣ Это по сути мини-ERD, но понятный не только дата-инженерам.

Такую матрицу можно держать в Notion / Confluence и тыкать в неё на всех созвонах:
Смотрим сюда: мы закрыли ещё 2 процесса и добавили 3 измерения


Для усиления всестороннего эффекта, можешь добавить подпись:

Всё, что мы делаем в DWH, должно быть видно в bus matrix. Если в матрице не видно пользы — мы делаем фигню


〰️〰️〰️〰️〰️〰️〰️〰️
Порядок в DWH

#dev #de #dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
58😁1
😁6💯3
✏️ Data Contract — таблица как продукт, а не как побочный эффект пайплайна

Каждый раз, когда кто-то строит дашборд на твоей таблице, у тебя по сути покупают продукт. Только большинство команд этот продукт никак не описывает.

Data contract — это простой документ, который отвечает на вопрос аналитика/продукта:
Что я могу ожидать от этой таблицы, чтобы не накосячить?


Минимальный набор, который уже делает магию:

1️⃣ Grain (зернистость)
Что означает ОДНА строка?
🔘"одна строка = одна позиция в заказе"
🔘"одна строка = дневной срез по пользователю"

2️⃣ SLA по доступности данных
🔘"данные за вчера будут готовы к 09:00 UTC"
🔘или "лаг до 15 минут"

3️⃣ Схема (колонки + типы)
Кратко и по делу, без воды.

4️⃣ Owner
Команда/человек, кто отвечает за таблицу + канал коммуникации.

5️⃣ Встроенные проверки качества (DQ)
🔘что именно контролируем (уникальность, not null, допустимые значения…)
🔘где смотреть алерты.

Важно: data contract — это документ, а не тулза.
Фактическое соблюдение (валидации, алерты) — это уже вопрос инструментов.

Что меняется, когда у таблицы есть контракт:
🟣 пользователи перестают додумывать семантику колонок
🟣 меньше "а чё у вас тут за цифры? вы нам бизнес сломали"
🟣 проще объяснить, почему вы не поддерживаете хаотичные запросы ("это вне контракта, давайте расширим его нормально")

〰️〰️〰️〰️〰️〰️〰️〰️
Порядок в DWH

#dev #de #dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
6
⭐️ Insert-only факты и snapshot-измерения — быстрый путь к стабильным таблицам

Большинство бизнес-вопросов в нормальных компаниях решается через обычные fact + dimension таблицы в стиле Кимбелла. Без извращений.

Предлагаю тебе практичный сетап:

1️⃣ Insert-only fact таблицы
Простое правило:

Вставили строку в факт — больше её не обновляем (кроме осознанного backfill).

Плюсы:
🔘 история событий не переписывается
🔘 легче дебажить: «вот, в этот день такой набор фактов и был»
🔘 меньше сложных merge-операций и конфликтов

2️⃣ Snapshot dimension таблицы
Вместо сложных SCD2 везде:
🔘 на каждый прогон пайплайна полностью пересобираем измерение (snapshot)
🔘 храним несколько лет истории снапшотов
🔘 SCD2 оставляем только там, где реально нужно

3️⃣ Одно зерно на таблицу
Никаких "и по пользователю, и по заказу, и по клику в одной таблице". Только один чёткий grain.

4️⃣ Флаги не плодим, чтобы не получить ад с флагами
Если колонка зависит от какого-то флага — лучше разнести в явно названные колонки, а не "если flag = 1, тогда тут другое значение".

5️⃣ Нейминг и ключи
🔘 использовать вменяемые нейминги (хотя бы кимбелловские)
🔘 surrogate key можно не городить, если технология позволяет нормально джойниться по натуральным ключам

6️⃣ View как интерфейс
Для пользователей всегда отдаём view, а не саму таблицу:
🔘 можно менять схему под капотом
🔘 можно вьюхой выбирать актуальный snapshot
🔘 пользователям не больно

Это очень скучные правила, но именно они позволяют делать модели быстро и не умирать от рефакторинга каждые 3 месяца.

〰️〰️〰️〰️〰️〰️〰️〰️
Порядок в DWH

#dev #de #dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
5❤‍🔥2😁111
Forwarded from Dealer.AI
Про разработку и AI-специалистов.

Дядя открывает рубрику #холиварвыходногодня. На рынке найма сталкиваюсь с заблуждением, что MCP должны создавать MLE или DS спецы. На самом деле, это придумано на замену API, для более нативной интеграции LLM и агентов с сервисами, т.к. обычные стандартные API для этого не подходят AS IS. А их доработки всеравно приведут вас к MCP-like. И делать это должны не ML-only спецы, а бэкендр разработчики, пусть и совместно с MLE, но при необходимости. При этом же я вижу кругом евангелистов агентов, которые вчерашние swe и другие представители разработки, и это, на мой взгляд, не с проста.

Действительно агентные системы это прикладной инструмент, который использует апи и AI-технологии вокруг, без необходимости знать детали работы LLM под капотом. Надо разделять разработку core технологий которые ложатся в основу agents и сами конструкторы агентных систем, для создания которых с уже готовыми блоками в виде библиотек, MCP, LLM ds/MLE уже не нужны. Свою работу они сделали, дали то, на чем это строится в лице моделей.

Моя позиция в том, что MCP и агентные системы, как прикладные решения, удел вчерашних разработчиков, когда как технологии (модели, алгоритмы консенсуса и др) в основании этого под капотом, удел ML/DL спецов. Причём, обратите внимание, как агентные системы нативны с тч зрения алгоритмики и архитектуры построения, что делает их проектирование разрабами более удобным и нативным для этих спецов.

Конечно все кругом хотят единорогов, которых очень мало, да ещё они имеют биас - или они больше разрабы или больше математики, редко когда они одинаково хороши в обоих местах.

А что думаете вы? Пишите в комментариях. 👇👇👇👇
Please open Telegram to view this post
VIEW IN TELEGRAM
💯41
🙂 4 проверки данных, которые дают 80% пользы

Если ты когда-либо видел, как неверные цифры попадают в отчёт к C-level — ты понимаешь, какой это треш. Доверие ломается мгновенно.

Важно фокусироваться на 4 типах DQ-проверок с максимальным ROI:

1️⃣ Table constraints
🔘 уникальность (id уникален)
🔘 not null там, где бизнес-логика не допускает пропусков
🔘 допустимые значения (enums, статусы, типы событий)

2️⃣ Referential integrity
🔘 каждый ключ измерения в факте должен существовать в соответствующем dimension
🔘 иначе join выкинет часть строк, и цифры поедут.

3️⃣ Reconciliation checks
🔘 сравниваем количество строк и ключевые агрегаты (выручка, количество заказов) между источником и витриной
🔘 допускаем небольшой дельта-порог, но не бесконечный

4️⃣ Metric variance
🔘 отслеживаем, насколько текущий запуск отличается от исторического диапазона
🔘 если привычно имеем +2–3%, а тут внезапно –40% — пора останавливать пайплайн.

📌 Фишка:
лучше иметь эти 4 хороших типа проверок, чем 40 рандомных, которые никто не смотрит.

Отдельно рекомендую использовать WAP-паттерн (write-audit-publish): сначала загрузили и проверили данные, потом только опубликовали конечную таблицу потребителям.

〰️〰️〰️〰️〰️〰️〰️〰️
Порядок в DWH

#dev #de #dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
210😁1💯1
😁10
😁7
▶️ Линейность (lineage) — без неё любой дебаг превращается в детективное расследование

Баг в отчёте — классика. Вопросы всегда одни и те же:
🔘 откуда вообще взялись эти цифры?
🔘 какой слой сломался — сырые данные, стейджинг, витрина?
🔘 где конкретно в цепочке логика пошла не туда?

Без data lineage всё это — ручной форензик в стиле "гуляем по кодовой базе и гадаем".

Что даёт нормальная линейность:

1️⃣ Быстрый ответ на вопрос "из каких таблиц и трансформаций родилась эта витрина?".

2️⃣ Возможность пройти путь: отчёт 🔜 витрина ➡️ факт/измерения 🔜 стейджинг 🔜 сырые данные.

3️⃣ В регуляторных областях (финансы, медицина) — это вообще must-have для аудита.

Многие современные тулзы уже умеют в lineage из коробки (dbt, SQLMesh и не только).

Но главный пойнт такой:

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

〰️〰️〰️〰️〰️〰️〰️〰️
Порядок в DWH

#dev #de #dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
163❤‍🔥1
😁13
⭐️ Единый источник правды для метрик — иначе все живут в разных реальностях

Со временем в компании становится:
🔘 всё больше метрик
🔘 всё больше команд
🔘 всё больше дашбордов, считающих "почти одно и то же, но чуть-чуть по-другому"

Без единого источника правды ты получаешь войну дашбордов: у маркетинга один LTV, у продукта другой, у финансов третий.

Критически важно держаться одной из двух стратегий (или гибрида):

1️⃣ Semantic layer
🟢 отдельный слой, где объявляются метрики: как считать, из чего, какие фильтры
🟢 все системы (BI, отчёты, сервисы) бьют запросами в этот слой и получают одно и то же определение.

2️⃣ Data mart с метриками
🟢 заранее считаем метрики в витринах
🟢 BI только читает уже готовые значения

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

〰️〰️〰️〰️〰️〰️〰️〰️
Порядок в DWH

#dev #de #dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
181
Нейродроны от neiry

🚀 Новая эра дронов — живых дронов. Neiry представила своих первых "птиц-биодронов" — реальных голубей с вживлёнными нейроинтерфейсами.

🧠 Как это работает: в мозг птицы имплантируют электроды, подключённые к контроллеру и стимулятору, который размещается в маленьком рюкзачке на спине. С его помощью оператор может задавать маршрут — и птица летит туда, куда нужно.

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

🔥 Преимущества перед обычными БПЛА: биодроны автономны — птица ведёт обычную жизнь, а электроника питается от солнечных батарей. Дальность полётов, выносливость и скрытность сильно выше.



❗️ По словам Neiry, проект уже переходит к реальным испытаниям и внедрению — возможно, подобные живые беспилотники мы увидим в деле совсем скоро.

#pigeon #drone #biodrone #bird #neiry
Please open Telegram to view this post
VIEW IN TELEGRAM
6😁1