staff engineer и его путь

Два дня argo+helm программирования изнасиловали мой мозг и теперь остается только текстики писать для расслабухи.

Посмотрел видео от ребят из Т Code of Leadership #6 - Staff+ инженеры, как мы их растим внутри и нанимаем с рынка: разговор о той самой мифической ветки развития в техничку после синьора помидора и какие занимательные конкурсы придумали в самом "техничном" банке на просторах всея РФ. Минут на 30 завис в мыслях, что же так не понравилось в нем и почему традиционно получилось казаться, а не быть.
Самое ценное во всем видео - иллюстрация из книги Staff engineer от Will Larson. Да, вот с этим я абсолютно согласен.

И даже натяну свою реальность на картинку с маленькими дополнениями:
- Solver - решатель проблем и человек уникального знания куда надо ударить. Ценный staff engineer, который при этом вообще не ходит на собеседования на рынке. Это к нему приходят люди с чемоданом денег и просьбой помочь. Ау, где вы админы хадупа в 24 году с умением настроить ATSv2 и kerberos за 2 недели.
- Right hand - правая рука. Все мы знаем, что путь в архитекторы лежит через постель с CTO. Чаще всего он приглядывает за командами за заслуги, или его нанимают чтобы приглядел. На собеседования тоже не ходит, он довесок к руководителю.

А теперь спорные ребята, на мой взгляд про одно и тоже, но в разных масштабах:
- Techlead - на мой взгляд, построение новой команды начинается как раз с техлида в основе, компетенции от которого дальше распространяются по самой команде. И даже если первым внедряющим кликхауз оказался случайно Вася-пхпист, то скорее всего знаний у него будет больше окружающих. Тянет ли техлид на стафа - вроде нет. Стоит ли эту роль гонять по придуманным собесам - тоже вроде нет.
- Architect - мечта всех 20 летних юношей. Есть ли польза брать архитекторов со стороны для компании - нет. Человек высоких материй просто не сможет со стороны зайти и получить нужную глубину знаний. Мы все видели ребят из выскоких замков, которые рисуют красивые презы или умеют писать тайные письмена архитекторов, но где та польза? Полезный архитектор вырос в компании, за время работы поработал со многими людьми (что обеспечивает необходимый для изменений социальный вес), поработал со многими системами (что обеспечивает нужный уровень знаний что надо менять, что не надо менять, где есть проблемы на миллион, а где мы строим космолет из прихоти). Поэтому может собесить его и надо, но не стоит.
Плюс к этому любой найм с рынка на такие роли сильно бьет по внутренним компетенциям и амбициям молодежи, а ведь именно для удержания людей и придумали эти громкие титулы.

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

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

Конференции

На почту упало письмо от ребят из Онтико о приеме докладов на DevOpsConf 2025. Немножко подумал для приличия день и отправил доклад по внедрению в платформу данных StarRocks. Вполне резонно возникает вопрос - почему эта конференция то? :)

Если судить по развитию аналитического окружения, и да и вообще появлению этих самых платформ данных - всё идет следом за основными трендами во взрослой разработке: сервисы миграций, появился dbt, который в версии 1.9 принесет нам еще и unit тесты, стенды разработки и приемочные стенды, построение зависимостей между сервисами поставки и потребления. Да и где еще обсуждать способы подключенния систем хранения в кубернетисе, не на смартдате же? :)

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

Посмотрим, что скажет программный комитет, в тренде оно все или нет...

А как выглядит ваша репа dbt?

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

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

Но каждый раз когда аналитики открывают репу их встречает вот такая пугающая картина, и она мало связана с sql :)

Тащу все наши проекты dbt (сейчас их 6) в новый гитлаб с новым ci, с новыми окружениями и тестированием. Опять же переход с тестирования на баше в обвязку на питоне смотрится приятно.

Cassandra

Почти 1.5 месяца потребовалось, чтобы вытянуть из кассандры 5 млрд записей. Утрирую слегка, не всегда получалось 24х7, но все же.

Я точно не люблю кассандру и не умею ее готовить.

В StarRocks залетело минут за 5-7 транзитом через паркеты в хадупе.

Куда идет StarRocks

