У нас в компании любят стриминг и любят CDC. Какие требования к функционалу влечет этот подход?
- быстрые(дешевые) операции delete и update
- невозможность использования движков над объектными хранилищами
- транзакции для операций вставки хотя бы на уровне таблиц
- возможность выполнять джойны, которые не вмещаются в память

Казалось бы, vertica закрывает все эти вопросы (с достаточно сильными ограничениями в пункте 1), но непонятные перспективы развития, плата за потребляемое место и отдельный весомый счет за техническую поддержку заставляли искать замену. И если 3-4 года назад на рынке кроме greenplum альтернатив не было, то все изменилось после появления StarRocks.
Тут стоит раскрыть, почему не слива и почему не дорис, ведь оба существуют на рынке достаточно давно.

Почему не Apache Doris

В дорис существует 3 основных и несколько дополнительных(типа работы с внешними каталогами) движков для работы с данными. До 2022 года основной движок Unique Key мог похвастаться только MoR (merge-on-read) механизмом для мутаций, все как в кликхаузе с его загонами. И только в 1.2 был реализован MoW (merge-on-write), который на порядки увеличил скорость таких операций.
И тут минутка про StarRocks: форк произошел задолго до добавления этого функционала, и они не стали переделывать текущую реализацию написав новую - Primary Key. Именно поэтому сейчас функционал Unique Key таблиц в обеих базах сильно отличается, хотя носит одинаковое название. Не знаю кто у кого подсмотрел реализацию, но сейчас по функционалу Unique Key в Doris и Primary Key в StarRocks - близнецы. Быстрый upsert по умолчанию с возможностью partial update во время вставки. Больше прочитать про реализацию можно здесь.
Но такое эволюционное развитие играет злую шутку - помня все старые ограничения движков и не учитывая бешенное развитие проекта, для меня он ушел в тень StarRocks. А еще мне понравились цифры с доклада авито с смартдаты за 2023 год - если честно я так и не понял причины выбора ими trino.

Почему не Greenplum

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

Неделя просто выносит по уровню загрузки :(

Apple Silicon + современные аналитические базы данных

Из свежего: развернуть локальное окружения для разработки с участием StarRocks занимает копейки на любой известной платформе: в kind на новых маках без проблем поднимается all-in-1 образ самой базы данных, следом накатываются миграции, и следом дбт прокатывает свои сиды с моделями.

А вот vertica... Даже самая последняя 24.1 (или как там их новая система релизов выглядит) не имеет такой возможности. 2 дня прыжков вокруг нее. Причем эту особенность можно обойти через композ, так как он способен поднять образ с другой платформой, а вот в кубике никак нет :(

Кстати, а clickhouse поднимается на армах?

Современный LakeHouse

Тренд последних лет у больших ребят - соединить объектное хранилище с основным аналитическим. Ибо ну сколько можно туда-сюда копировать, нет сил больше терпеть :) И именно тут врывается presto, trino, а теперь и doris с starrocks. И не будем здесь вспоминать про готовые движки в clickhouse и greenplum, которые вполне себе быстро читают, но не могут записать.

За что же выбрать StarRocks

Он предлагает на выбор 2 варианта:
1. Работа с внешними каталогами и открытыми форматами хранения. То есть просто подключаешь HMS своего любимого хадупчика (или другую дичь всяких айсбергов) и можешь читать, считать и записывать данные обратно. Причем доступ к данным настраивается дополнительно на уровне самой базы данных с гранулярностью в таблицу. Почитать больше можно здесь. И вокруг будет еще огромная куча внешних каталогов вплоть до JDBC.
2. Работа внутреннего формата данных поверх объектного хранилища. Как раз для ребят с большим количеством данных или перекосом горячих/холодных - когда количество вычислительных ресурсов разбалансированно относительно ресурсов хранения данных. Для хранения можно использовать только S3-like с версии 3.1 S3 как вендоров, так и открытые реализации типа minio, либо HDFS. Тут все должны понимать, что скорость будет равна количеству хаков в обработке и размеру горячего хранилища для кешей. Почитать больше можно здесь.

При всем этом в кластере StarRocks используется 2 типа инстансов для хранения и вычислений над данными: backend nodes and compute nodes. Отличаются они тем, что BE хранят данные локально на себе, а CN используются только для расчетов. В варианте один можно использовать оба типа нод, в варианте 2 так как локального хранения нет используются только CN.

Минутка практики

Для себя мы выбрали вариант 1. Скорость работы с хадупом через HMS позволяет отказаться от использования spark в ad-hoc запросах и сильно упрощает требования на клиентской стороне: mysql драйвер или собрать какой-нибудь pyhive в питоне - две больших разницы.

Поддержал рублем Алексея, все-таки с его докладов пришло понимание о выжигающей роли современного скрама.

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

Так что по сути вся книга - опечатанные в буквы выступления с хорошей полиграфией. Очень много слышал и видел, и если не хочется тратить часов 10-15 на просмотр ютуба - то, что надо для понимания канбана.

Порой подробности релизов пугают

2 недели назад вышел новый релиз StarRocks в ветке 3.3 - 3.3.5. Список изменений можно посмотреть по этой ссылке
Классно, подумал я, пора читать и обновляться и на первом же пункте я выпал в осадок:

Supports millisecond and microsecond precision in the DATETIME type.

Моя потоковая загрузка работает уже больше 2 месяцев, и в ней крайне важно наличие миллисекунд. И даже не так давно я делал пост, как ошибся с округлением. И миллисекунды в данных точно есть. Но добавили их только в 3.3.5. Что происходит то...

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

select distinct(id) from table

Одна из двух самых плохих вещей, на мой взгляд, что присутствуют сейчас в StarRocks - это проблема выполнения конкурентных запросов. Если 2 запроса пришли одновременно и оба требуют большую часть предоставляемой памяти, то упадут с сообщением о нехватке ресурсов они ОБА. Это просто ужас какой-то, почему не первый из них, почему не последний из них, почему не случайный? Столько вопросов, и ответ можно найти только в кодовой базе.

Поймал эту ситуацию на запуске тестов в dbt с threads = 5: unique на двух таблицах с единицами миллиардов значений на ограниченном по ресурсам пуле. Знаю, что плохо писать такие тесты, но в коробке dbt нет уника с ограничениями :)

