Data Engineer

#заметкинаполях #datapipelinespocketreference

Еще один экземпляр из бумажной коллекции, любовью к которой я проникаюсь все больше и больше, ибо является она чудесным спасением от мирской суеты последней пятилетки. Возможно, дело в успокаивающем шелесте перелистываемых страниц, восможно, в чем-то еще, но в электронных книгах этого нет. «Be still, в общем, and know that I am» - советует в одной из своих композиций британский товарищ Терри Олдфилд, старший брат, ну, того самого, который «Tubular Bells», который в некотором роде тоже «конвейер».

Автор данной книги, некий Джеймс Денсмор, доселе мне незнакомый, утверждает, что она «описывает передовые методы построения конвейеров данных в современную эпоху», и объявляет своей целью «чтобы эта книга стала для вас путеводителем и карманным справочником», потому что «конвейеры данных - это основа успеха в области анализа данных и машинного обучения”.

Подписываясь под каждым словом из последней цитаты предыдущего абзаца, напишу свое уже традиционное «продолжение следует…»

В жизни все случается вовремя. Только вот подумал, что хорошо бы подумать...

А вот уже и чек-лист интересный попался.

https://t.me/analyticsfromzero/133

#C4model #заметкинаполях

Заключение

Обзор книги «C4 Model for Visualising Software Architecture» от товарища Simon Brown подошел к своему завершению. Чтение мне доставило настолько неописуемое удовольствие, что даже странно, как я ухитрился так долго и упорно игнорировать C4, несмотря на очевидные подталкивания со стороны Вселенной.

Однозначно рекомендую архитекторам, инженерам, системным аналитикам, а также всем ответственным за наведение порядка и единообразия в дата-хозяйстве (таким, как я, завхозам данных, короче).

Лучшее, что в ней есть - это готовые практические рекомендации с примерами их применения (и объем, бесспорно).

Теперь можно переходить к следующей книге.

#C4model #заметкинаполях

Инструменты

Ну, а теперь об инструментах, «их есть», если кратко. Вот опробованные лично мной:

С4 DSL Model - расширение для VS Code

Упомянутый в комментариях (за что огромное спасибо, конечно же) Mermaid

Structurizr - инструмент от автора методологии C4

Глубоко в них я не погружался, поэтому плюсы-минусы расписать не могу (но буду рад, если кто-то поделится опытом). Тут, как мне кажется, на вкус и цвет..
Сам я выбрал Structurizr, просто потому что...

продолжение следует...

#C4model #заметкинаполях

Документирование

Следующая часть книги посвящена документированию создаваемого ПО. Как подчеркивает сам автор, основная сложность в данном вопросе заключается в неверном истолковании одной из ценностей, задекларированной в Agile Manifesto, а именно: «Работающий продукт важнее исчерпывающей документации».

В «интертрепации» (чую, что мне скоро придется выплачивать роялти кировской комикс-группе «Охальники» за это прекрасное слово, подслушанное мною на их концерте в далеком детстве и с тех пор нещадно эксплуатируемое) многих команд фраза сия звучит как: «К черту любую документацию!»

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

Собственно, структуру и правила, конечно же, с примерами, автор предоставляет вниманию читателей.

продолжение следует...

#C4model #заметкинаполях

Диаграмма контейнеров

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

Сей вид диаграммы призван помочь ответить на следующие вопросы:

Каковы общие очертания архитектуры системы?
Какие выбраны технологии?
Как распределены обязанности?
Как контейнеры взаимодействуют между собой
Где то самое место, в которое разработчикам нужно встроить свой замечательный код для реализации функционала?

Диаграмма контейнеров в первую очередь предназначена для технических специалистов,  и ее хорошо бы иметь.

Диаграмма компонентов

Шаг следующий - расчленить (как-то слишком по-питерски звучит) каждый контейнер на его составные части, именуемые в данной методологии компонентами.

Диаграмма компонентов может помочь с поиском ответов на следующие вопросы:

