#заметкинаполях #introducingmlops
Закончил чтение «Introducing MLOps». Еще одна понравившаяся глава рассказывает про управление моделями, если кратко, то - это очередное «наше все», без которого ничего работать не будет нормально.
В общем, относитесь к руководству моделями серьезно, не откладывайте в долгий ящик, планируйте процесс заранее, продумывайте политики, найдите инструменты для централизованного их представления и распространения на всю организацию ради.
Это займет много времени, понадобится не одна итерация, но в конце пути, оглянувшись назад, вы будете гордиться собой, подобно Александру Овечкину, давеча перекрывшему великое достижение товарища Ивана Грецкого.
За сим на этом все. А коль скоро так, самое время открыть новую книгу, надеюсь, не менее интересную.
Закончил чтение «Introducing MLOps». Еще одна понравившаяся глава рассказывает про управление моделями, если кратко, то - это очередное «наше все», без которого ничего работать не будет нормально.
В общем, относитесь к руководству моделями серьезно, не откладывайте в долгий ящик, планируйте процесс заранее, продумывайте политики, найдите инструменты для централизованного их представления и распространения на всю организацию ради.
Это займет много времени, понадобится не одна итерация, но в конце пути, оглянувшись назад, вы будете гордиться собой, подобно Александру Овечкину, давеча перекрывшему великое достижение товарища Ивана Грецкого.
За сим на этом все. А коль скоро так, самое время открыть новую книгу, надеюсь, не менее интересную.
👍4
#заметкинаполях #C4model #напочитать
Simon Brown, автор книги «C4 Model for Visualising Software Architecture», в которой он вводит лаконичную, но мощную нотацию для построения архитектурных диаграмм, оказал сильное влияние на авторов «Data Mesh in Action», коей, в свою очередь, вдохновляюсь я при решении рабочих задач, а коль скоро так, то мимо пройти я никак не мог. Тем более, что о данной методологии был наслышан, но вот случая ознакомиться не представлялось. А сейчас словно звезды сошлись…
Зачем нужна еще одна методология визуализации архитектуры? Автор отвечает на это следующим образом:
➕ C4 model - это простой способ «увидеть всю картинку целиком» (кто помнит героя популярного сериала, сделавшего эту фразу легендарной?), показать, как все устроено и как составные части «упаковываются» в картину еще большего размера
➕Создает единое видение разрабатываемого «нечто» у каждого члена команды и помогает им оставаться в фокусе, объясняет суть происходящего в том числе и людям без технического бэкграунда
➕ Быстрее вводит в курс дела новых членов команды
➕ При всей своей простоте и лаконичности данный вид диаграмм прекрасно отражает реальность
продолжение следует…
Simon Brown, автор книги «C4 Model for Visualising Software Architecture», в которой он вводит лаконичную, но мощную нотацию для построения архитектурных диаграмм, оказал сильное влияние на авторов «Data Mesh in Action», коей, в свою очередь, вдохновляюсь я при решении рабочих задач, а коль скоро так, то мимо пройти я никак не мог. Тем более, что о данной методологии был наслышан, но вот случая ознакомиться не представлялось. А сейчас словно звезды сошлись…
Зачем нужна еще одна методология визуализации архитектуры? Автор отвечает на это следующим образом:
➕ C4 model - это простой способ «увидеть всю картинку целиком» (кто помнит героя популярного сериала, сделавшего эту фразу легендарной?), показать, как все устроено и как составные части «упаковываются» в картину еще большего размера
➕Создает единое видение разрабатываемого «нечто» у каждого члена команды и помогает им оставаться в фокусе, объясняет суть происходящего в том числе и людям без технического бэкграунда
➕ Быстрее вводит в курс дела новых членов команды
➕ При всей своей простоте и лаконичности данный вид диаграмм прекрасно отражает реальность
продолжение следует…
👍6
#напочитать
Неожиданный и весьма приятный подарок на ДР пополнил коллекцию бумажных книг. Хочется немедленно приступить к чтению, но "порядок превыше всего".
Неожиданный и весьма приятный подарок на ДР пополнил коллекцию бумажных книг. Хочется немедленно приступить к чтению, но "порядок превыше всего".
👍7
#заметкинаполях #C4model
Душа радуется и настрой на будень трудовой резко повышается, когда с утра накатил быстрых повторов по Джеку Дэниэлсу: 600м - 2'5'', 500м - 1'41'', 400м - 1'19'', 300м - 52''. Но, как поет глубокоуважаемый мною Роман Суслов: «Не о том речь».
Итак, свое название методология С4 получила по первым буквам названий четырех уровней абстракции, коими она оперирует:
1️⃣ Context - отправная точка, показывает, как система вписывается в окружающую ее среду и как с ней взаимодействует. «К черту подробности, город какой?», - в общем.
2️⃣ Containers - Раскрывает основные «строительные блоки» системы и связи между ними.
3️⃣ Components - Переходит в отдельный компонент и демонстрирует его составные части
4️⃣ Code - детали реализации компонента, некоторые считают, что «он нам и нафиг не нужон».
продолжение следует…
Душа радуется и настрой на будень трудовой резко повышается, когда с утра накатил быстрых повторов по Джеку Дэниэлсу: 600м - 2'5'', 500м - 1'41'', 400м - 1'19'', 300м - 52''. Но, как поет глубокоуважаемый мною Роман Суслов: «Не о том речь».
Итак, свое название методология С4 получила по первым буквам названий четырех уровней абстракции, коими она оперирует:
1️⃣ Context - отправная точка, показывает, как система вписывается в окружающую ее среду и как с ней взаимодействует. «К черту подробности, город какой?», - в общем.
2️⃣ Containers - Раскрывает основные «строительные блоки» системы и связи между ними.
3️⃣ Components - Переходит в отдельный компонент и демонстрирует его составные части
4️⃣ Code - детали реализации компонента, некоторые считают, что «он нам и нафиг не нужон».
продолжение следует…
👍4
Forwarded from Сорока пишет | Об ИТ и менеджменте
Накопилось у меня тут материалов по иишнице, но открою эту тему с пятничного 😄
😁7
Forwarded from DataJourney
SCD - slowly changing dimension (медленно меняющиеся измерения)
Любимый вопрос на собеседования рядом с базами данных (от больших хранилищ до маленьких баз) - это вопрос про SCD. Если кратко, то это приёмы хранения различных справочников объектов, атрибуты которых меняются, но не так часто как таблицы фактов. В рускоязычной вики описаны три типа SCD, но на самом деле различают до семи типов.
0️⃣ вырожденный случай, в котором атрибуты не меняются никогда.
Пример: справочник химических элементов.
1️⃣ тип хранения, в котором не хранится историчность, а значения атрибута перезаписываются при его обновлении.
Пример: Состояние табло аэропорта, отображающего время и место вылета самолётов.
2️⃣ тип хранения, в котором уже сохраняются предыдущие значения справочника. Для того, чтобы выбрать актуальное состояние добавляется поле с версией объекта или флаг того, что строка актуальная и смотреть нужно именно на неё или же описываются даты начала и окончания действия строки.
Пример: справочник тарифов за коммуналку. Там важно знать именно периоды действия тарифа, чтобы иметь возможность делать перерасчеты.
3️⃣тип хранения, при котором добавляется новая колонка для нового состояния атрибута и, в некоторых случаях, дата смены атрибута.
Пример: справочник специалистов, которые ведут приём. Может статься так, что периодически специалист меняет кабент, но клиенту важно знать в каком кабинете он был в прошлый раз.
… продолжение следует
Любимый вопрос на собеседования рядом с базами данных (от больших хранилищ до маленьких баз) - это вопрос про SCD. Если кратко, то это приёмы хранения различных справочников объектов, атрибуты которых меняются, но не так часто как таблицы фактов. В рускоязычной вики описаны три типа SCD, но на самом деле различают до семи типов.
0️⃣ вырожденный случай, в котором атрибуты не меняются никогда.
Пример: справочник химических элементов.
1️⃣ тип хранения, в котором не хранится историчность, а значения атрибута перезаписываются при его обновлении.
Пример: Состояние табло аэропорта, отображающего время и место вылета самолётов.
2️⃣ тип хранения, в котором уже сохраняются предыдущие значения справочника. Для того, чтобы выбрать актуальное состояние добавляется поле с версией объекта или флаг того, что строка актуальная и смотреть нужно именно на неё или же описываются даты начала и окончания действия строки.
Пример: справочник тарифов за коммуналку. Там важно знать именно периоды действия тарифа, чтобы иметь возможность делать перерасчеты.
3️⃣тип хранения, при котором добавляется новая колонка для нового состояния атрибута и, в некоторых случаях, дата смены атрибута.
Пример: справочник специалистов, которые ведут приём. Может статься так, что периодически специалист меняет кабент, но клиенту важно знать в каком кабинете он был в прошлый раз.
… продолжение следует
👍5
В минувший четверг посетил конференцию, посвященную новым компьютерным технологиям, а именно Data LakeHouse, организованную компаниями Лемана Тех и Кверифай Лабс.
«Встреча прошла конструктивно, в теплой и дружественной обстановке». Хочется передать свою благодарность всем причастным к проведению мероприятия, докладчикам, экспертам да и просто участникам за интересные вопросы. Безумно рад был повидаться и пообщаться.
Надеюсь, что у коллег из Лемана Тех получится сделать историю с дата-митапами регулярной, ибо к ним я готов ходить "и ночью, и в дождь".
Запись для тех, кто все пропустил
«Встреча прошла конструктивно, в теплой и дружественной обстановке». Хочется передать свою благодарность всем причастным к проведению мероприятия, докладчикам, экспертам да и просто участникам за интересные вопросы. Безумно рад был повидаться и пообщаться.
Надеюсь, что у коллег из Лемана Тех получится сделать историю с дата-митапами регулярной, ибо к ним я готов ходить "и ночью, и в дождь".
Запись для тех, кто все пропустил
❤4👍2❤🔥1
#заметкинаполях #C4model
Диаграмма контекста
Диаграмма контекста позволяет ответить на три главных аналитических вопроса:
1️⃣ Что мы делаем?
2️⃣ Кому это надо?
3️⃣ «И де я нахожуся?»
Алгоритм предельно прост: нарисуйте в центре вашу систему и окружите ее пользователями и другими системами, с которыми она взаимодействует. Снабдите каждый элемент диаграммы кратким описанием, как-то: наименование, предназначение, выполняемые обязанности…
По желанию, пунктиром можно провести границу между вашей корпоративной средой и внешним миром.
Диаграмма контекста хорошо подходит для демонстрации коллегам без технического бэкграунда. Ее наличие обязательно для вашей системы.
продолжение следует...
Диаграмма контекста
Диаграмма контекста позволяет ответить на три главных аналитических вопроса:
1️⃣ Что мы делаем?
2️⃣ Кому это надо?
3️⃣ «И де я нахожуся?»
Алгоритм предельно прост: нарисуйте в центре вашу систему и окружите ее пользователями и другими системами, с которыми она взаимодействует. Снабдите каждый элемент диаграммы кратким описанием, как-то: наименование, предназначение, выполняемые обязанности…
По желанию, пунктиром можно провести границу между вашей корпоративной средой и внешним миром.
Диаграмма контекста хорошо подходит для демонстрации коллегам без технического бэкграунда. Ее наличие обязательно для вашей системы.
продолжение следует...
👍2
Forwarded from DataJourney
… SCD продолжение
Продолжаю с хранением справочников. Типы, которых нет в русской вики:
4️⃣ тип хранения при котором в справочнике содержится только актуальное на текущий момент состояние справочника, а рядом существует таблица (часто с суффиксом _history), в которой хранятся все предыдущие состояния с указанием периодов актуальности. У такого типа хранения есть преимущетсва по скорости доступа как у SCD1, но при этом есть возможность заглянуть по истории назад как в SCD2.
Пример: Справочник сотрудников, разбитый на две таблицы: personal и personal_hist. В первой таблице храняться все сотрудники на текущий момент в актуальном состоянии должностей, принадлежностей к отделам. В таблице с суффиксом hist хранится вся история изменений состояния.
5️⃣ тип хранения при котором часть справочника живет по второму типу, а часть вырождается в отдельный справочник, который живет по первому типу. Таким образом, у строки состояния справочника второго типа появляется свой собственный справочник с уникальным ключем, в котором хранится актуальное состояние.
Пример: Такой же справочник сотрудников как в примере выше, но у которого принадлежность к организационной структуре вынесена в отдельный справочник через внешний ключ. И этот отдельный справочник уже ведется по SCD1 для ускорения доступа.
6️⃣ тип хранения, в котором опять миксуются предыдущие типы для достижения каких-то бизнес целей и повышения производительности чтения. Здесь соединены SCD2 и SCD3. По части полей содержится актуальное состояние, а по части полей есть историчность с указанием периода актуальности.
Пример: Справочник моделей телефонов, в котором указано расположение их на планограмме выкладки, а так же какие-то справочные данные по поставщикам. Может возникнуть ситуация, когда товары перемещаются по планограмме и возникает необходимость сверки текущего состояния с состоянием на произвольный момент времени. Тогда имеет смысл в SCD2 справочник добавить колонку «current_position», которая будет содержать актуальную позицию товара во всех строках.
7️⃣ тип хранения, в чем-то схожиый с SCD5. Здесь так же справочник разбивается на две части: одна хранится по SCD2, а другая по SCD1. Но при этом в таблице фактов содержатся две ссылки: на основной справочник и на справочник с актуальными значениями характеристик.
💭Небольшой итог. Все типы хранения справочников, которые описаны выше могут применяться как в аналитических хранилищах, так и в OLTP базах. Выбор применения диктуется задачами, которые поставлены перед хранением. Где-то выгодней один раз потратиться на расчет, чтобы потом было удобно доставать данные, где-то хранилище используется только как историчное и там важно получить снепшоты всего, что происходило, но выбирать оттуда данные нужно будет раз в год.
SCD2 сейчас используется как универсальный метод хранения, который обеспечивает понятный ETL и понятные сценарии чтения. Его и просят описать на собесах. При этом, если отойти от собесов, то можно провести эксперимент и попробовать вынести более часто меняющиеся состояния в отдельный справочник и одним лишним джойном сэкономить на хранении излишних строк в широком справочнике.
Продолжаю с хранением справочников. Типы, которых нет в русской вики:
4️⃣ тип хранения при котором в справочнике содержится только актуальное на текущий момент состояние справочника, а рядом существует таблица (часто с суффиксом _history), в которой хранятся все предыдущие состояния с указанием периодов актуальности. У такого типа хранения есть преимущетсва по скорости доступа как у SCD1, но при этом есть возможность заглянуть по истории назад как в SCD2.
Пример: Справочник сотрудников, разбитый на две таблицы: personal и personal_hist. В первой таблице храняться все сотрудники на текущий момент в актуальном состоянии должностей, принадлежностей к отделам. В таблице с суффиксом hist хранится вся история изменений состояния.
5️⃣ тип хранения при котором часть справочника живет по второму типу, а часть вырождается в отдельный справочник, который живет по первому типу. Таким образом, у строки состояния справочника второго типа появляется свой собственный справочник с уникальным ключем, в котором хранится актуальное состояние.
Пример: Такой же справочник сотрудников как в примере выше, но у которого принадлежность к организационной структуре вынесена в отдельный справочник через внешний ключ. И этот отдельный справочник уже ведется по SCD1 для ускорения доступа.
6️⃣ тип хранения, в котором опять миксуются предыдущие типы для достижения каких-то бизнес целей и повышения производительности чтения. Здесь соединены SCD2 и SCD3. По части полей содержится актуальное состояние, а по части полей есть историчность с указанием периода актуальности.
Пример: Справочник моделей телефонов, в котором указано расположение их на планограмме выкладки, а так же какие-то справочные данные по поставщикам. Может возникнуть ситуация, когда товары перемещаются по планограмме и возникает необходимость сверки текущего состояния с состоянием на произвольный момент времени. Тогда имеет смысл в SCD2 справочник добавить колонку «current_position», которая будет содержать актуальную позицию товара во всех строках.
7️⃣ тип хранения, в чем-то схожиый с SCD5. Здесь так же справочник разбивается на две части: одна хранится по SCD2, а другая по SCD1. Но при этом в таблице фактов содержатся две ссылки: на основной справочник и на справочник с актуальными значениями характеристик.
💭Небольшой итог. Все типы хранения справочников, которые описаны выше могут применяться как в аналитических хранилищах, так и в OLTP базах. Выбор применения диктуется задачами, которые поставлены перед хранением. Где-то выгодней один раз потратиться на расчет, чтобы потом было удобно доставать данные, где-то хранилище используется только как историчное и там важно получить снепшоты всего, что происходило, но выбирать оттуда данные нужно будет раз в год.
SCD2 сейчас используется как универсальный метод хранения, который обеспечивает понятный ETL и понятные сценарии чтения. Его и просят описать на собесах. При этом, если отойти от собесов, то можно провести эксперимент и попробовать вынести более часто меняющиеся состояния в отдельный справочник и одним лишним джойном сэкономить на хранении излишних строк в широком справочнике.
👍3
#заметкинаполях #C4model
Диаграмма контекста (продолжение)
Давайте представим себе некий вымышленный футбольный клуб, который вдруг захотел стать data-driven и построить собственную аналитическую платформу, она-то как раз и будет центром нашей диаграммы. А вокруг нее поместим пользователей, которые с ней работают и системы, из которых она получает данные.
Тренерский штаб изучает соперника, физическое кондиции и статистику игроков и при помощи хитрых моделей выбирает тактику и состав на ближайшую игру, при помощи других, не менее хитрых, составляет тренировочные планы, учитывающие индивидуальные особенности игроков.
Медицинский персонал загружает данные осмотров, мониторит нагрузки и восстановление.
Игроки просматривают свою статистику, оценки, выставленные аналитическими моделями за прошедшие игры («Кариока - дуойка!»), рекомендации тренерского штаба и мед. персонала по питанию, тренировкам и восстановлению.
Скауты изучают трансферные цели, загружают данные из внешних источников, отчеты о соперниках.
Администрация анализирует финансовые отчеты, рентабельность трансферов…
Есть внешние поставщики статистических и скаутских данных, данные с датчиков GPS (чтобы сразу понятно было, кто реально тренировался, а кто, как легендарный Никита Баженов, датчик на собаку нацепил).
Наверняка существуют всякие CRM, системы учета трансферов (не через кассы же их пробивают), мониторинга соцсетей и много чего еще, но с нас хватит.
P.S. Диаграмма нарисована при помощи DeepSeek и слегка отредактирована в VS Code C4 DSL Extension.
продолжение следует…
Диаграмма контекста (продолжение)
Давайте представим себе некий вымышленный футбольный клуб, который вдруг захотел стать data-driven и построить собственную аналитическую платформу, она-то как раз и будет центром нашей диаграммы. А вокруг нее поместим пользователей, которые с ней работают и системы, из которых она получает данные.
Тренерский штаб изучает соперника, физическое кондиции и статистику игроков и при помощи хитрых моделей выбирает тактику и состав на ближайшую игру, при помощи других, не менее хитрых, составляет тренировочные планы, учитывающие индивидуальные особенности игроков.
Медицинский персонал загружает данные осмотров, мониторит нагрузки и восстановление.
Игроки просматривают свою статистику, оценки, выставленные аналитическими моделями за прошедшие игры («Кариока - дуойка!»), рекомендации тренерского штаба и мед. персонала по питанию, тренировкам и восстановлению.
Скауты изучают трансферные цели, загружают данные из внешних источников, отчеты о соперниках.
Администрация анализирует финансовые отчеты, рентабельность трансферов…
Есть внешние поставщики статистических и скаутских данных, данные с датчиков GPS (чтобы сразу понятно было, кто реально тренировался, а кто, как легендарный Никита Баженов, датчик на собаку нацепил).
Наверняка существуют всякие CRM, системы учета трансферов (не через кассы же их пробивают), мониторинга соцсетей и много чего еще, но с нас хватит.
P.S. Диаграмма нарисована при помощи DeepSeek и слегка отредактирована в VS Code C4 DSL Extension.
продолжение следует…
👍3
Forwarded from DataJourney
Data product как локомотив бизнеса
Недавно на просторах интернета наткнулся на статью уважаемых консалтеров о таком явлении как data productи о том, как ценно сначала заплатить денег компании mckinsey за аудит, а только потом начинать что-то строить.
Тема показалось мне интересной. Любопытным оставляю ссылку на оригинальную англоязычную статью, а тут изложу выжимку на русском со своими комментариями.
Что такое дата продукт? Для того, чтобы дальше рассуждать о некоем объекте договариваются, что дата продукт - это не просто данные и их доставка, а еще участие этих данных в бизнес-процессе. То есть просто собрать данные в хранилище - это не дата продукт. Собрать данные так, чтоб их использовали и принимали решения - продукт.
Опираясь на определение, авторы оригинальной статьи последовательно рассуждают о роли данных в компании, останавливаясь на следующих тезисах:
- важнее не качество данных, а их ценность - прежде чем заниматься качеством, важно подумать, а какую выгоду получит компания от качественных данных и труда, вложенного в гарантию этого качества;
- важно понимать экономику дата продукта - если удастся переиспользовать части пайплайна другими продуктами, то с кажым новым переиспользованием затпраты на разработку будут всё меньше и меньше, а ценность данных будет расти;
- важны люди, находящиеся на стыке бизнеса и технологий в вопросе данных: управленец, который одновременно понимает и бизнес и технологии сможет эффективней выстроить дата-продукт так, чтобы он приносил максимальную ценность и становился маховиком, разгоняющим ценность данных, и инженер данных, который будет строить мостики между источниками, агрегаторами и потребителями данных, понимая всех участникам процесса;
- GenAI - интеграция GenAI ускоряет разработку в три разаа интеграция модных слов в статью кратно увеличивает просмотры
- Data Marketplcae - нужно сделать доступ к данным максимально простым , чтобы другие команды могли удобно переиспользовать датасеты, собранные или созданные другими командами
В общем и целом, я полностью поддерживаю авторов статьи. Делать по одному продукту на каждый чих - это дорого. Лучше инвестировать в исследования, понять в каких местах возникают данные, собрать их, описать и затем использовать. При этом, важно понимать как и кем данные используются, чтобы уметь использовать технологии соизмеримые по стоимости с ценностью, которую приносит продукт.
Например, справочник товаров ритейл-компании должен быть аккуратно собран в одной системе и распространён на все остальные с минимальными задержками не считаясь со стоимостью итогового решения, так как от его наличия и актуальности зависят многие (если не все) процессы в ритейле. При этом условный справочник блюд столовой может быть в закрепе внутреннего ТГ канала. Оба датасета используются сотрудниками в рабочее время ежедневно. Но ценность для бизнеса и, соответственно, затраты на технологии, кардинально разнятся.
P.S. и да, при чем тут локомотив? В оригинальной статье приводится пример локомотива (дата продукта), как сущности, которая приводит в движение несколько вагонов (бизнес-кейсов). Вложения в поезд однократны и чем больше мы сможем прицепить к нему вагонов, тем меньше будет итоговая стоимость локомотива для бизнеса по перемещению вагонов.
Недавно на просторах интернета наткнулся на статью уважаемых консалтеров о таком явлении как data product
Тема показалось мне интересной. Любопытным оставляю ссылку на оригинальную англоязычную статью, а тут изложу выжимку на русском со своими комментариями.
Что такое дата продукт? Для того, чтобы дальше рассуждать о некоем объекте договариваются, что дата продукт - это не просто данные и их доставка, а еще участие этих данных в бизнес-процессе. То есть просто собрать данные в хранилище - это не дата продукт. Собрать данные так, чтоб их использовали и принимали решения - продукт.
Опираясь на определение, авторы оригинальной статьи последовательно рассуждают о роли данных в компании, останавливаясь на следующих тезисах:
- важнее не качество данных, а их ценность - прежде чем заниматься качеством, важно подумать, а какую выгоду получит компания от качественных данных и труда, вложенного в гарантию этого качества;
- важно понимать экономику дата продукта - если удастся переиспользовать части пайплайна другими продуктами, то с кажым новым переиспользованием затпраты на разработку будут всё меньше и меньше, а ценность данных будет расти;
- важны люди, находящиеся на стыке бизнеса и технологий в вопросе данных: управленец, который одновременно понимает и бизнес и технологии сможет эффективней выстроить дата-продукт так, чтобы он приносил максимальную ценность и становился маховиком, разгоняющим ценность данных, и инженер данных, который будет строить мостики между источниками, агрегаторами и потребителями данных, понимая всех участникам процесса;
- GenAI - интеграция GenAI ускоряет разработку в три раза
- Data Marketplcae - нужно сделать доступ к данным максимально простым , чтобы другие команды могли удобно переиспользовать датасеты, собранные или созданные другими командами
В общем и целом, я полностью поддерживаю авторов статьи. Делать по одному продукту на каждый чих - это дорого. Лучше инвестировать в исследования, понять в каких местах возникают данные, собрать их, описать и затем использовать. При этом, важно понимать как и кем данные используются, чтобы уметь использовать технологии соизмеримые по стоимости с ценностью, которую приносит продукт.
Например, справочник товаров ритейл-компании должен быть аккуратно собран в одной системе и распространён на все остальные с минимальными задержками не считаясь со стоимостью итогового решения, так как от его наличия и актуальности зависят многие (если не все) процессы в ритейле. При этом условный справочник блюд столовой может быть в закрепе внутреннего ТГ канала. Оба датасета используются сотрудниками в рабочее время ежедневно. Но ценность для бизнеса и, соответственно, затраты на технологии, кардинально разнятся.
P.S. и да, при чем тут локомотив? В оригинальной статье приводится пример локомотива (дата продукта), как сущности, которая приводит в движение несколько вагонов (бизнес-кейсов). Вложения в поезд однократны и чем больше мы сможем прицепить к нему вагонов, тем меньше будет итоговая стоимость локомотива для бизнеса по перемещению вагонов.
До сих пор с теплотой вспоминаю сие мероприятие, душевно тогда пообщались. Вот, кстати, и статья с итогами подъехала. Надо чаще встречаться!
https://habr.com/ru/companies/lemana_tech/articles/909542/
https://habr.com/ru/companies/lemana_tech/articles/909542/
Хабр
Заметки и материалы по итогам Lakehouse Meetup #3
Lakehouse – это не просто модное слово. Это попытка объединить лучшее из data lake и data warehouse, дешевое хранение S3, гибкость open source и производительность DWH. На третьем митапе,...
❤5
#C4model #заметкинаполях
Диаграмма контейнеров
После того, как мы разобрались с местоположением нашей системы в корпоративной среде и окружающем мире в целом - самое время показать верхнеуровнево ее архитектуру и выбранные для реализации требуемого функционала технологии, зоны ответственности и взаимодействия между контейнерами, которые обычно представляют собой либо какое-то приложение, либо вместилище данных.
Сей вид диаграммы призван помочь ответить на следующие вопросы:
Каковы общие очертания архитектуры системы?
Какие выбраны технологии?
Как распределены обязанности?
Как контейнеры взаимодействуют между собой
Где то самое место, в которое разработчикам нужно встроить свой замечательный код для реализации функционала?
Диаграмма контейнеров в первую очередь предназначена для технических специалистов, и ее хорошо бы иметь.
Диаграмма компонентов
Шаг следующий - расчленить (как-то слишком по-питерски звучит) каждый контейнер на его составные части, именуемые в данной методологии компонентами.
Диаграмма компонентов может помочь с поиском ответов на следующие вопросы:
Из каких компонентов состоит каждый контейнер?
Все ли компоненты имеют свое определенное место жительства (т. е. находятся в контейнере)? Опять по-питерски вышло… Ага, Краснодар - чемпион!
Как компоненты взаимодействуют между собой?
Очевидно ли, как работает программное обеспечение на высоком уровне?
Данный вид также предназначен для технических специалистов.
Заключительный уровень - диаграмма кода - считается опциональным, поскольку любой уважающий себя разработчик способен заполучить интересующую его информацию непосредственно из кода, поэтому сразу переходим дальше…
Продолжение следует...
Диаграмма контейнеров
После того, как мы разобрались с местоположением нашей системы в корпоративной среде и окружающем мире в целом - самое время показать верхнеуровнево ее архитектуру и выбранные для реализации требуемого функционала технологии, зоны ответственности и взаимодействия между контейнерами, которые обычно представляют собой либо какое-то приложение, либо вместилище данных.
Сей вид диаграммы призван помочь ответить на следующие вопросы:
Каковы общие очертания архитектуры системы?
Какие выбраны технологии?
Как распределены обязанности?
Как контейнеры взаимодействуют между собой
Где то самое место, в которое разработчикам нужно встроить свой замечательный код для реализации функционала?
Диаграмма контейнеров в первую очередь предназначена для технических специалистов, и ее хорошо бы иметь.
Диаграмма компонентов
Шаг следующий - расчленить (как-то слишком по-питерски звучит) каждый контейнер на его составные части, именуемые в данной методологии компонентами.
Диаграмма компонентов может помочь с поиском ответов на следующие вопросы:
Из каких компонентов состоит каждый контейнер?
Все ли компоненты имеют свое определенное место жительства (т. е. находятся в контейнере)? Опять по-питерски вышло… Ага, Краснодар - чемпион!
Как компоненты взаимодействуют между собой?
Очевидно ли, как работает программное обеспечение на высоком уровне?
Данный вид также предназначен для технических специалистов.
Заключительный уровень - диаграмма кода - считается опциональным, поскольку любой уважающий себя разработчик способен заполучить интересующую его информацию непосредственно из кода, поэтому сразу переходим дальше…
Продолжение следует...
👍3🍾1
#C4model #заметкинаполях
Документирование
Следующая часть книги посвящена документированию создаваемого ПО. Как подчеркивает сам автор, основная сложность в данном вопросе заключается в неверном истолковании одной из ценностей, задекларированной в Agile Manifesto, а именно: «Работающий продукт важнее исчерпывающей документации».
В «интертрепации» (чую, что мне скоро придется выплачивать роялти кировской комикс-группе «Охальники» за это прекрасное слово, подслушанное мною на их концерте в далеком детстве и с тех пор нещадно эксплуатируемое) многих команд фраза сия звучит как: «К черту любую документацию!»
В то время как, хорошо структурированная, качественно оформленная и подчиняющаяся заранее оговоренным правилам документация может служить путеводителям по разрабатываемым вами продуктам.
Собственно, структуру и правила, конечно же, с примерами, автор предоставляет вниманию читателей.
продолжение следует...
Документирование
Следующая часть книги посвящена документированию создаваемого ПО. Как подчеркивает сам автор, основная сложность в данном вопросе заключается в неверном истолковании одной из ценностей, задекларированной в Agile Manifesto, а именно: «Работающий продукт важнее исчерпывающей документации».
В «интертрепации» (чую, что мне скоро придется выплачивать роялти кировской комикс-группе «Охальники» за это прекрасное слово, подслушанное мною на их концерте в далеком детстве и с тех пор нещадно эксплуатируемое) многих команд фраза сия звучит как: «К черту любую документацию!»
В то время как, хорошо структурированная, качественно оформленная и подчиняющаяся заранее оговоренным правилам документация может служить путеводителям по разрабатываемым вами продуктам.
Собственно, структуру и правила, конечно же, с примерами, автор предоставляет вниманию читателей.
продолжение следует...
🔥3👍1