powered by simpleCommunicator - 2.0.43     © 2025 Programmizd 02
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / Микросервисная архитектура ХД
25 сообщений из 27, страница 1 из 2
Микросервисная архитектура ХД
    #40078849
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Коллеги, кто-то использует такое в ХД? Когда у вас десятки слабосвязанных витрин.

Пытаюсь сообразить, для чего так делать, пока вывод такой - можно быстро слепить, особенно, если над ХД работает несколько независимых команд, причем каждая команда по своим правилам.

Но ведь после наступает стадия поддержки. И изменение одного первичного источника приведёт к необходимости править десятки почти одинаковых (но разных!) подсистем. Это же ад для поддержки.
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40078850
Полковник.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Критик,
Если витрины уже слабосвязанные, то связывать их в дальнейшем врят ли понадобится, вполне нормальная архитектура, описана в книжке Кимбала.
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40078907
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Полковник.
Критик,
Если витрины уже слабосвязанные, то связывать их в дальнейшем врят ли понадобится, вполне нормальная архитектура, описана в книжке Кимбала.

Например, если обе витрины показывают выручку, но для разных отделов, и их итоги "немного" отличаются, хотя должны быть одинаковыми - это, обычно, "раздражает" пользователей.
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40078968
Полковник.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov,

"Выручка" пришла из разных источников? Если нет, то это, извините, не архитектура, а баг.
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40079001
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Полковник.
s_ustinov,

"Выручка" пришла из разных источников? Если нет, то это, извините, не архитектура, а баг.

Да, из разных.
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40079063
Полковник.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov,

ОК, ну раз из разных источников, тогда требование к фактам "должна быть одинаковой" нужно переадресовать к источникам данных.

Слабосогласованные витрины например могут быть такие - витрина закупок на основе системы SRM, и витрина анализа жизнедеятельности партии материалов на основе складского учёта ERP, справочники материалов могут быть не согласованы между собой иметь разное наполнение и разные иерархии.

А вы пишете про кривые факты.
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40079127
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мне, честно, не нравится такой подход. Потому что они сначала никак не связаны, а потом постепенно там появляются связи в виде одинаковых справочников или почти одинаковых, что еще хуже, потому что так мы постепенно терям "единую версию правды"
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40079144
Полковник.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Критик,

Появятся, если будет необходимость протянуть процесс от создания потребности и закупки до списания партии со склада.
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40079293
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Полковник.
Критик,

Появятся, если будет необходимость протянуть процесс от создания потребности и закупки до списания партии со склада.

Такое желание всегда есть у менеджмента - видеть картину от и до.
Да, это не всегда очень необходимо, но всегда - может быть полезно. Как только появляются такие данные - сразу же появляется возможность дополнительной оптимизации.
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40079295
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Полковник.
s_ustinov,

ОК, ну раз из разных источников, тогда требование к фактам "должна быть одинаковой" нужно переадресовать к источникам данных.

Слабосогласованные витрины например могут быть такие - витрина закупок на основе системы SRM, и витрина анализа жизнедеятельности партии материалов на основе складского учёта ERP, справочники материалов могут быть не согласованы между собой иметь разное наполнение и разные иерархии.

А вы пишете про кривые факты.


-Мыши! Станьте ежами!

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

Лучшего кандидата в качестве такой "точки сборки", чем DWH, я не знаю. И если у нас есть только набор слабосвязанных витрин - выровнять данные, скорее всего, будет технически невозможно. Все будут стараться, что то делать - но данные так и останутся "кривыми".
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40079301
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Это нормальный процесс эволюции хд, т.к. уже давно в крупных компаниях невозможно построить ОДНУ общую модель на ВЕСЬ бизнес.
Ну точнее это занимает годы даже в первом приближении, а по факту скорость ее создания меньше чем скорость изменения самого бизнеса.
В итоге единственным работающим вариантом становиться модель на ЧАСТЬ бизнеса с соответствующими витринами.
Точнее не одна а несколько создающихся в паралели меньших моделей для частей бизнеса. И до какого-то момента они полностью не пересекаются,но всегда в какой-то момент возникает задача их объединения.
И чаще всего никто не ломает структуру снизу, а добавляют еще один(или не один) логический слой сверху, превращая все это в такую слоеную капусту, где докапаться до самого нижнего слоя бывает часто просто не возможно.

