data будни

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 вас не спасут =(

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

📚 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

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

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


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


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

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

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


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

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

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

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


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


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

примеры того что получается в итоге

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

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

Получилось похоже на 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/

и следом ютуб-фид мне выдал релевантный доклад с 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 для Лямдб, чтобы распрараллелить обработку событий


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

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

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

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

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

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

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

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

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

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

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

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

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

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

📓 Infrastructure as a Code

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

первая неделя с CoPilot

тут в нашей Кларне держат фокус на AI. Может где-то и перегибают в горячке, но тем не менее всем разработчикам оплатили лицензию на CoPilot и неустанно напоминают её активировать и установить плагин свой IDE.

последнюю неделю дорвался наконец до питонячего кода и таки активировал-установил копайлот в свою Идею. Делюсь ощущениями по итогам первой недели с аи-помошником. Наверняка тут есть прожженные промпт-инженеры и гпт-мастера — не судите строго (а лучше приходите в комменты!)


+++

мне понравилось как копайлот справляется с питоном и конфигами терраформа: предлагает дополнения исходя из контекста файла и непосредственного окружения.

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

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

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

− − −

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


⌘⌘⌘

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

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

вывод:
- можно писать код на незнакомом языке (мама, я — фулстек!)

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

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


⌘⌘⌘

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

при этом аналитик говорит что «не знает питон»


⌘⌘⌘

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

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


⌘⌘⌘

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


⌘⌘⌘

в целом, выглядит как ещё один инструмент в наборе: python, sql, chatgpt …

а чо у вас по копайлотам по работе? применяете? полезно?

🎧 Father of «DataWarehouse»

продолжая копать под этого Joe Ries, нашёл у него подкаст. Полистая прошлые эпизоды, нашёл там никого иного как Билла наше-всё Инмона. Оказывается Билл его менторит (вот это размах!).

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

первую программу Билл написал в 1965, за свою карьеру успел пописать на ассемблере, паскале и коболе. Застал программирование на перфокартах; когда несёшь стопку таких карт к «компьютеру», то главное их не рассыпать — иначе придётся вручную восстанавливать и проверять их порядок >_<

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

Когда Билл читал свои первые лекции про «новый инструмент для аналитики — DWH», первые 3-4 года его слушателями были исключительно маркетологи, и никого из технических профессий.

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

тогда топовой компанией была IBM (которая продавала свои мейнфреймы по 2-3 миллиона при себестоимости в $165), и они там были настолько против этого вашего OLAP, что просили не упоминать в одном предложении OLAP и IBM.

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

и вот когда первая компания сделала у себя DWH, это дало такой прирост эффективности их аналитиков, что по отрасли пошли слухи о «новом секретном инструменте — DWH»; и сразу все захотели к себе такое же и на лекциях Билла стали появляться технари.


#подкаст в Apple Podcasts и Overcast

Data Modeling is Dead! Long Live Data Modeling!

https://youtu.be/OCClTPOEe5s

увидел у Семёна ссылку на рассылку про моделирование данных от Joe Reis, автора Fundamentals of Data Engineering — книги, которая вроде как пробилась в топы Амазона сразу по нескольким категориям.

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

В целом, от доклада сложилось впечатление «дед ворчит на облако», но кажется смысл сводиться, что мы стали забывать что такое модели данных и в принципе забивать на этот этап. Остаётся только поверить его обширному кругу общения — у него своё консалтинговое агентство, он много катается по миру с докладами, поэтому повидал и услышал всякое там; и даже сам Andrew Ng пригласил делать его делать курс вместе.

Автор приводит две книги по моделированию данных, с которыми стоит познакомиться. Мне тема близка и актуальна по работе, поэтому вторую книгу я уже заказал — посмотрим что там к чему (правда, тот же Кабанчик у меня лежал года полтора прежде чем я его прочитал с книжным клубом >_> )

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

🏦 Klarna — куда я попал

если коротко, то Klarna — это сервис отложенных платежей, т.н. BNPL — buy now, pay later (or never lol). Самоидентифицируют себя как банк, что ведёт за собой дополнительное регулирование. Начинали из Швеции, постепенно вышли в некоторые страны Европы и потом ещё в Штаты.


📍команда

из Штатов, кстати, наши тимлид и архитектор. Поэтому дейлики у нас в середине дня (но при этом Уэса всегда можно приветствовать «доброе утро!» :-)

остальная команда тоже довольно мультинациональная и распределённая: Германия, Румыния, Италия и, собственно, Швеция.

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


📍спектр задач

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

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

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

я не так часто собеседуюсь и ещё реже меняю работы, поэтому ещё не накачал умение задавать правильные вопросы на этапе знакомства и выбора команды; иначе бы я вряд ли решился пойти в команду разработки микросервиса единственным дата-инженером :-D


📍 техностек

в основном всё работает на AWS — данные с источников заливаются в S3, откуда их можно селектить через Athena. Или заливать дальше в Redshift.

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

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

DataHub в качестве дата-каталога.

на оркестрации централизованный Airflow. Даги генерятся из ямликов через воркеры на Jenkins. Из коробки умеет делать SQL в тех же Athena и Redshift, плюс джобы на AWS Glue.

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


📍 дата-архитектура

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

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

у нас в команде есть только «теневой» двх :-D чисто собрали витринки на своих таблицах. У каждого аналитика — свои. При этом свежесть данных по некоторым источникам — до пяти дней. Что-то неладное в датском королевстве. Будем разбираться.

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

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

Kafka is dead, long live Kafka

https://www.warpstream.com/blog/kafka-is-dead-long-live-kafka

два выходца из Datadog накидывают на Кафку. Ну, точнее не на саму Кафку, а на окружение, в котором крутятся современные инсталляции.

дисклеймер: сам я Кафку не варил, шарды не перебалансировал и патриции не восстанавливал; но кажется я понимаю спектр проблем, на которые указывают авторы, и мне в целом нравится что они ставят под вопрос дефолтное решение. И было интересно для общего кругозора прочитать что там их не устраивает и как же сделать лучше (по законам жанра в конце статьи [коммерческое] предложение).

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

Базовых проблем две:
- большие потоки данных между внутренними узлами
- много ручного труда для поддержки и развития

Изначально Кафка крутилась в датацентрах Линкедина, где внутренний трафик не тарифицировался. Текущие реализации работают в основном в облаках, где это стоит денег. Помимо прямого трафика, есть ещё внутренняя репликация в целях отказоустойчивости.

понравился кусочек про Accidental SRE; мол, вот в чём приходится разбираться, если решил завести себе Кафку:

1. Kafka (brokers, coordinators, watermarks, etc)
2. ZooKeeper (or KRaft)
3. Leader elections
4. Partitions (how many partitions do I need? Unclear, but better get it right because you can never change it!)
5. Consumer groups
6. Rebalancing
7. Broker tuning
8. Client tuning
9. etc

оставлю тут гифку из официального блога телеграма как найти эти Similar Channels

(в комментах подсказывают, что на Андроид и в веб версии пока не раскатили)