📚 Practical Data Modelling pre-book

не теряю надежды вкатиться в Data Modelling и продолжаю активно следить за господином Joe Reis.

ранее он объявил, что после соавторства книги Fundamentals of Data Engineering его следующей соло-книгой будет Practical Data Modelling (уже есть рисунок оглавления).

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

в качестве введения Джо предлагает договориться о терминах и приводит цитаты других, начиная с книги 1967 года

> A data model organizes and standardizes data in a precise structured representation to enable and guide human and machine behavior, inform decision-making, and facilitate actions.

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

обратите внимание, что автор явно включает машины в игру: под это понятие кажется подпадает всё МЛ направление со всеми этими фича-сторами и что там ещё у них есть

и далее любопытный заход через отрицание: чем же моделированные данных НЕ является:

⌘ идеальным. Модель не может содержать в себе всю реальность, поэтому она всегда будет что-то упускать.

⌘ исключительно физическим. часто про модель данных вспоминают непосредственно перед записью в базу и тогда задача превращается «как мне ЭТО засунуть в Сноуфлейк?!». Не стоит забывать, что есть перед этапом физического, есть ещё концептуальное и логическое моделирование.

⌘ какой-то отдельный подход. тезис «моделирование данных — это Кимбал» равен утверждению, что боевые искусства — это карате. На самом деле понятие шире и более этого: отсутствие модели — это тоже модель. У каждого подхода есть свои плюсы и минусы, по-разному проявляющие себя в конкретных условиях.

⌘ единовременный процесс. если модель — это срез реальности, то она начнёт устаревать с момента реализации. Сама компания и её термины так же постоянно эволюционируют и меняются. Модель должна поспевать за всем.

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

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

__________________
упомянутые ссылки:
* George Mealy, Another Look at Data, 1967
* William Kent, Data and Reality, 1978
* Steve Hoberman, Data Modeling Made Simple, 2005
* Larry Burns, Data Model Storytelling, 2021
* Eric Evans, Domain Driven Design, 2003

https://medium.com/@maciej.pocwierz/how-an-empty-s3-bucket-can-make-your-aws-bill-explode-934a383cb8b1

кулстори из интернетов: как получить счёт в $1300 за первый день создания пустого приватного s3-бакета в AWS

если работаете с s3, то полезно понимать как верхнеуровнево оно работает, чтобы не получить такие сюрпизы в своём аккаунте

в качестве повода размять мозги предлагаю сделать паузу и прикинуть как так могло случиться

спойлер: нужно было всего лишь угадать правильное имя бакета! некая опенсорсная софтина имела дефолтную конфигурацию с бекапом на s3 точно с таким же именем бакета.

имена бакетов находятся в eдином глобальном неймспейсе. т.е. они уникальны по всему миру, типа как урлы доменов первого уровня

можно закрыть бакет на доступ, но by design система будет биллить вас даже за отлупленные (4хх) запросы

