там завтра наши хэды из платформы данных будут рассказывать как ворочать петабайтами в YTsaurus (он же Ыть, он же а-ля Хадуп)

https://news.1rj.ru/str/ytsaurus_ru/2869

🤓️️Практикум: английский для разработчиков

Спустя 6 месяцев закончил курс, куда записался на панике сразу после мобилизации. На самом деле записался сразу на два английских от Практикума: общий и для разработчиков.

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

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

⌘ Процесс

В самом начале был небольшой скрининг, проверяли мой английский (видимо, что я смогу общаться с преподом без русского)

А дальше занятия 1-1 по зуму. Преподаватель шарит экран с уроками из Ноушена и мы вместе проходим. Там на понимание, на чтение и много на пересказ и прочие болталки.

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

Каждое 8-е занятие идёт с носителем. За время обучения у меня были разные ребята из Милана, Австралии, Турции, США и Сингапура. У них был разный уровень английского — двое точно не нейтивы. Но в целом норм, они типа те самые айтишники, об которых можно потренироваться: отработать поведенческие и технические интервью.

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

полгода назад было два курса: для разработчиков и аналитиков. Сейчас вижу добавили третий (и расширили старые):
1. для разработчиков и QA
2. для продактов и прожектов
3. для аналитиков и DS

https://practicum.yandex.ru/english/english_for_career-1/

ClickHouse: стриминг для бедных

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

смысл простой: из брокера сообщений инсёртим данные в КХ и там через материализованные представления раскладываем их в одну широкую денормализованную витрину.

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

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

1. колоночное хранение
2. движки таблиц семейства MergeTree
3. матвьюхи, работающие по принципу стриминга

1/ колоночное хранение

данные в таблицах базы — это файлы на диске (довольно очевидно, но до меня это дошло только когда читал Кабанчика)

Когда в одном файле лежат полные строки, то в них могут быть нуллы, т.е. лишняя информация. Если хранение повернуть на 90° и хранить в файлах колонки, то там ничего лишнего не будет; а дополнительно получаешь плюшки в виде более эффективного сжатия и аналитических запросов.

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

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


2/ таблицы MergeTree

ещё в Кабанчике читал про разницу между разными методами хранения данных в базе данных: B-Tree и LSM Tree.

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

Log-Structered Merge (LSM) Tree же наоборот оптимизирует запись. Все входящий байтики пишутся тупо в конец последнего файла. Это очень быстро для записи.

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

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


3/ «стриминг» матвью

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

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

напоминает триггеры из других баз — типа на каждый инсерт в таблицу Т1 делаем набор действий с таблицами Т2..Т99.

И тут история делает полный круг — на первом своём проекте по дох-строению я сделал условный ЕТЛ на триггерах внутри Постгрес (про Эйрфлоу я тогда ещё не знал =). Как прототип это работало, но развивать и поддерживать это было сложно.

В самом КХ это поддерживать тоже трудновато, надо запросы и DDL выносить куда-то во вне. Но по крайней мере оно всё работает на продавшен объёмах и не загибается; подозреваю, что благодаря пунктам 1. и 2. (и техническому гению Алексея Миловидова и команды КХ)

#послушано


🎧 Rework: AI! GPT! What a time to be alive!

речи фаундеров 37 Signals просто как бальзам на мою fomo-душу!

Для тех, кто переживает, что «поезд AI ушёл» и его уже не догнать, ребята предлагают взглянуть с другой стороны: в этой отрасли настолько быстро всё меняется, что период полураспада навыков — 48 часов!

Если вы были мастером по MidJourney версии 3, то в пятой версии уже всё поменялось и буквально надо вкатываться заново. Поэтому можно смело начинать вкатываться с версии 5 (или 10!) — и все будут примерно на том же уровне.

Главный совет от ребят — Have fun!

Apple Podcasts


🎧 Moscow Python: Пайтон в мире анализа данных

Мой бывший СТО из агентства Epoch8 — Андрей Татаринов — заглянул в подкаст Moscow Python рассказать про использование Python для анализа данных и ML.

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

Интересно было про ускорение работы Python за счёт переноса куска вычислений на Rust. Получилось быстро и удивительно мало итераций до работающего прототипа.

Общий совет — в начале писать наивную реализацию на Пайтон как быстрый прототип. И потом когда какие-то места упираются в производительность (problems nice to have) — точечно оптимизировать. А не наоборот =)

Всегда приятно послушать хорошо структурированные рассуждения Андрея и анекдоты из его опыта.


Apple Podcasts

YouTube (c таймингами!)


🎧 Проветримся: Системное мышление (из 2020)

к следующая книга в нашем книжном клубе будет «Системное мышление» Левенчука; в качестве подготовки переслушал эпизод подкаста с автором из 2020. Делюсь заметками:


- Удачный полёт на Марс с первой попытки как результат науки «системная инженерии».

- pretrain + finetune: чтобы поставить обучение танцам, можно прокачать «танцевальное мышление», понять куда смотреть — и тогда новый танец можно будет выучить за 2 часа, а не за дни-недели.

- «машинка с типами» — уметь мыслить абстракциями и моделями. Проверка через простой вопрос «Лидер — это роль. Какие роли у лидера?»