На канале у CelerData вышло видео с подведением итогов квартала. Кому лень смотреть краткая выжимка: StarRocks позиционируется исключительно как shared-data движок либо со своим собственным быстрым форматом, либо как основной движок для datalake на основе почти всех свободных форматов.

Основные фичи квартала:
- интеграция с Unity Catalog. Тут все понятно без слов.
- реализация новой фичи Automatic Materialized View. Причина использования описана хорошо - покрутил в голове наш случай, этак можно детальный слой из дбт выкинуть. Но дальше в реализации начал скипать видео, подводных камней хватает и надо ждать переезда фичи из облачной версии в открытый StarRocks.

А заодно на днях вышла версия версия 3.3.6. И опять же, посмотрев фичи за последний квартал, можно увидеть, что развитие идет в shared-data движке. Уже даже начал задумывать о том, что надо тестировать и может быть мигрировать на него с shared-nothing - но остается вопрос таймингов. И самое интересное, что когда я делал PoC как раз сильно обломался, в то время невозможно было использовать HDFS как систему хранения. На данный момент все реализовано.

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

Apache Kafka и StarRocks

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

Плюсы

Механика выглядит надежной и простой по подключениям ко всем видам кафок - у нас 3, включая managed aws кластер с разными видами аутентификаций: SASL_PLAINTEXT, SASL_SSL via SCRAM-SHA-512. И даже задаваемые креды в запросе маскируются при выводе show routine load:

{"security.protocol":"SASL_SSL","sasl.username":"username","sasl.mechanism":"SCRAM-SHA-512","kafka_default_offsets":"OFFSET_END","group.id":"dp_sr_1","sasl.password":"******"}

Минусы

Задания разделены по схемам нахождения таблиц, и это прям странно выглядит. То есть вы грузите таблицу в dds.table через задание и команда show routine load показывает только его, а то что в соседней схеме kafka есть еще 10 заданий никого не волнует. То есть в случае капитальных проблем нужно будет бегать и вспоминать (в нашем случае все записано в миграциях, но осадочек остается).

Особенности

В случае перегрузки кластера все задания ставятся на паузу, не мигрируя между живыми нодами. То есть пусть это будет обновление кластера на новую версию или добавление тега в k8s для добавления сетевых ACL - пауза везде. Тут важно мониторить метрику starrocks_fe_routine_load_jobs с значениями PAUSED (остановлено по какой-либо валидной причине - ручная операция или перегрузка кластера) и CANCELLED (сработал трешхолд по ошибкам в данных или нарушены значения ключей в таблице).

Epic fail

Середина рабочего дня, и вдруг вам в слак(ваш рабочий месенджер) приходит сообщение: "Я кластер XXX снес". Речь про k8s кластер, в котором у вас находится все - сервисы, базы данных, джобы эйрфлоу делают вжух. Эмоции были непередаваемые, голова сразу начинает работать сколько времени потребуется на восстановление данных - и эта основная часть как раз старрокс и данные из кассандры.

Кластер восстановили, старрокс за этом время не потерял ни одного сообщения из потока 👍 Вся эта хитрая модерновая история с тераформом может закончится вот так - команда на удаление одного узла развернулась в удаление всего кластера :) Люблю модерн оперейшенс стек ❤️

А что же цвет нашего modern data stack - cloud managed databases?

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

В компании есть небольшой проект, на котором мы решили потестировать работу только в облаке - BigQuery с месячным счетом в районе 500 баксов. Ничего не предвещало беды и все были очень довольны. Но бодрым октябрьским утром данные перестали поступать в бд - аккаунт был заморожен. Нет, РФ тут даже не при чем. Просто где-то там не понравились платежные документы аккаунта, и вместо уточнения по ним был приведен в действие рубильник. Отдел юристов бился как лев, но каждое наше письмо получало ответ в срок до 48 часов.

Итого 2 недели вся аналитика не функционировала - проект просто ехал в слепую. Ну да, ну да, уровень услуг чувствуется. Пожалуй, что спасибо, но нет.

Большая часть данных - не имеет цены

