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

Сейчас многие болеют. И мне хочется чтоб все болели правильно

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

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

🌿 Резервной копии себя нет. Кажется, что мир рухнет, если ваш отдел не выполнит какие-то сверхважные планы. Но на деле этот мир рухнет только если вы отъедете в мир иной.

🌿 Чтоб себя успокоить вспомните про bus-factor. Если в вашей компании не закрыт риск, что вас(или любого другого участника команды) может сбить автобус, значит таково решение руководства. Надо позволить руководству вкусить последствия решения, а не прекрывать их собой и своим здоровьем.

🌿 Ну и последний аргумент социальный. Хватит делать вид, что это нормально работать на больничном или работать сверхурочно, если вы на это не подписывались. Это всё нормализация какой-то фигни, которая вредит всем, кто за ней наблюдает.
У вас в компании стажер? Он будет уверен, что так и надо делать. Руководитель тоже легко перестанет считать это подвигом и начнет считать нормой, что все должны работать в любом состоянии.
Не надо так с собой. И не надо так с другими.

Ну и будьте здоровы🧡

🦆 Zero ETL?

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

Помимо репликации в бекап, данные так же могут около рейалтайм заливаться в «аналитический кластер». Типа рядом с OLTP кластером разворачиваешь такой же OLAP и пускаешь туда орду аналитиков, чтобы они делали свои SELECT * за всю историю. Заверяют, что это работает ого-го.

Плюс к тому, если я правильно понял спикера, то в репликацию между кластерами можно вставить кастомную js-функцию, которая будет налету преобразовывать схему из операционной в аналитическую (сразу делать тебе дата-волт, а?)

типа одна база to rule them all. С одной стороны у вас приложеньки и АПИ, а с другой — МПП и аналитика. Звучит как магия.

Кажется, что-то типа этого https://docs.couchbase.com/server/current/learn/architecture-overview.html

> The Analytics Service helps analyze JSON data in Couchbase in real time, without the need to extract, transform, and load (ETL) the underlying operational data into a separate system.

⌘⌘⌘

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

⌘⌘⌘

И сегодня вижу анонс от AWS, где они бьют в то же место:

> Within seconds of transactional data being written into Amazon Aurora, zero-ETL seamlessly makes the data available in Amazon Redshift, eliminating the need to build and maintain complex data pipelines that perform extract, transform, and load (ETL) operations.

https://aws.amazon.com/rds/aurora/zero-etl/

типа мы вам сам переложим ваши данные из вашего (нашего) MySQL/PostreSQL в замечательный Redshift.

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

🤔 Чего не хватает в Zero ETL?

разминаю мозги, пытаясь понять для чего этот их zero-etl ↑ будет хорош, а для чего не очень.

+

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

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

в целом, похоже на ещё один инструмент в ящике дата-инженера.


-

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

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

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

Ещё в голову приходит бекфил: вдруг настолько повезло, что захочется перезалить данные с источника ещё раз. Эт как тут?

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

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

Телеграм — настоящая соцсеть

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

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

соответственно, чтобы канал рос, нужно чтобы его репостили

вокруг выросла целая индустрия «давайте включим ваш канал в подборку» или более креативные и интересные стратегии типа «перестрелки»

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

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

я посмотрел для @data_days и надо сказать, что с компанией мне крайне повезло — все замечательные как на подбор. Сначала подумал, с нашей темой всё было довольно просто: достаточно пройтись регуляркой по названию и выделить всё со словом data 🤣 но судя по каналам других тематик, там под капотом всё-таки что-то сложнее

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

призываю затестить на всех своих каналах и поискать похожие

ну вы поняли, @data_days

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

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

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

🏦 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 чисто собрали витринки на своих таблицах. У каждого аналитика — свои. При этом свежесть данных по некоторым источникам — до пяти дней. Что-то неладное в датском королевстве. Будем разбираться.

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

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

Data Modeling is Dead! Long Live Data Modeling!

https://youtu.be/OCClTPOEe5s

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

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

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

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

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

🎧 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

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

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

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


+++

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

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

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

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

− − −

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


⌘⌘⌘

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

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

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

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

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


⌘⌘⌘

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

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


⌘⌘⌘

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

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


⌘⌘⌘

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


⌘⌘⌘

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

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

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

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

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

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

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

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

⌘ перед новым годом наш департамент расформировали (не говорите супруге!) — помню как прямо на встрече после объявления кинулся смотреть внутренние вакансии. Нашему отделу повезло, мы целиком перешли в другой департамент. Хорошо когда отдел напрямую генерирует прибыль (я говорил, что попал в команду аффилированного трафика?) Другие коллеги отправились во внутренний 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/