Telegram Web
Forwarded from Data Coffee
136 (S5E21). Будни дата-инженера

В гостях у подкаста 🎙"Data Coffee" Саша Михайлов, дата инженер ( Telegram⁠, LinkedIn⁠)

Обсудили:
• кофе
• дата инженер
• нужен ли CDO для data mesh
• карьерный путь
• переезд в Швецию
• деанон по фитнес-трекеру
• детские сады района
• почему дата инженер
• pet projects
• как развиваться

Сайт: ⁠⁠⁠⁠⁠⁠⁠⁠https://datacoffee.link⁠⁠⁠⁠⁠⁠⁠⁠
Telegram: ⁠⁠⁠⁠⁠⁠⁠⁠https://www.tgoop.com/datacoffee⁠⁠⁠⁠⁠⁠⁠⁠
Mastodon: ⁠⁠⁠⁠⁠⁠⁠⁠https://techhub.social/@datacoffee⁠⁠⁠⁠⁠⁠⁠⁠
Чат подкаста: ⁠⁠⁠⁠⁠⁠⁠⁠https://www.tgoop.com/datacoffee_chat

#datacoffee #data #podcast #данные #подкаст #кофе #coffee

Где слушать🎧:
Бот-плеер
RSS feed
YouTube
Остальные площадки
🎙️сходил на подкаст обсудить кофе и дату



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

в эпизоде упоминали:

доклады Жени Ермакова и Коли Гребенщикова про чудо-DWH в Яндекс GO, благодаря которым я загорелся идеей попасть туда;

на один из предыдущих эпизодов подкаста, где гостем был Игорь Мосягин — поскольку он был в команде дата-платформы, там было много сочных деталей типа админстрирования Редшифта на 2к пользователей и мотивацию к документации.
data будни
😱 забанили в LinkedIn случилось страшное! дело было после мобилизации, когда я активно искал работу за бугром. каждый день я стабильно искал дата-вакансии и откликался сначала на интересные, а потом и просто на все более-менее подходящие. Из всех откликов…
🍱 восстанавливаю LinkedIn

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

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

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

тем временем приглашаю всех причастных и сочувствующих законнектиться! обещаю в ответ не жать злосчастную кнопку
https://www.linkedin.com/in/sasha-mikhailov-

к слову, если вы знаете как сделать линкедин по красоте, чтобы прям ваще вах! буду рад услышать прикладные советы <3
🥴 Reverse ETL — антипаттерн или норм?

у меня тут недавно наконец-то сложилась картинка в голове! до этого краем уха слышал этот новый термин, но никак не мог переложить его на реальность. А потом увидел схемку где помимо стандартного направления

источник → двх

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

источник → двх → (обратно) источник

в итоге понял, что видел уже два таких кейса и пока ощущения смешанные:

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

2) сейчас есть задача передавать данные между микросервисами (разные команды): микросервис А производит данные, их сгружаем в ДВХ, там происходит очистка и обогащение; а потом мы эти данные выгружаем в микросервис Б.

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

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

⌘⌘⌘

что думаете про Reverse ETL? какбэ антипарттерн или норм? есть альтернативы? как «правильно»?
👋 Саша Михайлов, безработный

почти год назад я писал, как устроился в шведский финтех Klarna и уехал жить в Стокгольм. Раз уж написал начало истории, напишу и её окончание 😭

что же случилось? не прошел перфоманс ревью? очередные лейоффы? Кларна закрылась?

всё гораздо проще: семья не прижилась в новой стране и мы решили вернуться назад

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

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

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

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

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

сейчас мы все уже в Москве, снова вместе 🫶

P.S.: вместе с возвращённым корпоративным ноутом у меня сломался мой блоггерско-редакторский процесс (и не только, хе-хе), но планирую скоро вернуться с регулярными постами ✌️
🤓 подгтовка к собесам: список техвопросов

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

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

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

часть вопросов легко гуглилась, с другой помогли товарищи инженеры 👋

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

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

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

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

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

итоговая схема:
× собрать список тем
× темы заполнить вопросами
× по вопросам написать ответы
× перед встречей повторить ответы
× после встречи добавить новые вопросы

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

среди всех начатых процессов мне запоминалась команда Купера (они же Sbermarket до июня 2024, а ещё раньше это был Instamart)

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

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

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

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

они ищут синьористого дата инженера в команду дата лейка; вот пост тимлида команды в небезизвестном чатике со всеми подробностями — в него можно накидать вопросов (если вдруг среди 49+ реплаев нет нужного ответа)
https://www.tgoop.com/datajobs/482511

