Forwarded from Клуб CDO
Дайджест статей
📰: Путь в аналитику данных: базовый минимум для старта
Ссылка: https://habr.com/ru/articles/1003704/
Вывод одной строкой: Для успешного входа в аналитику данных необходимо освоить SQL, Python/R, основы статистики и визуализации данных, а также развивать навыки работы с бизнес-задачами и критического мышления, постепенно наращивая экспертизу через практические проекты и непрерывное обучение.
📰: BI-аналитик: стартовый пакет необходимых навыков
Ссылка: https://habr.com/ru/articles/1004298/
Вывод одной строкой: Для успешной работы BI-аналитиком необходимо освоить SQL для работы с базами данных, инструменты визуализации данных (Tableau, Power BI), основы статистики и аналитического мышления, а также развить навыки коммуникации для эффективного представления результатов анализа бизнес-заказчикам.
📰: Как мы улучшили рекомендации для пользователей Авито с помощью трансформенной персонализации
Ссылка: https://habr.com/ru/companies/avito/articles/1004694/
Вывод одной строкой: Трансформерная архитектура с механизмом внимания позволяет значительно повысить качество рекомендательных систем за счет более точного моделирования последовательности действий пользователя и учета долгосрочных зависимостей в его поведении.
📰: Data Mesh, Data Fabric, Lakehouse: разбираем модные термины
Ссылка: https://habr.com/ru/articles/1005062/
Вывод одной строкой: Современные архитектурные подходы Data Mesh, Data Fabric и Lakehouse решают разные задачи управления данными: децентрализацию и демократизацию доступа, интеллектуальную интеграцию разрозненных источников и унификацию аналитических и транзакционных нагрузок соответственно, поэтому выбор конкретного решения должен основываться на организационной структуре компании, существующей инфраструктуре и бизнес-целях.
📰: Data catalog есть, а пользы нет: Частые ошибки внедрения
Ссылка: https://habr.com/ru/articles/1003158/
Вывод одной строкой: Успешное внедрение каталога данных требует не только технической реализации, но и активного вовлечения пользователей, четкого определения процессов управления метаданными и постоянной поддержки культуры работы с данными в организации.
📰: Путь в аналитику данных: базовый минимум для старта
Ссылка: https://habr.com/ru/articles/1003704/
Вывод одной строкой: Для успешного входа в аналитику данных необходимо освоить SQL, Python/R, основы статистики и визуализации данных, а также развивать навыки работы с бизнес-задачами и критического мышления, постепенно наращивая экспертизу через практические проекты и непрерывное обучение.
📰: BI-аналитик: стартовый пакет необходимых навыков
Ссылка: https://habr.com/ru/articles/1004298/
Вывод одной строкой: Для успешной работы BI-аналитиком необходимо освоить SQL для работы с базами данных, инструменты визуализации данных (Tableau, Power BI), основы статистики и аналитического мышления, а также развить навыки коммуникации для эффективного представления результатов анализа бизнес-заказчикам.
📰: Как мы улучшили рекомендации для пользователей Авито с помощью трансформенной персонализации
Ссылка: https://habr.com/ru/companies/avito/articles/1004694/
Вывод одной строкой: Трансформерная архитектура с механизмом внимания позволяет значительно повысить качество рекомендательных систем за счет более точного моделирования последовательности действий пользователя и учета долгосрочных зависимостей в его поведении.
📰: Data Mesh, Data Fabric, Lakehouse: разбираем модные термины
Ссылка: https://habr.com/ru/articles/1005062/
Вывод одной строкой: Современные архитектурные подходы Data Mesh, Data Fabric и Lakehouse решают разные задачи управления данными: децентрализацию и демократизацию доступа, интеллектуальную интеграцию разрозненных источников и унификацию аналитических и транзакционных нагрузок соответственно, поэтому выбор конкретного решения должен основываться на организационной структуре компании, существующей инфраструктуре и бизнес-целях.
📰: Data catalog есть, а пользы нет: Частые ошибки внедрения
Ссылка: https://habr.com/ru/articles/1003158/
Вывод одной строкой: Успешное внедрение каталога данных требует не только технической реализации, но и активного вовлечения пользователей, четкого определения процессов управления метаданными и постоянной поддержки культуры работы с данными в организации.
Хабр
Путь в аналитику данных: базовый минимум для старта
❓Кто такой аналитик данных и зачем он нужен Аналитик данных — это специалист, который умеет доставать данные, очищать и фильтровать их, проводить исследование, визуализировать и интерпретировать...
This media is not supported in your browser
VIEW IN TELEGRAM
Создание соединений в Слайдер Данные
👍1
СД Excel Работа с отчетами SQL | Создание модели ROLAP
Дайджест статей
📰: Architectural Standards for Data Products and AI Interactions: Emergent & Aligned Patterns
Ссылка: https://moderndata101.substack.com/p/architecture-data-products-ai-interactions?publication_id=1170209&post_id=188149190&isFreemail=true&r=15862q&triedRedirect=true
Вывод одной строкой: Успешная архитектура данных и ИИ-продуктов требует применения согласованных паттернов проектирования, которые обеспечивают масштабируемость, надежность и эффективное взаимодействие между компонентами системы через стандартизированные интерфейсы и протоколы обмена данными.
📰: Data Mesh vs централизованная модель: выбираем оптимальный подход к управлению данными
Ссылка: https://habr.com/ru/companies/vk/articles/1005846/
Вывод одной строкой: Выбор между Data Mesh и централизованной моделью управления данными зависит от масштаба организации, сложности доменов, зрелости команд и требований к автономности подразделений, при этом Data Mesh подходит для крупных компаний с множественными доменами данных, а централизованная модель эффективнее для небольших организаций с ограниченными ресурсами.
📰: Почему Lakehouse нельзя построить без Spark
Ссылка: https://habr.com/ru/companies/datasapience/articles/1007428/
Вывод одной строкой: Apache Spark является критически важным компонентом для построения архитектуры Lakehouse, поскольку обеспечивает единую платформу для обработки структурированных и неструктурированных данных с возможностями как пакетной, так и потоковой обработки, что делает его незаменимым для реализации концепции объединения преимуществ озер данных и хранилищ данных.
📰: Корпоративная память как инфраструктура: как мы построили RAG-систему внутри ИТ-компании с промышленной экспертизой
Ссылка: https://habr.com/ru/companies/zyfra/articles/1007356/
Вывод одной строкой: Построение корпоративной RAG-системы требует тщательного планирования архитектуры данных, выбора подходящих методов векторизации и индексации, а также создания эффективных механизмов поиска и ранжирования релевантной информации для обеспечения качественной работы с корпоративными знаниями.
📰: Инструментарий аналитика данных: что реально нужно освоить в 2026 году
Ссылка: https://habr.com/ru/articles/1007780/
Вывод одной строкой: Современному аналитику данных критически важно сосредоточиться на освоении SQL, Python, инструментов визуализации данных и базовых принципов машинного обучения, поскольку эти навыки остаются фундаментальными независимо от появления новых технологий и трендов в области данных.
📰: The Data Team’s Survival Guide for the Next Era of Data | Towards Data Science
Ссылка: https://towardsdatascience.com/the-data-teams-survival-guide-for-the-next-era-of-data/
Вывод одной строкой: Я не могу получить доступ к содержимому статьи по предоставленной ссылке, поэтому не могу написать конкретный вывод на основе её материала. Чтобы помочь вам сформулировать вывод, мне потребуется текст статьи или её основные тезисы. Пожалуйста, скопируйте содержание статьи или её ключевые моменты, и я смогу составить краткий вывод в одно предложение для инженера по данным.
📰: Data Ownership in Practice: Defining Decision Rights in Enterprise Data Governance
Ссылка: https://moderndata101.substack.com/p/data-ownership-in-practice-defining?publication_id=1170209&post_id=187760032&isFreemail=true&r=15862q&triedRedirect=true
Вывод одной строкой: Эффективное управление корпоративными данными требует четкого распределения прав принятия решений между владельцами данных, их хранителями и потребителями, что обеспечивает качество данных, соблюдение требований безопасности и максимизацию бизнес-ценности информационных активов.
📰: Architectural Standards for Data Products and AI Interactions: Emergent & Aligned Patterns
Ссылка: https://moderndata101.substack.com/p/architecture-data-products-ai-interactions?publication_id=1170209&post_id=188149190&isFreemail=true&r=15862q&triedRedirect=true
Вывод одной строкой: Успешная архитектура данных и ИИ-продуктов требует применения согласованных паттернов проектирования, которые обеспечивают масштабируемость, надежность и эффективное взаимодействие между компонентами системы через стандартизированные интерфейсы и протоколы обмена данными.
📰: Data Mesh vs централизованная модель: выбираем оптимальный подход к управлению данными
Ссылка: https://habr.com/ru/companies/vk/articles/1005846/
Вывод одной строкой: Выбор между Data Mesh и централизованной моделью управления данными зависит от масштаба организации, сложности доменов, зрелости команд и требований к автономности подразделений, при этом Data Mesh подходит для крупных компаний с множественными доменами данных, а централизованная модель эффективнее для небольших организаций с ограниченными ресурсами.
📰: Почему Lakehouse нельзя построить без Spark
Ссылка: https://habr.com/ru/companies/datasapience/articles/1007428/
Вывод одной строкой: Apache Spark является критически важным компонентом для построения архитектуры Lakehouse, поскольку обеспечивает единую платформу для обработки структурированных и неструктурированных данных с возможностями как пакетной, так и потоковой обработки, что делает его незаменимым для реализации концепции объединения преимуществ озер данных и хранилищ данных.
📰: Корпоративная память как инфраструктура: как мы построили RAG-систему внутри ИТ-компании с промышленной экспертизой
Ссылка: https://habr.com/ru/companies/zyfra/articles/1007356/
Вывод одной строкой: Построение корпоративной RAG-системы требует тщательного планирования архитектуры данных, выбора подходящих методов векторизации и индексации, а также создания эффективных механизмов поиска и ранжирования релевантной информации для обеспечения качественной работы с корпоративными знаниями.
📰: Инструментарий аналитика данных: что реально нужно освоить в 2026 году
Ссылка: https://habr.com/ru/articles/1007780/
Вывод одной строкой: Современному аналитику данных критически важно сосредоточиться на освоении SQL, Python, инструментов визуализации данных и базовых принципов машинного обучения, поскольку эти навыки остаются фундаментальными независимо от появления новых технологий и трендов в области данных.
📰: The Data Team’s Survival Guide for the Next Era of Data | Towards Data Science
Ссылка: https://towardsdatascience.com/the-data-teams-survival-guide-for-the-next-era-of-data/
Вывод одной строкой: Я не могу получить доступ к содержимому статьи по предоставленной ссылке, поэтому не могу написать конкретный вывод на основе её материала. Чтобы помочь вам сформулировать вывод, мне потребуется текст статьи или её основные тезисы. Пожалуйста, скопируйте содержание статьи или её ключевые моменты, и я смогу составить краткий вывод в одно предложение для инженера по данным.
📰: Data Ownership in Practice: Defining Decision Rights in Enterprise Data Governance
Ссылка: https://moderndata101.substack.com/p/data-ownership-in-practice-defining?publication_id=1170209&post_id=187760032&isFreemail=true&r=15862q&triedRedirect=true
Вывод одной строкой: Эффективное управление корпоративными данными требует четкого распределения прав принятия решений между владельцами данных, их хранителями и потребителями, что обеспечивает качество данных, соблюдение требований безопасности и максимизацию бизнес-ценности информационных активов.
Substack
Architectural Standards for Data Products and AI Interactions: Emergent & Aligned Patterns
The Emergence of Unified Standards: From MCPs and Data Products to Unified Data Platforms. Unifying Purpose, Platform, and Protocol to Scale Intelligence
Обновления в Слайдер Данных
1) Прокси стартует в windows из под сессии пользователя - и имеет доступ ко всем сетевым ресурсам что и пользователь
2) Добавили "запускатель" , что бы пользователь мог сам управлять процессом
3) Исправили ошибки с сохранением результатов запросов во внешний файл
4) Переделали интеграцию с прокси на потоковый режим - теперь мы можем обрабатывать на прокси датасеты более чем на 1Gb
5) Единая установка и для Р7 Офис и для Excel
https://disk.yandex.ru/d/DXg_yeIlOtg2Bg
1) Прокси стартует в windows из под сессии пользователя - и имеет доступ ко всем сетевым ресурсам что и пользователь
2) Добавили "запускатель" , что бы пользователь мог сам управлять процессом
3) Исправили ошибки с сохранением результатов запросов во внешний файл
4) Переделали интеграцию с прокси на потоковый режим - теперь мы можем обрабатывать на прокси датасеты более чем на 1Gb
5) Единая установка и для Р7 Офис и для Excel
https://disk.yandex.ru/d/DXg_yeIlOtg2Bg
Forwarded from дата инженеретта
Датаклассы
Наконец-то спустя год дошли руки написать про датаклассы🌷 Меня спросили на собесе в ламоду, и тогда я про них либо краем уха слышала, либо вообще не слышала. Но точно не использовала. Посмотрим, что с ними можно делать
Зачем?
Датакласс описывает данные, но без кучи лишних методов. Он сам вместо нас добавит
Как создать?
Чтобы датаклассы заработали, нужно их импорнуть и добавить в виде аннотации:
Готово! Никакие методы добавлять не нужно
Как использовать?
Другие фишки
Запрещаем менять поля:
Задаем дефолтные значения:
Чуть подробнее можно прочитать в короткой статье
@data_engineerette
Наконец-то спустя год дошли руки написать про датаклассы
Зачем?
Датакласс описывает данные, но без кучи лишних методов. Он сам вместо нас добавит
__init__, __repr__, __eq__ по дефолту. Набор методов можем сами менять с помощью флаговКак создать?
Чтобы датаклассы заработали, нужно их импорнуть и добавить в виде аннотации:
from dataclasses import dataclass
@dataclass
class SparkParams:
"""Dataclass для параметров spark-submit команды."""
name: str
deploy_mode: str
driver_cores: int
driver_memory: str
executor_cores: int
executor_memory: str
num_executors: int
Готово! Никакие методы добавлять не нужно
Как использовать?
spark_params = SparkParams("test_app", "cluster", 2, "4g", 4, "32g", 8)
Другие фишки
Запрещаем менять поля:
@dataclass(frozen=True)
Задаем дефолтные значения:
@dataclass
class Team:
description: str | None = None
emails: list[str] = field(default_factory=list) # для list/dict/set
Чуть подробнее можно прочитать в короткой статье
@data_engineerette
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Инжиниринг Данных
В прошлом году Databricks купил Neon.
Основатели Neon:
• Никита Шамгунов - CEO и идейный вдохновитель Россиянин, PhD по Computer Science из Санкт-Петербурга
• Хейкки Линнакангас - Co-founder, Postgres-хакер
Финн, один из самых известных core committer'ов PostgreSQL с 20+ летним стажем.
• Стас Кельвич - Co-founder, инженер. Изучал физику, затем пришёл в разработку — работал в Яндексе в команде баз данных.
Команда собралась вокруг одной идеи: "что если сделать для Postgres то же, что Amazon Aurora сделала для MySQL/Postgres, но open-source и по-настоящему serverless?"
Amazon Aurora это serverless Postgres, но это как бы vendor lock.
У Neon было три основных этапа/фичи:
1️⃣ Разделение слоев давало serverless-поведение: scale-to-zero, оплата только за реальное использование, "бездонное" хранилище.
2️⃣ Разделение compute и storage открыло неожиданную суперспособность - branching базы данных через copy-on-write. Создать полную копию базы с данными и схемой стало бесплатным по времени и почти бесплатным по стоимости.
Кстати Snowflake zero-copy cloning имеет похожую идею copy-on-write - клон/ветка не копирует данные физически, а создаёт метаданные-указатели на те же блоки хранилища. Новые данные записываются только при изменениях. Оба мгновенные и почти бесплатные по хранилищу. Только у Neon каждая ветка это свой изолированный Postgres. Благодаря этому у каждой ветки свой compute и не влияет на продакшн базу данных.
3️⃣ Neon обнаружил, что 80% баз на их платформе создаются кодом, а не людьми. AI-агенты и платформы вроде Replit Agent стали создавать тысячи эфемерных баз на лету - под каждого пользователя, под каждый эксперимент. Один инженер в Retool управлял через Neon API 300,000 Postgres-инстансов.
Для Databricks это решение понравилось, ведь они уже работаю с AI агентами, каждый агент получает свою изолированную базу данных, и сама идея Zero ETL не нова, и Neon позволяет использовать OLTP workloads и хранить данные сразу в Databricks, ведь Neon хранит данные в облачном object storage (S3/ADLS/GCS), то есть буквально в том же хранилище, что и lakehouse.
И вот Databricks закончил интеграцию и назвал продукт/фичу - Lakebase. Это Postgres версии 16/17. Так же Databricks приобрел Mooncake для лучшей интеграции Postgres с Lakehouse.
Neon дал serverless Postgres compute, но данные в нём хранились в Postgres-формате — отдельно от lakehouse.
Чтобы аналитические движки (Spark, Databricks SQL) могли их читать, нужно было либо копировать данные через ETL, либо держать два источника правды.
Mooncake закрыл этот gap: вместо того чтобы копировать данные из Postgres в lakehouse, он делает Iceberg основным хранилищем. Postgres пишет сразу в Iceberg/Parquet в S3 - и тот же файл без какого-либо ETL читают и приложения через Postgres, и аналитика через Spark.
Есть еще Synced Tables - это отдельный, более старый механизм для обратного направления: когда нужно "опустить" уже готовые аналитические данные из Unity Catalog в Lakebase, чтобы приложение могло читать их с низкой латентностью (< 10 мс) (Reverse ETL). Здесь дублирование данных неизбежно — потому что аналитический Parquet нужно переложить в row-формат Postgres для быстрых point-lookup запросов.
PS Работаю часто с Databricks, пока реальных кейсов на Lakebase Postgres не видел =/
Основатели Neon:
• Никита Шамгунов - CEO и идейный вдохновитель Россиянин, PhD по Computer Science из Санкт-Петербурга
• Хейкки Линнакангас - Co-founder, Postgres-хакер
Финн, один из самых известных core committer'ов PostgreSQL с 20+ летним стажем.
• Стас Кельвич - Co-founder, инженер. Изучал физику, затем пришёл в разработку — работал в Яндексе в команде баз данных.
Команда собралась вокруг одной идеи: "что если сделать для Postgres то же, что Amazon Aurora сделала для MySQL/Postgres, но open-source и по-настоящему serverless?"
Amazon Aurora это serverless Postgres, но это как бы vendor lock.
У Neon было три основных этапа/фичи:
Кстати Snowflake zero-copy cloning имеет похожую идею copy-on-write - клон/ветка не копирует данные физически, а создаёт метаданные-указатели на те же блоки хранилища. Новые данные записываются только при изменениях. Оба мгновенные и почти бесплатные по хранилищу. Только у Neon каждая ветка это свой изолированный Postgres. Благодаря этому у каждой ветки свой compute и не влияет на продакшн базу данных.
Для Databricks это решение понравилось, ведь они уже работаю с AI агентами, каждый агент получает свою изолированную базу данных, и сама идея Zero ETL не нова, и Neon позволяет использовать OLTP workloads и хранить данные сразу в Databricks, ведь Neon хранит данные в облачном object storage (S3/ADLS/GCS), то есть буквально в том же хранилище, что и lakehouse.
И вот Databricks закончил интеграцию и назвал продукт/фичу - Lakebase. Это Postgres версии 16/17. Так же Databricks приобрел Mooncake для лучшей интеграции Postgres с Lakehouse.
Mooncake Labs - это маленький стартап (основан в 2024 году), который сделал одну очень конкретную вещь: pg_mooncake — Postgres-расширение, которое добавляет колоночное хранилище прямо внутрь Postgres, сохраняя данные в формате Apache Iceberg/Delta Lake в object storage.
Под капотом происходит следующее:
• Данные хранятся не в Postgres heap (row-формат), а в Parquet-файлах в S3 в формате Iceberg
• Аналитические запросы выполняются через DuckDB (встроен в расширение) - векторизованный движок, заточенный под колоночное чтение
Neon дал serverless Postgres compute, но данные в нём хранились в Postgres-формате — отдельно от lakehouse.
Чтобы аналитические движки (Spark, Databricks SQL) могли их читать, нужно было либо копировать данные через ETL, либо держать два источника правды.
Mooncake закрыл этот gap: вместо того чтобы копировать данные из Postgres в lakehouse, он делает Iceberg основным хранилищем. Postgres пишет сразу в Iceberg/Parquet в S3 - и тот же файл без какого-либо ETL читают и приложения через Postgres, и аналитика через Spark.
Есть еще Synced Tables - это отдельный, более старый механизм для обратного направления: когда нужно "опустить" уже готовые аналитические данные из Unity Catalog в Lakebase, чтобы приложение могло читать их с низкой латентностью (< 10 мс) (Reverse ETL). Здесь дублирование данных неизбежно — потому что аналитический Parquet нужно переложить в row-формат Postgres для быстрых point-lookup запросов.
PS Работаю часто с Databricks, пока реальных кейсов на Lakebase Postgres не видел =/
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Weekly Charts
🌻 Pi Day
Вчера (14 марта) был День числа Пи (3/14). Визуализируем с помощью #R и #ggplot2 первые 1 000 знаков числа Пи. В сердце этой визуализации — математически совершенный узор, который природа миллионы лет использует в подсолнухах и шишках для идеальной упаковки семян (филлотаксис).
Секрет в золотом угле (≈137.5°), который заставляет цифры числа Пи в виде точек занимать всё свободное пространство, не образуя пустых рядов или "швов". Чтобы узор оставался равномерным, используется спираль Ферма и модель Фогеля (r = √i). Квадратный корень удерживает плотность точек одинаковой как в центре, так и на краях, превращая бесконечный цифровой хаос в гармоничный "математический цветок".
Постер Pi Day в формате A4 300 dpi. Код постера на GitHub.
#pi #ggplot2 #R #rstats #dataviz #generative_art
Вчера (14 марта) был День числа Пи (3/14). Визуализируем с помощью #R и #ggplot2 первые 1 000 знаков числа Пи. В сердце этой визуализации — математически совершенный узор, который природа миллионы лет использует в подсолнухах и шишках для идеальной упаковки семян (филлотаксис).
Секрет в золотом угле (≈137.5°), который заставляет цифры числа Пи в виде точек занимать всё свободное пространство, не образуя пустых рядов или "швов". Чтобы узор оставался равномерным, используется спираль Ферма и модель Фогеля (r = √i). Квадратный корень удерживает плотность точек одинаковой как в центре, так и на краях, превращая бесконечный цифровой хаос в гармоничный "математический цветок".
Постер Pi Day в формате A4 300 dpi. Код постера на GitHub.
#pi #ggplot2 #R #rstats #dataviz #generative_art
❤2
Forwarded from Крохмалюк
💡 9 личных наблюдений о маркетинге и росте продуктов, которые хотелось бы знать 5 лет назад
1. Самая большая проблема в компаниях любого размера — специальная или случайная манипуляция с данными. По личным наблюдениям, 80%+ экспериментов в компаниях проводятся криво, а количество честных экспериментов в интернете стремится к нулю.
2. Самый переоценённый источник данных — рыночные исследования. Подробно изучить 10 конкурентов и похожих продуктов >>> псевдонаучные выводы на непонятной выборке.
3. Если доля платного трафика не уменьшается каждый год — вы что-то делаете не так. Абсолюты могут расти, но доля должна падать.
4. 99% продуктов не нужно проводить эксперименты. Мало трафика, нет инфраструктуры, нет процессов, нет экспертизы, слабые гипотезы и т.д. Лучший путь для них: найти того, кто заранее знает, что с большой вероятностью сработает.
5. Продукт без ретеншена и дешевого/бесплатного трафика = продавец на Wildberries. Уважаемо, ничего плохого нет, что-то заработать можно, но на дистанции будете страдать.
6. Нет ничего бесполезнее брейншторма, к которому никто заранее не готовился и пытается придумать решение на ходу.
7. Чем круче growth/маркетинговый канал, тем более стыдно показывать его в паблике.
8. Корреляция ≠ каузация. Все знают разницу в теории (два события идут рядом vs одно вызывает другое), но на практике большая часть продуктовых решений строится именно так: видят совпадение → делают фичу → удивляются, почему не сработало.
9. Стратегически заработок денег почти всегда про счастье пользователя. Тактически почти всегда не про счастье пользователя.
1. Самая большая проблема в компаниях любого размера — специальная или случайная манипуляция с данными. По личным наблюдениям, 80%+ экспериментов в компаниях проводятся криво, а количество честных экспериментов в интернете стремится к нулю.
2. Самый переоценённый источник данных — рыночные исследования. Подробно изучить 10 конкурентов и похожих продуктов >>> псевдонаучные выводы на непонятной выборке.
3. Если доля платного трафика не уменьшается каждый год — вы что-то делаете не так. Абсолюты могут расти, но доля должна падать.
4. 99% продуктов не нужно проводить эксперименты. Мало трафика, нет инфраструктуры, нет процессов, нет экспертизы, слабые гипотезы и т.д. Лучший путь для них: найти того, кто заранее знает, что с большой вероятностью сработает.
5. Продукт без ретеншена и дешевого/бесплатного трафика = продавец на Wildberries. Уважаемо, ничего плохого нет, что-то заработать можно, но на дистанции будете страдать.
6. Нет ничего бесполезнее брейншторма, к которому никто заранее не готовился и пытается придумать решение на ходу.
7. Чем круче growth/маркетинговый канал, тем более стыдно показывать его в паблике.
8. Корреляция ≠ каузация. Все знают разницу в теории (два события идут рядом vs одно вызывает другое), но на практике большая часть продуктовых решений строится именно так: видят совпадение → делают фичу → удивляются, почему не сработало.
9. Стратегически заработок денег почти всегда про счастье пользователя. Тактически почти всегда не про счастье пользователя.
Forwarded from { между скобок } анонсы 📣 (Grisha Skobelev)
Road to Highload
Наткнулся на серию материалов от команды Яндекс 360 про эволюцию их систем и путь к highload. Решил посмотреть, что там внутри.
Гораздо интереснее понять почему архитектура получилась именно такой, какие были ограничения и какие трейдоффы приходилось принимать по дороге. И здорово что можно посмотреть на путь который уже прошла другая big tech компания.
В этой серии как раз пытаются разобрать такие вещи на реальных примерах.
Всего получилось 5 выпусков, и они проходят по довольно базовым, но важным темам серверных систем:
— как сбор требований влияет на архитектуру и надежность системы
— проектирование API и почему ошибки на этом этапе потом дорого исправлять
— как визуализация архитектуры помогает объяснять систему команде
— что происходит, когда начинают расти данные: индексы, консистентность, компромиссы
— интеграции с внешними сервисами и типичные грабли
Мне больше всего зашел выпуск про рост данных. Там как раз обсуждают вещи, с которыми рано или поздно сталкивается почти любой сервис:
индексы, рост таблиц, влияние на производительность и какие решения обычно принимают, когда система начинает упираться в масштаб.
В целом серия получилась довольно практичной. Без «серебряных пуль» и магических архитектур - скорее про реальные проблемы, которые появляются, когда система живет и растет.
Если уже смотрели - интересно услышать ваше мнение.
И заодно поделитесь: какие материалы про highload вы считаете must-watch для инженеров?
Наткнулся на серию материалов от команды Яндекс 360 про эволюцию их систем и путь к highload. Решил посмотреть, что там внутри.
Гораздо интереснее понять почему архитектура получилась именно такой, какие были ограничения и какие трейдоффы приходилось принимать по дороге. И здорово что можно посмотреть на путь который уже прошла другая big tech компания.
В этой серии как раз пытаются разобрать такие вещи на реальных примерах.
Всего получилось 5 выпусков, и они проходят по довольно базовым, но важным темам серверных систем:
— как сбор требований влияет на архитектуру и надежность системы
— проектирование API и почему ошибки на этом этапе потом дорого исправлять
— как визуализация архитектуры помогает объяснять систему команде
— что происходит, когда начинают расти данные: индексы, консистентность, компромиссы
— интеграции с внешними сервисами и типичные грабли
Мне больше всего зашел выпуск про рост данных. Там как раз обсуждают вещи, с которыми рано или поздно сталкивается почти любой сервис:
индексы, рост таблиц, влияние на производительность и какие решения обычно принимают, когда система начинает упираться в масштаб.
В целом серия получилась довольно практичной. Без «серебряных пуль» и магических архитектур - скорее про реальные проблемы, которые появляются, когда система живет и растет.
Если уже смотрели - интересно услышать ваше мнение.
И заодно поделитесь: какие материалы про highload вы считаете must-watch для инженеров?
Яндекс 360. Road to Highload — проект о проектировании сервисов
Рассказываем, как создаём одни из самых крупных облачных сервисов
Forwarded from Клуб CDO
Дайджест статей
📰 Как аналитики данных используют ИИ для решения своих задач
🔗 https://habr.com/ru/companies/yandex_praktikum/articles/1004550/
💡 Вывод: ИИ меняет роль аналитика не в сторону «нажми кнопку — получи инсайт», а в сторону переквалификации: нужно уметь формулировать задачи для агентов и верифицировать их результат. Ключевая компетенция — не SQL, а способность задать правильный вопрос. (по метаданным)
📰 asapBI: архитектура ETL процессов – Trino, Spark, Airflow и прочий зоопарк
🔗 https://habr.com/ru/articles/1011510/
💡 Вывод: Платформа asapBI — попытка решить вечную проблему ETL: 90% трансформаций тривиальны (маппинг полей), но их всё равно пишут руками на SQL. Подход «графический интерфейс для простого, код для сложного» с единой точкой мониторинга и автогенерацией дагов Airflow. Критично: система не создаёт vendor lock — все артефакты работают без неё. Правильный вопрос на фоне прогресса ИИ: а нужны ли вообще моделированные DWH, если можно дать ИИ доступ к Lakehouse напрямую?
📰 Манипулирование данными или как не дать графикам себя обмануть
🔗 https://habr.com/ru/articles/1012236/
💡 Вывод: Каталог из 8 типичных приёмов визуальных манипуляций — от обрезанных осей до выборочного периода. Полезно как чеклист при ревью любого дашборда или отчёта. Ключевой навык для CDO-команды: не только строить визуализации, но и уметь защитить их от манипулятивного использования другими.
📰 Три задачи требований к данным
🔗 https://habr.com/ru/articles/1012406/
💡 Вывод: Автор выделяет три типа требований к данным: изменения в таблицах + маппинг, миграции существующих данных, enum’ы в коде. Главный инсайт: без документированной базы данных в вики (концептуальная схема + бизнес-логика на каждую таблицу) требования неизбежно превращаются в дублирование и устаревание. Физическая модель — не замена концептуальному описанию.
📰 Reference Data Management по-русски: что мы называем НСИ и почему это не всегда RDM
🔗 https://habr.com/ru/companies/datasapience/articles/1012404/
💡 Вывод: В российской практике «НСИ» стало зонтиком для RDM + MDM + DQ, хотя международный стандарт (DAMA DMBOK) чётко разделяет эти дисциплины. Ожидание «одна система на всё» — классическая ловушка: чем больше функций, тем выше риск получить продукт, который умеет всё, но плохо. При выборе инструмента важно разделить задачи: ведение справочников ≠ дедубликация ≠ гармонизация форматов.
📰 Data Mesh vs Data Fabric: The Ultimate 2025 Comparison for Enterprise Architects
🔗 https://medium.com/analysts-corner/data-mesh-vs-data-fabric-key-differences-architecture-future-trends-2025-c69287b1ef07
💡 Вывод: Сравнение двух архитектурных подходов к масштабированию работы с данными. Data Mesh — про организационную децентрализацию (domain ownership), Data Fabric — про технологическую унификацию (metadata-driven automation). (по метаданным)
📰 How did Meta modernize their lakehouse?
🔗 https://blog.dataengineerthings.org/how-did-meta-modernize-their-lakehouse-f2fec45af2f4
💡 Вывод: Meta переархитектурила свой Lakehouse, стартовавший с Hive в 2010 году. Статья фокусируется не на компонентах, а на организационных проблемах, которые возникают при масштабировании data-инфраструктуры на 20+ лет. (за пейволом, по метаданным)
📰 Hands-on with an MCP for data quality
🔗 https://medium.com/@mikldd/hands-on-with-an-mcp-for-data-quality-6fe4b9ed52a8
💡 Вывод: MCP (Model Context Protocol) в связке с метаданными о пайплайне (lineage, владельцы, мониторы) даёт AI-агенту возможность: оценить downstream-impact изменения колонки с взвешенным risk assessment, провести root cause analysis инцидента по шагам (lineage → upstream checks → code changes), найти таблицы с недостаточным покрытием тестами и сгенерировать еженедельный DQ-отчёт. Ключевой инсайт: MCP полезен ровно настолько, насколько богаты ваши метаданные.
📰 The Three-Body Problem of Data: Why Analytics, Decisions, & Ops Never Align
🔗 https://medium.com/@community_md101/the-three-body-problem-of-data-why-analytics-decisions-ops-never-align-5b428763b33c
📰 Как аналитики данных используют ИИ для решения своих задач
🔗 https://habr.com/ru/companies/yandex_praktikum/articles/1004550/
💡 Вывод: ИИ меняет роль аналитика не в сторону «нажми кнопку — получи инсайт», а в сторону переквалификации: нужно уметь формулировать задачи для агентов и верифицировать их результат. Ключевая компетенция — не SQL, а способность задать правильный вопрос. (по метаданным)
📰 asapBI: архитектура ETL процессов – Trino, Spark, Airflow и прочий зоопарк
🔗 https://habr.com/ru/articles/1011510/
💡 Вывод: Платформа asapBI — попытка решить вечную проблему ETL: 90% трансформаций тривиальны (маппинг полей), но их всё равно пишут руками на SQL. Подход «графический интерфейс для простого, код для сложного» с единой точкой мониторинга и автогенерацией дагов Airflow. Критично: система не создаёт vendor lock — все артефакты работают без неё. Правильный вопрос на фоне прогресса ИИ: а нужны ли вообще моделированные DWH, если можно дать ИИ доступ к Lakehouse напрямую?
📰 Манипулирование данными или как не дать графикам себя обмануть
🔗 https://habr.com/ru/articles/1012236/
💡 Вывод: Каталог из 8 типичных приёмов визуальных манипуляций — от обрезанных осей до выборочного периода. Полезно как чеклист при ревью любого дашборда или отчёта. Ключевой навык для CDO-команды: не только строить визуализации, но и уметь защитить их от манипулятивного использования другими.
📰 Три задачи требований к данным
🔗 https://habr.com/ru/articles/1012406/
💡 Вывод: Автор выделяет три типа требований к данным: изменения в таблицах + маппинг, миграции существующих данных, enum’ы в коде. Главный инсайт: без документированной базы данных в вики (концептуальная схема + бизнес-логика на каждую таблицу) требования неизбежно превращаются в дублирование и устаревание. Физическая модель — не замена концептуальному описанию.
📰 Reference Data Management по-русски: что мы называем НСИ и почему это не всегда RDM
🔗 https://habr.com/ru/companies/datasapience/articles/1012404/
💡 Вывод: В российской практике «НСИ» стало зонтиком для RDM + MDM + DQ, хотя международный стандарт (DAMA DMBOK) чётко разделяет эти дисциплины. Ожидание «одна система на всё» — классическая ловушка: чем больше функций, тем выше риск получить продукт, который умеет всё, но плохо. При выборе инструмента важно разделить задачи: ведение справочников ≠ дедубликация ≠ гармонизация форматов.
📰 Data Mesh vs Data Fabric: The Ultimate 2025 Comparison for Enterprise Architects
🔗 https://medium.com/analysts-corner/data-mesh-vs-data-fabric-key-differences-architecture-future-trends-2025-c69287b1ef07
💡 Вывод: Сравнение двух архитектурных подходов к масштабированию работы с данными. Data Mesh — про организационную децентрализацию (domain ownership), Data Fabric — про технологическую унификацию (metadata-driven automation). (по метаданным)
📰 How did Meta modernize their lakehouse?
🔗 https://blog.dataengineerthings.org/how-did-meta-modernize-their-lakehouse-f2fec45af2f4
💡 Вывод: Meta переархитектурила свой Lakehouse, стартовавший с Hive в 2010 году. Статья фокусируется не на компонентах, а на организационных проблемах, которые возникают при масштабировании data-инфраструктуры на 20+ лет. (за пейволом, по метаданным)
📰 Hands-on with an MCP for data quality
🔗 https://medium.com/@mikldd/hands-on-with-an-mcp-for-data-quality-6fe4b9ed52a8
💡 Вывод: MCP (Model Context Protocol) в связке с метаданными о пайплайне (lineage, владельцы, мониторы) даёт AI-агенту возможность: оценить downstream-impact изменения колонки с взвешенным risk assessment, провести root cause analysis инцидента по шагам (lineage → upstream checks → code changes), найти таблицы с недостаточным покрытием тестами и сгенерировать еженедельный DQ-отчёт. Ключевой инсайт: MCP полезен ровно настолько, насколько богаты ваши метаданные.
📰 The Three-Body Problem of Data: Why Analytics, Decisions, & Ops Never Align
🔗 https://medium.com/@community_md101/the-three-body-problem-of-data-why-analytics-decisions-ops-never-align-5b428763b33c
Хабр
Как аналитики данных используют ИИ для решения своих задач
Нейросети и быстрое развитие ИИ в целом (плюс постепенное распространение ИИ‑агентов в ежедневной работе) меняет подход к работе аналитика данных. Однако действительно ли это...
Forwarded from Если быть точным
В прошлом году мы добавили в каталог «Если быть точным» новый формат данных — parquet. Подробно рассказываем, как с ним работать
Parquet в 2013 году придумали инженеры Twitter и Cloudera. Теперь им пользуются в Google, Amazon и Netflix. С апреля, кроме привычных csv и xlsx, мы публикуем все наборы данных в этом формате.
Главное преимущество parquet — компактность. Например, датасет по онкологии в csv весит 576 мегабайт. Файл excel c теми же данными — 140 мегабайт, а parquet занимает всего 4 мегабайта.
Формат позволяет не загружать весь файл в память — можно читать только нужные столбцы и строки, в том числе напрямую из облачного хранилища, не скачивая сам файл.
Как работать с parquet — читайте на сайте «Если быть точным» или в нашем новом блоге на Хабре.
◾️ Этот гайд впервые вышел в рассылке «Это не показатель» — присоединяйтесь через Tribute или Boosty.
Parquet в 2013 году придумали инженеры Twitter и Cloudera. Теперь им пользуются в Google, Amazon и Netflix. С апреля, кроме привычных csv и xlsx, мы публикуем все наборы данных в этом формате.
Главное преимущество parquet — компактность. Например, датасет по онкологии в csv весит 576 мегабайт. Файл excel c теми же данными — 140 мегабайт, а parquet занимает всего 4 мегабайта.
Формат позволяет не загружать весь файл в память — можно читать только нужные столбцы и строки, в том числе напрямую из облачного хранилища, не скачивая сам файл.
Как работать с parquet — читайте на сайте «Если быть точным» или в нашем новом блоге на Хабре.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Forwarded from Клуб CDO
Дайджест статей
📰 Как я проектирую OLTP-БД с нуля: принципы, trade-off'ы и архитектурные решения
🔗 https://habr.com/ru/articles/1014098/
💡 Вывод: Инженер пишет собственный OLTP-движок на Rust — с UNDO-log MVCC (как у InnoDB, Oracle, MSSQL), unified storage на БД и fail-closed поведением вместо тихой деградации. Главный тезис: если система под нагрузкой молчит и тянет — она врёт. Предсказуемый отказ с внятным SQLSTATE лучше, чем иллюзия, что «ещё дотянет». Для CDO: пример архитектурных решений на уровне storage engine, которые стоит знать при оценке собственных data-платформ.
📰 Как ML изменит бизнес в 2026 году: прогноз Selectel, GlowByte и Data Sapience
🔗 https://habr.com/ru/companies/selectel/articles/1013862/
💡 Вывод: Маркетинговый по форме, но полезный по структуре обзор корпоративного AI. Зерно: компании переходят от хаотичного использования LLM к централизованным корпоративным порталам с RBAC, квотами и биллингом. Shadow AI становится реальным драйвером создания внутренних GenAI-сред — не из любви к технологиям, а из страха потери контроля над корпоративными данными. AI-агенты в продакшн — это микросервис, которому нужен жизненный цикл, версионирование и CI/CD, а не просто промпт в блокноте.
📰 Как мы подружили DataLens и OpenMetadata: архитектура, код и подводные камни
🔗 https://habr.com/ru/companies/magnit/articles/1015708/
💡 Вывод: Команда DWH Magnit написала ingestion-коннектор DataLens → OpenMetadata с нуля и выложила в открытый доступ. Практический кейс: BI-объекты (дашборды, чарты, датасеты) вытащены в общий граф метаданных с lineage-цепочками. Главный урок — ingestion на реальном объёме немедленно упирается в rate limits и scope management, поэтому operational-параметры (задержки, ретраи, фильтрация коллекций) нужно закладывать в коннектор сразу, не после первого запуска на продовом контуре.
📰 Case for Self-Healing Data Observability in Converged Architectures
🔗 https://moderndata101.substack.com/p/self-healing-data-observability-in
💡 Вывод: Аргумент в пользу ARI-цикла (Anticipate → Remediate → Immunize) как архитектурного слоя качества данных, а не инструментального. Основная мысль: конвергированные платформы убрали швы между системами, но оставили observability в парадигме «оповестить человека» — это незаконченная архитектура. Самовосстанавливающаяся платформа не исключает инженера, а меняет его роль: от дежурного пожарного к проектировщику иммунной системы. Граница «что платформа решает сама, а что эскалирует» — это архитектурное решение, а не настройка порогов.
📰 Reference Data Management по-русски: что мы называем НСИ и почему это не всегда RDM
🔗 https://habr.com/ru/companies/datasapience/articles/1012404/
💡 Вывод: Честная разборка терминологии: российское «НСИ» на практике = RDM + часть MDM + немного DQ — исторически потому, что отдельных систем не было, и всё сваливали в одну. Для CDO: смешение задач — это не культурная особенность, а архитектурный риск. Один инструмент «на всё» хорошо звучит на слайде и плохо работает в эксплуатации. Продукт, который претендует закрыть RDM, MDM и DQ одновременно, — кандидат на идиотский индекс.
📰 How Long Until We Call AI Agents Data Products
🔗 https://moderndata101.substack.com/p/data-products-as-ai-agents
💡 Вывод: AI-агент в продакшне соответствует всем критериям data product — пользователи, контракты качества, жизненный цикл, обратная связь. Большинство команд запускают агентов как эксперименты и удивляются, почему они деградируют. Обсервабилити ≠ логирование: каждый retry — это измеримое трение, каждый брошенный диалог — невидимый отток. Единственная работающая обратная связь — ручная аннотация разговоров с последующим маппингом паттернов на тикеты. Не дашборды — решения.
📰 Как я проектирую OLTP-БД с нуля: принципы, trade-off'ы и архитектурные решения
🔗 https://habr.com/ru/articles/1014098/
💡 Вывод: Инженер пишет собственный OLTP-движок на Rust — с UNDO-log MVCC (как у InnoDB, Oracle, MSSQL), unified storage на БД и fail-closed поведением вместо тихой деградации. Главный тезис: если система под нагрузкой молчит и тянет — она врёт. Предсказуемый отказ с внятным SQLSTATE лучше, чем иллюзия, что «ещё дотянет». Для CDO: пример архитектурных решений на уровне storage engine, которые стоит знать при оценке собственных data-платформ.
📰 Как ML изменит бизнес в 2026 году: прогноз Selectel, GlowByte и Data Sapience
🔗 https://habr.com/ru/companies/selectel/articles/1013862/
💡 Вывод: Маркетинговый по форме, но полезный по структуре обзор корпоративного AI. Зерно: компании переходят от хаотичного использования LLM к централизованным корпоративным порталам с RBAC, квотами и биллингом. Shadow AI становится реальным драйвером создания внутренних GenAI-сред — не из любви к технологиям, а из страха потери контроля над корпоративными данными. AI-агенты в продакшн — это микросервис, которому нужен жизненный цикл, версионирование и CI/CD, а не просто промпт в блокноте.
📰 Как мы подружили DataLens и OpenMetadata: архитектура, код и подводные камни
🔗 https://habr.com/ru/companies/magnit/articles/1015708/
💡 Вывод: Команда DWH Magnit написала ingestion-коннектор DataLens → OpenMetadata с нуля и выложила в открытый доступ. Практический кейс: BI-объекты (дашборды, чарты, датасеты) вытащены в общий граф метаданных с lineage-цепочками. Главный урок — ingestion на реальном объёме немедленно упирается в rate limits и scope management, поэтому operational-параметры (задержки, ретраи, фильтрация коллекций) нужно закладывать в коннектор сразу, не после первого запуска на продовом контуре.
📰 Case for Self-Healing Data Observability in Converged Architectures
🔗 https://moderndata101.substack.com/p/self-healing-data-observability-in
💡 Вывод: Аргумент в пользу ARI-цикла (Anticipate → Remediate → Immunize) как архитектурного слоя качества данных, а не инструментального. Основная мысль: конвергированные платформы убрали швы между системами, но оставили observability в парадигме «оповестить человека» — это незаконченная архитектура. Самовосстанавливающаяся платформа не исключает инженера, а меняет его роль: от дежурного пожарного к проектировщику иммунной системы. Граница «что платформа решает сама, а что эскалирует» — это архитектурное решение, а не настройка порогов.
📰 Reference Data Management по-русски: что мы называем НСИ и почему это не всегда RDM
🔗 https://habr.com/ru/companies/datasapience/articles/1012404/
💡 Вывод: Честная разборка терминологии: российское «НСИ» на практике = RDM + часть MDM + немного DQ — исторически потому, что отдельных систем не было, и всё сваливали в одну. Для CDO: смешение задач — это не культурная особенность, а архитектурный риск. Один инструмент «на всё» хорошо звучит на слайде и плохо работает в эксплуатации. Продукт, который претендует закрыть RDM, MDM и DQ одновременно, — кандидат на идиотский индекс.
📰 How Long Until We Call AI Agents Data Products
🔗 https://moderndata101.substack.com/p/data-products-as-ai-agents
💡 Вывод: AI-агент в продакшне соответствует всем критериям data product — пользователи, контракты качества, жизненный цикл, обратная связь. Большинство команд запускают агентов как эксперименты и удивляются, почему они деградируют. Обсервабилити ≠ логирование: каждый retry — это измеримое трение, каждый брошенный диалог — невидимый отток. Единственная работающая обратная связь — ручная аннотация разговоров с последующим маппингом паттернов на тикеты. Не дашборды — решения.
Хабр
Как я проектирую OLTP-БД с нуля: принципы, trade-off'ы и архитектурные решения
В двух предыдущих статьях я писал о том, почему эксплуатация современных баз данных всё чаще превращается в борьбу не с данными, а со сложностью самой системы: Мы знаем как готовить БД. Но индустрия...
Forwarded from Сообщество Управления Данными
А все решение StarRocks - это и есть будущее, фактически open source snowflake