Отношения между Spark и Parquet (и другими колоночными форматами) можно вкратце описать так:
– Мама, можно нам домой doExecuteColumnar?
– У нас есть дома doExecuteColumnar.
*doExecuteColumnar дома: ColumnarToRowExec.*

Несмотря на значительные усилия разработчиков Spark по внедрению колоночной модели вычислений, на практике пользователи часто наблюдают преобразование колонок в строки в плане запроса и дальнейшее выполнение операций над ними. Для тяжелых аналитических нагрузок данный подход имеет определенные недостатки.

Чтобы понять причины такого поведения и выяснить, можем ли мы его контролировать, нам надо сделать шаг назад и разобрать текущую модель вычислений в Spark: данные (строки, колонки, партиции, JVM-объекты, внутренние структуры и типы даных Spark, Arrow) и их обработка (Columnar Execution, WholeStageCodeGeneration), связав эти понятия в единую картину. Рассмотрим, как из примитивных конструкций формируются распределенные коллекции, и как нам их приручить, чтобы писать более оптимальные приложения. Обсудим нюансы и детали связанных концепций: кеширование, шаффл, некоторые трансформы. В конце проведем небольшое сравнение архитектуры Spark и смежных фреймворков: Databricks Photon, Apache Comet, Apache Gluten.