Как оказалось вообще, такие запросы - самое слабое место для SR и в документации есть несколько разделов и способов для их оптимизации:
- битмапы для каунта дистинктов
- апроксимизация для каунта дистинктов
Так что если жить не можете без таких запросов на сотни миллионов, а еще лучше на миллиарды строк - то дважды подумайте стоит ли использовать StarRocks 😂

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

dbt docs

Мы достаточно давно живем на dbt docs в качестве единого места документации данных и метрик, и даже делали доклады на митапах. И всю дорогу ехали на предельно примитивном решении с поднятием эндпойнта `dbt docs serve`. Поборовшись в openmetadata в последний раз пару дней и оценив рынок каталогов данных, приняли решение и дальше использовать dbt в качестве единого сервиса документации.

Но у него есть 2 достаточных недостатка:
- скорость работы
- качество поиска

Проблему поиска без елки в составе решить сложно, но ее включение сразу ставит ресурсоемкость сервиса на один уровень с той же опенметадатой. А вот ускорить отдачу статики - это низко висящий фрукт. Я уже как-то делился в канале статьей ребят из дагстера, в которой они перепилили весь фронт и сократили время открытия страничек в доке до миллисекунд: https://dagster.io/blog/dbt-docs-on-react Но и проблем там хватает - чудовищный размер получаемого артифката (вместо мегабайт на выходе сотня мегабайт), отсутствие lineage на страничках, сложность сборки артефактов.

В итоге сделав все по заветам доки dbt - выставив перед 3 статичными файлами nginx с хорошей степенью сжатия удалось добиться вполне удовлетворительных результатов: размер манифеста на тестируемом проекте при передаче уменьшился с 2,5 мегабайт до 240 килобайт, время открытия странички сократилось с 10 секунд до меньше чем 1 секунды.

Стоило ли это сделать раньше? Пока на горизонте маячили крутые каталоги данных - оставалась надежда. Теперь ее больше нет - dbt наше всё :)

Вторая плохая вещь в StarRocks

Если почитать чатик https://news.1rj.ru/str/hadoopusers, то почти все при слове StarRocks начинают рассказывать про китайский язык, отсутствие сообщества и отсутствие успешных внедрений в компаниях 1 ранга в своих отраслях. И кажется, что это и есть та самая вторая плохая вещь.

Но нет.

Документация в проекте находится на достаточно зрелом уровне, в крайнем случае в вашем доступе есть гитхаб с примерами кода - например, транзакционная загрузку через API там есть в 3 или 4 вариантах. Или вот есть репа с demo.
Китайский язык вам понадобится только в случае жесткого дебага, скорее всего вы уйдете на китайские форумы где уже встречали такие баги. Но опять же, документация на английском + код покрывают этот кейс.
История про внедрения: ютуб завален видосами. Там и про сравнение с кликхаузом, и про будущее датабрикс + старрокс, и про опыт внедрения в компаниях разного масштаба. Не говоря о росте вакансий на hh.ru - там теперь целых 5 вакансий по сравнению с 1 в конце лета 😂

А теперь серьезно: я наткнулся на регресс в ветке 3.3 по отношению к 3.2 - констрейнты просто не работали :) 9 сентября создал ишью, через 15 минут баг подтвердили, на следующий рабочий день был готов код с фиксом, и итоговая версия с фиксом вышла через пару недель.

Ребят, да ладно, кто из вендоров сейчас вам настолько быстро поможет? :) Мертвый чат вертики? Разработка кликхауза, в которой транзакции не могут победить 5+ лет? :)

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

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, кучка в вертику дбт, что-то в спарк дбт, что-то в цеппелин, и так с десяток реп. И иногда прямо стреляет :(