Вопросы, которые постоянно возникают вокруг пайплайнов Spark, dbt и Flink — те же самые, что сформировали то, что реально проверяет движок правил opti-pipe.
Флаг --deploy-mode в spark-submit решает, где запускается драйвер — а client mode незаметно привязывает выживание продакшен-задачи к тому, что бы ни отправило её.
Движок исполнения Spark идентичен независимо от того, что планирует его executor'ы. Реальный вопрос — кто владеет провижинингом и восстановлением после сбоев: Spark, вы или вендор.
Session mode и application mode расходятся ровно в одном измерении: может ли плохо ведущая себя задача утянуть с собой другие. Вот когда каждый из них правильный выбор по умолчанию.
Нативная интеграция Flink с Kubernetes значит, что сам Flink обращается к Kubernetes API, чтобы управлять своими подами TaskManager — значимо другой деплой, чем просто запуск Flink в контейнере.
dbt run просто выполняется один раз и завершается — у dbt нет мнения о планировании. Вот что реально берут на себя dbt Cloud, свой оркестратор и обычный cron.
dbt намеренно разделяет «что строить» и «куда подключаться» на два файла. Вот как profiles.yml и env_var() должны держать креды вне git.
Модель может отработать чисто на таблице, которая не обновлялась три дня. Вот как sources.yml и dbt source freshness ловят это, вместо того чтобы молчать.
Настройки Flink по умолчанию годятся, чтобы быстро запустить задачу в dev, но не чтобы пережить реальный рестарт с реальным объёмом состояния. Вот как на самом деле работают state backend и хранилище чекпоинтов.
Поведение рестарта Flink по умолчанию рассчитано на редкий сбой, а не на по-настоящему сломанный деплой. Вот чем на самом деле различаются fixed-delay, exponential-delay и failure-rate.
Одного spark.dynamicAllocation.enabled=true обычно недостаточно. Вот предпосылка про shuffle-сервис и границы min/max, которые реально заставляют dynamic allocation работать.
Spark UI — это просто визуализация того же файла. Вот что в нём реально есть, и однострочная команда jq, которая даст те же цифры быстрее.
Каждый запуск dbt пишет этот файл в target/, открываете вы его или нет. В нём уже есть ответ на вопрос «какая модель медленная».
«Завершилось без ошибок» и «мы использовали кластер, за который платим» — два разных утверждения. Вот как понять, о каком из них на самом деле речь.
Broadcast join — это ставка на то, что одна сторона join'а достаточно мала. Когда ставка верна — это самый быстрый join в Spark, когда нет — самый быстрый способ уронить driver по OOM.
Задача может упираться в I/O, но выглядеть упирающейся в вычисления на любом дашборде, который отслеживает только CPU — узкое место реально в открытии файлов, а не в чтении байтов.
API метрик Flink возвращает десятки счётчиков на таск. Вот короткий список, который реально отвечает «всё ли в порядке», и почему остальное может подождать.
Checkpoint, который тихо истекает под нагрузкой, не роняет задачу — он просто оставляет вам гораздо более широкое окно восстановления, чем вы думаете.
Изменение схемы или неверно настроенный on_schema_change может незаметно вынудить полную пересборку таблицы при каждом запуске — без ошибки, просто гораздо более долгий запуск и больший счёт.
Спекулятивное выполнение перезапускает медленные задачи на предположении, что они — аутсайдеры. Хорошая ставка для сбойного узла и плохая для перекоса данных — вот как понять, что у вас.
У OOM драйвера и OOM executor'а почти нет общих причин, хотя первое, что все пробуют — одно и то же: увеличить настройку памяти.
ClickHouse стал первым партнёрским v2-адаптером на платформе dbt, работающим на новом движке Fusion на Rust — вот что реально доступно уже сегодня.
В девяти случаях из десяти дело не в коде. Дело в данных, кластере или конфигурации, которая незаметно перестала соответствовать одному из них.
Универсального правильного ответа нет, но есть разумная отправная точка — и, что важнее, способ понять, что ваши текущие цифры неверны.
«Просто увеличьте память executor'а» решает проблему примерно в половине случаев и впустую тратит деньги в другой половине. Вот как понять, какой у вас случай.
Не все рычаги экономии несут одинаковый риск. Вот порядок, который даёт реальную экономию прежде, чем вы тронете что-то, способное действительно сломать пайплайн.
Перекос невидим в агрегированных метриках и очевиден в метриках по отдельным задачам — нужно просто смотреть в правильное место.
Правильный размер кластера — не число, которое вы выбираете один раз, а политика, которую вы настраиваете исходя из того, как нагрузка реально себя ведёт, и пересматриваете по мере изменения этого поведения.
В проекте dbt время выполнения и счёт за хранилище — почти одна и та же метрика под разными именами: исправление одного обычно исправляет и другое.
Backpressure — не баг, который нужно устранить, а Flink, честно указывающий вам, где реальное узкое место в пайплайне.
Dev-окружение обычно не врёт напрямую — оно просто отвечает на другой вопрос, чем тот, что важен в продакшене: «работает ли это», а не «работает ли это при данных в 50 раз больше».
Полноценные observability-платформы решают эту задачу, но это слишком много платформы для вопроса, который обычно сводится к четырём-пяти цифрам, движущимся не в ту сторону.
Счёт не подскакивает из-за одной плохой задачи — он ползёт вверх из-за нескольких настроек, заданных один раз при запуске и больше не пересмотренных. Вот с чего начать.
Статьи не найдены.