И это не намек на "данные - это новая нефть", а скорее на "сколько можно хранить мусор" :) Спасибо Никите, который принес статью и поделился своими историями в подтверждение ее тезисов. Каждый выносит из нее полезное на основании своего опыта, а основная часть в ней про моду последнего сезона в бигдатке - realtime analytics. Да, безусловно, король голый - большая часть заказчиков опять идет на поводу хайпа.

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

История из жизни

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

Поставьте себя на место лица, принимающего решение, в момент, когда приходит алерт о достижении 90-95-100-105% занятого места в хранилище (лицензия отрубает бд на 110 :). Ваш ход? Следуя логике бигдаты - стращаем СТО и покупаем на все выбитые бабки расширение и лицензии, да и о вычислительных ресурсах подумать можно. Вместе с ним можно и инженеров еще нанять - у нас же эльдорадо из новой нефти не за горами. И не отвертятся ведь от покупки - вот же графики роста, вот пользователи с горящими попамиглазами.

А есть вариант 2 - погружение в каждый запрос на добавление данных (зачем, почему, сколько стоит), регулярный опрос необходимости текущих данных (устарели, в активной работе), регламентирование сроков хранения данных по каждому источнику (10 лет истории говорите для отслеживания трендов - это после ковида и войн то?). Не забываем про щепотку автоматизации - автоматическая чистка(запрос на чистку) неиспользуемых таблиц и вообще отслеживание использования данных.

А вот какой результат варианта 2: 3+ года без расширения лицензий и железа, потребление места упало с 90% до 65%, падение обращений в команду по поводу нехватки ресурсов для выполнения запросов. Эти 3 года позволили спокойно подобрать и начать внедрение замены этой базы данных в оптимальном темпе.

О чем умолчал

Конечно умолчал :) Львиную долю разгрузки хранилища дало внедрение хадупа рядом. Вот только в чем фишка - пользователи туда стараются не ходить. Можно сказать, что это место подготовки и перевалки данных, и еще аргумент "мы здесь срезали срок хранения до 3 месяцев, но вся история есть в хадупе". И как вы думаете, сколько людей ходили смотреть эту всю историю за годы? :) Сейчас хадуп уже не нужен, s3 вокруг нас и решения стали еще проще.

PS есть еще интересный тезис в статье, но и так многа букф, оставлю на потом

Сделать правильно с первого раза

Каков шанс достигнуть Эльдорадо программных проектов, которые было утеряно после посадки космических кораблей на Луну - запустить все с первого раза ровно так, как задумано?

Мы потратили неделю+ на разработку нового процесса деплоя dbt для нового проекта под StarRocks. Потом еще тройка-пятерка сторипойнтов для удаления кусков конкретного проекта и создания удобного шаблона под остальные проекты.
После этого прошла миграция 2 проектов бигквери на новый шаблон - опять доработки.

И вот он - наш царь всех дбт - проект вертики. Легкая миграция на тщательно отлаженный шаблон превратился в головную боль на 3 дня. Оказалось, что неправильно было сделано больше 50% и как оно работало иначе как чудом не обозвать. И вроде как снаружи кажется, что ты знаешь как пользоваться этим вашим ArgoCD, gitlab-ci, helm, k8s, dockerfile, pytest и сам dbt. Но нет - недостаточно. Надо больше, выше, сильнее, пока мозги не треснут.

Люблю старые проекты, сразу показывают кто ты есть.

Опыт внедрения StarRocks нормальных людей

Мне очень нравится компания Agoda, но исключительно по одному человеку в сообществе из нее. Алекс очень классный, до сих пор помню как он мне помогал тайминги выжимать из HBase.
Вот тут и ниже он написал про боли, которые у них возникают в процессе внедрения: https://news.1rj.ru/str/hadoopusers/222943

Минусы
- это плюсы - а значит все может начать падать вместо красивых ошибок в логе у жабки
- порой код удивляет детскими болезнями и не очень зрелым подходом(где тестирование?)
- падение скорости разработки в репе на гитхабе начиная с лета - и сильный проигрыш в этом сейчас дорису: около 200 пул реквестов за прошлый месяц в СР против 1500 в дорис
- планировщик чудит
- медленно принимают пулреквесты

Плюсы
- быстрый
- пользователи довольны по сравнению с импалой (у них кейс как раз lakehouse - хранение данных в открытых форматах на hdfs)

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

