Comments 19
Хорошо расписано про то когда DWH не нужен. У меня как раз так. Но при этом DWH настойчиво предлагают все консалтеры под любым предлогом, и ценник на железо явно повыше: не +0.5M, а как минимум +2M.
включу зануду
RUR - (810) обозначение российского рубля до деноминации 1998г
RUB - (643) нонешнее обозначение российского рубля
Вики
https://ru.wikipedia.org/wiki/Российский_рубль
Буквенный код российского рубля в стандарте ISO 4217 — RUB, цифровой — 643; до денежной реформы 1998 года использовался код RUR (810)[10]. Этот цифровой код (810) исключён и из стандарта ISO 4217, и из Общероссийского классификатора валют, но продолжает использоваться для нумерации банковских счетов[11].
А есть ли смысл при любой непонятной ситуации затрачивать время на тяжелый data vault уровень (silver) DWH, если можно сразу data mart'ы (gold) делать из стандартизированных staging данных (bronze)? Оно (data vault) все равно для аналитики не годится (оптимизирован для записи/изменения). На один этап сложной транформации станет меньше и саппорт легче как по мне. Метаинфу можно пристроить в ту же staging.
Привет!
Предположу, что data vault - это не единственный вариант модели хранения данных.
Если Ваш вопрос про то - надо ли вообще заморачиваться с нормализацией, логической и физической моделью данных, то мой ответ - если действительно нужно хранилище - да, конечно надо.
Смысл "тяжёлого silver уровня" в data vault, как минимум, в том, чтобы
- проще было масштабировать хранилище при появлении доп.источников/изменениях
- без проблем/тяжелых исследований создавать/дорабатывать/менять пайплайны данных, сохраняя консистентность и согласованность данных
Ответил на вопрос?
OK. Соглашусь. Хотя для меня ядро DWH наверное больше raw + staging, а не консистентный нормализованный уровень, так как при каждой трансформации утрачивается некоторая часть данных, и при ошибке в логике можно восстановить их по raw/stage данным.
Мне думается, что если хранилище заканчивается на row + staging, это больше похоже на lakehouse, чем на DWH)
Делать надо чтобы решало цель бизнеса за минимальную плату и быстро. Дядькам сверху вообще не ведом этот дата волт им презенташка нужна с достоверными данными и все. А как она получилась не важно
Привет!
Всё так.
По классике, дядькам сверху по любому вопросу надо чтобы было дёшево и стабильно без проблем.
И в случае, когда без тяжёлых инженерных систем не обойтись, начинаются интересные защиты перед дядьками).
Я так и делаю. Все довольны. Раньше делал по бест практисам как в книжках, но получалось долго, сложно и мучительно больно для всех.
Кто мешает к оптимизированному на запись\изменения прикрутить репликацию на OLAP-базу для этих аналитиков, пусть кладут сколько угодно, но основной прод онлайн и консистентен
Работаю аналитиком в одной не очень большой российской компании (а всего нас двое). Не знаю половины ваших красивых инженерных слов, но точно знаю, что с внедрением DWH стало жить гораздо проще.
Можно не использовать DWH. А откуда собственно брать данные, как их аккумулировать? Можно с примером альтернативы? Мне вот кроме файликов csv да xlsx ничего в голову не приходит.
В качестве ERP у нас 1С, задача 1сникам это долго, нудно и с плавающим результатом на выходе.
А есть ещё CRM, а ещё 3-4 сторонних источника, а ещё просто файлики справочники разных отделов, а кто сказал что BI и Power BI в частности будет со всем этим работать напрямую? А если да, то с какой скоростью? А предобработку на SQL можно сделать, чтобы не весь массив запросом тянуть? А какой data driven, если если эту дату по закоулкам искать надо? Выдвинул гипотезу и неделю всё собирать перепроверять? Ну нет.
У нас один DWHшник всё тянет, да чуток глаз у него дёргается, ну так с нуля всё фактически, можт кому и не надо, совсем молодняку без IT инфраструктуры, где бухгалтер и админ сидят, а где человек 100-200 есть, уже лучше с DWH чем без него. ИМХО так сказать.
Привет!
Если в Вашем случае, нужные данные лежат по разным базкам, возможно, простой-быстрой альтернативой DWH будет настройка логической репликации из нескольких баз в одну для PgSQL или linked servers для MsSQL.
На сколько я помню, 1С работают на одной из этих СУБД.
Ещё, как вариант, если устраивает лаг по свежести данных в пару часов и более, посмотрите в сторону восстановления бекапов нужных Вам баз на одном сервере и связи через linked.
Логическая репликация позволит работать со всем данными в одной базе, это точно быстрее любых линков. Линки - это доп.особенности к написанию запросов к данным, но всё решаемо, полагаю. Если данных до 3 ТБ и нет супер-огромных таблиц по 1 млрд+ строк, и линки будут летать.
Действительно, около 80% всех данных у коммерческих компаний среднего-крупного размера хранятся в 1С (PostgreSQL/MSSQL/SQLite). Остальное - в чем-то еще и "эксельках".
Проблемы тут две: 1С запрещает работать с ее данными напрямую из DBeaver итп (извольте писать SQL-запросы в 1C-Конструкторе), а еще 1С-данные лежат в 10 тысячах(!) таблиц с непонятными названиями (чтобы джойнить в чем-то стороннем расхотелось сразу и навсегда). Монополизм он такой. Поэтому прав коллега - 1сники это так долго и нудно, что проще не просить.
Привет!
Не могу согласиться.
С 1с можно работать из компилятора вроде dbeaver. Под 1С фреймворком либо mssql либо pgsql. Подключайтесь и работайте.
Из 1с даже стримить можно отдельные объекты в нужные вам приемники. Посмотрите в сторону dbr от softpoint
Dbeaver крупные компании используют, но "со вчерашней копией 1С-данных" или в режиме ReadOnly к продовой БД, нарушая лиц. условия 1С (инфописьмо их об этом сходу не нашел).
С платформой 1С - согласен, из под нее доступно всё, и стримить можно, и регламентными заданиями зеркалить регистры в понятные внешние БД. Но не покидает ощущение чужого продукта, намеренно переусложненного для отстрела автоматизаторов-одиночек на местах. Если честно это "война", и мирятся с этим немногие.
Что-ж, 1С выстроила и правда очень эффективную бизнес-модель монополиста, и мы позволили ей занять 86% рынка учетных систем РФ. Так что роптать нельзя, импортозамес и все такое. Но 1С всем средне-крупным не хватает, потому что долго/сложно, а временами еще и криво. Даже изменения бухучета отражаются в больших 1С-коробках (ERP, УПП, КА итд) в авральном режиме, тут не до аналитики. В контексте темы статьи - 1С-данные провоцируют создание и затем висят бельмом в любой DWH/DL/DM, являются болевой точкой и требуют изменений в будущем. Боюсь без появления конкуренции изменения не наступят.
Пора перестать в любой непонятной ситуации строить DWH для аналитики