получается, если кто-то будет знать ваши бакеты, он легко может взорвать ваш счёт за облачные услуги. ни WAF, ни CloudFront вас не спасут =(

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

🐘 Nimble Elephant — книга про паттерны моделирования данных

в этот раз потребовалось даже меньше двух лет, чтобы прочитать купленную книгу!

почему-то ожидал, что будет больше про аналитику, но оказалось в основном про большие энтерпрайз системы на сотни сущностей. Но в целом полезно; автор — консультант с большим стажем и технической насмотренностью, а ещё пишет просто и с юмором.

⌘

понравилась идея про дата паттерны: 50% ваших моделей — можно брать готовые из сборников; 30-40% — надо чуток подкрутить. А вот оставшиеся надо будет готовить с нуля — и вот на это уже уйдёт 80% от всего отведённого времени на проектирование.

автор подробно разобрал паттерн Party/Role на примере базы данных для школы. Есть ученики, учителя и родители. В теории вроде всё несложно. На практике вылазят интересные особенности, когда у ученика количество родителей != 2; или учитель является чьим-то родителем; или у учителя нет классов активных в данный момент, но были раньше.

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

⌘

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

⌘

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

проект готовы передавать в реализацию — начинать писать, собственно, код. Уже есть готовая модель данных, на которую потратили несколько месяцев. Она включает в себя 600 сущностей О_о

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

за счёт использования паттернов удалось упростить модель с 600 до 120 сущностей. За оставшиеся 4 месяца команда из трёх синьёров (вдвоe меньше запланированной) реализовала проект по упрощённой модели. Где-то пришлось сущности генерализировать и повысить уровень абстракций, поэтому планка сложности стала выше.

простой пример силы предварительного и тщательного проектирования, а так же демонстрация сил матёрых синьёоров.

⌘

автор неоднократно упоминает, что его книга это как введение в тему паттернов. Он приводит в пример несколько из них и рассказывает несколько историй из своей консалтинговой практики о них, но отсылает как к словарю к книгам других авторов, где можно найти исчерпывающий список всех паттернов

____
несколько книг из того списка:

- The Data Model Resource Book, Vol. 3: Universal Patterns for Data Modeling by Len Silverston (Author)

- Analysis Patterns: Reusable Object Models by Martin Fowler

- Data Model Patterns: Conventions of Thought by David C. Hay

- Building the Agile Database: How to Build a Successful Application Using Agile Without Sacrificing Data Management by Larry Burns

🫧 big tech bubble

слушал подкаст с инженером из Убера, нашёл интересным несколько моментов:


§ 1

большие компании по мере свеого дикого роста сталкиваются с проблемами, с которыми до них никто не сталкивался. На рынке просто нет готовых решений для таких объёмов. И даже какие-то бест-практис ещё надо поискать, поэтому им приходится решать задачи самим.

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


§ 2

это одна из причин, почему такие инженеры ценятся на рынке — они повидали всякое: они умеют решать проблемы и работать руками.

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


§ 3

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

малый и средний бизнес не ворочает экзобайтами и им не надо выдерживать тысячи рпс — такие проблемы исключительны для того самого биг-теха.

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

👨‍🔧 разобрался с Terraform

спустя пару лет после моего первого знакомства с infrastructure-as-a-code наконец-то достался проект где можно попрактиковаться.


⌘⌘⌘

в Кларне всё на AWS, для управления архитектурой используют CloudFormation или Terraform; у нас в команде — последний.

почему вообще дата инженер занимается инфрой? в команде образовалось провал по компетенциям: есть несколько разрабов, пара аналитиков и менеджер, а вот деплоить инфру, получается, некому; сейчас приходиться закрывать техлиду на сдачу от других дел. Вызвался помочь с этим, потому что самому было интересно как это всё работает


⌘⌘⌘

за один проект удалось покопаться в разных инструментах AWS-стэка (+ DataDog для мониторинга):

- S3 — тут и сам ТФ хранит свои стейты, Афина хранит результаты запросов, а ещё там будут лежать файлы для Glue таблиц

- Glue — тут храниться мета-информация для баз и таблиц (данные которых лежат на S3)

- Lake Formation — новая тема от AWS для раздачи прав и полномочий на доступы к базам и таблицам

- Lambda функции — тут реализована логика по прекладыванию данных (плюс задаётся отдельная роль)

- CloudWatch — набор правил для запуска Лямбы с нужными параметрами

- DataDog — метрики, мониторы с алертами и дешы для мониторинга

- Secrets Ьanager — тут хранятся ключи для доступа к DadaDog


⌘⌘⌘

в результате получается такая логика:

1. готовим s3-бакеты (сразу с нужными тэгами для правильной аллокации костов)

2. в Glue создаём таблицы над бакетами — причём часть таблиц пошарена с другого аккаунта

3. через LakeFormation создаём нужные доступы, в том числе для кросс-акаунт и кросс-регион

4. Python-код для Лямбды пакуется, форматируется, валидируется и отправляет в облако как новый Layer

5. CloudWatch правило триггерит Лямбду с нужным набором параметров и та переваривает очередной кусок данных

6. на выходе у Лямбды данные и набор метрик, отправленных в DataDog

7. по этим метрикам настроены мониторы и алерты в нужный Слак-канал

и отдельно заморочился и настроил себе (и коллегам!) удобный Developer Experience — сохранил основные команды для работы с ТФ в Makefile:

- авторизация с нужной стейджинг-ролью для локальной разработки

- инит терраформа с хранением стейта в staging s3 (для централизированного доступа и хранения)

- форматирование и валдиация тф-конфига

- подготовка плана и вывод его в консоль для глазуальной проверки

- деплой на стейджинг с нужными значениями параметров


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

🤯 ChatGPT научилась смотреть, слушать и быстро отвечать

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

теперь ChatGPT совсем даже не чат, а вполне себе собеседник: добавили возможность включать камеру в приложении и попросить описать что она видит

помимо новой модели выкатили десктопное приложение, которое тоже может смотреть экран — на демонстрации моделька рассматривала простенький график, нарисованный в юпитер-ноутбуке, интерпретировала увиденное и даже отвечала на простые вопросы по содержанию.

показательно насколько снижение задержки ответа может менять восприятие. Согласитесь, что когда ассистент отвечает тебе через 2-3 секунды после вопроса, то особо диалога не построишь.

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

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

🏌️ RAG

однажды в коменты пришёл читатель Семён и пошутил что-то про RAG. Я тогда ничего не понял, но на всякий случай молча кивнул типа «да-да, я в курсе! во дают!1»

чтобы в следующий раз не попасть впросак, решил таки сделать домашку и погуглить что за зверь этот ваш раг. В интернетах нашёл красиво свёрстаное (аж захотелось купить что они там продают) и главное доступное объяснение:
https://gradient.ai/blog/rag-101-for-enterprise


⌘⌘⌘

что нужно, чтобы сделать своего чатбота на ллм? помимо самой ллм, конечно.

я так понял*, ллм из коробки будет знать много чего из общего мира, но конкретно про вашу специфику — неоч

* для экономии места я не буду перед каждым абзацем вставлять «я так понял», но представьте, что оно там есть и это будет справедливо показывать уровень моего знания о предмете

RAG — это сокращение от retrieval-augmented generation, типа генерация ответа с обогащением релевантной информацией; т.е. помимо общего знания в ллм добавляется релевантного контекста: например, вики компании.


⌘⌘⌘

плюшки:

→ добавляет свежие факты и документы, появившиеся после горизонта обучения модели

→ с дополнительным контекстом модель меньше галлюцинирует

→ косты меньше, чем у файн-тюнинга; причём как по деньгам, так и по времени и технической экспертизе


⌘⌘⌘

примеры, когда RAG будет полезен:

- чатбот сапорта: будет знать последний статус заказа и чётко расскажет про варианты доставки;

- поиск по базе знаний: например, по вики компании — что там по удалённой работе

- рекомендации: выдать самые последние статьи в соответствие с персональными характеристиками.


⌘⌘⌘

как можно улучшить ответы ллм? товарищи в статье приводят три метода:
1. prompt engineering
2. fine-tuning
3. и, собственно, RAG


prompt engineering — дёшево и сердито, низкий порог входа. Не нужны ресурсы на до-обучение.

fine-tuning — нужны ресурсы, время и корпус для до-обучения (?). Как результат более глубокие знания доменной области (например, медицина или финансы)

RAG — нужны ресурсы и специальная подготовка данных в векторной базе данных. На выходе обогащение ответов последними обновлениями и релевантным внутренним контекстом



⌘⌘⌘

чтобы RAG смог «читать» дополнительный контекст, его предварительно надо перевести в вектора (эмбединги, да?), эти вектора хранятся в специализированных базах данных.

целевой процесс обогащения сгенерированного ответа выглядит примерно так:

- (подразумевается, что уже) есть векторная база, заполненная подготовленными эмбедингами

- запрос пользователя переводится в вектора и в векторной базе ищутся семантически похожие данные

- эти релевантные данные добавляются в исходный запрос как дополнительный контекст

- на основе запроса и контекста генерируется ответ пользователю


если вы дошли до этого уровня то вряд ли читаете советы любителей в интернетах, в конце статьи приводятся продвинутые шаги для дальнейшей оптимизацией (прямо перед предложением купить что-то под названием gradient cloud)


⌘⌘⌘

буду рад, если покажете где я наврал — век учись!

что меня привлекло в подходе: среди всех приведённых вариантов допиливания моделей RAG выглядит как чисто дата-инженерская задача.

получается, надо взять какие-то данные, как-то их трансформировать, где-то похранить и потом предоставить для удобного пользования. И, естественно, нужно как можно чаще, по́лно и без ошибок! Ничего не напоминает?)

