Возврат наработок в 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 хотя бы на поддерживаемой версии живет. Все не так плохо, можно жить дальше :)

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

Целевая аудитория

Прошлой зимой к нам для развития лидерских качеств пригласили достаточно известных Aletheia Digital, которые всю дорогу выступали и партнерились с highload conf, а затем и с teamlead conf. И среди дополнительной литературы они дали книгу "Искусство решения проблем" Акоффа. Прошел год и руки дошли дочитать.

Название классное, но при этом задает некие ожидания. А после прочтения первой главы ожидаешь как минимум откровения из ТРИЗ, не меньше. Вся эта история про творческий подход к решению проблем и угнетению воображения в школе. Но следом на нас обрушивается огромное число побасенок с небольшими выводами - прям как будто читаешь сборник сказок какого-то народа :) Так проходит первая половина книги - первая часть, а со второй все интересней. Там и про современные бирюзовые организации, и про информационные системы для помощи в принятии решений, и про моделирование. На минуточку - это книга 1978 года.
С одной стороны, эти 200 страниц читаются очень легко, и все достаточно увлекательно. С другой стороны я 2 дня ходил и думал - как оценить эту книгу, была она полезной или просто весело время провел.

Вот точно та же самая история была и с тренингом. Известные спикеры, которые имеют хорошие рекомендации. Но при этом структура курса из разряда объять необъятное, да еще на огромную группу самых разнородных лидеров - от С* до лидеров самых малых команд в 2 человека (это я, если что :). Широкая аудитория сильно размывает полезные мысли до уровня - делай хорошо, не делай плохо. А по другому 2/3 потребителей могут и не понять. Но это все равно понижает ценность, и так плохо, и по другому не лучше.

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

А книжку прочитать стоит, просто для расширения кругозора :)

StarRocks 3.3.8

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

А вообще полезно читать release notes - узнал, что в SR есть динамическое партиционирование (оно же partition ttl). Где были мои глаза до этого... В итоге можно будет выкинуть очередную airflow таску на чистку партиций и заменить на внутренний механизм. Ура-ура.

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

2025

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

А между тем CelerData выпустили видео с итогами 24 года и планами на 25. Основная информация на картинке - айсберг захватывает мир и трине придется потесниться. Еще в видео есть несколько кейсов от клиентов, но мне кажется что мы про них уже слышали. А так слайдов мало, но много китайского английского - не под каждое настроение зайдет.

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

Вообщем там или иначе, если кто будет в апреле на конфе, то можно поболтать.

Трино против (или вместе)

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

А между тем поток видео на канале cleverdata стал каким-то безумным - видимо финансовый год подходит к концу и настала пора пиарить успехи. Вот Grab отчитался, как starrocks ускорил построение отчетов в superset по сравнению с trino. И смешно видеть опять историю про написание своего гейтвея к трино - все говорят про это узкое место (и авито говорило при внедрении, и тинек), и вместо стандарта каждый пилит свое. Вообщем примерно в 10 раз быстрее стало - можете сами посмотреть

Для тех, кто не любит видео есть слайды

Из своего опыта тоже набрали кое-что, попозже напишу.

Кому бы дать деньги

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

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

И да, это пост - не реклама (не видать мне мерседеса еще долго видимо) :)

Про стриминг (в последний раз)

Пожалуй пора закрывать историю с интеграцией кафки - основные подводные камни изучены, лимиты найдены, но источник лимитов нет :)

Часть первая про ограничение количества задач на загрузку.

Добавляя один поток за другим наконец уперлись в первый лимит - max_routine_load_task_concurrent_num. В starrocks по умолчанию значение этого ключа равно 5, и общее количество задач на загрузку равно значению ключа, умноженному на количество FE нод. В случае дефолта с 3 нодами - совсем не густо потоков запихнуть можно. Почему так? Вот тут есть рекомендации по оптимальной настройке загрузок, основной упор - routine load начнут забирать много ресурсов, которые лучше пустить на полезную работу по расчету запросов. Если вдуматься, то вполне согласен. С другой стороны мониторинг ресурсов кластера показывает, что ни память, ни процессор не утилизированы даже на 5-10% (если мы говорим про время, когда не идут запросы). И еще если посмотреть на аналогичные настройки в doris - там значение ключа выставлено в 1024. То есть вам надо сильно постараться, чтобы упереться в этот самый лимит. И тут либо ребята из апача упоролись в оптимизацию, либо ребята из ср перестраховались. НО, 1024 вы точно никогда не достигните потому что

Часть вторая про UX.

Начиная с 10+ задач routine load администрировать становится очень неудобно. Задачи привязаны исключительно к схеме (если посмотрите в документацию все команды работают только в пределах одной). И, например, при обновлении кластера поймали историю, когда несколько задач остановилось, а часть работает, и пойди найди что где как. В итоге требуется или все загрузки размещать в одной схеме, или бегать повсюду - неудобно. Для себя решили, что мелкие проекты будут загружаться встроенным движком, а основной поток по старинке через самопис на go - благо писать всего ничего, назвал starship :)

На этом историю закрываем, пора переходить к CDC из наших mysql.

Не свезло

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

Итого на руках билет за 100к забесплатно, отель, проезд и мелочек бонусов, плюс доклад, который прошел несколько этапов причесывания с тренерами. Неожиданно узнал, что не смартдатой единой жив мир ДЕ - онтико сделали https://datainternals.ru/2025, который пройдет на неделю или две раньше СД :)

Чоб не попробовать и туда... С другой стороны даже видео доклада уже есть в норм стилистике, может нафиг все эти конфы и ютубчик?...

Trino to starrocks

Кстати говоря, случайно наткнулся на встроенный конвертер диалекта трино в старрокса. Это к истории от Grab выше, появился в 3.3.9. Молодцы, ребята, стараются.

Вот откуда ноги растут и куда деньги текут

Очень удивился, когда увидел статью про настройку на сайте dis group. А зря - вот чьё детище селена. Интересно будет подождать успешных проданных кейсов.

А вот нам бы новую БД для аналитиков в платформу приземлить...

Hadoop, clickhouse, k8s и даже greenplum с cassandra — в какой момент набор кубиков на доске архитектора становится платформой данных? В своём докладе расскажу, как наша команда нашла путь не умереть от кучи «модных» технологий. Пример внедрения китайской «серебряной пули» Starrocks покажет, какие вызовы стоят перед современными он-прем аналитическими базами данных и корпоративными платформами.

Спасибо ребятам из Екатеринбурга - там нашлось местечко для доклада, прям как будто меня ждало последнее :) Всегда хотел там побывать.

Superset и k8s

Картинка найдена в интернетах по запросу "k8s helm hell" и она крайне точно олицетворяет мое состояние после общения с этим современным стеком, платформами и всем остальным.

А в подробностях, helm чарт для superset от самого superset падает из-за проблем с psycopg2-binary. Причем в самом чарте по умолчанию выбран постгресс. И даже ишью есть. Но не помогает, версии 0.14 все кривые.

Ладно, подумал я. И правда, разве умеют эти программисты писать нормальные чарты для своих сервисов. То ли дело bitnami, эти ребята съели пуд соли и там будет стабильно.

Релиз от 4 апреля падает на этапе разворачивания постгресса - формат директории с данными от 14 постгресса, а запускается 17.

И даже чатгпт не поможет, все надо сжечь...