Телеграм канал «Клуб CDO»

Дайджест статей

📰 OneDWH VK: как мы консолидировали данные 35 бизнес-вертикалей 🔗 https://habr.com/ru/companies/vk/articles/1064978/ 💡 Вывод: VK перенесла 0,5+ EB из 35 вертикалей на единую облачную платформу, сознательно отказавшись от переноса "как есть": каждый из 30 тысяч data-объектов описывался заново, с дедупликацией, data-контрактами и ролевой моделью вместо ручных заявок. Главный вывод авторов: успех единого DWH определяется не стеком, а способностью компании договориться о единых правилах работы с данными.

📰 Migrating a Data Platform: 20% technology, 80% everything else 🔗 https://medium.com/datamindedbe/migrating-a-data-platform-20-technology-80-everything-else-6a24472650f4 💡 Вывод: миграции проваливаются не на переводе SQL, а на несогласованных заранее критериях успеха, владении и порогах валидации. С AI-кодингом исполнение тривиализируется: миграция теперь 75% анализа и 25% execution, и ломается она там, где discovery-фазу пропустили как "непрогресс".

📰 8 Pillars of Modern Data Engineering 🔗 https://medium.com/@bvsarathc06/8-pillars-of-modern-data-engineering-5b36870c729f 💡 Вывод (по частичному тексту, пейволл Medium): инженерию данных преподают как список инструментов, хотя устойчивость даёт понимание анатомии системы, пути данных от источника до потребителя. Инструменты вроде dbt и Airflow - соединительная ткань, а не органы.

📰 Как я собрала локальную MCP-платформу для мониторинга промышленных данных 🔗 https://habr.com/ru/articles/1064802/ 💡 Вывод: воспроизводимый Docker Compose стенд (PostgreSQL, Airflow, MinIO, Superset, шесть MCP-сервисов, Ollama) с полным путём данных от ETL до пояснений метрик. Ключевой паттерн: LLM подключается после детерминированного расчёта и ограничена комментарием, числа формирует код.

📰 Чек-лист по настройке системы дашбординга 🔗 https://habr.com/ru/companies/magnit/articles/1061480/ 💡 Вывод: Magnit OMNI сводит типовые боли дашбординга к шести фреймам: процессы с заказчиками, базовая гигиена отчётов, единая точка входа, скорость доставки, доверие к метрикам, процессы развития. Итог - чек-лист с приоритетами, переводящий систему из реактивного режима в проактивный.

📰 Как «Дикси» мигрировала с Power BI на Sigla Vision за 5 месяцев 🔗 https://habr.com/ru/companies/glowbyte/articles/1063906/ 💡 Вывод (материал интегратора GlowByte): миграцию 155 дашбордов строили от ранжирования по использованию: сначала топ-5, обучение команды в процессе, затем спринт переноса. Платформу выбрали под порог входа команды, а не под функциональность; T2M сократился с 210 до 112 дней.

📰 Как LLM могут помочь определить Data Lineage 🔗 https://habr.com/ru/companies/sberbank/articles/1058618/ 💡 Вывод: Сбер извлекает target и sources из SQL через GigaChat: F1 0,92 у GigaChat 2 Pro на базовом промпте, агент-рефлексия на LangGraph довёл до 0,93. Lineage позиционируется не как документация, а как механизм управления миграциями: заранее видны все потребители данных.

📰 Как мы подружили LLM с А/Б-тестами 🔗 https://habr.com/ru/companies/vk/articles/1063862/ 💡 Вывод: Дзен ушёл от BI, не потянувшего объём, к генерируемым HTML-отчётам с ботом как точкой входа. LLM работает "микроштатным аналитиком" и даёт итоговую рекомендацию по раскатке с учётом стратегического контекста компании. Переопределение успешного А/Б: важно не "всё зелёное", а кто именно выиграл и проиграл.

📰 Дата-агенты поверх BI: кто такая Dora 🔗 https://habr.com/ru/companies/glowbyte/articles/1064590/ 💡 Вывод (перевод вендора FanRuan с комментарием GlowByte): дата-агенты автоматизируют цепочку от алерта до задачи поверх готовых BI-активов: моделей, метрик, прав доступа. Ценная оговорка интегратора: агент наследует текущий беспорядок, три способа считать выручку станут тремя уверенными ответами, а фильтры интерфейса превращаются в контур безопасности.

Регулирование AI надвигается волнами :) первая полна - Еврокомиссия со 02/08 вводит правда прозрачности в использовании ИИ