🗿 этому каналу не хватало лица!

вы могли заметить, что тут помимо сухих ссылок стало больше появляться всяких «что вижу вокруг», «что про это думаю» и «помогите разобраться дурачку»

не хочу делать из канала сми с контент-планом и заданным количеством постов в неделю, поэтому планирую дальше вести в духе дружеского чатика по интересам.

как и любой подобный чатик, канал может затихнуть на месяц, а потом начать выдавать по посту-два в день ¯\_(ツ)_/¯

кажется чуток странным вести в таком духе анонимный канал (там правда подписано, но официально-то мы друг другу не представлены!)

в общем вот:

👋 я — Саша Михайлов: муж, отец, латентный рационалист, иногда сноубордист и любитель поиграть по воскресениям в доту. В октябре 2023 переехал в Стокгольм 🇸🇪 и работаю инженером данных в местном финтехе Klarna


§ про работу

собственно, те самые data будни!

⌘ до 30 лет работал менеджером по логистике — следил, чтобы контейнеры из Китая и фуры из Европы исправно привозили нужные товары.

→ потом отучился на аналитика данных в Практикуме (в самой первой когорте, хе-хе), после него два месяца искал первую работу по новому профилю.

⌘ работу нашёл в отделе маркетинга торгового центра — спасибо ребятам за доверие! помню, как пришёл к ним готовый анализировать их данные с пандасом наперевес… а данных-то и не было! их мне как раз и предстояло собрать >_>