Паралельно в процесе объединения возникают задачи уровня создания глобального MDM которые сами по себе занимают годы.
Таким образом можно сказать что процес объединения моделей разных частей бизнеса идет всегда непрерывно, однако никогда не способен достигнуть финальной стадии где все уже объединено.
Новые бизнес процессы и новые дата можели зарождаются в недрах больших компаний с огромной скоростью, в виде сперва экселей, потом мини дашбордов сделаных самими юзхерами в каком-нить powerbi, а потом глядь- и уже новый датамарт на новых сорсах где-то живет в своем микромире. Это все напоминает эволюцию в животном мире, с новым видообразованием, конкуренцией и естественным отбором
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40079302
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
.
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40079310
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Критик
Мне, честно, не нравится такой подход. Потому что они сначала никак не связаны, а потом постепенно там появляются связи в виде одинаковых справочников или почти одинаковых, что еще хуже, потому что так мы постепенно терям "единую версию правды"

а никакого друго подхода и нет, создать "единую версию правды" уже для бизнеса уровня одного среднего банка невозможно, неговоря уже про нормальные международные корпорации.
Для примера можно вспомнить что в рф реалиях всегда модельки и витрины внутри 1С (для налогов, зарплат или отпусков) никак не связаны с моделями учета основного бизнеса. И живут паралельно годами и десятилетиями, и никто в здравом уме не будет СРАЗУ их созадвать объединенными, до тех пор пока компания не созреет до момента зрелости когда уже можно объединить все расходы с доходами, что в большинстве компаний на самом деле вообще не наступает никогда.
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40079312
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
.
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40079314
H5N1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan Durak,

+1, даже если компания доросла и выделила бюджет, все равно будут только что поглащеные компании, которые еще живут на своих системах со своими dwh и только начинают миграции и интеграции.
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40079320
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
H5N1,

Мы в этом случае отбрасывали "их DWH" и, используя первичные источники, заливали данные в нашу модель. У меня есть опыт подобного по поглощению трех банков, довольно нормально работает. Основная причина успеха в том, что центр принятия решений перемещался к нам, а наш топ-менеджмент привык к нашему DWH
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40079322
Полковник.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov,
Факты, это сто рублей выручки в одной системе и двести рублей выручки в другой системе на одних и тех же операциях? Что вы хотите выравнивать? У вас явный косяк в источниках данных, или кто то в наглую кладёт бабки мимо кассы себе в карман.

Когда говорят о связанных или согласованных витринах говорят о справочниках а не фактах
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40079335
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Полковник.
s_ustinov,
Факты, это сто рублей выручки в одной системе и двести рублей выручки в другой системе на одних и тех же операциях? Что вы хотите выравнивать? У вас явный косяк в источниках данных, или кто то в наглую кладёт бабки мимо кассы себе в карман.

Когда говорят о связанных или согласованных витринах говорят о справочниках а не фактах

Дата признания выручки, курс для пересчета в валюту отчетности (операции наверно в 20-30 разных валютах, как то не интересовался, сколько именно), в одном из типов источников не все транзакции...
Причин расхождений довольно много.
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40079361
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov
Полковник.
s_ustinov,
Факты, это сто рублей выручки в одной системе и двести рублей выручки в другой системе на одних и тех же операциях? Что вы хотите выравнивать? У вас явный косяк в источниках данных, или кто то в наглую кладёт бабки мимо кассы себе в карман.

Когда говорят о связанных или согласованных витринах говорят о справочниках а не фактах

Дата признания выручки, курс для пересчета в валюту отчетности (операции наверно в 20-30 разных валютах, как то не интересовался, сколько именно), в одном из типов источников не все транзакции...
Причин расхождений довольно много.