Из каких компонентов состоит каждый контейнер?
Все ли компоненты имеют свое определенное место жительства (т. е. находятся в контейнере)? Опять по-питерски вышло… Ага, Краснодар - чемпион!

Как компоненты взаимодействуют между собой?
Очевидно ли, как работает программное обеспечение на высоком уровне?

Данный вид также предназначен для технических специалистов.

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

Продолжение следует...

До сих пор с теплотой вспоминаю сие мероприятие, душевно тогда пообщались. Вот, кстати, и статья с итогами подъехала. Надо чаще встречаться!

https://habr.com/ru/companies/lemana_tech/articles/909542/

Data product как локомотив бизнеса

Недавно на просторах интернета наткнулся на статью уважаемых консалтеров о таком явлении как data product и о том, как ценно сначала заплатить денег компании mckinsey за аудит, а только потом начинать что-то строить.

Тема показалось мне интересной. Любопытным оставляю ссылку на оригинальную англоязычную статью, а тут изложу выжимку на русском со своими комментариями.

Что такое дата продукт? Для того, чтобы дальше рассуждать о некоем объекте договариваются, что дата продукт - это не просто данные и их доставка, а еще участие этих данных в бизнес-процессе. То есть просто собрать данные в хранилище - это не дата продукт. Собрать данные так, чтоб их использовали и принимали решения - продукт.

Опираясь на определение, авторы оригинальной статьи последовательно рассуждают о роли данных в компании, останавливаясь на следующих тезисах:
- важнее не качество данных, а их ценность - прежде чем заниматься качеством, важно подумать, а какую выгоду получит компания от качественных данных и труда, вложенного в гарантию этого качества;
- важно понимать экономику дата продукта - если удастся переиспользовать части пайплайна другими продуктами, то с кажым новым переиспользованием затпраты на разработку будут всё меньше и меньше, а ценность данных будет расти;
- важны люди, находящиеся на стыке бизнеса и технологий в вопросе данных: управленец, который одновременно понимает и бизнес и технологии сможет эффективней выстроить дата-продукт так, чтобы он приносил максимальную ценность и становился маховиком, разгоняющим ценность данных, и инженер данных, который будет строить мостики между источниками, агрегаторами и потребителями данных, понимая всех участникам процесса;
- GenAI - интеграция GenAI ускоряет разработку в три раза а интеграция модных слов в статью кратно увеличивает просмотры;
- Data Marketplcae - нужно сделать доступ к данным максимально простым , чтобы другие команды могли удобно переиспользовать датасеты, собранные или созданные другими командами

В общем и целом, я полностью поддерживаю авторов статьи. Делать по одному продукту на каждый чих - это дорого. Лучше инвестировать в исследования, понять в каких местах возникают данные, собрать их, описать и затем использовать. При этом, важно понимать как и кем данные используются, чтобы уметь использовать технологии соизмеримые по стоимости с ценностью, которую приносит продукт.

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

P.S. и да, при чем тут локомотив? В оригинальной статье приводится пример локомотива (дата продукта), как сущности, которая приводит в движение несколько вагонов (бизнес-кейсов). Вложения в поезд однократны и чем больше мы сможем прицепить к нему вагонов, тем меньше будет итоговая стоимость локомотива для бизнеса по перемещению вагонов.

#заметкинаполях #C4model

Диаграмма контекста (продолжение)

Давайте представим себе некий вымышленный футбольный клуб, который вдруг захотел стать data-driven и построить собственную аналитическую платформу, она-то как раз и будет центром нашей диаграммы. А вокруг нее поместим пользователей, которые с ней работают и системы, из которых она получает данные.

Тренерский штаб изучает соперника, физическое кондиции и статистику игроков и при помощи хитрых моделей выбирает тактику и состав на ближайшую игру, при помощи других, не менее хитрых, составляет тренировочные планы, учитывающие индивидуальные особенности игроков.

Медицинский персонал загружает данные осмотров, мониторит нагрузки и восстановление.