→ поскольку там я был единственным дата-инженером, приходилось собирать советы по чатикам <3 и сильно помог вводный курс по ДЕ от Димы Аношина

⌘ после того как чуток освоился на работе и насмотрелся курсов, нашёл вторую — уже более айтишную — работу в консалтинге Epoch8. Там помогал разворачивать облачные двх для клиентов. Узнал как правильно это всё делать: разворачивать инфру, раскладывать данные по слоям, вот это всё.

→ тем временем продолжал учиться и закончил курс Практикума по бэкенд-разработке на Питоне: подтянул программирование на примере веб-приложения на джанго.

⌘ там ↑ заботал алгосики и смог пройти все ступени собесов в Яндекс (приходил в общее ДВХ Такси, но почти сразу нас отделили в ДВХ Доставки). В составе лихой дата-бригады обслуживать ДВХ на всю компанию.

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

⌘ одна из нескольких ниточек привела к офферу в шведский финтех и мы с супругой решили попробовать пожить-поработать в другой стране

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


§ фан-факты обо мне

✓ до того как податься в айти, думал стать дизайнером

✓ спарсил сайт из гугл-таблиц, чтобы сделать красивый чек-лист с треком личного прогресса

✓ чтобы стать дата-инженером, я учился на дата-аналитика (а целился вообще в дата-саенс!)

✓ опознал человека по данным с его фитнес-трекера

✓ помог Роме Бунину достать данные из движка блога, чтобы он сделал клёвый виз

✓ приходил гостем в подкаст Data Heroes

✓ после переезда в Стокгольм, спарсил емейлы детских садов нашего района и отранжировал их по дальности от дома, чтобы записать сына в ближайший детский сад

✓ моё лицо висит на главной Практикума

✓ у меня есть тату, разработанная нейросетью


а в комментах открою один страшный блоггерский секрет!

🎠 астрологи объявили неделю ии

поэтому вот три ссылки в тему; ссылки получились по возрастающему уровню сложности — можно найти на свой вкус


I. подкаст «вы находитесь здесь»

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

всё разбито на идеальные серии по ~25 минут — удобно слушать в дороге или на обеде. Каждая серия раскрывает свою тему. Рекомендую.

https://libolibo.ru/nowyouarehere


II. выпуск Подлодки про приложения на ллм

интересный гость с кучей релевантного опыта и чётким, структурированным рассказом — помогло связать в голове разные кусочки в единую картину.