Стало интересно, посмотрел сейчас - операции у нас в 37 разных валютах. Включая достаточно экзотические.
Я надеюсь, вы не ожидаете, что бухгалтера в какой нибудь Малайзии будут использовать те же самые курсы валют, которые решили использовать программисты в центральном офисе, не имеющие отношения к финансам?
Вот и один из источников расхождений в фактах . Отчеты то все по холдингу надо в Евро формировать...
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40079369
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan Durak
Это нормальный процесс эволюции хд, т.к. уже давно в крупных компаниях невозможно построить ОДНУ общую модель на ВЕСЬ бизнес.
Ну точнее это занимает годы даже в первом приближении, а по факту скорость ее создания меньше чем скорость изменения самого бизнеса.
В итоге единственным работающим вариантом становиться модель на ЧАСТЬ бизнеса с соответствующими витринами.
Точнее не одна а несколько создающихся в паралели меньших моделей для частей бизнеса. И до какого-то момента они полностью не пересекаются,но всегда в какой-то момент возникает задача их объединения.
И чаще всего никто не ломает структуру снизу, а добавляют еще один(или не один) логический слой сверху, превращая все это в такую слоеную капусту, где докапаться до самого нижнего слоя бывает часто просто не возможно.

Паралельно в процесе объединения возникают задачи уровня создания глобального MDM которые сами по себе занимают годы.
Таким образом можно сказать что процес объединения моделей разных частей бизнеса идет всегда непрерывно, однако никогда не способен достигнуть финальной стадии где все уже объединено.
Новые бизнес процессы и новые дата можели зарождаются в недрах больших компаний с огромной скоростью, в виде сперва экселей, потом мини дашбордов сделаных самими юзхерами в каком-нить powerbi, а потом глядь- и уже новый датамарт на новых сорсах где-то живет в своем микромире. Это все напоминает эволюцию в животном мире, с новым видообразованием, конкуренцией и естественным отбором

Построить одну модель для всего бизнеса даже среднего размера, согласен, практически невозможно.
Но если сразу начать создавать все "частичные" модели с прицелом, что их потом надо будет объединять - это ОЧЕНЬ облегчит дальнейшую жизнь.
Например, сразу создавать инфраструктуру таким образом, что параллельно будут жить частично (или полностью) независимые модели, но в рамках одной инфраструктуры.

Как у нас было.
Была BI система, собирающая данные о продажах от партнеров и там формировались отчеты о продажах.
Надо было сделать систему для финансов. Я сразу предложил - выделите мне независимую область в существующей системе, мы туда будем закачивать наши данные из ERP и формировать отчеты для финансов. Но - не судьба. Причина, насколько я понимаю - при проектировании никто вообще не учитывал, что там может понадобится обрабатывать совсем другие данные. Пришлось делать свое.
Как результат, сейчас есть две системы для отчетности, работающие на полностью разном стеке...
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40079404
H5N1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov

Надо было сделать систему для финансов. Я сразу предложил - выделите мне независимую область в существующей системе, мы туда будем закачивать наши данные из ERP и формировать отчеты для финансов. Но - не судьба. Причина, насколько я понимаю - при проектировании никто вообще не учитывал, что там может понадобится обрабатывать совсем другие данные. Пришлось делать свое.
Как результат, сейчас есть две системы для отчетности, работающие на полностью разном стеке...

вот потому у меня глубокое убеждение, что в крупной канторе по центру должен быть data lake/lakehouse с полноценным централизованным ХД, который и смаштабируется легко и прототип можно протестить без полноценной интеграции в ХД.
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40079445
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
H5N1
s_ustinov

Надо было сделать систему для финансов. Я сразу предложил - выделите мне независимую область в существующей системе, мы туда будем закачивать наши данные из ERP и формировать отчеты для финансов. Но - не судьба. Причина, насколько я понимаю - при проектировании никто вообще не учитывал, что там может понадобится обрабатывать совсем другие данные. Пришлось делать свое.
Как результат, сейчас есть две системы для отчетности, работающие на полностью разном стеке...

вот потому у меня глубокое убеждение, что в крупной канторе по центру должен быть data lake/lakehouse с полноценным централизованным ХД, который и смаштабируется легко и прототип можно протестить без полноценной интеграции в ХД.

