Привет!
Кажется, первая статья нашла своего благодарного читателя.
Снова мысли от CDO трудящегося вместе с одной небольшой компанией.
Продолжу о том, что "наболело".
Эта статья может быть Вам полезна, если консалтинг/интегратор/CTO/CIO/сын маминой подруги настойчиво хочет решить все Ваши "проблемы" в аналитике классным корпоративным хранилищем, далее - DWH.
Иногда специалисты склонны называть DWH место, куда просто всё сгрузили, например, в какую-либо СУБД, MDX OLAP, S3 тот же. По сети ходят мемы про dwh на excel.
И, в принципе, это всё тоже можно называть хранилищем. Тут как с аналитиками и многообразием специальностей.
В этой статье про другое DWH.
Для меня DWH/корп.хранилище/Хранилище - это, в первую очередь, система, которая включает процессы транспорта данных, профилирования - проверки на полноту и консистентность (гуглим, если читаем в первый раз), дообогащения, нормализации, моделирования и преобразования.
Ещё для DWH нужна модель хранения данных, автоматизация рутинных операций, регламенты ведения разработки.
Наверняка, вместе со словами о DWH Вы слышали про корректные, доступные, удобные и быстрые витрины данных. Что хорошее хранилище - это один из лучших способов повышения культуры данных в компании. А за DWH сразу тянется потребность в документации, бесчисленные тесты подтягивают качество и доверие к данным. Аналитики делают свои задачи быстрее и правильнее, расчёты согласованные. С DWH Ваши специалисты успешно и быстро решают задачи на ML/LLM/AI.
Всё это правда, только не полная.
DWH - это система, это про стратегию, про далёкое и светлое и упорядоченное.
И к нему безусловно следует стремиться, иногда.
DWH также - один из инструментов, который может использоваться для развития аналитики и data-driven подхода, который может использоваться в компании вместе с системой контроля качества данных, с глоссарием/каталогом, вариацией self-service и BI, системы MDM/НСИ.
Как любой другой инструмент, DWH стоит создавать и использовать при наличии на это потребности.
Возможно, именно для Вашего проекта DWH не нужен. И без него аналитики достаточно и аналитика качественная.
Разберём когда DWH НЕ нужен
Проект только начался, с методиками расчётов ещё не определились, не знаем как устроены данные/плохо представляем модель данных компании/продуктивный контур под активным рефакторингом - не доработка, а именно рефакторинг.
Риск тут в том, что разработанное потом и кровью нужно будет переделывать "с 0", не потому что ошиблись, а потому что реальность оказалась совсем иной.Все интересные для аналитики данные лежат в одном источнике/расчёты собираются в пределах одного источника данных И данных мало, до 2 ТБ + прирост данных в год до 200 МБ.
А зачем тогда хранилище? Строим отчётность на репликах прода. Если нужно, собираем все нужные реплики на одном сервереНет потребности в регулярных расчётах. Вам больше интересны однократные исследования
Возможно, потребности в регулярных расчётах у Вас и не будет, возможно, это случай про начало проекта, когда ещё не понятно как на цифрах управлять бизнесом. Риски указал вышеУ Вас нет бюджета на это мероприятие. Цена вопроса ~1,2 млн.rur. на ФОТ + 0,5 млн.rur. на железо. Для разработки DWH Вам нужен devops/dba с уклоном в инженерные задачи для репликации данных, которые будете собирать в хранилище, системный аналитик для профилирования данных и проработки модели данных, архитектор для определении архитектуры хранения, правил разработки и инженер для настройки и сопровождения Extract-Load-Transform-процесса. Каждый стоит ~350k rur на сегодня. Да, можно на старте все эти роли закрывать одним человеком. Видел проекты, в которых 1 человек всё DWH и поддерживает.
Если Вам достаточно 1 человека на DWH, возможно, и без DWH потребность можно было закрытьНекому пользоваться хранилищем. Вот такой вот парадокс. Основные пользователи DWH - аналитики. Если у Вас нет/меньше 3-х аналитиков, скорее всего, потребность в аналитике можно закрыть без хранилища - на автоматизациях программированием и/или коробочными предложениями от крупных поставщиков BI решений. Тот же Power BI предлагает внутри своего облака делать небольшое хранилище.
И это будет быстрее-дешевле и проще
Ни один из пунктов не остановил?
Тогда вот ещё несколько "не" про DWH
не дёшево в ресурсах на разработку, на внедрение, на сопровождение и на ошибки
Для хорошей реализации одной витринки на 3-4 табличках нужно ~1/2 месяца времени системного аналитика и ~1 месяц времени инженера. Ошибка в реализации часто приводит к удорожанию работ в 2 раза.
не решает всех потребностей аналитики
Часто аналитика нужна сегодня, по той фиче, которую вчера выкатили. И возможно, эта аналитика к чему-то регулярному не приведёт
не строится "с наскоку" и по неизведанным данным
Хранилище - это определённая структура. Чтобы что-либо сложить в структуру, нужно хорошо понимать природу данных, особенности и ограничения данных
Может показаться что я против хранилищ. Я за. Сам разрабатывал хранилище на позиции инженера, руководил тремя командами инженеров в трёх разных командах и, конечно, был одним из самых частых пользователей.
Думаю, DWH - это про определённую зрелость функции аналитики и культуры работы с цифрами в компании.
Пока зреете, будет полезнее сфокусировать внимание на каталоге данных, реестре отчётов и расчётов/дереве метрик, стандартах процессов работы с данными, на вопросах качества данных и на популяризации data-driven в принятии решений.
И да, будет нормально НЕ строить DWH, но сгрузить все нужные источники на один сервер.
Часто, под DWH понимают только это.
Буду рад комментариям.
Надеюсь, пара незрелых проектов разработки DWH свернётся за недостаточностью оснований.
Комментарии (16)
imotorin
04.12.2024 11:27включу зануду
RUR - (810) обозначение российского рубля до деноминации 1998г
RUB - (643) нонешнее обозначение российского рубляВики
https://ru.wikipedia.org/wiki/Российский_рубль
Буквенный код российского рубля в стандарте ISO 4217 — RUB, цифровой — 643; до денежной реформы 1998 года использовался код RUR (810)[10]. Этот цифровой код (810) исключён и из стандарта ISO 4217, и из Общероссийского классификатора валют, но продолжает использоваться для нумерации банковских счетов[11].
heisil
04.12.2024 11:27А есть ли смысл при любой непонятной ситуации затрачивать время на тяжелый data vault уровень (silver) DWH, если можно сразу data mart'ы (gold) делать из стандартизированных staging данных (bronze)? Оно (data vault) все равно для аналитики не годится (оптимизирован для записи/изменения). На один этап сложной транформации станет меньше и саппорт легче как по мне. Метаинфу можно пристроить в ту же staging.
AkaMikhelson Автор
04.12.2024 11:27Привет!
Предположу, что data vault - это не единственный вариант модели хранения данных.
Если Ваш вопрос про то - надо ли вообще заморачиваться с нормализацией, логической и физической моделью данных, то мой ответ - если действительно нужно хранилище - да, конечно надо.
Смысл "тяжёлого silver уровня" в data vault, как минимум, в том, чтобы
- проще было масштабировать хранилище при появлении доп.источников/изменениях
- без проблем/тяжелых исследований создавать/дорабатывать/менять пайплайны данных, сохраняя консистентность и согласованность данных
Ответил на вопрос?heisil
04.12.2024 11:27OK. Соглашусь. Хотя для меня ядро DWH наверное больше raw + staging, а не консистентный нормализованный уровень, так как при каждой трансформации утрачивается некоторая часть данных, и при ошибке в логике можно восстановить их по raw/stage данным.
AkaMikhelson Автор
04.12.2024 11:27Мне думается, что если хранилище заканчивается на row + staging, это больше похоже на lakehouse, чем на DWH)
heisil
04.12.2024 11:27Оно не заканчивается. Скорее является фундаментом, если грамотно каталогизировать, документировать, поддерживать и управлять. А всякие star schema, data vault - это производное, кому как удобно решать проблемы.
masdv
04.12.2024 11:27Делать надо чтобы решало цель бизнеса за минимальную плату и быстро. Дядькам сверху вообще не ведом этот дата волт им презенташка нужна с достоверными данными и все. А как она получилась не важно
AkaMikhelson Автор
04.12.2024 11:27Привет!
Всё так.
По классике, дядькам сверху по любому вопросу надо чтобы было дёшево и стабильно без проблем.
И в случае, когда без тяжёлых инженерных систем не обойтись, начинаются интересные защиты перед дядьками).
heisil
04.12.2024 11:27Я так и делаю. Все довольны. Раньше делал по бест практисам как в книжках, но получалось долго, сложно и мучительно больно для всех.
Q3_Results
04.12.2024 11:27Кто мешает к оптимизированному на запись\изменения прикрутить репликацию на OLAP-базу для этих аналитиков, пусть кладут сколько угодно, но основной прод онлайн и консистентен
AkaMikhelson Автор
04.12.2024 11:27Привет!
Вот тут не понял.
Добавьте деталей по предложению, пожалуйста
AlexMinch
04.12.2024 11:27Работаю аналитиком в одной не очень большой российской компании (а всего нас двое). Не знаю половины ваших красивых инженерных слов, но точно знаю, что с внедрением DWH стало жить гораздо проще.
Можно не использовать DWH. А откуда собственно брать данные, как их аккумулировать? Можно с примером альтернативы? Мне вот кроме файликов csv да xlsx ничего в голову не приходит.
В качестве ERP у нас 1С, задача 1сникам это долго, нудно и с плавающим результатом на выходе.
А есть ещё CRM, а ещё 3-4 сторонних источника, а ещё просто файлики справочники разных отделов, а кто сказал что BI и Power BI в частности будет со всем этим работать напрямую? А если да, то с какой скоростью? А предобработку на SQL можно сделать, чтобы не весь массив запросом тянуть? А какой data driven, если если эту дату по закоулкам искать надо? Выдвинул гипотезу и неделю всё собирать перепроверять? Ну нет.
У нас один DWHшник всё тянет, да чуток глаз у него дёргается, ну так с нуля всё фактически, можт кому и не надо, совсем молодняку без IT инфраструктуры, где бухгалтер и админ сидят, а где человек 100-200 есть, уже лучше с DWH чем без него. ИМХО так сказать.
AkaMikhelson Автор
04.12.2024 11:27Привет!
Если в Вашем случае, нужные данные лежат по разным базкам, возможно, простой-быстрой альтернативой DWH будет настройка логической репликации из нескольких баз в одну для PgSQL или linked servers для MsSQL.
На сколько я помню, 1С работают на одной из этих СУБД.
Ещё, как вариант, если устраивает лаг по свежести данных в пару часов и более, посмотрите в сторону восстановления бекапов нужных Вам баз на одном сервере и связи через linked.
Логическая репликация позволит работать со всем данными в одной базе, это точно быстрее любых линков. Линки - это доп.особенности к написанию запросов к данным, но всё решаемо, полагаю. Если данных до 3 ТБ и нет супер-огромных таблиц по 1 млрд+ строк, и линки будут летать.
economist75
Хорошо расписано про то когда DWH не нужен. У меня как раз так. Но при этом DWH настойчиво предлагают все консалтеры под любым предлогом, и ценник на железо явно повыше: не +0.5M, а как минимум +2M.