Возврат наработок в upstream

Недавно писал про нашу миграцию дбт проектов. Хехе, нет, так просто оно не закончилось. На финишной прямой задача приведение stage кластера для вертики в production вид dbt run на всех 600 моделях начал падать в непредсказуемых местах - каждый раз новом. Еще денек на поиск: флажок --full-refresh. И да, это был баг в адаптере - вместо создания временной модели и потом замене существующей адаптер пытался создать еще раз существующую таблицу. Замена переменной в одной строчке и добавление строчки на дроп промежуточной таблицы, вот и весь фикс.

Свои форки

И тут надо рассказать, почему этот баг вообще попался. Адаптер вертики изначально был частной разработкой, и как в любой частной разработке энтузиазм закончился в районе 0.19 версии, на которой мы форкнули адаптер в первый раз. Затем свежая кровь апнула адаптер в апстриме до версии 1.3 - это вертика прислала своего работника из Индии. И казалось бы, наконец то заживем. Но нет, в 1.3 были все те баги и отсутствие фичей, которые к тому времени были у нас. Отступать было некуда - на апстрим 1.3 были накручены все наши правки и фичи, а пул реквесты были засланы на гитхаб. И да, они не были приняты и некоторые висят открытыми до сих пор.

Промежуточный итог

Мы живем на своем форке и вот такие баги правим у себя (а встречали много). Но и в текущем апстриме этот баг поправлен. Сложно, короче, пушить свои правки в апстрим, как морально, так и физически. Вроде у себя ты уже поправил, а взаимодействие с ребятами с той стороны гитхаб репы бывает ух каким непростым. Так у меня висит пулреквест в фласк для работы с вложенными группами MS AD для airflow, кучка в вертику дбт, что-то в спарк дбт, что-то в цеппелин, и так с десяток реп. И иногда прямо стреляет :(

Где SR хранит офсеты кафки?

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

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

ErrorReason{errCode = 104, msg='FE aborts the task with reason: failed to check task ready to execute, err: Consume offset: 7702455725 is greater than the latest offset: 100248496 in kafka partition: 1. You can modify 'kafka_offsets' property through ALTER ROUTINE LOAD and RESUME the job'}

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

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

ALTER ROUTINE LOAD FOR dds.quotes
FROM KAFKA
(
"kafka_partitions" = "0, 1, 2",
"kafka_offsets" = "74280122, 99609165, 42423911",
"property.group.id"="dp_sr_quotes_1"
);

Дичь же? :)

Организация работы

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

А вот теперь и правда минутка ненависти

В пятницу в районе 19-00 начинает кипеть чатик с алертами - сначала кучно пошли пул реквесты от автоматики, следом пошли аварийные сообщения. Что же тут у нас? А тут у нас молодцы, которые катят прод в пятницу вечером. Ненавижу скрам, ненавижу спринты, ненавижу спринты, которые заканчиваются в пятницы. Всю неделю команда ударно работала и значит в пятницу вечером наступает пора эту самую работу доставлять. Меняются колонки, добавляются и удаляются таблицы, вжух-вжух-пыщь-пыщь.

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

Как-как простите определить хорошего менеджера в команде? 1-1 говорите он должен регулярно проводить и календарь плотно забит?

Выводы

А вы знали, что в статистике канала в телеге можно посмотреть у скольки людей он стоит на мьюте? Для меня стало неожиданностью, что 70% не проставляют отключение оповещений сразу после подписки. Мне бы такую нервную систему, у меня даже телефон с часами после 23-00 гасят все входящее. И на попытку внедрить команду мониторинга к нам результат был бы таким же, как без нее - все равно трубку никто бы не снимал.

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

Гараж аналитических решений

Иногда охватывает паника по поводу выбранных решений в той или иной ситуации, наш СТО часто за это меня обзывает нерешительным. И пока в голове крутил риски - придумал аналогию текущему рынку аналитических баз данных на просторах онпрема РФ. Мы же все умеем пользоваться аналогиями, правда? Обычно это абсолютно безумные сравнения, но просто веселые. Так вот :)