Игроки просматривают свою статистику, оценки, выставленные аналитическими моделями за прошедшие игры («Кариока - дуойка!»), рекомендации тренерского штаба и мед. персонала по питанию, тренировкам и восстановлению.

Скауты изучают трансферные цели, загружают данные из внешних источников, отчеты о соперниках.

Администрация анализирует финансовые отчеты, рентабельность трансферов…

Есть внешние поставщики статистических и скаутских данных, данные с датчиков GPS (чтобы сразу понятно было, кто реально тренировался, а кто, как легендарный Никита Баженов, датчик на собаку нацепил).

Наверняка существуют всякие CRM, системы учета трансферов (не через кассы же их пробивают), мониторинга соцсетей и много чего еще, но с нас хватит.

P.S. Диаграмма нарисована при помощи DeepSeek и слегка отредактирована в VS Code C4 DSL Extension.

продолжение следует…

… SCD продолжение

Продолжаю с хранением справочников. Типы, которых нет в русской вики:

4️⃣ тип хранения при котором в справочнике содержится только актуальное на текущий момент состояние справочника, а рядом существует таблица (часто с суффиксом _history), в которой хранятся все предыдущие состояния с указанием периодов актуальности. У такого типа хранения есть преимущетсва по скорости доступа как у SCD1, но при этом есть возможность заглянуть по истории назад как в SCD2.

Пример: Справочник сотрудников, разбитый на две таблицы: personal и personal_hist. В первой таблице храняться все сотрудники на текущий момент в актуальном состоянии должностей, принадлежностей к отделам. В таблице с суффиксом hist хранится вся история изменений состояния.

5️⃣ тип хранения при котором часть справочника живет по второму типу, а часть вырождается в отдельный справочник, который живет по первому типу. Таким образом, у строки состояния справочника второго типа появляется свой собственный справочник с уникальным ключем, в котором хранится актуальное состояние.

Пример: Такой же справочник сотрудников как в примере выше, но у которого принадлежность к организационной структуре вынесена в отдельный справочник через внешний ключ. И этот отдельный справочник уже ведется по SCD1 для ускорения доступа.

6️⃣ тип хранения, в котором опять миксуются предыдущие типы для достижения каких-то бизнес целей и повышения производительности чтения. Здесь соединены SCD2 и SCD3. По части полей содержится актуальное состояние, а по части полей есть историчность с указанием периода актуальности.

Пример: Справочник моделей телефонов, в котором указано расположение их на планограмме выкладки, а так же какие-то справочные данные по поставщикам. Может возникнуть ситуация, когда товары перемещаются по планограмме и возникает необходимость сверки текущего состояния с состоянием на произвольный момент времени. Тогда имеет смысл в SCD2 справочник добавить колонку «current_position», которая будет содержать актуальную позицию товара во всех строках.

7️⃣ тип хранения, в чем-то схожиый с SCD5. Здесь так же справочник разбивается на две части: одна хранится по SCD2, а другая по SCD1. Но при этом в таблице фактов содержатся две ссылки: на основной справочник и на справочник с актуальными значениями характеристик.

💭Небольшой итог. Все типы хранения справочников, которые описаны выше могут применяться как в аналитических хранилищах, так и в OLTP базах. Выбор применения диктуется задачами, которые поставлены перед хранением. Где-то выгодней один раз потратиться на расчет, чтобы потом было удобно доставать данные, где-то хранилище используется только как историчное и там важно получить снепшоты всего, что происходило, но выбирать оттуда данные нужно будет раз в год.

SCD2 сейчас используется как универсальный метод хранения, который обеспечивает понятный ETL и понятные сценарии чтения. Его и просят описать на собесах. При этом, если отойти от собесов, то можно провести эксперимент и попробовать вынести более часто меняющиеся состояния в отдельный справочник и одним лишним джойном сэкономить на хранении излишних строк в широком справочнике.

#заметкинаполях #C4model

Диаграмма контекста