Согласен.
В идеале "инфраструктурная" часть должна быть полностью отделена от самих данных / коннекторов.
И нужна возможность быстро и легко создавать дополнительные отдельные области / песочницы, которые с одной стороны не будут мешать существующим схемам / витринам, но в то же время легко использовать те данные, которые кто то уже подготовил.
Разумеется, проблемы все равно будут, но в других вариантах все еще хуже будет.
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40079772
Фотография George Nordic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov
Стало интересно, посмотрел сейчас - операции у нас в 37 разных валютах. Включая достаточно экзотические.Я надеюсь, вы не ожидаете, что бухгалтера в какой нибудь Малайзии будут использовать те же самые курсы валют, которые решили использовать программисты в центральном офисе, не имеющие отношения к финансам?
Мда. Давно такого косяка в архитектуре не видел. В учетных системах, таких как SAP, Navision или Axapta в проводке всегда есть валюта проводки и валюта учета. Даже есть валюта триангуляции, для пересчетов. Что помогает одновременно в 3 валютах вести учет, если что. И да, закрытие склада во второй валюте, и расчет / пересчет себестоимости во вторичной валюте - все это дело учетных систем, не DWH!!
Курс валют должны задавать не программисты и не локальные бухгалтера, а должен быть четкий механизм, описанный в учетной политике: например, курс ЦБ страны или некий международный справочник валют. То есть разработка учетной политика и настройка учетной системы позволяет полностью решить данную проблему. С другой стороны, если они вместо этого решили кормить штат DWH, то дай Бог здоровья этим людям.

С Уважением,
Георгий
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40079773
Фотография George Nordic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Критик
Коллеги, кто-то использует такое в ХД? Когда у вас десятки слабосвязанных витрин
Критик, термин "микросервис" стал таким хайповым, что вызывает отторжение. Только как маркетинговый можно использовать, чтобы деньги выбить "мы сейчас все перепишем на микросервисах, ибо модно". И, кстати, бюджет могут дать. Ибо!
Полковник.
Если витрины уже слабосвязанные, то связывать их в дальнейшем врят ли понадобится, вполне нормальная архитектура, описана в книжке Кимбала.
Кстати, в этом случае можно их не связывать, а просто каталог данных на них натравить или datamarket.

С Уважением,
Георгий
...
Рейтинг: 0 / 0
Микросервисная архитектура ХД
    #40079806
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
George Nordic
s_ustinov
Стало интересно, посмотрел сейчас - операции у нас в 37 разных валютах. Включая достаточно экзотические.Я надеюсь, вы не ожидаете, что бухгалтера в какой нибудь Малайзии будут использовать те же самые курсы валют, которые решили использовать программисты в центральном офисе, не имеющие отношения к финансам?
Мда. Давно такого косяка в архитектуре не видел. В учетных системах, таких как SAP, Navision или Axapta в проводке всегда есть валюта проводки и валюта учета. Даже есть валюта триангуляции, для пересчетов. Что помогает одновременно в 3 валютах вести учет, если что. И да, закрытие склада во второй валюте, и расчет / пересчет себестоимости во вторичной валюте - все это дело учетных систем, не DWH!!
Курс валют должны задавать не программисты и не локальные бухгалтера, а должен быть четкий механизм, описанный в учетной политике: например, курс ЦБ страны или некий международный справочник валют. То есть разработка учетной политика и настройка учетной системы позволяет полностью решить данную проблему. С другой стороны, если они вместо этого решили кормить штат DWH, то дай Бог здоровья этим людям.

С Уважением,
Георгий

Одна из систем отчетности создавалась людьми, к фин учету не имеющими никакого отношения. Вот и получилась такая ситуация.

Разумеется, у нас есть отдельный раздел в учетной политике, где описано, какие курсы в какой стране используем, и в ERP (Навике) мы эти курсы и используем. Но другая система использует другие курсы и алгоритмы пересчетов.
Для фин отчетов мы сперва пересчитываем суммы выручки из валюты операции в функциональную валюту (в холдинге - пять функциональных валют), а потом из функциональной валюты в валюту отчетности (евро). И все это делается внутри навика.
А другая система пересчитывает все напрямую, и для унификации результатов надо много менять в алгоритмах.
...
Рейтинг: 0 / 0
25 сообщений из 27, страница 1 из 2
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / Микросервисная архитектура ХД
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]