Для чего нужна эмпатия и психология в работе.
Покажу пару кейсах при назначении владельцев данных.
Цифровая трансформация редко имеет дело с чисто техническими вызовами.
Ее основной посыл лежит к области человеческих факторов, в виде готовности людей к изменениям.
1️⃣ кейс. В одном банке было инициировано внедрение некой платформы по управлению данными. Ключевым требованием было назначение владельцев данных из числа руководителей фин департамента, казначейства, бэк-офиса. Формально приказ подписан, но на практике ответственность игнорировалась. Руководители восприняли это как доп. нагрузку, не видя пользы. На их взгляд казалось что данные это удел IT. То самое сопротивление, когда нововведение не согласуется с убеждениям и «традициями».
Успех был достигнут после следующего: вместо приказов- индивидуальные рабочие встречи, где на примерах показано, как качественные данные напрямую влияют на качество обязательной отчетности.
2️⃣ Кейс про глубокую форму сопротивления — эмоциональную, основанную на страхе. Владельцем данных по домену «Клиенты» назначили нового руководителя из соседнего Департамента. Несмотря на внешнее согласие, процесс стал саботироваться. Суть саботажа заключался в невысказанном страхе, что выявятся потенциальные недостатки в процессе реконсиляции данных , может подорваться авторитет и руководителя и коллектива.
Выходом из ситуации стала интеграция экспертного знания коллег в новый процесс. Было назначение одного из коллег в качестве методолога от управления данными.
На основании всего этого можно сформулировать принцип: работа с изменениями это не задача кнута, а потенциального пряника.
Необходимо уйти от эмоций и выявить лежащие в их основе суть вещей — непонимание нововведений, эмоциональный страх или инерция.
#психология
#управление_изменениями
Покажу пару кейсах при назначении владельцев данных.
Цифровая трансформация редко имеет дело с чисто техническими вызовами.
Ее основной посыл лежит к области человеческих факторов, в виде готовности людей к изменениям.
1️⃣ кейс. В одном банке было инициировано внедрение некой платформы по управлению данными. Ключевым требованием было назначение владельцев данных из числа руководителей фин департамента, казначейства, бэк-офиса. Формально приказ подписан, но на практике ответственность игнорировалась. Руководители восприняли это как доп. нагрузку, не видя пользы. На их взгляд казалось что данные это удел IT. То самое сопротивление, когда нововведение не согласуется с убеждениям и «традициями».
Успех был достигнут после следующего: вместо приказов- индивидуальные рабочие встречи, где на примерах показано, как качественные данные напрямую влияют на качество обязательной отчетности.
2️⃣ Кейс про глубокую форму сопротивления — эмоциональную, основанную на страхе. Владельцем данных по домену «Клиенты» назначили нового руководителя из соседнего Департамента. Несмотря на внешнее согласие, процесс стал саботироваться. Суть саботажа заключался в невысказанном страхе, что выявятся потенциальные недостатки в процессе реконсиляции данных , может подорваться авторитет и руководителя и коллектива.
Выходом из ситуации стала интеграция экспертного знания коллег в новый процесс. Было назначение одного из коллег в качестве методолога от управления данными.
На основании всего этого можно сформулировать принцип: работа с изменениями это не задача кнута, а потенциального пряника.
Необходимо уйти от эмоций и выявить лежащие в их основе суть вещей — непонимание нововведений, эмоциональный страх или инерция.
Эффективный менеджер должен быть и системным аналитиком и психологом с развитой эмпатией.
Технологии - это инструменты, внедряют их люди.
#психология
#управление_изменениями
👍2
Дорогие подписчики, Data- Авантюристы! С наступающим Новым годом! 🎉
2025-й был огонь: много классных мероприятий, конференции и практичных идей, благодаря вам! Вы — лучшие.
Но, не останавливаемся! Вместе сделаем data-driven подход мейнстримом. К новым победам над данными в 2026! 🚀
С праздником! И пусть ваш код работает без дебагов!
2025-й был огонь: много классных мероприятий, конференции и практичных идей, благодаря вам! Вы — лучшие.
Но, не останавливаемся! Вместе сделаем data-driven подход мейнстримом. К новым победам над данными в 2026! 🚀
С праздником! И пусть ваш код работает без дебагов!
❤4👍4🔥1
В связи с внедрением в законодательство термина ИТ-активы, хотелось бы разобраться, кто является Владельцем ИТ-актива?
Данный вопрос явно лежит на стыке права, корпоративного управления и технологий и требует четкого разграничения.
Сам термин «ИТ-актив» является агрегирующим и обозначает любой ресурс, имеющий ценность для организации в контексте ИТ. Однако с юридической и операционной точек зрения внутри этого понятия существуют принципиально разные категории, права на которые часто распределены между различными субъектами.
Владельцем данных, в классическом понимании, является субъект, который определяет цель, содержание и правила обработки информации. В корпоративной среде таким субъектом выступает владелец бизнес-процесса или функциональное подразделение, которое создает и использует данные для достижения целей. Например, данные о клиентах принадлежат департаменту продаж или операционному подразделению, а счета — бухгалтерии. Их право собственности носит не технический, а содержательный и управленческий характер. Они несут ответственность за качество, конфиденциальность и целостность данных в соответствии с регламентами 152 ФЗ. При этом физическое хранение и обработка этих данных осуществляются на инфраструктуре, которой они, как правило, не владеют.
Владельцем информационной системы, как технологического актива, является тот, кто несет ответственность за ее жизненный цикл, эксплуатационную готовность, безопасность и развитие. В рамках организации это часто подразделение ИТ-службы или центры ответственности, такие как владелец сервиса или владелец инфраструктуры. Их право собственности — техническое и операционное. Они обеспечивают вычислительные мощности, хранилища, сетевые компоненты, ПО и прикладные системы, которые служат средой для обработки данных. Их ключевая задача — предоставление надежного и эффективного сервиса владельцам данных.
Таким образом, в рамках парадигмы ИТ-активов возникает фундаментальное разделение: владелец данных контролирует контент и логику его использования, а владелец системы контролирует контейнер и механизмы для этого использования. Конфликт интересов и зон ответственности между ними является классическим. Владелец данных требует от системы максимальной гибкости, доступности и функциональности, часто не учитывая технологических ограничений и стоимости владения. Владелец системы, наоборот, стремится к стандартизации, управляемости и безопасности инфраструктуры, что может восприниматься как ограничение для бизнес-подразделений.
С правовой точки зрения, если данные представляют собой объект интеллектуальной собственности или содержат перс данные, владелец данных выступает в роли правообладателя или оператора персональных данных, что налагает на него дополнительные обязательства, выходящие за рамки внутрикорпоративных отношений. Владелец системы в этой схеме становится обработчиком или уполномоченным лицом, действующим на основании договора или корпоративного регламента.
Следовательно, ответ на вопрос о владельцах в контексте ИТ-активов заключается в признании дуализма собственности. Эффективное управление ИТ-активами невозможно без установления прозрачных и формализованных отношений между владельцем данных как субъекта бизнеса и владельцем системы как субъекта технологического обеспечения. Это разделение прав и ответственности формирует основу для архитектуры управления предприятием, где ИТ-активы перестают быть просто затратами, а становятся объектом страт управления, требующего баланса между бизнес-ценностью и технологической целесообразностью.
#ит-активы
#владелец_данных
#владелец_ИС
Данный вопрос явно лежит на стыке права, корпоративного управления и технологий и требует четкого разграничения.
Сам термин «ИТ-актив» является агрегирующим и обозначает любой ресурс, имеющий ценность для организации в контексте ИТ. Однако с юридической и операционной точек зрения внутри этого понятия существуют принципиально разные категории, права на которые часто распределены между различными субъектами.
Владельцем данных, в классическом понимании, является субъект, который определяет цель, содержание и правила обработки информации. В корпоративной среде таким субъектом выступает владелец бизнес-процесса или функциональное подразделение, которое создает и использует данные для достижения целей. Например, данные о клиентах принадлежат департаменту продаж или операционному подразделению, а счета — бухгалтерии. Их право собственности носит не технический, а содержательный и управленческий характер. Они несут ответственность за качество, конфиденциальность и целостность данных в соответствии с регламентами 152 ФЗ. При этом физическое хранение и обработка этих данных осуществляются на инфраструктуре, которой они, как правило, не владеют.
Владельцем информационной системы, как технологического актива, является тот, кто несет ответственность за ее жизненный цикл, эксплуатационную готовность, безопасность и развитие. В рамках организации это часто подразделение ИТ-службы или центры ответственности, такие как владелец сервиса или владелец инфраструктуры. Их право собственности — техническое и операционное. Они обеспечивают вычислительные мощности, хранилища, сетевые компоненты, ПО и прикладные системы, которые служат средой для обработки данных. Их ключевая задача — предоставление надежного и эффективного сервиса владельцам данных.
Таким образом, в рамках парадигмы ИТ-активов возникает фундаментальное разделение: владелец данных контролирует контент и логику его использования, а владелец системы контролирует контейнер и механизмы для этого использования. Конфликт интересов и зон ответственности между ними является классическим. Владелец данных требует от системы максимальной гибкости, доступности и функциональности, часто не учитывая технологических ограничений и стоимости владения. Владелец системы, наоборот, стремится к стандартизации, управляемости и безопасности инфраструктуры, что может восприниматься как ограничение для бизнес-подразделений.
С правовой точки зрения, если данные представляют собой объект интеллектуальной собственности или содержат перс данные, владелец данных выступает в роли правообладателя или оператора персональных данных, что налагает на него дополнительные обязательства, выходящие за рамки внутрикорпоративных отношений. Владелец системы в этой схеме становится обработчиком или уполномоченным лицом, действующим на основании договора или корпоративного регламента.
Следовательно, ответ на вопрос о владельцах в контексте ИТ-активов заключается в признании дуализма собственности. Эффективное управление ИТ-активами невозможно без установления прозрачных и формализованных отношений между владельцем данных как субъекта бизнеса и владельцем системы как субъекта технологического обеспечения. Это разделение прав и ответственности формирует основу для архитектуры управления предприятием, где ИТ-активы перестают быть просто затратами, а становятся объектом страт управления, требующего баланса между бизнес-ценностью и технологической целесообразностью.
#ит-активы
#владелец_данных
#владелец_ИС
👍4
Текущая заметка про связь данных и 152-ФЗ.
Одним из недостатков базовых платформ по умалению данными,является неспособность к интерпретации перс. данных. Без вкрученных ML-модулей базовый алгоритм обнаружит только шаблон, без определения совокупности перс данных, подпадающих под 152-ФЗ
Тот же алгоритм квалифицирует категорию данных как биометрию или чувствительную, инсайдерку и т.д.
Ключевой фигурой, кто нужен - ответственный за обработку перс. данных, в быту - DPO.
DPO переводит законы в правила и классификации. Его экспертиза позволяет внести не только технические, но и юридически значимые метки, определяющие политику безопасности, получение доступа по ролевой модели. Без этого платформа превращается сперва в свалку, а затем в рискованный актив.
Данные из пассивного ресурса уходят в управляемый, обеспечивается легитимность данных.
С DPO данные становятся полноценным ИТ- активом и в последующем могут быть монетизированы.
Обрабатываете данные по закону, и прибудет с Вами сила !💪🏻
Одним из недостатков базовых платформ по умалению данными,является неспособность к интерпретации перс. данных. Без вкрученных ML-модулей базовый алгоритм обнаружит только шаблон, без определения совокупности перс данных, подпадающих под 152-ФЗ
Тот же алгоритм квалифицирует категорию данных как биометрию или чувствительную, инсайдерку и т.д.
Ключевой фигурой, кто нужен - ответственный за обработку перс. данных, в быту - DPO.
DPO переводит законы в правила и классификации. Его экспертиза позволяет внести не только технические, но и юридически значимые метки, определяющие политику безопасности, получение доступа по ролевой модели. Без этого платформа превращается сперва в свалку, а затем в рискованный актив.
Данные из пассивного ресурса уходят в управляемый, обеспечивается легитимность данных.
С DPO данные становятся полноценным ИТ- активом и в последующем могут быть монетизированы.
Обрабатываете данные по закону, и прибудет с Вами сила !💪🏻
👍2❤1
This media is not supported in your browser
VIEW IN TELEGRAM
А теперь немного управленческих кейсов в мире big data.
Кейс: «Deadline или Качество?»
Контекст:
Крупный ритейлер запускает рекламную кампанию к «black Friday». Маркетинг опирается на сегментацию клиентов, которую рассчитывает ваша команда Data Science. За день до старта (вечер пятницы) выясняется, что в витрине DWH обнаружен критический баг: 15% клиентов попали не в свои сегменты (например, «потеряшки» получили премиальные скидки, а VIP — спам).
Бизнес-юнит говорит: «Мы не можем останавливать кампанию, потери составят миллион рублей за час простоя. Исправляйте на лету». Техлид говорит: «Чтобы пересчитать данные честно, нужно 12 часов, а старые данные удалить нельзя, так как они уже ушли в CRM».
Вопрос:
Как CDO/ COO каков будет ваш план действий в ближайшие 30 минут и в ближайшие 24 часа?
Кейс: «Deadline или Качество?»
Контекст:
Крупный ритейлер запускает рекламную кампанию к «black Friday». Маркетинг опирается на сегментацию клиентов, которую рассчитывает ваша команда Data Science. За день до старта (вечер пятницы) выясняется, что в витрине DWH обнаружен критический баг: 15% клиентов попали не в свои сегменты (например, «потеряшки» получили премиальные скидки, а VIP — спам).
Бизнес-юнит говорит: «Мы не можем останавливать кампанию, потери составят миллион рублей за час простоя. Исправляйте на лету». Техлид говорит: «Чтобы пересчитать данные честно, нужно 12 часов, а старые данные удалить нельзя, так как они уже ушли в CRM».
Вопрос:
Как CDO/ COO каков будет ваш план действий в ближайшие 30 минут и в ближайшие 24 часа?
Вариант ответа (можете изложить свою версию в комментариях):
1. ⛑️ Первая помощь (первые 30 минут)
Немедленная коммуникация с маркетингом. Если нельзя остановить рассылку, можно ли остановить списание средств? Блокировка отправки пушей/смс самым критичным сегментам (VIP), пока не разберемся.
2. 🧰Квадрат решений: Классификация инцидента по матрице «Срочность/Важность» и «Влияние на бизнес/Репутацию».
3. 🛠️Технический компромисс: Предложение тех.команде не пересчитывать 100% данных, а разработать скрипт «обратного потока данных» или обогащения данными на стороне CRM (досылка правильных атрибутов).
4. 🛎️ Прозрачность: Разбора полетов и план коммуникации с пострадавшими клиентами (извинения + двойной кешбэк), если баг дошел до пользователей.
1. ⛑️ Первая помощь (первые 30 минут)
Немедленная коммуникация с маркетингом. Если нельзя остановить рассылку, можно ли остановить списание средств? Блокировка отправки пушей/смс самым критичным сегментам (VIP), пока не разберемся.
2. 🧰Квадрат решений: Классификация инцидента по матрице «Срочность/Важность» и «Влияние на бизнес/Репутацию».
3. 🛠️Технический компромисс: Предложение тех.команде не пересчитывать 100% данных, а разработать скрипт «обратного потока данных» или обогащения данными на стороне CRM (досылка правильных атрибутов).
4. 🛎️ Прозрачность: Разбора полетов и план коммуникации с пострадавшими клиентами (извинения + двойной кешбэк), если баг дошел до пользователей.
👍1
Кейс №2: «Молчаливая поломка»
Контекст:
Вы отвечаете за пайплайн данных, поставляющий данные для управленческую отчетность. В понедельник утром на оперативном совещании гендир заявляет, что «продажи рухнули на 30% в выходные» и требует наказания команды. Вы открываете дашборд — данные действительно красные. Вы звоните инженерам: «Все сервисы зеленые, ETL (процесс загрузки данных) завершился успешно в 03:00 ночи».
Через час выясняется, что смежная команда обновила API системы-источника (CRM), но забыла предупредить. Данные загружались, но грузились NULL или дубли в ключевом поле revenue…
Вопрос:
Каков план ваших действий?
Что сделаете в первую очередь?
Как выстроите коммуникацию с руководством и командами?
Контекст:
Вы отвечаете за пайплайн данных, поставляющий данные для управленческую отчетность. В понедельник утром на оперативном совещании гендир заявляет, что «продажи рухнули на 30% в выходные» и требует наказания команды. Вы открываете дашборд — данные действительно красные. Вы звоните инженерам: «Все сервисы зеленые, ETL (процесс загрузки данных) завершился успешно в 03:00 ночи».
Через час выясняется, что смежная команда обновила API системы-источника (CRM), но забыла предупредить. Данные загружались, но грузились NULL или дубли в ключевом поле revenue…
Вопрос:
Каков план ваших действий?
Что сделаете в первую очередь?
Как выстроите коммуникацию с руководством и командами?
Непутевые Заметки Data Steward ‘а
Кейс №2: «Молчаливая поломка» Контекст: Вы отвечаете за пайплайн данных, поставляющий данные для управленческую отчетность. В понедельник утром на оперативном совещании гендир заявляет, что «продажи рухнули на 30% в выходные» и требует наказания команды.…
Вариант ответа:
1. Перевести разговор из эмоциональной плоскости в техническую: «Давайте разберемся, данные требуют верификации».
2. Маршрут данных (Data Lineage): Показать, как строится пайалайн. Использовать концепцию родословной данных, чтобы найти точку сбоя (source -> staging -> mart).
3. Иногда нужно иметь План Б: Быстрый запуск пересчета данных за выходные из сырого бакета (raw data) в обход сломанного API, если есть снапшоты. Оценка времени на исправление.
4. Управление ожиданиями: Предложить гендиру метрику "SLA по качеству данных" и создать протокол оповещения топ-менеджмента о "ненадежных данных" на дашбордах (например, раскрашивать плитки желтым, пока идет верификация).
1. Перевести разговор из эмоциональной плоскости в техническую: «Давайте разберемся, данные требуют верификации».
2. Маршрут данных (Data Lineage): Показать, как строится пайалайн. Использовать концепцию родословной данных, чтобы найти точку сбоя (source -> staging -> mart).
3. Иногда нужно иметь План Б: Быстрый запуск пересчета данных за выходные из сырого бакета (raw data) в обход сломанного API, если есть снапшоты. Оценка времени на исправление.
4. Управление ожиданиями: Предложить гендиру метрику "SLA по качеству данных" и создать протокол оповещения топ-менеджмента о "ненадежных данных" на дашбордах (например, раскрашивать плитки желтым, пока идет верификация).
Короткая заметка на тему
Рисуем архитектуру данных бесплатно:
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.
Рисуем архитектуру данных бесплатно:
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.
❤2👍2🔥1
Напомнило случай, когда показатели делают ради самих показателей:
Forwarded from Comedy Radio
🤓 В МФЦ можно поставить негативную оценку за работу, но она не учитывается в общей статистке
👉Подписаться на Comedy Radio
👉Подписаться на Comedy Radio
😁3🥰1
Цена проверки
Стоимость запуска одной проверки качества данных в DWH складывается из переменных затрат, зависящих от:
архитектуры (On-Premise / Cloud),
инструментария (dbt, Spark, DG-платформы)
объема данных.
В частности затраты:
1. Железо:
- Стоимость CPU и RAM: Чем сложнее проверка (например сложная аномалия на основе скользящего окна или сравнение с ML-моделью), тем дольше она работает. Можно почитать так:
- Затраты на оркестрацию: Если проверка запускается через 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. Логирование, мониторинг и хранение истории
Каждый запуск проверки записывает строку в таблицу логов.
Затраты на хранение этой истории со временем растут линейно от количества запусков.
Стоимость запуска одной проверки качества данных в 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. Логирование, мониторинг и хранение истории
Каждый запуск проверки записывает строку в таблицу логов.
Затраты на хранение этой истории со временем растут линейно от количества запусков.
❤2🤝1
С каждым разом все поражает , когда без выстроенной системы данных, без внятной методологии мы хотим внедрять AI и надеемся что он нам все полечит. Заменит и DE и DS,разрабов, Тим лидов.
Останется работать только Ванька, который будет лихо вайб кодить.
Красота ж.
Останется работать только Ванька, который будет лихо вайб кодить.
Красота ж.