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

 Mysql диалект

Ожидания оправдались на 85%, на текущий момент существует такие отличия:
- ddl создания таблиц отличаются сильно
- prepared statement существую, но в очень специфичном виде
- в основных десктопных клиентах (dbeaver, datagrip) обрезаются миллисекунды для datetime. И это странно, потому что по стандарту для mysql они могут там быть

Cервисы миграций

В итоге пришлось дописывать поддержку диалекта в отличный гошный проект goose (и не смотря на небольшое сопротивление диалект был добавлен быстро под давлением сообщества - сюрприз, сюрприз). Картинка как раз из него.
Если вам не нужен монстр типа Liquibase, а надо просто чтобы работало всегда и везде - советую. Особенно совместно miga, в которой достаточно прописать в конфиге подключение к базе данных и указать путь к каталогу с миграциями.

#офтоп

Я знаком с питоном последние лет 10, а за код на нем получаю деньги уже лет 8. Но только примерно год или полтора назад ощутил, что его уровень сильно повысился до приемлемого уровня. Когда ты уже не скрипт программист, а нормальный писатель уровня мидл. И дело не в том, что мне стали сниться сны на asyncio или я стал рассказывать устройство GIL детям перед сном вместо сказки, а скорее вышел рывок в понимании как легче код будет прочтен, как идеоматично писать тот или иной кусок. Есть несколько причин, среди которых и работа на golang, и книга с фотографии выше. Ее чтение мне доставило большое удовольствие, несмотря на простоту или размеры, и даже приходилось себя останавливать в скорости чтения для лучшего усвоения.

А вот вторую книгу я прочитать не смог. Там котики, там лёгкая подача материала, там важные вещи. Сейчас активно выходят видео докладов с прошедшего codefest, среди которых очень зашёл Макс Дорофеев. Раньше это слегка мучило, стоит и смотрит на меня - а теперь спрячу ее подальше :)

Хорошо ходить в отпуск, пусть даже отпуск и в ноябре :)

Apache Doris vs Starrocks

Для человека со стороны различия между двумя этими базами данных совсем непонятны. И вот уже более 3 недель готовился написать статью о различиях: в каком случае выбирать одно, а в каком другое.
Но время решает за нас - развитие обеих баз летит вперед как starship Элона Маска, и 2 важных отличия между ними, которые привели к выбору starrocks для внедрения, обнулились :( То есть в марте-апреле даже вопроса для движка нового поколения lakehouse/dwh не стояло, то в ноябре надо тестировать и ванговать кто победит в гонке за общественное мнение в будущем.
Вот такой вот спойлер следующего цикла постов про причину выбора starrocks и краткого описания аналогичного функционала в doris.

Минутка истории

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

Да, прошло четыре года с момента первого форка. И Apache Doris, и StarRocks выросли и развились по-своему. Хотя у них много общих функций, они достигли разных уровней зрелости, что мы признаем.

Кратко: 4 года назад часть разработчиков Apache Doris отделились и захотели развивать его по своему (и надо сказать, что сам дорис 4 года назад представлял не очень веселое зрелище по темпам развития). Так появилась сначала DorisDB, а из нее Starrocks. И если вы посмотрите в документацию, то много различий там не найдете. Особенно сейчас, когда в обе базы стали вливать много, очень много ресурсов и денег.

У нас в компании любят стриминг и любят 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 есть еще интересный тезис в статье, но и так многа букф, оставлю на потом