Диаграмма контекста позволяет ответить на три главных аналитических вопроса:

1️⃣ Что мы делаем?
2️⃣ Кому это надо?
3️⃣ «И де я нахожуся?»

Алгоритм предельно прост: нарисуйте в центре вашу систему и окружите ее пользователями и другими системами, с которыми она взаимодействует. Снабдите каждый элемент диаграммы кратким описанием, как-то: наименование, предназначение, выполняемые обязанности…

По желанию, пунктиром можно провести границу между вашей корпоративной средой и внешним миром.

Диаграмма контекста хорошо подходит для демонстрации коллегам без технического бэкграунда. Ее наличие обязательно для вашей системы.

продолжение следует...

В минувший четверг посетил конференцию, посвященную новым компьютерным технологиям, а именно Data LakeHouse, организованную компаниями Лемана Тех и Кверифай Лабс.

«Встреча прошла конструктивно, в теплой и дружественной обстановке». Хочется передать свою благодарность всем причастным к проведению мероприятия, докладчикам, экспертам да и просто участникам за интересные вопросы. Безумно рад был повидаться и пообщаться.

Надеюсь, что у коллег из Лемана Тех получится сделать историю с дата-митапами регулярной, ибо к ним я готов ходить "и ночью, и в дождь".

Запись для тех, кто все пропустил

SCD - slowly changing dimension (медленно меняющиеся измерения)

Любимый вопрос на собеседования рядом с базами данных (от больших хранилищ до маленьких баз) - это вопрос про SCD. Если кратко, то это приёмы хранения различных справочников объектов, атрибуты которых меняются, но не так часто как таблицы фактов. В рускоязычной вики описаны три типа SCD, но на самом деле различают до семи типов.

0️⃣ вырожденный случай, в котором атрибуты не меняются никогда.
Пример: справочник химических элементов.

1️⃣ тип хранения, в котором не хранится историчность, а значения атрибута перезаписываются при его обновлении.
Пример: Состояние табло аэропорта, отображающего время и место вылета самолётов.

2️⃣ тип хранения, в котором уже сохраняются предыдущие значения справочника. Для того, чтобы выбрать актуальное состояние добавляется поле с версией объекта или флаг того, что строка актуальная и смотреть нужно именно на неё или же описываются даты начала и окончания действия строки.
Пример: справочник тарифов за коммуналку. Там важно знать именно периоды действия тарифа, чтобы иметь возможность делать перерасчеты.

3️⃣тип хранения, при котором добавляется новая колонка для нового состояния атрибута и, в некоторых случаях, дата смены атрибута.
Пример: справочник специалистов, которые ведут приём. Может статься так, что периодически специалист меняет кабент, но клиенту важно знать в каком кабинете он был в прошлый раз.

… продолжение следует

Накопилось у меня тут материалов по иишнице, но открою эту тему с пятничного 😄

#заметкинаполях #C4model

Душа радуется и настрой на будень трудовой резко повышается, когда с утра накатил быстрых повторов по Джеку Дэниэлсу: 600м - 2'5'', 500м - 1'41'', 400м - 1'19'', 300м - 52''. Но, как поет глубокоуважаемый мною Роман Суслов: «Не о том речь».

Итак, свое название методология С4 получила по первым буквам названий четырех уровней абстракции, коими она оперирует:

1️⃣ Context - отправная точка, показывает, как система вписывается в окружающую ее среду и как с ней взаимодействует. «К черту подробности, город какой?», - в общем.

2️⃣ Containers - Раскрывает основные «строительные блоки» системы и связи между ними.

3️⃣ Components - Переходит в отдельный компонент и демонстрирует его составные части

4️⃣ Code - детали реализации компонента, некоторые считают, что «он нам и нафиг не нужон».

продолжение следует…

#напочитать

Неожиданный и весьма приятный подарок на ДР пополнил коллекцию бумажных книг. Хочется немедленно приступить к чтению, но "порядок превыше всего".