вот все жалуются, что сети иногда галлюцинируют; на самом деле это не так — сети галлюцинируют 100% времени. Это суть их работы — придумывать ответ, которого до этого не было.

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

это сильно отличается от того как привыкли работать с инструментами разработчики. Чтобы исправить нежелательное поведение модели, нужно менять не саму модель, а её обучающую выборку — на каждый кейс добавить правильных примеров и перезапустить обучение.

как правильно замечает гость, самое сложно в работе с ллм — задать нужный вопрос, т.е. найти применение этому инструменту (я примерно здесь!)

прошлись по методам промпт-инжиниринга — как можно быстро улучшить выдачу от нейросети:

→ базовый метод — жать кнопку «ответить снова» пока ответ не будет устраивать; вполне рабочий вариант для старта, рано или поздно сеть может догаллюционировать до приемлемого ответа

→ ещё сильно помогает добавить к вопросу пример ожидаемого ответа; никто не знает, почему это работает, но кажется это подксказывает сети в какой области собственных знаний найти подходящий ответ

→ если попросить сеть рассуждать по шагам, то вероятность промежуточной ошибки снижается

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

→ langchain — если ответ сети отправить на проверку другой сети, это тоже снизит вероятность явного бреда (на бинарные вопросы сеть отвечает с бо́льшим успехом)

https://www.tgoop.com/podlodkanews/1313


III. большой обзор подходов к промпт-инжинирингу

Seattle Data Guy ретвитнул рестакнул большую статью. Я прочитал где-то треть и мозг уже вспух. Похоже на научный пейпер: рассмотрены все подходы к улучшению ответов ллм, всё по порядку и по полочкам. И на некоторые топики есть отдельные лонгриды.

в целом, список тем такой же как в подкасте Подлодки — можно либо слушать, либо читать

https://substack.com/home/post/p-143156742

😱 забанили в LinkedIn

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

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

однажды, зайдя в линкедин, я увидел просьбу подтвердить свою личность. Прислав им в форму скан паспорта (О_о), они обещали ответить в ближайшее время. Спустя сколько-то дней пришло письмо, что «ваш аккаунт заблокирован по причине нарушений правил»

от неожиданность я растерялся, но всё же попросил их уточнить что за правила и постарался убедить, что никаких правил я не нарушал (по крайней мере сознательно). Потом подумал, что наверное так говорит каждый: даже тот, кто нарушал — вряд ли те приходят с повинной.

через 14 дней получил сухую копипасту в ответ, что мол конкретные причины мы не называем, т.к. это может быть использовано во зло. так что адьос!

⌘⌘⌘

интересная особенность бана в линкедине, что (видимо) он относиться не к аккаунту, а к персоне. по крайней мере, у меня сложилось такое впечатление — первым делом я зарегал акк на другую почту. Заполнил профиль и историю работ.

на следующий день этот новый акк забанили по той же схеме.

тогда я попробовал зарегать следующий. Уже с новым телефоном. Бан на следующий день. Новый акк с рабочей почты — тоже бан. Когда появился шведская симка я сделал ещё одну попытку, но результат остался тем же.

⌘⌘⌘

понятно, что по ту стороны коммерческая организация, которая вправе придумывать любые правила пользования своими услугами; и, регистрируясь, мы все жмём галочку и «подписываем» этот контракт.

где-то в интернетах видел, что соцсети предлагали обязать предоставлять доступ к своим услугам безусловно всем желающим. Мол, допишем после права на свободу выбора ещё одно строчку — условно «право на фейсбук». В текущей ситуации я понимаю тех кто это придумал: если без доступа к тому же фейсбуку ещё можно прожить, то как искать новую работу без линкедина?

как бы теперь Кларна не оказалась моим последним местом работы >_>

🍅 middle →→→ senior

https://seattledataguy.substack.com/p/how-to-grow-from-mid-level-to-senior

y Seattle Data Guy гостевой пост про то с какой стороны подходить к прыжку от мидла к синьору. Резонирует с тем что я вижу вокруг и как представляю свой путь в сторону помидорства


⌘⌘⌘

