Непутевые Заметки Data Steward ‘а

Филосовское

Семантический слой своими руками: как ИИ и open source меняют правила игры Знакомо? В компании три дашборда, и на каждом «активные пользователи» посчитаны по-своему. Семантический слой решает эту проблему: раз описываешь логику — и все отчёты, ad-hoc запросы, BI-инструменты используют одно и то же определение. Не «я думал, выручка без НДС», а «выручка — вот так, точка». Вот только вручную строить такой слой — та ещё морока. Нужно знать в глубину SQL, разбираться в структуре данных, держать в голове весь бизнес-контекст. Ошиблись в джойне — метрики поехали. Но сейчас это можно ускорить с помощью ген ИИ и целого набора open source модулей. Они берут на себя нудную часть. Open source даёт готовый фундамент. dbt управляет трансформациями: вы пишете модели как код, версионируете, тестируете. Cube поверх dbt делает из этих моделей полноценный семантический слой — с REST/GraphQL API, авто-генерацией SQL и кэшированием, чтобы база не тормозила от однотипных запросов. MetricFlow, от тех же ребят, что создали dbt, заточен на метрики: описываете их в YAML, а система сама строит оптимальные запросы. Хотите сразу BI-интерфейс? Lightdash и Malloy садятся и дают вполне себе выразительный язык запросов. Все эти модули открыты, постоянно допиливаются и стыкуются как конструктор — не привязаны к вендору. А теперь — ИИ. Локально запущенная LLM через Ollama или Llama.cpp - делает рутину. Скармливаете ей DDL таблиц — получаете dbt-модели с джойнами, тестами и комментариями. Пишете : «средний чек за вычетом возвратов» — через минуту у вас YAML для Cube с формулой, измерениями и типами агрегации. Она же находит нестыковки в определениях и дописывает документацию. А потом — самое вкусное: Natural Language интерфейс. Спрашиваете: «Продажи по регионам за прошлый месяц» — LLM, используя сгенерированные модели как контекст, превращает фразу в запрос к API (через Vanna.ai или связку Cube + LangChain). Ни строчки SQL. Как это выглядит на практике. Допустим, есть таблицы orders и customers. Говорите ИИ: «Хочу метрики: выручка, количество заказов, процент повторных покупок. Разрезы — дата, статус заказа, регион». Пару минут — и получаем готовый набор .yml для Cube: кубы, измерения, расчётные показатели и pre-aggregations для скорости. Запускаете Cube, подключаете BI — слой живёт. Решили пересчитать выручку без НДС? Меняете описание — ИИ перегенерирует определения. Что получается: времени на подготовку меньше, аналитики без глубокого SQL могут править метрики, определения не плывут, документация не отстаёт. Гибко, подконтрольно и без вендор-лока.

Выдерну из нашего сообщества хорошую цитату по Методистов: 1. Философия: отвечает на вопрос "почему?". Она занимается более общими принципами, идеями и целями, лежащими в основе какой-либо деятельности или подхода. Философия определяет основные ценности, убеждения и стратегические направления. 2. Методология: отвечает на вопрос "как в общем?". Она определяет общие принципы, правила и процессы, которые следует применять для достижения определенных целей или решения задач. Методология обеспечивает рамочный подход к выполнению задачи и определяет методы, используемые для ее реализации. 3. Методика: отвечает на вопрос "как конкретно?" Это описание конкретных шагов, методов, процедур или инструкций, которые следует выполнить для достижения определенных результатов. Методика предоставляет практические рекомендации и детальные указания о том, как именно выполнять определенные задачи или действия. Спасибо, @StasKaramushko

Когда делаешь форк иностранного open source.

Когда говоришь друзьям что стал заниматься большой политикой )) #data_fun

С каждым разом все поражает , когда без выстроенной системы данных, без внятной методологии мы хотим внедрять AI и надеемся что он нам все полечит. Заменит и DE и DS,разрабов, Тим лидов. Останется работать только Ванька, который будет лихо вайб кодить. Красота ж.

by Alice

Без пуха и лишней важности 😄