добавлю посту несколько сотен охвата к 3900+ подписчикам чатика, хе-хе

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

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

на тот момент (и с той стороны границы) самым выгодным казался вариант «валютной удалёнки»: когда платят в валюте европейского уровня зарплату, а я сам буду попивать смузи у себя в Москве. в уме я рисовал себе картину как буду получать на руки 5-7к долларов хе-хе-хе

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



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

по мере получения откликов, сложилось понимание, что топовые компании типа Miro или JetBrains (где я бы точно не отказался поработать при случае) имеют дополнительные ограничения на удалёнку: некоторые понимают «удалёнку» как «не обязательно ходить в офис, но надо быть в городе/стране где он есть».

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

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



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

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

⌘⌘⌘

потом подбил для себя плюсы и минусы:

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

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

(без оценки: кому как)
· точно удалёнка, без офиса рядом


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

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

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

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

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

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

а с не давних пор, посмотреть на этого дивного зверя могут все желающие — теперь YTsaurus доступен в опенсорс.

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

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

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

⌘ по трудозатратам — год для команды 10 человек, и это только первый минимальный вариант «за который не стыдно»

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

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

https://youtu.be/Z7kv8tYVHx0
Please open Telegram to view this post
VIEW IN TELEGRAM
⚖️ собесы: дисбаланс за столом

бывало на собесе сижу-пыхчу над задачкой, отбрасывая варианты один за другим, в итоге в муках порождаешь вроде-ничего-такое решение… только для того, чтобы интервьюер на той стороне нашёл там несколько критичных багов, и не особо запариваясь при этом. в такие моменты я чувствовал себя совсем тупым. ну или как минимум тупее интервьюера (а значит, тупее среднего сотрудника целевой компании!) 🤦‍♂️

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

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


⌘⌘⌘

🤓 как можно подготовиться к собесам:

— собрать список вопросов и накидать ответы;

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

— обложиться поддержкой: профильные коммьюнити и консультанты;

— потренироваться «на кошках»: попробовать пройти мок-собесы;


⌘⌘⌘

📚 открытая инфа

§ эпизод Lenny’s podcast c Phyl Terry — он помогает людям искать работу уже третий десяток лет и автор книги Never Search Alone; один из его советов — не бояться попросить помощи.
https://www.lennysnewsletter.com/p/land-your-dream-job-phyl-terry

§ подкаст Собес — плод труда Киры Кузьменко (New HR) и не менее замечательных ребят из студии подкастов Либо/Либо. В последнем сезоне как раз делают публичные мок-интервью: соискатель проходит интервью и сразу получает обратную связь с рекомендациями.
https://libolibo.ru/sobes

§ спин-офф от команды LeftJoin — канал о карьере и рекомендациях. Я воспользовался советами об оформлении Линкедин https://www.tgoop.com/leftjoin_career/32

§ свежий неожиданный врыв в дата-инфополе: канал с отчётами по форме о нескольких десятках собесах: с вопросами и вилками. можно пополнить свой список вопросов, посмотреть интересные компании и откалибровать хотелки https://www.tgoop.com/get_rejected/39


⌘⌘⌘

👯‍♀️ коммьюнити

во время поиска наткнулся на два активных коммьюнити, направленные именно на инжиниринг данных:

§ https://boosty.to/halltape_data (больше для джунов и только-только вкатывающихся)

§ https://boosty.to/rzv_de (уже для миддлов и дальше)

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


🥊 консультации

как тренер за спиной боксёра — не сможет за тебя помахать кулаками, но настроит на нужный лад перед встречей и поможет отрефлексировать итоги после. плюс можно сориентироваться внутри отрасли, узнать общую сводку по компаниям: кто чем отметился в публичном поле за последнее время. как пример — Семён Осипов https://www.tgoop.com/ohmydataengineer


⌘⌘⌘

до мок-интервью пока руки не дошли — было ощущение что на внутреннем рынке поиск идёт «достаточно хорошо». в следующий раз хочу попробовать пройти несколько, уже присматриваюсь к сисдизайну https://www.tgoop.com/system_design_world и архитектурным катам https://www.tgoop.com/arch_katas_russia


⌘⌘⌘

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

☝️
😭 как я не прошёл «собес» в ABBYY

сходил на подкаст к Кире Кузьменко, поговорили в формате мок-интервью
https://www.tgoop.com/kirafound/1861

ещё год назад я бы точно не рискнул публично собеситься — да ну его! но в последнее время стал спокойнее ко всему относиться: даже «отказ» это тоже новый опыт. тем более в этом случае была полезная обратная связь от Киры и Татьяны.