в первую очередь от синьора ожидают, что он автономно решает проблемы — от предложения рабочего решения до его имплементации, включая переговоры (!) с нужными сторонами и развитие коллег

✓ непрекращающееся развитие — всегда готов научиться чему-то новому и рассказать об интересном

✓ действительно крутые штуки делаются вместе, поэтому развитие команды — ключевая необходимость

→ направления на подумать: вдумчивые и развивающие код-ревью, парное программирование и другие сессии обмена опытом; улучшение процесса онбординга


⌘⌘⌘

работать над действительно важными для компании штуками: ведь неважно сколько кафок с куберами задействовано, если пользователей — ноль

→ направления на подумать: интересоваться целями компании, смотреть вширь от проекта: апстрим и даунстрим


⌘⌘⌘

овнершип и ответственность. Увидел проблему — взял и решил. Не скидывать ответственность на других.

→ направления на подумать: оставлять поляну после себя чуть лучше, чем была до; планомерная работа над документацией проекта; помогаешь преодолевать блоки у задачи


⌘⌘⌘

да! и не забыть рассказать тимлиду про свои хотелки, составить и провалидировать конкретный план с явными сроками; а после — не забыть задокументировать результаты своей бурной деятельность

→ направления на подумать: вести список достижений и сделанных задач, брать инициативу на 1:1 встречах с лидом, искать самые больные места и предлагать решения

😱 етл-таски в очереди по ~23 часа

в Яндекс Го была довольно стандартная (да ведь?) дата-архитектура: были дата-лейк на YT и DWH на Greenplum. Вначале все данные попадали в лейк, там как-то предобрабатывалось и потом можно было залить в GP для всяких там джойнов и прочих оптимальных доступов.

Два наблюдения:

- между YT и GP случались заторы — данные туда-сюда заливались немаленькие и задача перекладывания джейсонов между базами довольно нетривиальная

- одного не самого инженера могло быть достаточно, чтобы сделать GP плохо ( :wave: ) — как-то ко мне пришёл наш ДБА и попросил засунуть в остановить свой запрос и немного его оптимизировать перед следующим запуском

⌘⌘⌘


Проблема, видимо, распространённая, так как в Кларне схожая картина: есть лейк на S3/Athena и DWH в Redshift. По умолчанию все данные заливаются в Редшифт и там уже обрабатываются.

Дата платформа хотела как лучше и сделала удобный фреймоврк по клепанию Airflow-тасков: нужно всего лишь написать sql-файлики и добавить их в yaml по нужной форме. Вуаля! и ваш даг уже задеплоен Дженкинсом в коммунальный Airflow.

Фреймворк получися удобным и всё больше дата-инженеров и аналитиков стали добавлять свои тасочки. В начале задержек не было, потом очередь стала больше и свободные слоты в пуле Редшифта заполнились.

Начались очереди на запуск тасков — квадратик таска в Airflow никак не хочет становиться ярко-зелёным, хотя ДАГ запущен.

Задержки в очереди всё росли и росли; и к текущему моменту нельзя с точностью сказать когда запуститься твой таск. При кроне в 7 утра он может начать работать в 10, 18 или даже завтра! О новый дивный мир!

⌘⌘⌘


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

Но, видимо, в какой-то момент что-то пошло не так. Коммунальное и доступное привело к ситуациям, когда дата-саентист жалуется в поддержке, что его запрос выдаёт ошибку. Начинают разбираться и оказывается что он пытается скопировать к себе во временную таблицу все заказы за пять лет — и не просто инкрементально, а через drop-create каждый раз!

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

⌘⌘⌘


у команды платформы тоже не хватет рук на всё: несколько человек не могут уследить за поделками тысячи! при этом предмодерация каждой джобы здесь тоже не сработает — сломается демократизация и тот самый селф-сервис, куда все так стремятся.

и сейчас всеми силами пытаются исправить это бутылочное горлышко в виде Редшифта и перевести таски на Афину или Спарк с выделенным компьютом.

ещё из альтернативных предложений — каждая команда может заказать себе выделенный кластер Redshift Serverless. Всё то же самое, только ваше собственное: ни с кем делиться не надо и локтями толкаться в очереди не придётся.