Каждый раз, когда кто-то строит дашборд на твоей таблице, у тебя по сути покупают продукт. Только большинство команд этот продукт никак не описывает.
Data contract — это простой документ, который отвечает на вопрос аналитика/продукта:
Что я могу ожидать от этой таблицы, чтобы не накосячить?
Минимальный набор, который уже делает магию:
Что означает ОДНА строка?
Кратко и по делу, без воды.
Команда/человек, кто отвечает за таблицу + канал коммуникации.
Важно: data contract — это документ, а не тулза.
Фактическое соблюдение (валидации, алерты) — это уже вопрос инструментов.
Что меняется, когда у таблицы есть контракт:
Порядок в DWH
#dev #de #dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
Большинство бизнес-вопросов в нормальных компаниях решается через обычные fact + dimension таблицы в стиле Кимбелла. Без извращений.
Предлагаю тебе практичный сетап:
Простое правило:
Вставили строку в факт — больше её не обновляем (кроме осознанного backfill).
Плюсы:
Вместо сложных SCD2 везде:
Никаких "и по пользователю, и по заказу, и по клику в одной таблице". Только один чёткий grain.
Если колонка зависит от какого-то флага — лучше разнести в явно названные колонки, а не "если flag = 1, тогда тут другое значение".
Для пользователей всегда отдаём view, а не саму таблицу:
Это очень скучные правила, но именно они позволяют делать модели быстро и не умирать от рефакторинга каждые 3 месяца.
Порядок в DWH
#dev #de #dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
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 спецов. Причём, обратите внимание, как агентные системы нативны с тч зрения алгоритмики и архитектуры построения, что делает их проектирование разрабами более удобным и нативным для этих спецов.
Конечно все кругом хотят единорогов, которых очень мало, да ещё они имеют биас - или они больше разрабы или больше математики, редко когда они одинаково хороши в обоих местах.
А что думаете вы? Пишите в комментариях.👇 👇 👇 👇
Дядя открывает рубрику #холиварвыходногодня. На рынке найма сталкиваюсь с заблуждением, что 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
💯4 1
Если ты когда-либо видел, как неверные цифры попадают в отчёт к C-level — ты понимаешь, какой это треш. Доверие ломается мгновенно.
Важно фокусироваться на 4 типах DQ-проверок с максимальным ROI:
лучше иметь эти 4 хороших типа проверок, чем 40 рандомных, которые никто не смотрит.
Отдельно рекомендую использовать WAP-паттерн (write-audit-publish): сначала загрузили и проверили данные, потом только опубликовали конечную таблицу потребителям.
Порядок в DWH
#dev #de #dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
2 10😁1💯1
Баг в отчёте — классика. Вопросы всегда одни и те же:
Без data lineage всё это — ручной форензик в стиле "гуляем по кодовой базе и гадаем".
Что даёт нормальная линейность:
Многие современные тулзы уже умеют в lineage из коробки (dbt, SQLMesh и не только).
Но главный пойнт такой:
Если у тебя нет наглядной lineage-картинки, каждая проблема в данных будет стоить тебе или твоей команде человеко-дней, а не часов.
Порядок в DWH
#dev #de #dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
1 6 3❤🔥1
Со временем в компании становится:
Без единого источника правды ты получаешь войну дашбордов: у маркетинга один LTV, у продукта другой, у финансов третий.
Критически важно держаться одной из двух стратегий (или гибрида):
Общее правило:
Порядок в DWH
#dev #de #dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
1 8 1
Нейродроны от neiry
🚀 Новая эра дронов — живых дронов. Neiry представила своих первых "птиц-биодронов" — реальных голубей с вживлёнными нейроинтерфейсами.
🧠 Как это работает: в мозг птицы имплантируют электроды, подключённые к контроллеру и стимулятору, который размещается в маленьком рюкзачке на спине. С его помощью оператор может задавать маршрут — и птица летит туда, куда нужно.
🌍 Зачем это нужно: такие живые дроны могут использоваться для мониторинга инфраструктуры (линии электропередач, газовые узлы), экологического и промышленного контроля, поисково-спасательных операций, охраны и наблюдения.
🔥 Преимущества перед обычными БПЛА: биодроны автономны — птица ведёт обычную жизнь, а электроника питается от солнечных батарей. Дальность полётов, выносливость и скрытность сильно выше.
❗️ По словам Neiry, проект уже переходит к реальным испытаниям и внедрению — возможно, подобные живые беспилотники мы увидим в деле совсем скоро.
#pigeon #drone #biodrone #bird #neiry
#pigeon #drone #biodrone #bird #neiry
Please open Telegram to view this post
VIEW IN TELEGRAM
neiry.ru
Neiry представляет птиц-биодронов
Соберём картинку целиком.
Если ты хочешь строить быстрые и стабильные модели, которые уважают и бизнес, и инженерию, у тебя должны появиться:
чтобы показывать бизнесу прогресс в их координатах: процессы × разрезы.
чтобы каждая продовая таблица была продуктом с понятными ожиданиями.
чтобы пайплайны были простыми, а история — честной.
constraints, референциальная целостность, reconciliation, variance.
чтобы дебаг был техзадчей, а не расследованием.
чтобы в компании была одна реальность, а не десять.
Это тот редкий случай, когда набор простых практик:
Порядок в DWH
#dev #de #dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
2 5👏2 2 2
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
Автор статьи считает, что pandas «сдулся» для тяжёлых задач:
В следующих постах расскажу:
#apache #arrow #pandas #bigdata
Please open Telegram to view this post
VIEW IN TELEGRAM
Apache Arrow
The universal columnar format and multi-language toolbox for fast data interchange and in-memory analytics
1 5❤🔥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
Arrow закладывает новый memory-уровень — колонное, компактное, соседнее в памяти хранение всех значений столбца. Это даёт сразу несколько плюсов:
То есть Arrow — это фундамент, на котором можно строить более масштабируемые, быстрые и "бигдатаподобные" аналоги pandas-подходов.
Apache Arrow
#apache #arrow #pandas #bigdata
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
DE
Apache Arrow — это попытка решить главные внутренние проблемы pandas, связанные с производительностью, памятью и масштабируемостью. Он даёт эффективное, колонное, близкое к металлу представление данных, что открывает путь к работе с наборами, которые раньше…
2 6❤🔥1 1