почему бы Старбаксу не позаботится о достойной зарплате своих сотрудников в кафе
Потому что тогда даже для белых воротничков кофе там будет дорогим. Я вообще, чем больше погружаюсь в тему налогов и регулирования, тем больше перестаю понимать, как можно построить честный и справедливый бизнес😅😅😅 И удивляюсь, как текущий бизнес вроде умудряется хоть какую-нить прибыль получать🤪
Согласен. В современных банковских приложениях пока не закроешь рекламу кредита, не посмотришь неправильную сториз, не ознакомишься с акциями у партнёров на эту неделю и не кликнешь 3 раза - не увидешь список последних транзакций по счету (утрирую немного, но вы поняли к чему я).
Рекомендую разобраться сначала с юридической и бизнесовой стороной международных переводов (а не только с политической), прежде чем предлагать что-то свое. А то будет как с криптой, которая уже 10 лет как должна была убить обычные деньги.
Дополнение. Вот вам, менеджменту, хорошо бы услышать нас, архитекторов, и как раз озадачится приближением подобных документов к чему-то реально полезному для проекта;) А то так и будем жить в двух параллельных реальностях
Спасибо, что аргументированно отвечаете! На самом деле не вижу смысла продолжать дискуссию, так как по ощущениям у нас с вами разный бэкграунд. Я внедрил 7 (8е в процессе щас и уже маячит на горизонте 9е в планах) разных DWH/Data Platform в разных организациях, работая непосредственно в полях, и на практике в каждодневной работе сталкиваясь со всеми подходами и методолгиями, упомянутыми вами, обсуждая все это с другими архитекторами, на практике сталкиваясь с плюсам и минусами того или иного паттерна, в том числе принимая во внимание используемый тех стек ( это тоже влияет на выбор подхода кстати ) Вы же, осмелюсь предположить на основании статьи и ваших ответов, скорее решаете задачу формального написания и защиты какого-то внутреннего документа (возможно, который будет потом мало общего имеет с действительностью "в полях", но зато выполнить функцию ЖПП отлично:)) И такое встречал на одном проекте, когда менеджеры жили в одной реальности, а все остальные - в другой))) Было забавно) Ну и пишите этот документ опираясь на теоретические статьи про "космические корабли в большом театре", не до конца понимая как эти теоретические концепты потом выливаются в конкретную архитектуру и физ. модель. Для подобных документов ссылка на какой то авторитетный источник куда важнее практики. Тут согласен.
У вас в статье фундаментальная ошибка в том, то вы подходы Инмона и Кимбалла ставите в один ряд (по сути - противопоставляете) с Data vault и Anchor modelling (кстати, а почему 3NF вы отсюда выкинули???). Еще с натяжкой терпимо "для сельской местности" или для презентации ничего не понимающему бизнесу, но не для технического портала как хабр, где статьи пишутся профессионалами для профессионалов. Вы сравниваете красное с круглым.
Если совсем упрощать в паре слов, то выбор стоит "Инмон vs Кимбал" - тут все понятно (надеюсь) - это именно разные МЕТОДОЛЛОГИЧЕСКИЕ подходы к построению и ХД, причем во многом еще и ОРГАНИЗАЦИОННЫЕ. Кимбал - это по сути "витрины первыми, собственно они и являются КХД". Инмон же говорит "строим сначала детальный слой - единую версию правды, и уже потом витрины". Эти подходы не противопоставляются Data vault и Anchor modelling, они стоят над ними.
Data vault и Anchor modelling (и забытая вами 3NF) - это подходы к построению ФИЗИЧЕСКОЙ модели данных ДЕТАЛЬНОГО слоя данных ХД. И любой из них отлично сочетается как минимум с подходом Инмона.
Ну и раз вы тут говорите про подходы к проектированию физической модели, то почему не упомянуты звезды и снежинки? Они уже про слой витрин данных и так же отлично сочетается с подходам и Инмона, и Кимбалла.
Как видите, все написанное выше никак не противоречит вашей задаче "подготовить архитектуру решения, ее защитить не только технологически, но и бизнесово".
Боже мой. Все в кучу, перемешать и взболтать... Вы сами писали это или LLM "помогал". Инмон и Кимбал поставлены в один раз с Дата Валтом и Якорным моделированием... Вы хоть понимаете абсурдность этого?
Так в портфельном менеджменте нет проблем с кросс-курсами. Как правило, все приводится к базовой валюте (Евро, Баксы, Рубли, Юани и т.п.) - обычно валюте той страны, где "центр жизненных интересов" инвестора. Ему куда более понятны "свои родные деревянные", чем абстрактные "попугаи". Причем а какую валюту не переводи (даже хоть в "абсолютную", как предлагает автор), все суммы будут одинаковы с поправкой на множитель константы. Корме того, математический аппарат портфельных инвестиций вообще инвареантен относительно валюты. При этом если у тебя активы номинированы в разных валютах, то все равно тебе надо считать валютный риск (риск изменения курсов) - это этого ты никуда не денешься. "Природу" колебания курсов валют не обманешь.
Ни в одной из ваших статей на эту тему нет ответа на вопрос - а для чего это? какую ПРОБЛЕМУ вы пытаетесь решить? То, что курсы во всем мире парные - это не проблема. По крайней мере вы не раскрыли тему, почему это проблема? Почему не устраивает приведение всего к опорной валюте? Имея кросс-курсы можно все остальные пересчитать в те же Рубли и получить единую точку отсчета, что, собственно, и делают все.
Согласен, проекция собственного опыта: всегда были более-менее централизованные команды (и/или четкиe SLA по готовности данных, если поставляли их "во вне") и разброс часовых поясов максимум 2-3, поэтомут всегда было удобное "ночное окно".
То есть верно я понял, что по сути у вас множество систем с разными режимом готовности данных, ещё и размазанные по разным часовым поясам, и как следствие, нет того самого единого "технологического окна", которое могло бы быть точкой синхронизации всех процессов? И получается по сути у вас в течении 24 часов непрерывно то одна, то другая система поставляет новые порции данных, которые (учитывая упомянутую выше особенность) надо "добавлять" в отчёты/дашборты в течении "бизнес дня" и ещё готовить некие расчеты на основании поступивших данных для поставки внешним потребителям/системам?
Никогда. Загрузка данных в дата платформу обычно всегда по расписанию в ночное окно (чтобы утром уже все было готово для бизнеса). Все процессы идемпотентны. Грамотно выстроенная оркестрация. Грустно выстроенная стратегия обновления и загрузки данных. Грамотная модель данных. Проверки качества и готовности данных. Платформа данных - это про аналитику, а не операционную работу. По моему опыту, если ACID для платформы данных становиться критичным, то это говорит скорее об архитектурных проблемах платформы и загрузки данных в нее.
Если у вас есть пример обратного, с удовольствием готов предметно обсудить его (даже в личке, если не хотите публично) и даже обрадуюсь, если окажусь неправ.
ACID как раз не накладывает никаких ограничений - то есть транзакция атомарна независимо от того, какие объекты БД и в каком количестве она затрагивает. Классическая СУБД , являясь умной надстройкой над файлам, позволяет по дефолту в рамках одной транзакции оперировать несколькими таблицами. Дельты и Айсберги же - нет
.... парадигма ACID, которая была фундаментальной в Data Warehouse.
ACID фундаментален для реляционных баз данных и транзакционных систем. Для DWH он никогда не был фундаментальным, а пришел просто побочный эффект от реляционных БД, на которых строились долгое время DWH
OTF принес возможность использовать ACID-операции...
Не совсем. Надо добавить, что только в рамках одной таблицы. Ну и кстати, отсутствие ACID в Дата Лейке особо никому не мешало никогда (по моему опыту)
Удалось разделить слои вычисления и хранения...
Было успешно сделано до появления термина Lakehouse
Это связано с тем, что Lakehouse использует опенсорсные технологии ...
Как и ДатаЛейк.
И далее в том же духе, нет смысла весь список приводить. Ещё и ,Data Governance и AI приплели, хотя к архитектурному походу они не имеют никакого отношения. Многовато неточностей и ошибок для директора направления Data Engineering ;)
Потому что тогда даже для белых воротничков кофе там будет дорогим.
Я вообще, чем больше погружаюсь в тему налогов и регулирования, тем больше перестаю понимать, как можно построить честный и справедливый бизнес😅😅😅 И удивляюсь, как текущий бизнес вроде умудряется хоть какую-нить прибыль получать🤪
Сэкономили на VPS для хостинга бота)
Выложили бы код на гитхаб - норм для хабра было бы. А так очередная реклама очередного бота.
Согласен. В современных банковских приложениях пока не закроешь рекламу кредита, не посмотришь неправильную сториз, не ознакомишься с акциями у партнёров на эту неделю и не кликнешь 3 раза - не увидешь список последних транзакций по счету (утрирую немного, но вы поняли к чему я).
Рекомендую разобраться сначала с юридической и бизнесовой стороной международных переводов (а не только с политической), прежде чем предлагать что-то свое. А то будет как с криптой, которая уже 10 лет как должна была убить обычные деньги.
Дополнение.
Вот вам, менеджменту, хорошо бы услышать нас, архитекторов, и как раз озадачится приближением подобных документов к чему-то реально полезному для проекта;) А то так и будем жить в двух параллельных реальностях
Спасибо, что аргументированно отвечаете!
На самом деле не вижу смысла продолжать дискуссию, так как по ощущениям у нас с вами разный бэкграунд. Я внедрил 7 (8е в процессе щас и уже маячит на горизонте 9е в планах) разных DWH/Data Platform в разных организациях, работая непосредственно в полях, и на практике в каждодневной работе сталкиваясь со всеми подходами и методолгиями, упомянутыми вами, обсуждая все это с другими архитекторами, на практике сталкиваясь с плюсам и минусами того или иного паттерна, в том числе принимая во внимание используемый тех стек ( это тоже влияет на выбор подхода кстати )
Вы же, осмелюсь предположить на основании статьи и ваших ответов, скорее решаете задачу формального написания и защиты какого-то внутреннего документа (возможно, который будет потом мало общего имеет с действительностью "в полях", но зато выполнить функцию ЖПП отлично:)) И такое встречал на одном проекте, когда менеджеры жили в одной реальности, а все остальные - в другой))) Было забавно) Ну и пишите этот документ опираясь на теоретические статьи про "космические корабли в большом театре", не до конца понимая как эти теоретические концепты потом выливаются в конкретную архитектуру и физ. модель. Для подобных документов ссылка на какой то авторитетный источник куда важнее практики. Тут согласен.
У вас в статье фундаментальная ошибка в том, то вы подходы Инмона и Кимбалла ставите в один ряд (по сути - противопоставляете) с Data vault и Anchor modelling (кстати, а почему 3NF вы отсюда выкинули???). Еще с натяжкой терпимо "для сельской местности" или для презентации ничего не понимающему бизнесу, но не для технического портала как хабр, где статьи пишутся профессионалами для профессионалов. Вы сравниваете красное с круглым.
Если совсем упрощать в паре слов, то выбор стоит "Инмон vs Кимбал" - тут все понятно (надеюсь) - это именно разные МЕТОДОЛЛОГИЧЕСКИЕ подходы к построению и ХД, причем во многом еще и ОРГАНИЗАЦИОННЫЕ. Кимбал - это по сути "витрины первыми, собственно они и являются КХД". Инмон же говорит "строим сначала детальный слой - единую версию правды, и уже потом витрины". Эти подходы не противопоставляются Data vault и Anchor modelling, они стоят над ними.
Data vault и Anchor modelling (и забытая вами 3NF) - это подходы к построению ФИЗИЧЕСКОЙ модели данных ДЕТАЛЬНОГО слоя данных ХД. И любой из них отлично сочетается как минимум с подходом Инмона.
Ну и раз вы тут говорите про подходы к проектированию физической модели, то почему не упомянуты звезды и снежинки? Они уже про слой витрин данных и так же отлично сочетается с подходам и Инмона, и Кимбалла.
Как видите, все написанное выше никак не противоречит вашей задаче "подготовить архитектуру решения, ее защитить не только технологически, но и бизнесово".
Боже мой. Все в кучу, перемешать и взболтать... Вы сами писали это или LLM "помогал". Инмон и Кимбал поставлены в один раз с Дата Валтом и Якорным моделированием... Вы хоть понимаете абсурдность этого?
Так в портфельном менеджменте нет проблем с кросс-курсами. Как правило, все приводится к базовой валюте (Евро, Баксы, Рубли, Юани и т.п.) - обычно валюте той страны, где "центр жизненных интересов" инвестора. Ему куда более понятны "свои родные деревянные", чем абстрактные "попугаи". Причем а какую валюту не переводи (даже хоть в "абсолютную", как предлагает автор), все суммы будут одинаковы с поправкой на множитель константы. Корме того, математический аппарат портфельных инвестиций вообще инвареантен относительно валюты. При этом если у тебя активы номинированы в разных валютах, то все равно тебе надо считать валютный риск (риск изменения курсов) - это этого ты никуда не денешься. "Природу" колебания курсов валют не обманешь.
Ни в одной из ваших статей на эту тему нет ответа на вопрос - а для чего это? какую ПРОБЛЕМУ вы пытаетесь решить? То, что курсы во всем мире парные - это не проблема. По крайней мере вы не раскрыли тему, почему это проблема? Почему не устраивает приведение всего к опорной валюте? Имея кросс-курсы можно все остальные пересчитать в те же Рубли и получить единую точку отсчета, что, собственно, и делают все.
Ну вы поняли, что я имел в виду;)
DDL на создание 4х таблиц, гордо названный архитектурой - вот текущий уровень статей на хабре(
И как вы решили вопрос консистенции и согласованности данных для скорингов, если у вас тем более Хадуп?
Согласен, проекция собственного опыта: всегда были более-менее централизованные команды (и/или четкиe SLA по готовности данных, если поставляли их "во вне") и разброс часовых поясов максимум 2-3, поэтомут всегда было удобное "ночное окно".
То есть верно я понял, что по сути у вас множество систем с разными режимом готовности данных, ещё и размазанные по разным часовым поясам, и как следствие, нет того самого единого "технологического окна", которое могло бы быть точкой синхронизации всех процессов? И получается по сути у вас в течении 24 часов непрерывно то одна, то другая система поставляет новые порции данных, которые (учитывая упомянутую выше особенность) надо "добавлять" в отчёты/дашборты в течении "бизнес дня" и ещё готовить некие расчеты на основании поступивших данных для поставки внешним потребителям/системам?
Никогда.
Загрузка данных в дата платформу обычно всегда по расписанию в ночное окно (чтобы утром уже все было готово для бизнеса). Все процессы идемпотентны. Грамотно выстроенная оркестрация. Грустно выстроенная стратегия обновления и загрузки данных. Грамотная модель данных. Проверки качества и готовности данных.
Платформа данных - это про аналитику, а не операционную работу. По моему опыту, если ACID для платформы данных становиться критичным, то это говорит скорее об архитектурных проблемах платформы и загрузки данных в нее.
Если у вас есть пример обратного, с удовольствием готов предметно обсудить его (даже в личке, если не хотите публично) и даже обрадуюсь, если окажусь неправ.
Ну и кстати, в своей прокатике многолетней ни разу не встречал, чтобы отсутствие ACID как то мешало в Data Lake / Data Platform.
ACID как раз не накладывает никаких ограничений - то есть транзакция атомарна независимо от того, какие объекты БД и в каком количестве она затрагивает. Классическая СУБД , являясь умной надстройкой над файлам, позволяет по дефолту в рамках одной транзакции оперировать несколькими таблицами. Дельты и Айсберги же - нет
ACID фундаментален для реляционных баз данных и транзакционных систем. Для DWH он никогда не был фундаментальным, а пришел просто побочный эффект от реляционных БД, на которых строились долгое время DWH
Не совсем. Надо добавить, что только в рамках одной таблицы. Ну и кстати, отсутствие ACID в Дата Лейке особо никому не мешало никогда (по моему опыту)
Было успешно сделано до появления термина Lakehouse
Как и ДатаЛейк.
И далее в том же духе, нет смысла весь список приводить. Ещё и ,Data Governance и AI приплели, хотя к архитектурному походу они не имеют никакого отношения. Многовато неточностей и ошибок для директора направления Data Engineering ;)