🤓 испытательный срок — тю!

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

понял, насколько спокойно было в России — кажется, чтобы тебя уволили надо очень сильно постараться. Особенно в нашей уютной айтишечке.

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

⌘ на второй неделе моего пребывания местный профсоюз предупредил компанию о забастовке — они хотели подписать коллективный трудовой договор. Последний раз про забастовки я слышал из телевизора ещё при Ельцине. А тут это как бы обычный инструмент профсоюзов.

⌘ через месяц НЕ полетел в Лондон на офсайт сходку нашего департамента — не успели сделать вовремя визы, хотя билеты и отель был уже заказан. Почувствовал (виртуально) размах активностей компании. Ну и виза осталась >_>

⌘ перед новым годом наш департамент расформировали (не говорите супруге!) — помню как прямо на встрече после объявления кинулся смотреть внутренние вакансии. Нашему отделу повезло, мы целиком перешли в другой департамент. Хорошо когда отдел напрямую генерирует прибыль (я говорил, что попал в команду аффилированного трафика?) Другие коллеги отправились во внутренний competence pool в поисках подходящих вакансий в других департаментах компании.

⌘ где-то в этот же момент в Спотифае буквально через дорогу сократили 1500 человек. Поэтому было довольно тревожно. С одной стороны, в Кларне «прямых» сокращений не было (в этот раз), но с другой — меня-то и сокращать не надо было, можно было бы просто не продлить рабочий контракт.

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

⌘ сходил на митап Coachbasе в местном офисе Google. Послушал про базы два-в-одном — как они с одной стороны держат транзакционную нагрузку, а с другой не боятся сотен аналитиков с их select *

⌘ слетали семьей в Милан за €100 на человека (спасибо Ryanair). И город посмотрел, и поработал там из местного офиса. Развиртуализировался с коллегой. Плюсы большой компании и распределённой команды. На очереди Берлин и Бухарест.

⌘ помимо отменённых самолётов в Россию ещё закрыли сухопутную границу между Питером и Хельсинки, так что и без того весёлый трёх-сегментный маршрут домой превратился в четырёх-сегментный: Стокгольм → Хельсинки → Таллин → Питер → Москва. Удивлял коллег на стендапах вступлением «из какой страны выхожу на связь в этот раз».

⌘ залетел перед работой на дата-завтрак от Snowflake с участием dbt labs. Я думал, что и те, и другие дальше штатов не заглядывают, а оказывается у них тут есть офис и люди. Правда, судя по вакансиям, только сейлзы =) Послушал как Эриксон строит универсальный датамеш (уже как год). Мне конечно до таких масштабов далеко, поэтому просто довольствуюсь кружкой и блокнотом со снежинкой ❄️

📓 Infrastructure as a Code

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

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

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

осталось поднять Airflow, который, собственно, и будет всё раскладывать по слоям, а ещё Metabase, где будут жить все дашборды.

я долго смотрел на этот космолёт приборную панель управления облачными ресурсами: столько там всяких разделов что сложно понять с чего начинать. В итоге как-то нашёл docker registry с понял куда пихать ссылки на docker hub из соответствующих туториалов.

где-то там же осознал, что Airflow и Metabase надо где-то хранить свои данные типа юзеров и истории, а значит помимо общего хранилища им ещё понадобится и своя отдельная постгря

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

я был дико горд собой. не иначе как «Ты девопс, Гарри!». Всё-таки первый проект в облаке, это вам не в тапки это самое

показываю Андрею — нашему основателю и по совместительству техдиру. Он посмотрел так скептически. Допустим, говорит, красивый урл для админки вместо циферок айпи мы настроим, ок. Но вот зачем тебе три медиум инстанса ЕС2 для одного метабейза с полутора пользователями? но ладно, можно скейлнуть вниз — не проблема. В целом годиться для начала! Показывай теперь, говорит, свои Helm чарты, посмотрим что там как.

Так я узнал про подход infrastructure as a code.

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

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

с кодом же всё чётко: каждое обновление — пулл реквест. Явно видно предлагаемые изменения. Легко встраивается в CI/CD пайплайны. Раскатывается на одну или тысячи машин — неважно.

🐭 постоянство в достижениях

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

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

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

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

При этом для него просто поднимается дефолтная планка качества работы — он не выжимает из себя 146% эффективности, он просто «бежит в комфортном для себя темпе» и дыхание не сбивается.