было интересно поговорить и ещё более интересно узнать «как надо».

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

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

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



ещё раз рекомендую послушать записи из подкаста как разные люди проходят собесы и получают обратную связь — полезно сопоставить себя с ними и взглянуть на весь процесс со точки зрения рекрутера
🏦 новый_план(2)_final

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

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

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

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

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

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

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

в общем, по всем пунктам можно поставить галочки:

посмотрел в сторону валютных удаленок (но не пошёл дальше)

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

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

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

и как итог «вернулся назад» в Яндекс, на этот раз в Яндекс Банк, он же Финтех (надеюсь, уже все открыли счёт, научились сплитить, и подключили авто-пополнение))

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

что же там оптимизировать, спросите вы? сейчас расскажу:

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

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

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

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

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

ложка → вилка → нож → нож → вилка → ложка

ложка → ложка → вилка → вилка → нож → нож



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

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

можно пойти дальше и провести аналогии в выборе момента для упорядочивания элементов с двумя известными известными подходами: запись inplace в B-Tree или append-only LSM; то есть либо мы заранее оптимально раскладываем элементы (тратя какой-то ресурс на это), либо мы сваливаем как есть, а разбор элементов оставляем на потом (ровно как и траты ресурсов).

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

⌘ ⌘ ⌘

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

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

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

специально для постоянной читательницы этого блога — Натальи — ни к чему не обязывающая подборка подкастов на тему карьеры, её смены и всякого такого >_>

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

⌘⌘⌘

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

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

https://libolibo.ru/sobes


⌘⌘⌘

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

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

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


⌘⌘⌘

и отдельно на тему аналитики два проекта от ребят из тбанка.

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

https://www.tgoop.com/eto_schitaetsya/477

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

https://www.tgoop.com/karty_dengi_product/112


⌘⌘⌘

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

https://music.yandex.ru/album/22481935/track/129159864


⌘⌘⌘

§ что ещё можно послушать-посмотреть условному бизнес-аналитику в условном финтехе?

что вообще понимают в разных компаниях под «бизнес-аналитиком»? в моей голове есть системные аналитики, которые ближе к данным и процессам, а есть продакты, которые ближе к бизнесу. а «бизнес-аналитиком» получается, это что-то между этими двумя.
2025_02_06_Новые_возможности_YDB_СУБД_Яндекса_для_аналитических.pdf
8.7 MB
📦 YDB + OLAP = ?

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

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

https://yandex.cloud/ru/blog/posts/2024/12/ydb-dwh


⌘⌘⌘

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

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

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

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

→ стоимостной оптимизатор (cost-based) для плана запроса с подбором оптимального порядка и алгоритма джойнов

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

→ спиллы на диск для больших вычислений

→ нативная поддержка охлаждения данных в s3 (автоматическое гибридное хранение для колоночных таблиц)

→ сбор статистики для таблиц

→ predicate pushdown для оптимизации чтения

→ федеративные sql-запросы из разных источников

→ пулы ресурсов — разделение под разные нагрузки

→ асинхронная репликация между удб-инстансами


по мотивам обзорного доклада про новости удб с конфы yandex scale
https://vkvideo.ru/video-200452713_456239488

и недавнего вебинара, посвященного релизу ydb dwh (ссылки не осталось есть ссылка, есть презентация)

1/2
2/2

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

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

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

> В настоящий момент реализована не вся функциональность колоночных таблиц
https://ясубд.рф/docs/ru/concepts/datamodel/table.html#column-oriented-tables

(надеюсь, документация просто чуток отстаёт от новых фич)

⌘⌘⌘

в теории звучит хорошо — один инструмент лучше, чем пять разных (при прочих равных)

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

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



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

то есть зоопарк инструментов остаётся, но задачи и кейсы могут чуток перераспределиться — polyglot persistance пока не отменяем
https://martinfowler.com/bliki/PolyglotPersistence.html

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

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

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

со стороны это читается как «там на дисках место заканчивается … кто-нибудь сделайте что-нибудь

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

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

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

- понятно, что решение может быть тоже не простое или даже несовсем правильное

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

иными словами, приходи с решением, а не проблемой!
🤑 yet another zarplaty

классный пример коллаборации:

Саша Варламов собрал парсер и визуализацию
https://www.tgoop.com/data_bar/60

а Никита это дело автоматизировал
https://www.tgoop.com/joni_in_web/21

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

что мне нравится в подобных проектах:

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

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

3. полезность, направленная наружу: когда решал свою задачу, а польза — всем

в общем, смотрите деш и ставьте лайки Саше с Никитой)
2025/03/09 19:01:43
Back to Top
HTML Embed Code: