Почему обработка данных из data lake может быть недостаточно быстрой?

Trino позволяет читать данные в открытых форматах (ORC, Parquet, и т.д.) из HDFS и S3-совместимых хранилищ. Одна из потенциальных проблем — высокие сетевые задержки. Частично проблема решается уменьшением количества читаемых данных за счет оптимизаций filter pushdown и aggregate pushdown. Частично — за счет кэширования данных на worker-узлах (например, Alluxio Cache https://docs.alluxio.io/ee/user/stable/en/core-services/Caching.html). Достаточно ли этого? Не всегда. Современные облачные провайдеры позволяют читать данные по сети со скоростями в сотни мегабайт в секунду. Высокая скорость чтения совместно с filter/aggregate pushdown зачастую приводит к ситуации, когда узким местом становится ... CPU.

Форматы ORC и Parquet позволяют разным системам работать с одной и той же копией данных, упрощая и удешевляя инфраструктуру. В то же время, различные движки, будь то Spark или Trino, используют собственное внутреннее представление данных, оптимизированное под архитектуру конкретного продукта. Конвертация данных из открытых форматов в формат целевой системы является дорогостоящей операцией.

Ниже прикреплен flame graph собранный с помощью Async Profiler (https://github.com/jvm-profiling-tools/async-profiler) при выполнении TPC-DS запроса №7 (https://github.com/apache/impala/blob/master/testdata/workloads/tpcds-unmodified/queries/tpcds-q7.test) на scale factor 1000 в облаке Yandex.Cloud к данным в формате ORC. Видно, что значительная часть времени потрачена на перекодирование данных из формата ORC во внутреннее представление Trino (центральная часть flame graph). В том же время, непосредственно чтение данных из S3-совместимого хранилища занимает считанные проценты. Профили других SQL-запросов могут существенно отличаться. Тем не менее проблема траты ресурсов CPU на многократное перекодирование одних и тех же преимущественно immutable данных повторяется от запроса к запросу.

Мы считаем, что локального кэширования данных в оригинальном формате (как это сделано в Alluxio) недостаточно для оптимальной утилизации ресурсов кластера Trino.

Более продвинутым подходом может быть хранение дополнительной копии данных в формате, оптимизированном для Trino. Учитывая низкую стоимость SSD-дисков и облачных хранилищ, подготовленные для Trino данные можно хранить как на локальных SSD, так и в облаке. Внедрение подобной оптимизации позволит пользователям CedrusData эффективно выполнять запросы, используя меньшее количество дорогостоящих CPU.

Мы будем делиться с вами результатами эксперимента по мере разработки прототипа.