|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
Коллеги, кто-то использует такое в ХД? Когда у вас десятки слабосвязанных витрин. Пытаюсь сообразить, для чего так делать, пока вывод такой - можно быстро слепить, особенно, если над ХД работает несколько независимых команд, причем каждая команда по своим правилам. Но ведь после наступает стадия поддержки. И изменение одного первичного источника приведёт к необходимости править десятки почти одинаковых (но разных!) подсистем. Это же ад для поддержки. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.06.2021, 16:04 |
|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
Критик, Если витрины уже слабосвязанные, то связывать их в дальнейшем врят ли понадобится, вполне нормальная архитектура, описана в книжке Кимбала. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.06.2021, 16:10 |
|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
Полковник. Критик, Если витрины уже слабосвязанные, то связывать их в дальнейшем врят ли понадобится, вполне нормальная архитектура, описана в книжке Кимбала. Например, если обе витрины показывают выручку, но для разных отделов, и их итоги "немного" отличаются, хотя должны быть одинаковыми - это, обычно, "раздражает" пользователей. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 01:50 |
|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
s_ustinov, "Выручка" пришла из разных источников? Если нет, то это, извините, не архитектура, а баг. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 14:52 |
|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
Полковник. s_ustinov, "Выручка" пришла из разных источников? Если нет, то это, извините, не архитектура, а баг. Да, из разных. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 19:14 |
|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
s_ustinov, ОК, ну раз из разных источников, тогда требование к фактам "должна быть одинаковой" нужно переадресовать к источникам данных. Слабосогласованные витрины например могут быть такие - витрина закупок на основе системы SRM, и витрина анализа жизнедеятельности партии материалов на основе складского учёта ERP, справочники материалов могут быть не согласованы между собой иметь разное наполнение и разные иерархии. А вы пишете про кривые факты. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.06.2021, 07:14 |
|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
Мне, честно, не нравится такой подход. Потому что они сначала никак не связаны, а потом постепенно там появляются связи в виде одинаковых справочников или почти одинаковых, что еще хуже, потому что так мы постепенно терям "единую версию правды" ... |
|||
:
Нравится:
Не нравится:
|
|||
21.06.2021, 13:12 |
|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
Критик, Появятся, если будет необходимость протянуть процесс от создания потребности и закупки до списания партии со склада. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.06.2021, 14:01 |
|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
Полковник. Критик, Появятся, если будет необходимость протянуть процесс от создания потребности и закупки до списания партии со склада. Такое желание всегда есть у менеджмента - видеть картину от и до. Да, это не всегда очень необходимо, но всегда - может быть полезно. Как только появляются такие данные - сразу же появляется возможность дополнительной оптимизации. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.06.2021, 11:39 |
|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
Полковник. s_ustinov, ОК, ну раз из разных источников, тогда требование к фактам "должна быть одинаковой" нужно переадресовать к источникам данных. Слабосогласованные витрины например могут быть такие - витрина закупок на основе системы SRM, и витрина анализа жизнедеятельности партии материалов на основе складского учёта ERP, справочники материалов могут быть не согласованы между собой иметь разное наполнение и разные иерархии. А вы пишете про кривые факты. -Мыши! Станьте ежами! Чтобы "выровнять" факты, надо поместить факты из нескольких систем в одно место, сравнить их между собой и выявить все расхождения (это может быть весьма нетривиально), выработать методику устранения по каждому из типов расхождений (а это вообще может быть крайне сложно - часто для "выравнивания" надо менять бизнес процессы, корректировать учетную политику и т.п.), сгенерировать выравнивающие "корректировки" и загрузить их в каждую из систем. Лучшего кандидата в качестве такой "точки сборки", чем DWH, я не знаю. И если у нас есть только набор слабосвязанных витрин - выровнять данные, скорее всего, будет технически невозможно. Все будут стараться, что то делать - но данные так и останутся "кривыми". ... |
|||
:
Нравится:
Не нравится:
|
|||
22.06.2021, 11:49 |
|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
Это нормальный процесс эволюции хд, т.к. уже давно в крупных компаниях невозможно построить ОДНУ общую модель на ВЕСЬ бизнес. Ну точнее это занимает годы даже в первом приближении, а по факту скорость ее создания меньше чем скорость изменения самого бизнеса. В итоге единственным работающим вариантом становиться модель на ЧАСТЬ бизнеса с соответствующими витринами. Точнее не одна а несколько создающихся в паралели меньших моделей для частей бизнеса. И до какого-то момента они полностью не пересекаются,но всегда в какой-то момент возникает задача их объединения. И чаще всего никто не ломает структуру снизу, а добавляют еще один(или не один) логический слой сверху, превращая все это в такую слоеную капусту, где докапаться до самого нижнего слоя бывает часто просто не возможно. Паралельно в процесе объединения возникают задачи уровня создания глобального MDM которые сами по себе занимают годы. Таким образом можно сказать что процес объединения моделей разных частей бизнеса идет всегда непрерывно, однако никогда не способен достигнуть финальной стадии где все уже объединено. Новые бизнес процессы и новые дата можели зарождаются в недрах больших компаний с огромной скоростью, в виде сперва экселей, потом мини дашбордов сделаных самими юзхерами в каком-нить powerbi, а потом глядь- и уже новый датамарт на новых сорсах где-то живет в своем микромире. Это все напоминает эволюцию в животном мире, с новым видообразованием, конкуренцией и естественным отбором ... |
|||
:
Нравится:
Не нравится:
|
|||
22.06.2021, 12:05 |
|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
Критик Мне, честно, не нравится такой подход. Потому что они сначала никак не связаны, а потом постепенно там появляются связи в виде одинаковых справочников или почти одинаковых, что еще хуже, потому что так мы постепенно терям "единую версию правды" а никакого друго подхода и нет, создать "единую версию правды" уже для бизнеса уровня одного среднего банка невозможно, неговоря уже про нормальные международные корпорации. Для примера можно вспомнить что в рф реалиях всегда модельки и витрины внутри 1С (для налогов, зарплат или отпусков) никак не связаны с моделями учета основного бизнеса. И живут паралельно годами и десятилетиями, и никто в здравом уме не будет СРАЗУ их созадвать объединенными, до тех пор пока компания не созреет до момента зрелости когда уже можно объединить все расходы с доходами, что в большинстве компаний на самом деле вообще не наступает никогда. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.06.2021, 12:21 |
|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
Ivan Durak, +1, даже если компания доросла и выделила бюджет, все равно будут только что поглащеные компании, которые еще живут на своих системах со своими dwh и только начинают миграции и интеграции. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.06.2021, 12:25 |
|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
H5N1, Мы в этом случае отбрасывали "их DWH" и, используя первичные источники, заливали данные в нашу модель. У меня есть опыт подобного по поглощению трех банков, довольно нормально работает. Основная причина успеха в том, что центр принятия решений перемещался к нам, а наш топ-менеджмент привык к нашему DWH ... |
|||
:
Нравится:
Не нравится:
|
|||
22.06.2021, 12:39 |
|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
s_ustinov, Факты, это сто рублей выручки в одной системе и двести рублей выручки в другой системе на одних и тех же операциях? Что вы хотите выравнивать? У вас явный косяк в источниках данных, или кто то в наглую кладёт бабки мимо кассы себе в карман. Когда говорят о связанных или согласованных витринах говорят о справочниках а не фактах ... |
|||
:
Нравится:
Не нравится:
|
|||
22.06.2021, 12:49 |
|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
Полковник. s_ustinov, Факты, это сто рублей выручки в одной системе и двести рублей выручки в другой системе на одних и тех же операциях? Что вы хотите выравнивать? У вас явный косяк в источниках данных, или кто то в наглую кладёт бабки мимо кассы себе в карман. Когда говорят о связанных или согласованных витринах говорят о справочниках а не фактах Дата признания выручки, курс для пересчета в валюту отчетности (операции наверно в 20-30 разных валютах, как то не интересовался, сколько именно), в одном из типов источников не все транзакции... Причин расхождений довольно много. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.06.2021, 13:32 |
|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
s_ustinov Полковник. s_ustinov, Факты, это сто рублей выручки в одной системе и двести рублей выручки в другой системе на одних и тех же операциях? Что вы хотите выравнивать? У вас явный косяк в источниках данных, или кто то в наглую кладёт бабки мимо кассы себе в карман. Когда говорят о связанных или согласованных витринах говорят о справочниках а не фактах Дата признания выручки, курс для пересчета в валюту отчетности (операции наверно в 20-30 разных валютах, как то не интересовался, сколько именно), в одном из типов источников не все транзакции... Причин расхождений довольно много. Стало интересно, посмотрел сейчас - операции у нас в 37 разных валютах. Включая достаточно экзотические. Я надеюсь, вы не ожидаете, что бухгалтера в какой нибудь Малайзии будут использовать те же самые курсы валют, которые решили использовать программисты в центральном офисе, не имеющие отношения к финансам? Вот и один из источников расхождений в фактах . Отчеты то все по холдингу надо в Евро формировать... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.06.2021, 15:01 |
|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
Ivan Durak Это нормальный процесс эволюции хд, т.к. уже давно в крупных компаниях невозможно построить ОДНУ общую модель на ВЕСЬ бизнес. Ну точнее это занимает годы даже в первом приближении, а по факту скорость ее создания меньше чем скорость изменения самого бизнеса. В итоге единственным работающим вариантом становиться модель на ЧАСТЬ бизнеса с соответствующими витринами. Точнее не одна а несколько создающихся в паралели меньших моделей для частей бизнеса. И до какого-то момента они полностью не пересекаются,но всегда в какой-то момент возникает задача их объединения. И чаще всего никто не ломает структуру снизу, а добавляют еще один(или не один) логический слой сверху, превращая все это в такую слоеную капусту, где докапаться до самого нижнего слоя бывает часто просто не возможно. Паралельно в процесе объединения возникают задачи уровня создания глобального MDM которые сами по себе занимают годы. Таким образом можно сказать что процес объединения моделей разных частей бизнеса идет всегда непрерывно, однако никогда не способен достигнуть финальной стадии где все уже объединено. Новые бизнес процессы и новые дата можели зарождаются в недрах больших компаний с огромной скоростью, в виде сперва экселей, потом мини дашбордов сделаных самими юзхерами в каком-нить powerbi, а потом глядь- и уже новый датамарт на новых сорсах где-то живет в своем микромире. Это все напоминает эволюцию в животном мире, с новым видообразованием, конкуренцией и естественным отбором Построить одну модель для всего бизнеса даже среднего размера, согласен, практически невозможно. Но если сразу начать создавать все "частичные" модели с прицелом, что их потом надо будет объединять - это ОЧЕНЬ облегчит дальнейшую жизнь. Например, сразу создавать инфраструктуру таким образом, что параллельно будут жить частично (или полностью) независимые модели, но в рамках одной инфраструктуры. Как у нас было. Была BI система, собирающая данные о продажах от партнеров и там формировались отчеты о продажах. Надо было сделать систему для финансов. Я сразу предложил - выделите мне независимую область в существующей системе, мы туда будем закачивать наши данные из ERP и формировать отчеты для финансов. Но - не судьба. Причина, насколько я понимаю - при проектировании никто вообще не учитывал, что там может понадобится обрабатывать совсем другие данные. Пришлось делать свое. Как результат, сейчас есть две системы для отчетности, работающие на полностью разном стеке... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.06.2021, 15:20 |
|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
s_ustinov Надо было сделать систему для финансов. Я сразу предложил - выделите мне независимую область в существующей системе, мы туда будем закачивать наши данные из ERP и формировать отчеты для финансов. Но - не судьба. Причина, насколько я понимаю - при проектировании никто вообще не учитывал, что там может понадобится обрабатывать совсем другие данные. Пришлось делать свое. Как результат, сейчас есть две системы для отчетности, работающие на полностью разном стеке... вот потому у меня глубокое убеждение, что в крупной канторе по центру должен быть data lake/lakehouse с полноценным централизованным ХД, который и смаштабируется легко и прототип можно протестить без полноценной интеграции в ХД. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.06.2021, 17:26 |
|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
H5N1 s_ustinov Надо было сделать систему для финансов. Я сразу предложил - выделите мне независимую область в существующей системе, мы туда будем закачивать наши данные из ERP и формировать отчеты для финансов. Но - не судьба. Причина, насколько я понимаю - при проектировании никто вообще не учитывал, что там может понадобится обрабатывать совсем другие данные. Пришлось делать свое. Как результат, сейчас есть две системы для отчетности, работающие на полностью разном стеке... вот потому у меня глубокое убеждение, что в крупной канторе по центру должен быть data lake/lakehouse с полноценным централизованным ХД, который и смаштабируется легко и прототип можно протестить без полноценной интеграции в ХД. Согласен. В идеале "инфраструктурная" часть должна быть полностью отделена от самих данных / коннекторов. И нужна возможность быстро и легко создавать дополнительные отдельные области / песочницы, которые с одной стороны не будут мешать существующим схемам / витринам, но в то же время легко использовать те данные, которые кто то уже подготовил. Разумеется, проблемы все равно будут, но в других вариантах все еще хуже будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.06.2021, 19:33 |
|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
s_ustinov Стало интересно, посмотрел сейчас - операции у нас в 37 разных валютах. Включая достаточно экзотические.Я надеюсь, вы не ожидаете, что бухгалтера в какой нибудь Малайзии будут использовать те же самые курсы валют, которые решили использовать программисты в центральном офисе, не имеющие отношения к финансам? Курс валют должны задавать не программисты и не локальные бухгалтера, а должен быть четкий механизм, описанный в учетной политике: например, курс ЦБ страны или некий международный справочник валют. То есть разработка учетной политика и настройка учетной системы позволяет полностью решить данную проблему. С другой стороны, если они вместо этого решили кормить штат DWH, то дай Бог здоровья этим людям. С Уважением, Георгий ... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2021, 11:17 |
|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
Критик Коллеги, кто-то использует такое в ХД? Когда у вас десятки слабосвязанных витрин Полковник. Если витрины уже слабосвязанные, то связывать их в дальнейшем врят ли понадобится, вполне нормальная архитектура, описана в книжке Кимбала. С Уважением, Георгий ... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2021, 11:21 |
|
Микросервисная архитектура ХД
|
|||
---|---|---|---|
#18+
George Nordic s_ustinov Стало интересно, посмотрел сейчас - операции у нас в 37 разных валютах. Включая достаточно экзотические.Я надеюсь, вы не ожидаете, что бухгалтера в какой нибудь Малайзии будут использовать те же самые курсы валют, которые решили использовать программисты в центральном офисе, не имеющие отношения к финансам? Курс валют должны задавать не программисты и не локальные бухгалтера, а должен быть четкий механизм, описанный в учетной политике: например, курс ЦБ страны или некий международный справочник валют. То есть разработка учетной политика и настройка учетной системы позволяет полностью решить данную проблему. С другой стороны, если они вместо этого решили кормить штат DWH, то дай Бог здоровья этим людям. С Уважением, Георгий Одна из систем отчетности создавалась людьми, к фин учету не имеющими никакого отношения. Вот и получилась такая ситуация. Разумеется, у нас есть отдельный раздел в учетной политике, где описано, какие курсы в какой стране используем, и в ERP (Навике) мы эти курсы и используем. Но другая система использует другие курсы и алгоритмы пересчетов. Для фин отчетов мы сперва пересчитываем суммы выручки из валюты операции в функциональную валюту (в холдинге - пять функциональных валют), а потом из функциональной валюты в валюту отчетности (евро). И все это делается внутри навика. А другая система пересчитывает все напрямую, и для унификации результатов надо много менять в алгоритмах. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2021, 12:46 |
|
|
start [/forum/topic.php?fid=49&fpage=3&tid=1857122]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
22ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
others: | 228ms |
total: | 350ms |
0 / 0 |