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
#C4model #заметкинаполях
Инструменты
Ну, а теперь об инструментах, «их есть», если кратко. Вот опробованные лично мной:
С4 DSL Model - расширение для VS Code
Упомянутый в комментариях (за что огромное спасибо, конечно же) Mermaid
Structurizr - инструмент от автора методологии C4
Глубоко в них я не погружался, поэтому плюсы-минусы расписать не могу (но буду рад, если кто-то поделится опытом). Тут, как мне кажется, на вкус и цвет..
Сам я выбрал Structurizr, просто потому что...
продолжение следует...
Инструменты
Ну, а теперь об инструментах, «их есть», если кратко. Вот опробованные лично мной:
С4 DSL Model - расширение для VS Code
Упомянутый в комментариях (за что огромное спасибо, конечно же) Mermaid
Structurizr - инструмент от автора методологии C4
Глубоко в них я не погружался, поэтому плюсы-минусы расписать не могу (но буду рад, если кто-то поделится опытом). Тут, как мне кажется, на вкус и цвет..
Сам я выбрал Structurizr, просто потому что...
продолжение следует...
Visualstudio
C4 DSL Extension - Visual Studio Marketplace
Extension for Visual Studio Code - A DSL for C4 Models
#C4model #заметкинаполях
Заключение
Обзор книги «C4 Model for Visualising Software Architecture» от товарища Simon Brown подошел к своему завершению. Чтение мне доставило настолько неописуемое удовольствие, что даже странно, как я ухитрился так долго и упорно игнорировать C4, несмотря на очевидные подталкивания со стороны Вселенной.
Однозначно рекомендую архитекторам, инженерам, системным аналитикам, а также всем ответственным за наведение порядка и единообразия в дата-хозяйстве (таким, как я, завхозам данных, короче).
Лучшее, что в ней есть - это готовые практические рекомендации с примерами их применения (и объем, бесспорно).
Теперь можно переходить к следующей книге.
Заключение
Обзор книги «C4 Model for Visualising Software Architecture» от товарища Simon Brown подошел к своему завершению. Чтение мне доставило настолько неописуемое удовольствие, что даже странно, как я ухитрился так долго и упорно игнорировать C4, несмотря на очевидные подталкивания со стороны Вселенной.
Однозначно рекомендую архитекторам, инженерам, системным аналитикам, а также всем ответственным за наведение порядка и единообразия в дата-хозяйстве (таким, как я, завхозам данных, короче).
Лучшее, что в ней есть - это готовые практические рекомендации с примерами их применения (и объем, бесспорно).
Теперь можно переходить к следующей книге.
🔥2👍1
В жизни все случается вовремя. Только вот подумал, что хорошо бы подумать...
А вот уже и чек-лист интересный попался.
https://news.1rj.ru/str/analyticsfromzero/133
А вот уже и чек-лист интересный попался.
https://news.1rj.ru/str/analyticsfromzero/133
Telegram
Архитектор Данных
Ситуационный центр данных
То, чего как правило нет.
Должен отвечать на вопросы:
⁃ Какой сейчас статус прогрузки данных?
⁃ Какие инциденты активны? Какого типа: мисы по SLA, ошибки качества, нарушения контрактов, недоступность источников. Кто ответственный…
То, чего как правило нет.
Должен отвечать на вопросы:
⁃ Какой сейчас статус прогрузки данных?
⁃ Какие инциденты активны? Какого типа: мисы по SLA, ошибки качества, нарушения контрактов, недоступность источников. Кто ответственный…
#заметкинаполях #datapipelinespocketreference
Еще один экземпляр из бумажной коллекции, любовью к которой я проникаюсь все больше и больше, ибо является она чудесным спасением от мирской суеты последней пятилетки. Возможно, дело в успокаивающем шелесте перелистываемых страниц, восможно, в чем-то еще, но в электронных книгах этого нет. «Be still, в общем, and know that I am» - советует в одной из своих композиций британский товарищ Терри Олдфилд, старший брат, ну, того самого, который «Tubular Bells», который в некотором роде тоже «конвейер».
Автор данной книги, некий Джеймс Денсмор, доселе мне незнакомый, утверждает, что она «описывает передовые методы построения конвейеров данных в современную эпоху», и объявляет своей целью «чтобы эта книга стала для вас путеводителем и карманным справочником», потому что «конвейеры данных - это основа успеха в области анализа данных и машинного обучения”.
Подписываясь под каждым словом из последней цитаты предыдущего абзаца, напишу свое уже традиционное «продолжение следует…»
Еще один экземпляр из бумажной коллекции, любовью к которой я проникаюсь все больше и больше, ибо является она чудесным спасением от мирской суеты последней пятилетки. Возможно, дело в успокаивающем шелесте перелистываемых страниц, восможно, в чем-то еще, но в электронных книгах этого нет. «Be still, в общем, and know that I am» - советует в одной из своих композиций британский товарищ Терри Олдфилд, старший брат, ну, того самого, который «Tubular Bells», который в некотором роде тоже «конвейер».
Автор данной книги, некий Джеймс Денсмор, доселе мне незнакомый, утверждает, что она «описывает передовые методы построения конвейеров данных в современную эпоху», и объявляет своей целью «чтобы эта книга стала для вас путеводителем и карманным справочником», потому что «конвейеры данных - это основа успеха в области анализа данных и машинного обучения”.
Подписываясь под каждым словом из последней цитаты предыдущего абзаца, напишу свое уже традиционное «продолжение следует…»
👍3🔥1
#заметкинаполях #datapipelinepocketreference
Начинается книга с расшифровки основных понятий, описания навыков, необходимых разработчикам конвейеров данных, и обсуждения современной инфраструктуры данных.
Ключевая мысль первой главы, на мой взгляд, заключается в следующем абзаце:
продолжение следует...
Начинается книга с расшифровки основных понятий, описания навыков, необходимых разработчикам конвейеров данных, и обсуждения современной инфраструктуры данных.
Ключевая мысль первой главы, на мой взгляд, заключается в следующем абзаце:
«Конвейеры данных не только строить - их нужно контролировать, обслуживать и развивать. Перед инженерами данных стоит задача не просто организовать доставку данных тем или иным способом, но и создать конвейеры и поддерживающую инфраструктуру, которые обеспечивают надежную, безопасную и своевременную доставку и обработку данных. Это нелегкий подвиг, но, когда все сделано правильно, можно спокойно сосредоточиться на извлечении ценной информации из данных организации».
продолжение следует...
👍2
Forwarded from Starrocks and modern data stack
StarRocks meetup
Всем привет.
Рады пригласить вас на первый онлайн митап по восходящей звезде аналитических баз данных StarRocks 19 июня в 19:00МСК. Митап состоится онлайн, регистрация по ссылке.
Сообщество пользователей подготовило 2 доклада, охватывающие весь спектр задач - от типичного dwh небольшой компании до использования lakehouse движка поверх S3 и открытых форматов. От часовых витрин до bi безумия из сотен тысяч запросов. Мы постараемся ответить - жив ли еще опенсорс, есть ли альтернатива кликхаузу, гринпламу или трино. А если вдруг что-то забудем, то после докладов приглашаем вас на сессию вопросов и ответов в zoom к докладчикам 👍
Всем привет.
Рады пригласить вас на первый онлайн митап по восходящей звезде аналитических баз данных StarRocks 19 июня в 19:00МСК. Митап состоится онлайн, регистрация по ссылке.
Сообщество пользователей подготовило 2 доклада, охватывающие весь спектр задач - от типичного dwh небольшой компании до использования lakehouse движка поверх S3 и открытых форматов. От часовых витрин до bi безумия из сотен тысяч запросов. Мы постараемся ответить - жив ли еще опенсорс, есть ли альтернатива кликхаузу, гринпламу или трино. А если вдруг что-то забудем, то после докладов приглашаем вас на сессию вопросов и ответов в zoom к докладчикам 👍
👍4
#заметкинаполях #datapipelinepocketreference
Глава третья посвящена обсуждению ETL/ELT, про это сказано очень много и картинок много нарисовано, вот у меня тут одна из них, уже примелькавшаяся в других каналах, приведена.
Но у меня есть свой (Yet Another) вариант.
На футбольном языке ETL - это «спартаковские кружева», стиль, который «заключается в постоянном контроле мяча с помощью выверенных коротких/средних передач и последующих своевременных открываниях преимущественно на чужой половине поля».
ELT, в свою очередь, - это тактика, более известная как «бей-беги», основанная на длинных передачах, предполагающая минимальную работу в центре поля и быстрый переход от обороны к атаке.
В современном мире ELT практически вытеснил ETL, команды предпочитают «пульнуть» мяч пользователю, а он там сам уже разберется, что ему с этими данными делать, если, конечно, пользователь обладает необходимыми для этого навыками таргетмена.
Иногда бывает полезно выполнить некоторые преобразования перед загрузкой, такие как удаление дубликатов строк или же маскировка конфиденциальных данных. Этот подшаблон иногда называют EtLT или же гегенпрессинг, вместо того, чтобы «перегруппировываться и ждать», организуется моментальное «нападение» на данные, часто результат стоит затраченных усилий, смело используйте, если вашего CDO зовут Юрген Клопп.
P.S. Когда-нибудь я, вдохновленный творчеством Дуги Бримсона, обязательно напишу большую статью, что-то типа «Все о данных для настоящих мужиков».
P.P.S Я снова читаю «Улисса» (на этот раз английском) и, кажется, Джойса в моем творчестве становится слишком много. Это пройдет. Или нет. Потому что в планах прочитать всего Джойса.
Глава третья посвящена обсуждению ETL/ELT, про это сказано очень много и картинок много нарисовано, вот у меня тут одна из них, уже примелькавшаяся в других каналах, приведена.
Но у меня есть свой (Yet Another) вариант.
На футбольном языке ETL - это «спартаковские кружева», стиль, который «заключается в постоянном контроле мяча с помощью выверенных коротких/средних передач и последующих своевременных открываниях преимущественно на чужой половине поля».
ELT, в свою очередь, - это тактика, более известная как «бей-беги», основанная на длинных передачах, предполагающая минимальную работу в центре поля и быстрый переход от обороны к атаке.
В современном мире ELT практически вытеснил ETL, команды предпочитают «пульнуть» мяч пользователю, а он там сам уже разберется, что ему с этими данными делать, если, конечно, пользователь обладает необходимыми для этого навыками таргетмена.
Иногда бывает полезно выполнить некоторые преобразования перед загрузкой, такие как удаление дубликатов строк или же маскировка конфиденциальных данных. Этот подшаблон иногда называют EtLT или же гегенпрессинг, вместо того, чтобы «перегруппировываться и ждать», организуется моментальное «нападение» на данные, часто результат стоит затраченных усилий, смело используйте, если вашего CDO зовут Юрген Клопп.
P.S. Когда-нибудь я, вдохновленный творчеством Дуги Бримсона, обязательно напишу большую статью, что-то типа «Все о данных для настоящих мужиков».
P.P.S Я снова читаю «Улисса» (на этот раз английском) и, кажется, Джойса в моем творчестве становится слишком много. Это пройдет. Или нет. Потому что в планах прочитать всего Джойса.
👍5
Наблюдал сегодня за попыткой десятимесячного сына выбраться из стульчика для купания(кто не знает, что это такое - см фото). Он встал на ноги, придерживаясь за поручни, но не стал перешагивать, а перегнулся через них и перелез, то есть свел задачу к той, которую он умеет решать хорошо.
Эти натолкнуло меня на мысль, что в роли CDO очень полезен архитектурный бэкграунд. По сути, в проектируемой системе на уровне C1 появляется еще один вид связи, который нужно учитывать: связи между людьми. Таким образом, «вылив воду из чайника, задачу можно легко свести к предыдущей».
К слову, подобный прием предлагал великому ультрамарафонцу Скотту Джуреку, мандражировавшему перед выходом на старт дебютного стомильника, его друг Дасти Олсен: «Это всего лишь пятидесятимильник, а потом еще один пятидесятимильник, а бегать пятидесятимильники ты уже умеешь».
Объединив эти случаи можно сформулировать Закон чайника-стульчика-Олсена: «Довольно часто сложную и незнакомую задачу можно свести к простой и знакомой при помощи смекалки».
P.S. И да, я просто пародирую здесь Джерри Вайнберга.
Эти натолкнуло меня на мысль, что в роли CDO очень полезен архитектурный бэкграунд. По сути, в проектируемой системе на уровне C1 появляется еще один вид связи, который нужно учитывать: связи между людьми. Таким образом, «вылив воду из чайника, задачу можно легко свести к предыдущей».
К слову, подобный прием предлагал великому ультрамарафонцу Скотту Джуреку, мандражировавшему перед выходом на старт дебютного стомильника, его друг Дасти Олсен: «Это всего лишь пятидесятимильник, а потом еще один пятидесятимильник, а бегать пятидесятимильники ты уже умеешь».
Объединив эти случаи можно сформулировать Закон чайника-стульчика-Олсена: «Довольно часто сложную и незнакомую задачу можно свести к простой и знакомой при помощи смекалки».
P.S. И да, я просто пародирую здесь Джерри Вайнберга.
👍5
#заметкинаполях #datapipelinepocketreference
Нанес на свою беговую карту очередную локацию - старинный русский город Тотьму, «город музеев и мореходов», «родину души» замечательного русского поэта Николая Рубцова, «долго гнавшего свой велосипед и остановившего его в глухих лугах, чтобы нарвать цветов и подарить букет любимой девушке». Легкая сорокаминутная пробежка на низком пульсе (до 120 ударов в минуту) - идеальная возможность и город осмотреть, и о планах на рабочий день подумать.
Вернемся ненадолго к книге о конвейерах данных, в прочитанных к сему моменту главах много кода, говорить особо не о чем.
Глава 4 посвящена извлечению данных из различных источников, таких как: MySQL, PostgreSQL, MongoDB, REST API и загрузке их в S3. В главе 5 данные переносятся из S3 в RedShift и Snowflake. Глава 6 - про преобразование данных, слегка затрагивается тема моделирования.
А Тотьма, одна из «жемчужин Русского Севера», летом хороша, рай для удаленщика, пусть и без тыквенного латте и чибисовских неип. Как же чудесно встать в 5 утра, взять ноутбук и книжку, помахать приветственно памятнику Николая Михайловича, окунуться по пояс в зеленое море дикорастущих трав и, глазея на почти неподвижную Сухону, под щебет птиц писать сие сообщение.
Нанес на свою беговую карту очередную локацию - старинный русский город Тотьму, «город музеев и мореходов», «родину души» замечательного русского поэта Николая Рубцова, «долго гнавшего свой велосипед и остановившего его в глухих лугах, чтобы нарвать цветов и подарить букет любимой девушке». Легкая сорокаминутная пробежка на низком пульсе (до 120 ударов в минуту) - идеальная возможность и город осмотреть, и о планах на рабочий день подумать.
Вернемся ненадолго к книге о конвейерах данных, в прочитанных к сему моменту главах много кода, говорить особо не о чем.
Глава 4 посвящена извлечению данных из различных источников, таких как: MySQL, PostgreSQL, MongoDB, REST API и загрузке их в S3. В главе 5 данные переносятся из S3 в RedShift и Snowflake. Глава 6 - про преобразование данных, слегка затрагивается тема моделирования.
А Тотьма, одна из «жемчужин Русского Севера», летом хороша, рай для удаленщика, пусть и без тыквенного латте и чибисовских неип. Как же чудесно встать в 5 утра, взять ноутбук и книжку, помахать приветственно памятнику Николая Михайловича, окунуться по пояс в зеленое море дикорастущих трав и, глазея на почти неподвижную Сухону, под щебет птиц писать сие сообщение.
👍6
#заметкинаполях #datapipelinepocketreference
Глава 7 посвящена «оркестровке» конвейеров данных - процессу, «обеспечивающему надлежащее управление зависимостями и выполнение шагов конвейера в правильном порядке», - и одному из самых популярных инструментов такого рода - Apache Airflow.
Airflow в мире данных - это как Джек Дэниэлс в беге, то есть довольно простой инструмент, предоставляющий весь функционал, необходимый для объединения отдельных, различных по типу задач в единый «тренировочный конвейер», направленный на достижение конкретной цели и вместе с тем обладающий механизмами для контроля текущего статуса.
В главе содержатся основные сведения об Airflow: история возникновения, установка и настройка, компоненты, примеры создания DAG.
Стоит упомянуть, что в книге рассматривается версия 1, а 2 только предвкушается, в то время как совсем недавно свет увидел Airflow 3. Надеюсь, что, подобно великой книге Джека Дэниэлса, сей инструмент ждет еще множество переизданий.
продолжение следует...
Глава 7 посвящена «оркестровке» конвейеров данных - процессу, «обеспечивающему надлежащее управление зависимостями и выполнение шагов конвейера в правильном порядке», - и одному из самых популярных инструментов такого рода - Apache Airflow.
Airflow в мире данных - это как Джек Дэниэлс в беге, то есть довольно простой инструмент, предоставляющий весь функционал, необходимый для объединения отдельных, различных по типу задач в единый «тренировочный конвейер», направленный на достижение конкретной цели и вместе с тем обладающий механизмами для контроля текущего статуса.
В главе содержатся основные сведения об Airflow: история возникновения, установка и настройка, компоненты, примеры создания DAG.
Стоит упомянуть, что в книге рассматривается версия 1, а 2 только предвкушается, в то время как совсем недавно свет увидел Airflow 3. Надеюсь, что, подобно великой книге Джека Дэниэлса, сей инструмент ждет еще множество переизданий.
продолжение следует...
👍2
#заметкинаполях #datapipelinepocketreference
В отпуске совсем не хочется ни читать, ни писать, ни думать на рабочие темы, тем более, что провожу я его в этот раз на своей малой Родине - селе Ильинско-Подомское, расположенном на юге Архангельской области.
Главной местной достопримечательностью, на мой взгляд, является новенький, открытый прошлой осенью стадион с четырехсотметровым кругом и весьма приличными беговыми дорожками, в моих московских локациях: ДДС и Таганский Парк - качество дорожек примерно такое же. Успел тут уже установить парочку тренировочных season best, постепенно приближаясь к самому себе образца 2018 года.
Занимательный факт: восстанавливаюсь здесь я намного быстрее, чем в Москве, при том, что встаю намного раньше и сплю меньше. «Наверно, это мой рай.» - пела исполнительница дорогого сердцу каждого красно-белого хита «Знаешь ли ты?».
Тем не менее, книгу о конвейерах я все-таки дочитал.
Глава 8 посвящена проверкам качества данных, приведен пример разработки простого фреймворка для осуществления сего действа, описаны основные отслеживаемые метрики.
Глава 9 рассказывает о передовых методах обслуживания конвейеров.
Глава 10 - про измерение и мониторинг производительности.
На этом книга все, в следующий раз подведем итоги.
продолжение следует...
В отпуске совсем не хочется ни читать, ни писать, ни думать на рабочие темы, тем более, что провожу я его в этот раз на своей малой Родине - селе Ильинско-Подомское, расположенном на юге Архангельской области.
Главной местной достопримечательностью, на мой взгляд, является новенький, открытый прошлой осенью стадион с четырехсотметровым кругом и весьма приличными беговыми дорожками, в моих московских локациях: ДДС и Таганский Парк - качество дорожек примерно такое же. Успел тут уже установить парочку тренировочных season best, постепенно приближаясь к самому себе образца 2018 года.
Занимательный факт: восстанавливаюсь здесь я намного быстрее, чем в Москве, при том, что встаю намного раньше и сплю меньше. «Наверно, это мой рай.» - пела исполнительница дорогого сердцу каждого красно-белого хита «Знаешь ли ты?».
Тем не менее, книгу о конвейерах я все-таки дочитал.
Глава 8 посвящена проверкам качества данных, приведен пример разработки простого фреймворка для осуществления сего действа, описаны основные отслеживаемые метрики.
Глава 9 рассказывает о передовых методах обслуживания конвейеров.
Глава 10 - про измерение и мониторинг производительности.
На этом книга все, в следующий раз подведем итоги.
продолжение следует...
👍4🥰1