История простая: у нас в компании есть DWH(да, вот так вот) на oracle или ms sql. Ситуация на рынке или выявленные ограничения диктуют замену текущему решению. И лицо, принимающее решение, начинает выбирать. Тут надо заметить, что выбор - это предпочтение одного варианта другому, а сколько вариантов есть?

Clickhouse - офигенно быстрый спортивный автомобиль. Но без багажника и крыши, и места там на одного здоровяка или двоих тощих. Да и ветрового стекла нет, нам же надо быстро ехать. Но 3 секунды до ста.

Greenplum - ваз-2101(копейка) от мира аналитики. Все же знают, что теслы с планшетами, ну или на худой конец китайцы - это все современная бесполезная фигня. Вот деды знали толк в машинах, руль, педали, рычаг, отремонтировать можно в поле с помощью ветки. А в планшетах этих ваших если мозги сломаются - что делать?

Через какое-то время в стеке появляется hadoop, ну потому что GP перестал справляться, а в s3 или куда еще сыпят и сыпят эти ваши джосоны без схем. А hadoop у нас - это нормальный такой грузовик, ну давайте камаз самосвал. Можно в кабине попутчика подвести, а можно 10 тон песка на участок.

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

Цена ошибки (1): стоимость коробки

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

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

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

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

StarRocks/Apache Doris - при неудачном внедрении по этой категории рисков набирают 0 долларов затрат.

StarRocks 3.3.7 & 3.2.13

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

А вот что выглядит притихшим, так это дбт адаптер. Не смотря на то, что 1.7 выпустили в октябре, с тех пор репа стоит без обновлений. При этом уже почти все основные игроки готовятся к 1.9 - тут еще даже 1.8 ни в каком виде нет. Печалька :(

Линус, linux и opensource

Честно взял картинку у https://news.1rj.ru/str/it_gonzales. А вспомнил про нее благодаря посту на ЛОРе, в котором добрый человек прочитал годовой отчет Linux Foundations. Новости примерно такие:
- суммарный доход LF за прошедший год вырос до 292 миллионов долларов, расходы выросли до $299.7 миллионов;
- из них, доля расхода на собственно ядро Linux в процентном соотношении упала до 2%, что в два раза меньше расходов на Blockchain (4%) и почти в 6 раз меньше расходов на ИИ, машинное обучение и подобные штуки (11%).
- затраты на ядро Linux в LF в данный момент меньше, чем зарплата CEO Mozilla
- в этом году из отчёта напрочь исчезли такие термины как: diversity, inclusion, equity, climate change и другие интересные вещи
- 70% членов совета директоров работают на корпорации, регулярно нарушающие GPL, в том числе и в отношение этого самого Linux. И двое работают в Microsoft.

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

А что у нас?

А у нас до сих пор не доперли, что можно получать бесплатно то, что внутри компании надо делать за деньги. Да-да, до сих адаптер greenplum, да впрочем и сам greenplum не нашли себе дома в виде сообщества или фаундейшена. Продавать коробку или облако - пожалуйста, но сделать для него удобные инструменты - не то что денег нет, а мозгов нет. Вроде из требований просто создать репу и договориться, что теперь патчи присылать сюда. Поэтому каждый пользователь ГП допиливает гитхаб Марка как умеет.

Новые игрушки

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

Например рассказать о новом релизе dbt 1.9. Но на повороте меня обгоняет Паша из инженерки, что безусловно и неплохо. Когда сервис внедрен уже довольно давно - шаблон привычек работы с ним уже сформирован, подходы закреплены и заставить внутреннюю обезьянку изучать новые фичи довольно сложно. На каждое новое есть уже устоявшийся привычный подход. Да, он не идеален, но он есть и не требуется думать. Микробатчи - прикольно же. А вроде и так уже все работает :) Из года в год работает. Так что даже и рассказывать на митапах нечего. Завидую тем, кто внедряет новые для себя штуки - можно и так попробовать, и сяк, время на эксперименты заложено в решение бизнеса.

Нашел почему не дорис!

Потому что ситуация с адаптером dbt под него еще хуже, чем у старрокса :) На просторах гитхаба есть 2 адаптера - версии 1.3 и 1.5, обе давно EoL. Тут SR с его 1.7 хотя бы на поддерживаемой версии живет. Все не так плохо, можно жить дальше :)

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