Дайджест статей
Сори за задержку, разобрал немного архивы
📰 От каталога данных к платформе управления метаданными
🔗 https://habr.com/ru/companies/lemana_tech/articles/976350/
💡 Вывод: Лемана Тех за 2 года заменила Collibra собственной платформой. Ключевое решение — гибкая метамодель, где любой тип актива создаётся без разработчиков. 650 MAU, 25 типов активов, 26 автоматических экстракторов метаданных. Вывод для CDO: зрелый data governance требует не покупки вендора, а правильной культурной базы и гибкой ролевой модели, которую проприетарные решения обычно не дают.
📰 А что на входе? Разбираем структуру данных для AI-агента
🔗 https://habr.com/ru/articles/1007056/
💡 Вывод: При использовании LLM для анализа документации ключевой шаг — не промпт, а структура входных данных. Автор показывает пайплайн: ТЗ → атомарные требования → JSON-паспорт с числовыми признаками → дерево решений для классификации ошибок. LLM используется как feature extractor (не как чёрный ящик), а основная классификация — на дешёвом дереве решений. Accuracy ~82%, главное ограничение — субъективность разметки одним человеком.
📰 Do you know architecture of Recommendation System at Netflix?
🔗 https://shilpathota.medium.com/do-you-know-architecture-of-recommendation-system-at-netflix-f49786ca083b
💡 Вывод: Эволюция рекомендаций Netflix за 20 лет — от матричной факторизации до RL с бюджетным ограничением на время просмотра рекомендаций. Ключевая архитектурная идея — три слоя вычислений (offline/nearline/online) с разными trade-offs по latency и свежести данных. Свежий фронтир — CRAG (Collaborative Retrieval Augmented Generation), объединяющий LLM с коллаборативной фильтрацией для диалоговых рекомендаций.
📰 Data Warehouse, Data Lake, Data Lakehouse, Data Mesh: What They Are and How They Differ
🔗 https://luminousmen.substack.com/p/data-warehouse-data-lake-data-lakehouse
💡 Вывод: Системный обзор четырёх архитектур без фанатизма. Warehouse — для известных вопросов к известным данным. Lake — для гибкости и ML. Lakehouse — попытка убрать дублирование (одно хранилище + ACID через Iceberg/Delta). Mesh — ответ на организационную, а не техническую боль. Выбор определяется масштабом, зрелостью команд и типом данных, а не модным словом.
📰 Blazing Fast OLAP on Uber's Inventory and Catalog Data with Apache Pinot
🔗 https://www.uber.com/en-IN/blog/blazing-fast-olap-on-ubers-inventory-and-catalog-data-with-apache-pinot/
💡 Вывод: Uber использует Apache Pinot для OLAP на 10+ млрд записей каталога с latency 1-3 секунды и обновлением данных за 5-10 минут. Ключевые оптимизации: UUID hash-функция для первичных ключей (экономия 35% heap), Small Segment Merger (снижение p99 latency на 75%), переход с Java 11 на 17 (10-кратное улучшение tail latency). Если нужен real-time OLAP на больших объёмах — Pinot с upsert заслуживает внимания как альтернатива Hive/batch-подходам.
📰 Data Mesh Theology. Dead or Alive?
🔗 https://dataengineeringcentral.substack.com/p/data-mesh-theology-dead-or-alive
💡 Вывод: Data Mesh — идея, а не технология, и она работает только в крупных организациях с сильными техническими командами (Netflix, Wayfair, PayPal). Для 90% компаний децентрализация ownership создаёт больше проблем с governance, чем решает. Создатель концепции (Zhamak Dehghani) фактически ребрендирует идею в NextData, убирая акцент на «Mesh». Консенсус сообщества: хорошо в теории, но без серьёзных ресурсов — головная боль.
📰 Data Mesh is Dead (And That's Actually Good News)
🔗 https://medium.com/@aminsiddique95/data-mesh-is-dead-and-thats-actually-good-news
💡 Вывод Автор утверждает, что смерть Data Mesh как бренда — позитивный сигнал: полезные принципы (domain ownership, data-as-a-product) выживут и интегрируются в централизованные платформы без хаоса полной децентрализации.