Pull to refresh

Comments 6

Какая из этих методологий больше подходит по гибкости под большую часть компаний

Не бывает универсальных методологий ;)

Хоть какие-то рамки нужно задавать, размер компании, стадия развития, количество данных и их поток, цель какая?

Размер и стадия - чтобы прикинуть кто занимается данными сейчас, бух Галина или отдел аналитики.

Количество и сколько данных - чтобы хотя бы приблизительно понимать, на чем строить.

Цель - в общем это вообще самое важное ;) Без нее будет собираться не то и не так (точнее уже собирается, но цель позволяет, определиться с набором первых шагов, может цель "десяток дашбордов, чтобы главный был доволен")

Соглашусь, универсальной методологии действительно не существует, и выбор определяется контекстом: задачами бизнеса, количеством источников, тем, кто вообще работает с данными внутри компании.

Именно поэтому в проектах мы ориентируемся на подход A16Z, о котором упомянуто в статье: в подборе архитектуры и стека отталкиваемся от уровня data-зрелости компании и встраиваем хранилище в имеющуюся инфраструктуру управления данными.

Если смотреть в целом, к внедрению DWH с нуля приходят компании, которые находятся на минимальном или установленном уровне зрелости управления данными (классификация DMMA). На этих уровнях важно сначала навести порядок в данных, уйти от хаотичной аналитики и выстроить базовые практики управления данными, а уже потом думать о масштабировании и сложных сценариях анализа.

Поэтому для быстрого старта и понятной аналитики чаще строят витрины (Кимбалл), а при росте источников и усложнении задач добавляют более гибкое ядро (часто Data Vault). Гибридный подход дает баланс между скоростью внедрения и возможностью дальнейшего развития.

Если компания уже внедрила DWH и вышла на управляемый уровень зрелости, дальше обычно начинается масштабирование: появляются Data Lake и Lakehouse, комбинирование разных хранилищ под разные задачи. А на продвинутом уровне можно говорить о таких концептуальных подходах, как Data Mesh.

В любом случае логика одна - двигаться от простого к сложному и не пытаться сразу построить идеальную архитектуру. Начать стоит с предпроектного обследования, в ходе которого выявляются цели, задачи, требования и ограничения проекта DWH.

Неплохая статья, но она скорее про концепцию. Хорошо упомянуто,что без цели DWH превращается в свалку. Зрелость бизнеса тут самое важное.

На деле было бы интересно почитать про практику реализации.

  1. ETL, особенно в купе с ИИ (обработка неформатированных бумажных и электронных документов, аудио/видео контент)

  2. MDM/PIM - нормализацию единых НСИ и упаковку ее в структуру. Тоже с ИИ, особенно если номенклатура не имеет отраслевого идентификатора.

А так это очередно модное слово, реализацию которого мы делали десятилетиями имея гетерогенное/лоскутное поле систем и данных. Иного выбора не было.

Спасибо за оценку! Статья создавалась с целью закрыть основные вопросы тех, кто только подходит к теме и хочет получить объяснения более простым языком.

Действительно, DWH как концепция существует давно - новое здесь не столько в идее, сколько в системных подходах к реализации и масштабе задач.

По вашим пунктам:

1. ETL + ИИ – с такими сценариями сталкиваемся, но это уже выходит за рамки классического DWH. Обычно подобные задачи решаются в связке с Data Lake и ML-инструментами. Мы же чаще всего работаем с SMB-сегментом, где компаниям первостепенно важно решить более тривиальные задачи качества и консолидации данных, и только потом прийти к ИИ.
2. MDM / НСИ – актуальная тема, без нормализации справочников DWH быстро деградирует. При этом это в большей степени организационная задача, чем техническая: нужно договориться о единых сущностях и правилах. Вопрос инструмента в контексте Data Quality третий по порядку после людей (оргструктуры) и методологии. ИИ-инструменты уже используются на проектах, но они являются следствием высокого понимания проблематики и стандартов к которым должны приводиться данные.

Поддержу @qlever, на практике в среднем бизнесе самая большая проблема не стек и не методология, а то, что у мастер-данных нет хозяина по имени. «Контрагент» в CRM, бухгалтерии и логистике - три разных сущности, и каждый отдел уверен что прав. Пока не вырастишь Data Owner’ов на стороне бизнеса, до технологии и не доходишь - она вторична.

Sign up to leave a comment.

Articles