Чатботы обязаны раскрывать, что пользователь имеет дело с AI, а не человеком. Дипфейки должны быть про маркированы. AI-контент должен нести машиночитаемые метки для детекции.

Запрещенные практики становятся enforceable. Запрещены системы, которые манипулируют людьми, эксплуатируют их уязвимости, несправедливо скорят их с угрозой правам или ведут индивидуальный predictive policing на базе профилирования.

Так же вводятся обязательства GPAI-провайдеров: прозрачность для downstream-провайдеров, соблюдение копирайта, плюс требования security и safety для самых продвинутых моделей.

https://digital-strategy.ec.europa.eu/en/news/commission-starts-enforcing-ai-act-rules-and-new-transparency-requirements-2-august

Попалась подборка open source инструментов, делюсь:

SQLFluff (github.com/sqlfluff/sqlfluff). Линтер и форматтер для SQL, самый звёздный на GitHub в своей категории. Ловит кривой SQL до продакшена: стиль, синтаксис, дрейф схемы. Ставится pre-commit хуком или в CI/CD рядом с dbt, понимает диалекты Spark SQL и Databricks. Скучный инструмент, который экономит нескучные часы код-ревью.

Splink (github.com/moj-analytical-services/splink). Entity resolution: дедупликация и связывание записей, у которых нет общего идентификатора. Вероятностный матчинг без размеченных данных, миллион записей на обычном ноутбуке примерно за минуту. Локально работает на DuckDB, на сотнях миллионов записей масштабируется на Spark или Athena. Отдельно радует происхождение: инструмент сделали аналитики британского Министерства юстиции.

Apache DataFusion (datafusion.apache.org). Query engine на Rust поверх Apache Arrow. Ключевое слово - модульность: его встраивают в свои продукты как движок исполнения запросов, вместо того чтобы тащить целую платформу. Именно на таких движках сейчас собирают лёгкие альтернативы Spark.

Sail (github.com/lakehq/sail), Rust-замена Spark с совместимостью на уровне протокола, и вечные DuckDB (duckdb.org) с Polars (pola.rs), которые все знают и мало кто использует всерьёз.

Редкий случай, когда OLAP-движок работает как key-value хранилище.

Momentic перенесли кэш своих браузерных агентов с Postgres на ClickHouse когда кэш вырос с 80 тысяч записей до миллиарда.

Интересно, что ClickHouse для точечных lookups это антипаттерн, о котором написано в каждом втором гайде. Но у них сработало, потому что запрос ровно один: достать кэш по тесту, версии, ветке и коммиту.

Хороший пример того, как решение было выбрано и реализовано точно под задачу, без попыток найти "универсального" решение для любого случая

https://momentic.ai/blog/postgres-to-clickhouse-migration

Редкий случай, когда OLAP-движок работает как key-value хранилище.

Momentic перенесли кэш своих браузерных агентов с Postgres на ClickHouse когда кэш вырос с 80 тысяч записей до миллиарда.

Интересно, что ClickHouse для точечных lookups это антипаттерн, о котором написано в каждом втором гайде. Но у них сработало, потому что запрос ровно один: достать кэш по тесту, версии, ветке и коммиту.

Хороший пример того, как решение было выбрано и реализовано точно под задачу, без попыток найти "универсального" решение для любого случая

https://momentic.ai/blog/postgres-to-clickhouse-migration

ИИ-пилот сработал. Почему компания всё равно теряет деньги?

Успешный пилот ещё не означает, что проект принесёт бизнесу пользу. После масштабирования расходы могут вырасти, качество — снизиться, а обещанная экономия так и остаться «сэкономленными часами» в отчёте.

6 августа в 18:30 на бесплатном вебинаре разберём:

📌 как считать реальную экономику ГенИИ-проектов;
📌 почему быстрый пилот может оказаться дорогим решением;
📌 какие ошибки чаще всего приводят к потерям;
📌 как оценивать TCO, риски и стоимость масштабирования;
📌 по каким метрикам принимать решение: запускать проект или остановить.

Спикер — Мурат Хажгериев, технический директор в stresstech-стартапе Pillloai, эксперт Центра непрерывного образования ФКН НИУ ВШЭ.

Покажем российские и зарубежные кейсы и дадим практический фреймворк для оценки GenAI-проектов до крупных вложений.

Зарегистрироваться

#мероприятия_ИИ

@aileadershse