Цена проверки Стоимость запуска одной проверки качества данных в DWH складывается из переменных затрат, зависящих от: архитектуры (On-Premise / Cloud), инструментария (dbt, Spark, DG-платформы) объема данных. В частности затраты: 1. Железо: - Стоимость CPU и RAM: Чем сложнее проверка (например сложная аномалия на основе скользящего окна или сравнение с ML-моделью), тем дольше она работает. Можно почитать так: время выполнения запроса × Стоимость единицы вычислительной мощности (vCPU/час или $/час) - Затраты на оркестрацию: Если проверка запускается через Airflow или Dagster, учитывается время работы воркера, который держит соединение и мониторит выполнение. 2. Хранилище - Сканирование данных в системах с раздельной оплатой хранения и вычислений (Snowflake, BigQuery, Redshift) оплата за гигабайт. Если проверка делает полное сканирование многолетней таблицы без партиций, стоимость одной проверки может равняться стоимости хранения всей таблицы за месяц. - Запись промежуточных результатов. Если проверка создает временные таблицы (например, для дедупликации или сравнения), то плата взимается за хранение этих временных данных. 3. Инструмент проверки. Нативная проверка (dbt test, Snowflake Streams). Цена обычно включена в стоимость вычислительных ресурсов. Но если вы используете dbt Cloud, то стоимость может рассчитываться по количеству “разработчиков” или джебов. Сторонние платформы (Great Expectations, Soda). SaaS модель: плата взимается за сканирование. Один запуск проверки = один сканируемый столбец или одна таблица в тарифе. 4. Сетевая передача данных (чаще для МРР). Если DQ-инструмент (например, Python-скрипт с Great Expectations) запущен вне кластера DWH (в Kubernetes или на EC2), и он тянет данные через ODBC/JDBC наружу из DWH, вы платите за исходящий трафик. Если DQ-инструмент запускает SQL внутри DWH (Snowflake Task, BigQuery Routine), сетевых затрат нет. 5. Логирование, мониторинг и хранение истории Каждый запуск проверки записывает строку в таблицу логов. Затраты на хранение этой истории со временем растут линейно от количества запусков.

Драматический момент 🎭 в битве за клиента. Попкорн, чипсы, и слезы (радости или печали - тут как получится)

🤓 В МФЦ можно поставить негативную оценку за работу, но она не учитывается в общей статистке 👉Подписаться на Comedy Radio

Напомнило случай, когда показатели делают ради самих показателей:

Короткая заметка на тему Рисуем архитектуру данных бесплатно: 5 инструментов, которые не стоят ничего. ситуация: нужно спроектировать модель данных, показать ее заказчику или согласовать с командой. Бюджета и времени за закупку нет, либо есть желание попробовать open-source. Open-source дает не просто возможность рисовать квадратики. Он предлагают современные подходы: хранение моделей в Git, генерацию кода, интеграцию с CI/CD и теперь уже AI. Нашел для себя интересные бесплатные решений, делюсь). ❓Что и для кого: 1️⃣ DrawDB Быстро набросать схему, сгенерировать SQL, развернуть на своем сервере Self-hosted / Railway 2️⃣ ChartDB Импортировать существующую БД и получить диаграмму "в один клик" Облако (бесплатно) / Self-hosted 3️⃣ Diagrams Хранить архитектуру в коде, интегрировать в DevOps, версионировать в Git Python-библиотека. Писать схемы как код (DSL), удобно для разработчиков Облако (freemium) 4️⃣ ERD Plus Образовательные цели, быстрая конвертация ER в реляционные схемы Облако (бесплатно). 🪄 Как выбрать: 1. Если нужно быстро нарисовать концепт и показать бизнесу — берите DrawDB или dbdiagram.io. 2. Если нужно задокументировать уже работающую базу — ChartDB справится лучше всех. 3. Если вы DevOps и хотите автоматизации — ваш выбор Diagrams. 4. Если это разовая задача для курсовой или пет-проекта — хватит ERD Plus.

На злобу дня )

