На мой взгляд тут ситуация похожа с API микросервисов. Если API опубликован — в нем нельзя делать breaking changes. То же самое с опубликованными схемами данных. Как это форсировать и контролировать? Мы сейчас думаем про автоматические тесты, которые не дадут накатить миграцию если в ней есть breaking changes.
Мне кажется, тут будет довольно сложно определить, что означает breaking change. Очевидно, изменения в структуре данных, такие как удаление колонки в таблице или изменение типа данных в колонке — это breaking change.
Но как быть с изменениями в логике данных? Простой пример: раньше в столбце «сумма чека» хранилась сумма без НДС, а потом в операционной системе что-то поменяли и стала храниться сумма уже с включенным НДС. С точки зрения продуктовой команды — это необходимое изменение, но при этом все потребители, которые опирались на этот показатель в data lake, сразу прибегут и скажут что у них сломались расчеты. Для написания тестов, которые будут проверять все возможные подобные случаи, надо будет потратить кучу времени — для каждой метрики или атрибута продумать возможные варианты использования, написать тесты, убедиться что они корректно работают при всех возможных раскладах и т.п.
Я искренне желаю чтобы у вас все получилось :) но из моего опыта часто при разделении ответственности за данные между разными командами начинается хаос. В основном потому, что каждой команде проще встать в позицию «моя хата с краю» и не думать про последствия изменений, которые они вносят. Также начинается дублирование данных в data lake, так как часто отдельной команде срочно необходимы какие-то данные и им проще рассчитать их заново, нежели искать, не сделал ли кто-то это уже ранее.
Интересная статья, спасибо. Но есть ощущение, что не полностью раскрыт рабочий процесс при использовании нового подхода с data mesh.
Из того, что сразу приходит на ум: к примеру, одна продуктовая команда — например, CRM, становится ответственной за «домен» CRM внутри data lake. При подходе data mesh эта команда самостоятельно вносит изменения в структуры данных и логику загрузки этих данных в data lake — то есть полностью управляет данными своей области. Но в большинстве случаев потребителям данных (скажем, для аналитических отчетов), нужны не только данные из CRM, но и из других областей тоже (к примеру, из биллинговой системы — чтобы посчитать выручку по каждой пиццерии). В таком случае, потребитель отчета уже оказывается «завязан» на две продуктовые команды. И если любая из этих команд внесет изменения в данные в своем домене, не учтя все возможные последствия этого изменения, то отчет скорее всего работать перестанет. А в любой крупной компании таких зависимостей между данными разных систем будет очень и очень много, соответственно и разделить ответственность между продуктовыми командами будет непросто — все равно нужен «надсмотрщик», который будет разруливать зависимости и контролировать изменения. Что в некоторой степени возвращает к «классической» модели с единой командой, отвественной за весь data lake.
Сталкивались ли с подобным? Или как планирует решать?
Зато какая отличная схема сложилась, чтобы в любой момент любого оператора связи можно было взять за «одно место»! Закон есть? Есть. Не исполняете? Так оборудования нет… А это никого не волнует.
Такой «шутник» должен вылететь со своей должности на следующий день, как пробка из бутылки. Но нам заявляют «чего разшумелись, челядь — боярин пошутил, не понятно, что ли?»
Плюсую неистово. На мой взгляд, лучший из современных авторов НФ. Когда история сплетается из множества ниточек, каждая из которых сама по себе очень интересна, и все это в фантастическом мире, продуманном до мелочей… это нечто)
Вот кстати да, что всегда удивляло — почему даже у приличной нашей продукции в большинстве своем такая ужасная реклама? Неужто никто подойдет и не скажет директору «наша реклама — г… но!»?
А вообще хорошая статья. Думаю, при выборе следующего регистратора отдам им предпочтение:)
На самом деле может и хорошо, что решили делать часть деталей самостоятельно а часть заказывать в Китае, если это действительно позволяет снизить конечную цену принтера. Но представление этого как «принципиально новой» разработки, сделанной «специалистами Центра технологической компетенции аддитивных технологий» (название-то какое), конечно, вызывает некоторое отторжение. Тем более что на нашем заводе, я думаю, производятся наименее технологически сложные компоненты.
«Его стоимость составляет всего 38500р. Такой цены удалось добиться из-за того, что ряд необходимых составных деталей производится на базе «Воронежсельмаш», а не заказывается за рубежом. Также такое тесное сотрудничество с заводом позволяет оперативно осуществлять сервисное обслуживание и модернизировать машину.»
Особенно умиляют рассуждения о том, что это может простимулировать развитие собственного ПО. Во-первых, кто раньше-то мешал его развивать? Во-вторых, известно, что качественный продукт может появиться только на открытом рынке, в условиях конкуренции. Иначе это будет такой же отстой, как любой потребительский продукт в СССР
«Да пошли бв пи****сы на х*й…
А, черт, им только этого и надо.»
«Просто нужно добавить скрипт который проверяет браузер, если Firefox то выдавать предупреждение — что так и так, и что благодаря «пидорам» вы не можете использовать этот браузер»
«Ну так это естественно. Не понимаю, зачем пропагандировать гомосексуализм? Это же болезнь, отклонение.»
Крайне печально, что вроде и взрослые прогрессивные люди, но в таких вопросах сразу куча неадеквата и ненависти.
Ну уж прям «повлияли на нашу сферу деятельности» — это в чем еще?
Первопричина тут не в гноблении, как вы выразились, а в том, что это действия в ответ на очевидно неадекватную и узколобую позицию самого Брендана — заключающуюся в том, что надо лишить людей права заключать брак, исходя из их ориентации.
Мне кажется, тут будет довольно сложно определить, что означает breaking change. Очевидно, изменения в структуре данных, такие как удаление колонки в таблице или изменение типа данных в колонке — это breaking change.
Но как быть с изменениями в логике данных? Простой пример: раньше в столбце «сумма чека» хранилась сумма без НДС, а потом в операционной системе что-то поменяли и стала храниться сумма уже с включенным НДС. С точки зрения продуктовой команды — это необходимое изменение, но при этом все потребители, которые опирались на этот показатель в data lake, сразу прибегут и скажут что у них сломались расчеты. Для написания тестов, которые будут проверять все возможные подобные случаи, надо будет потратить кучу времени — для каждой метрики или атрибута продумать возможные варианты использования, написать тесты, убедиться что они корректно работают при всех возможных раскладах и т.п.
Я искренне желаю чтобы у вас все получилось :) но из моего опыта часто при разделении ответственности за данные между разными командами начинается хаос. В основном потому, что каждой команде проще встать в позицию «моя хата с краю» и не думать про последствия изменений, которые они вносят. Также начинается дублирование данных в data lake, так как часто отдельной команде срочно необходимы какие-то данные и им проще рассчитать их заново, нежели искать, не сделал ли кто-то это уже ранее.
Из того, что сразу приходит на ум: к примеру, одна продуктовая команда — например, CRM, становится ответственной за «домен» CRM внутри data lake. При подходе data mesh эта команда самостоятельно вносит изменения в структуры данных и логику загрузки этих данных в data lake — то есть полностью управляет данными своей области. Но в большинстве случаев потребителям данных (скажем, для аналитических отчетов), нужны не только данные из CRM, но и из других областей тоже (к примеру, из биллинговой системы — чтобы посчитать выручку по каждой пиццерии). В таком случае, потребитель отчета уже оказывается «завязан» на две продуктовые команды. И если любая из этих команд внесет изменения в данные в своем домене, не учтя все возможные последствия этого изменения, то отчет скорее всего работать перестанет. А в любой крупной компании таких зависимостей между данными разных систем будет очень и очень много, соответственно и разделить ответственность между продуктовыми командами будет непросто — все равно нужен «надсмотрщик», который будет разруливать зависимости и контролировать изменения. Что в некоторой степени возвращает к «классической» модели с единой командой, отвественной за весь data lake.
Сталкивались ли с подобным? Или как планирует решать?
Просто чудеса эффективного менеджмента.
Есть планы перевести остальные части?:)
Можно цветами разделить, например:)
Хотя мне как-то кажется что спокойное чаепитие и вращающаяся с приличной скоростью чашка как-то не подходят друг другу:)
А вообще хорошая статья. Думаю, при выборе следующего регистратора отдам им предпочтение:)
vselmash.ru/news/?ELEMENT_ID=1119#content
Интересно, какой ряд?
«Да пошли бв пи****сы на х*й…
А, черт, им только этого и надо.»
«Просто нужно добавить скрипт который проверяет браузер, если Firefox то выдавать предупреждение — что так и так, и что благодаря «пидорам» вы не можете использовать этот браузер»
«Ну так это естественно. Не понимаю, зачем пропагандировать гомосексуализм? Это же болезнь, отклонение.»
Крайне печально, что вроде и взрослые прогрессивные люди, но в таких вопросах сразу куча неадеквата и ненависти.
Первопричина тут не в гноблении, как вы выразились, а в том, что это действия в ответ на очевидно неадекватную и узколобую позицию самого Брендана — заключающуюся в том, что надо лишить людей права заключать брак, исходя из их ориентации.