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
✏️ 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
Всё вместе: как этим реально пользоваться 🌟

Соберём картинку целиком.

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

1️⃣ Bus matrix
чтобы показывать бизнесу прогресс в их координатах: процессы × разрезы.

2️⃣Data contracts
чтобы каждая продовая таблица была продуктом с понятными ожиданиями.

3️⃣ Insert-only факты и snapshot-измерения
чтобы пайплайны были простыми, а история — честной.

4️⃣ 4 базовых DQ-паттерна
constraints, референциальная целостность, reconciliation, variance.

5️⃣ Lineage
чтобы дебаг был техзадчей, а не расследованием.

6️⃣ Централизованные метрики
чтобы в компании была одна реальность, а не десять.

Это тот редкий случай, когда набор простых практик:
🟢 снимает кучу боли у дата-инженеров
🟢 делает бизнес счастливее
🟢 помогает тебе выглядеть взрослым инженером, а не человеком, который крутит SQL по запросу

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

#dev #de #dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
25👏222
😁8
DE
pandas 2.0.0 Встречаем новый pandas с Apache Arrow, теперь очень быстро 🐼
Apache Arrow — это попытка решить главные внутренние проблемы pandas, связанные с производительностью, памятью и масштабируемостью. Он даёт эффективное, колонное, близкое к металлу представление данных, что открывает путь к работе с наборами, которые раньше были просто нереалистичны в pandas.

Автор статьи считает, что pandas «сдулся» для тяжёлых задач:
🔘 Когда автор начинал писать pandas в 2008, задачи были проще, рамок не было для анализа сотен гигабайт — внутренности pandas (через BlockManager, NumPy и Python-объекты) были адекватны.
🔘Современные сценарии часто подразумевают большие данные. По грубой оценке автора, чтобы безопасно работать с датасетом ~10 ГБ, нужно 64–128 ГБ RAM.
🔘Кроме того, представление строк и других типов через отдельные Python-объекты размазывает данные по куче — жёстко бьёт по памяти и скорости.

В следующих постах расскажу:
🔘Плюсы Apache Arrow
🔘Что даёт на практике
🔘Когда Arrow даёт преимущество

#apache #arrow #pandas #bigdata
Please open Telegram to view this post
VIEW IN TELEGRAM
15❤‍🔥3👏2😁1
Плюсы Apache Arrow

Arrow закладывает новый memory-уровень — колонное, компактное, соседнее в памяти хранение всех значений столбца. Это даёт сразу несколько плюсов:

🟣Данные хранятся contiguously — т.е. подряд в памяти, что снижает количество промахов кэша и повышает производительность при сканировании столбцов.

🟣Поддержка null / пропусков (missing data) на уровне битовой маски: отдельная карта битов, быстрая проверка, оптимизация путей, когда null отсутствуют.

🟣Возможность мемаппинга больших датасетов — работать с таблицами, превышающими RAM, как с mmap-файлами, читать куски данных без загрузки всего.

🟣Эффективная поддержка категориальных данных (categorical / dictionary types) — не костыли, а родной тип.

🟣Более "нормальное" добавление данных / апенд — благодаря chunked/streamed колонной структуре, можно делать append без жёсткого переписывания всего столбца.

🟣Широкая типизация и возможность добавлять новые типы данных с гибким мета-описанием, расширяемое.

То есть Arrow — это фундамент, на котором можно строить более масштабируемые, быстрые и "бигдатаподобные" аналоги pandas-подходов.

Apache Arrow

#apache #arrow #pandas #bigdata
Please open Telegram to view this post
VIEW IN TELEGRAM
26❤‍🔥11
😁8