Вариант ответа: 1. Перевести разговор из эмоциональной плоскости в техническую: «Давайте разберемся, данные требуют верификации». 2. Маршрут данных (Data Lineage): Показать, как строится пайалайн. Использовать концепцию родословной данных, чтобы найти точку сбоя (source -> staging -> mart). 3. Иногда нужно иметь План Б: Быстрый запуск пересчета данных за выходные из сырого бакета (raw data) в обход сломанного API, если есть снапшоты. Оценка времени на исправление. 4. Управление ожиданиями: Предложить гендиру метрику "SLA по качеству данных" и создать протокол оповещения топ-менеджмента о "ненадежных данных" на дашбордах (например, раскрашивать плитки желтым, пока идет верификация).

Кейс №2: «Молчаливая поломка» Контекст: Вы отвечаете за пайплайн данных, поставляющий данные для управленческую отчетность. В понедельник утром на оперативном совещании гендир заявляет, что «продажи рухнули на 30% в выходные» и требует наказания команды. Вы открываете дашборд — данные действительно красные. Вы звоните инженерам: «Все сервисы зеленые, ETL (процесс загрузки данных) завершился успешно в 03:00 ночи». Через час выясняется, что смежная команда обновила API системы-источника (CRM), но забыла предупредить. Данные загружались, но грузились NULL или дубли в ключевом поле revenue… Вопрос: Каков план ваших действий? Что сделаете в первую очередь? Как выстроите коммуникацию с руководством и командами?

Вариант ответа (можете изложить свою версию в комментариях): 1. ⛑️ Первая помощь (первые 30 минут) Немедленная коммуникация с маркетингом. Если нельзя остановить рассылку, можно ли остановить списание средств? Блокировка отправки пушей/смс самым критичным сегментам (VIP), пока не разберемся. 2. 🧰Квадрат решений: Классификация инцидента по матрице «Срочность/Важность» и «Влияние на бизнес/Репутацию». 3. 🛠️Технический компромисс: Предложение тех.команде не пересчитывать 100% данных, а разработать скрипт «обратного потока данных» или обогащения данными на стороне CRM (досылка правильных атрибутов). 4. 🛎️ Прозрачность: Разбора полетов и план коммуникации с пострадавшими клиентами (извинения + двойной кешбэк), если баг дошел до пользователей.

А теперь немного управленческих кейсов в мире big data. Кейс: «Deadline или Качество?» Контекст: Крупный ритейлер запускает рекламную кампанию к «black Friday». Маркетинг опирается на сегментацию клиентов, которую рассчитывает ваша команда Data Science. За день до старта (вечер пятницы) выясняется, что в витрине DWH обнаружен критический баг: 15% клиентов попали не в свои сегменты (например, «потеряшки» получили премиальные скидки, а VIP — спам). Бизнес-юнит говорит: «Мы не можем останавливать кампанию, потери составят миллион рублей за час простоя. Исправляйте на лету». Техлид говорит: «Чтобы пересчитать данные честно, нужно 12 часов, а старые данные удалить нельзя, так как они уже ушли в CRM». Вопрос: Как CDO/ COO каков будет ваш план действий в ближайшие 30 минут и в ближайшие 24 часа?

Текущая заметка про связь данных и 152-ФЗ. Одним из недостатков базовых платформ по умалению данными,является неспособность к интерпретации перс. данных. Без вкрученных ML-модулей базовый алгоритм обнаружит только шаблон, без определения совокупности перс данных, подпадающих под 152-ФЗ Тот же алгоритм квалифицирует категорию данных как биометрию или чувствительную, инсайдерку и т.д. Ключевой фигурой, кто нужен - ответственный за обработку перс. данных, в быту - DPO. DPO переводит законы в правила и классификации. Его экспертиза позволяет внести не только технические, но и юридически значимые метки, определяющие политику безопасности, получение доступа по ролевой модели. Без этого платформа превращается сперва в свалку, а затем в рискованный актив. Данные из пассивного ресурса уходят в управляемый, обеспечивается легитимность данных. С DPO данные становятся полноценным ИТ- активом и в последующем могут быть монетизированы. Обрабатываете данные по закону, и прибудет с Вами сила !💪🏻