- утверждение, что «у стада коров есть хвост» валидно с точки зрения математики (через вхождение в подмножество), но невалидно с точки зрения систем, потому что оперирует разными уровнями систем.

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

- программирование как подобласть системной инженерии (утверждено NASA в 1968)

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

ссылки на платформы и сам файл с записью в канале подкаста
https://news.1rj.ru/str/progulka/128

Нет правильных решений

в школе было просто: тебе дают пример, ты что-то там решаешь на листочке и выдаёшь ответ — «42!». И сссразу получаешь обратную связь «правильно / неправильно».

дальше всё получается сложнее.

возьмём кластер Кликхауса, которому плоховато от нагрузки. Что с этим можно сделать? можно добавить ещё хостов, можно апнуть текущие хосты, можно добавить шардирование.

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

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

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

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

просто продолжаешь наблюдать растущую нагрузку и как предыдущие решения на неё влияют. Оп! — один хост ушёл в maintenance, как система держится? CPU на живых машинах ушло в полочку на 100%, но лаг по данным не растёт. Уже неплохо! Если бы не предыдущие оптимизациия, было бы точно хуже.

нет «правильных» решений — есть только более оптимальные в текущем контексте.

Польза вопросов

Последние пару месяцев активно копаю в сторону стриминга. Последний проект — перевод одной отдельновзятой поставки данных на Flink.

В какой-то момент настолько увлёкся и закопался, что потерял общий ориентир; ви́дение стало слишком узким и застал себя за тем, что «искал ключи где светло, а не там где их мог потерять»

Благо дело было перед регулярной встрече 1-1 и на помощь пришёл наш бравый лид (привет, Саша!). Через ряд последовательных вопросов у него получилось упорядочить хаос в моей голове: вспомнить о цели проекта, предстоящих этапах и когда это должно быть сделано.

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

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

я был сосредоточен на парсинге, потому что это самое простое 🤡

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

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

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

О приоритизации задач

Дорогой читатель Алексей Махоткин @squadette в коментах к прошлому посту прислал релевантную заметку (спасибо большое! люблю такое, шлите ещё).

Мой ограниченный опыт подтверждается богатым (подозреваю) опытом автора из ЖЖ — ошибка довольно распространённая.

https://gaperton.livejournal.com/36144.html

⁃ неопределённость в проектах есть всегда; ей можно управлять (хотя бы наблюдать и иметь в виду).

⁃ неопределённость к концу проекта должна снижаться

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

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

⁃ иначе неопределённость проявится на 90% готовности проекта (тот случай когда внезапно появляются «вторые 90% проекта»).

👆

🥸 про коучинг

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

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

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

по себе знаю, насколько это сложно не пытаться давать совет после каждой реплики собеседника (ведь я же ЗНАЮ КАК ЛУЧШЕ!!1)

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

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

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

🖤

Яндекс 🇷🇺 → Klarna 🇸🇪

2 года назад у меня был план

к тому моменту я поработал полгода джуном в Ривьере, потом ещё годик в агентстве Epoch8. Когда пришёл в Яндекс, по прикидкам в такой большой компании можно смело проработать года 2-4, продолжая открывать что-то новое.

помню как смотрел такими О_О глазами на коллег, которые уходили из Яндекса когда я только туда добрался. Смотрел и не понимал что за жизнь такая может быть после.

но потом что-то случилось 🫠

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

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

начало получаться складывать кубики в простые башенки

решение вышло сложным. Было бы гораздо проще, если бы тимлид был самодур, денег бы не платили и проекты были скучные, да ещё и на легасной инфре. Но нет, тут они совершенно не «помогали» =)

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

ну штош, а теперь попробуем повторить всё то же самое на новой земле и в англоязычном окружении — stay как говорится tuned

✍️ первое задание для новенького

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

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

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

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

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

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

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

послушал как принципалы Thoughtworks обсуждают ai-помогаторы для написания кода.

самое простое описание — это продвинутое автодополнение. Как раньше курсор предлагал дописать несколько символов текущего слова, так сейчас предлагает дописать несколько строк.

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

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

есть ещё подход в TDD — даешь на вход пачку тестов и генеришь к ним код; если проходит, то типа всё ок. Но тут надо смотреть на полноту и качество тестов. А что если и сами тесты тоже генерить?

на сайте подкаста есть транскрипт, возможность послушать и ссылки на iTunes и Spotify. На Overcast ссылку не даю, там чёт шерилка сломалась — пинганите меня в комментах если пользуетесь Overcast (просто любопытно)
https://www.thoughtworks.com/insights/podcasts/technology-podcasts/ai-assisted-coding-experiences-perspectives

Microsoft Excel в 1990 году

https://www.youtube.com/watch?v=kOO31qFmi9A

тв-реклама Экселя из 1990 года — как 30 лет назад люди воспринимали возможность вставить циферки в таблицу и красиво раскрасить.

особенно полезно посмотреть на это в контексте фразы «AI отберёт у людей работу» — ведь сам по себе АИ ничего отобрать не может (пока что, хехе!). Миджорни не знает куда вставлять свои чудесные креативы, а ChaGPT не понимает как использовать этот гениальный контент-план, который он только что нагенерил.

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

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

При этом ни эксель, ни майкрософт ни у кого работы не отобрали

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

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

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

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

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

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

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

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