DataFrame против RDD: Catalyst и Tungsten

RDD гибкий: в нём могут лежать любые объекты Python, а функции в map и filter делают что угодно. Но за гибкость приходится платить. Spark не знает, что внутри ваших кортежей и лямбд, и поэтому не может ничего улучшить: он честно выполняет функции строка за строкой. В Spark 2.0 главным интерфейсом стал DataFrame, и с тех пор почти весь код пишут на нём. Разберём почему.

Рецепт и заказ в ресторане

Есть два способа поесть. Можно отдать повару рецепт: «возьми три яйца, разбей, взбей вилкой, вылей на сковороду». Повар сделает ровно это, даже если взбивать миксером быстрее, а яйца уже стоят взбитыми в холодильнике.

А можно сказать официанту: «омлет из трёх яиц». Вы описали результат, а как его получить, решает кухня. Она знает, что есть миксер и заготовки, и сделает быстрее.

RDD это рецепт. DataFrame это заказ.

DataFrame знает схему

DataFrame это распределённая таблица со схемой. Spark знает имена и типы колонок, а операции вы описываете выражениями, которые Spark умеет читать: F.col("status") == "delivered", а не лямбдой.

Это даёт ему две возможности, у которых есть имена.

Catalyst это оптимизатор. Он берёт план, построенный из ваших операций, и переписывает его по правилам. Фильтр он переносит к самому чтению файла, чтобы лишние строки не поднимались. Из Parquet он читает только те колонки, которые используются. Для соединения таблиц выбирает способ по их размеру. Вы пишете как удобно, а выполняется как быстро.

Tungsten это движок исполнения. Строки DataFrame хранятся не как объекты Python и не как объекты JVM, а в компактном двоичном формате. А цепочку операторов Spark склеивает в одну сгенерированную функцию, которая проходит по строкам без лишних вызовов. В плане такие склеенные куски помечены звёздочкой и номером: *(1).