Для него приготовить божественный рататуй — это ежедневная рутина, а не достижение.

открываю для себя семейство продуктов Kinesis от AWS. Всё вместе оно решает дата-стриминговые задачи, но чисто по названиям не понять чем Streams отличаются от Analytics и зачем там ещё Firehose.

посмотрев три обзора на ютубе, ответственно заявляю вот что я узнал:

🟣 Kinesis Streams — типа топиков Кафки. Можно несколько консьюмеров на топик, есть ретеншен полиси для записей внутри — т.е. чтение на консьюмере управляется офсетом.

🟣 Kinesis Firehose — по сути коннектор, можно туда паблишить евенты и оно из коробки может писать во все основные тулзы AWS. Нельзя много консьюмеров.

🟣 Kinesis Analytics — под капотом это Managed Flink (почему нельзя было так назвать сразу?). Умеет в разные стрим-трансформации: джойнить потоки, анализировать налету, работать с разными окнами.

к Streams и Firehose можно присобачить Лямбду на обработку входящих событий — на каждое событие или батч будет инициироваться инстанс функции и выполняться её код.

и следом ютуб-фид мне выдал релевантный доклад с AWS re:Invent «как не терять данные в стриминге»

Рассказывает AWS Hero из консалтинга, т.е. она насмотрелась за свою карьеру на разные aws-архитектуры.

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

⌘⌘⌘

кейс начинается с того, что при простом паблише и консьюме из Kinesis Streams они заметили недостачу данных. И дальше по цепочке разбирали кейсы, которые они обнаружили (вместе с поддержкой aws)

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

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

у Streams единица параллелизации — шард. Хотя AWS называет это serverless, но по сути провизией мощностей надо заниматься самоу. Скейлить вниз и вверх в зависимости от текущей нагрузки, чтобы не попасть не попасть на тротлинг, но и не переплатить за лишнее.

из streams события консьюмит лямбда. По умолчанию 1 шард = 1 конкурентный запуск лямбды. Если включить event source mapping, то можно увеличить фактор параллелизации до 10 одновременно запущенных лямбд на каждый шард.

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


выводы

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

🟣 настроить ретраи — exponential backoff + jitter, чтобы распределять нагрузку в случае проблем

🟣 добавить кастомные метрики на тротлинг в cloudwatch, чтобы не пропустить логи с ошибками

🟣 настроить ESM для Лямдб, чтобы распрараллелить обработку событий


и всё то же самое в виде статьи с примерами кода

🛫 визуализация полётов на Кликхаусе 🛬

Алексей Миловидов собрал красивый демо-проект, чтобы показать как Кликхас могёт ворочать миллиарды записей (это в день).

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

всё работает на чистом html поверх кликхауса в их облаке. В статье подробный рассказ что под капотом: js-функции, ddl таблиц и вьюх, sql-запросы с сайта.


Статья https://clickhouse.com/blog/interactive-visualization-analytics-adsb-flight-data-with-clickhouse

Сайт https://adsb.exposed/

Исходники https://github.com/ClickHouse/adsb.exposed

Источники данных:
1. https://www.adsb.lol/
2. https://www.adsbexchange.com/products/historical-data/

🏆 что мне нравится в проекте с авиа-трейсами adsb.exposed

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


⌘ во-первых, как увлечённый дата-инженер я радуюсь каждому проекту, где-то как-то вовлечены данные и потом с ними происходит что-то интересное. Всегда хотел замутить что-то своё, но всё никак не нашёл подходящего повода и времени (а вот фаундер международной компании таки нашёл, хе-хе!)


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

если я правильно понял, мой веб-бразузер напрямую ходит в облачный КХ и тянет данные налету — даже сами запросы прозрачны (ещё и с динамическим прогрессбаром)

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


→→→ итого получается, что у этого решения-как-продукта всё продумано:

× простым юзерам сходу показывает красивые картинки

× продвинутые же юзеры имеют прямой доступ к запросом и могут подхачить их под своё усмотрение

× ну и социальный фактор — своим кастомным результатом можно легко поделиться.


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


UPD: я уже переслал этот вопрос по всем своим дата-чатикам, но закину и тут. Как вам Extract на чистом баше, а? и потом такой же лаконичный Transform & Load уже на SQL с чтением джейсона

📚 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. по этим метрикам настроены мониторы и алерты в нужный Слак-канал