Apache Spark, lazy evaluation и многостраничные SQL запросы

[sshikov]

1. Опрометчиво судить о реальной базе по игрушечному примеру для статьи.
2. Тут идет речь о ETL, а «любая промышленная СУБД» сама по себе — так себе инструмент для ETL, к ней еще придется рядом кластер пристроить, который этим будет заниматься. Впрочем, тут могут быть разные мнения.
3. При этом кластер хадуп — это одновременно хранилище, и процессорные мощности для обработки, причем в любом разумном сочетании пропорций, какие мы сможем придумать.

Банковские транзакции за несколько лет — это сколько по-вашему? Например, в петабайтах?

[Korolevmv]

Ваш п.3: согласен, это важно, про это забывают (почему-то)

[Korolevmv]

1. Пример есть пример (договора страхования), он не меняет сути
2. Многие наши "консультанты" так и говорят — "зачем вам Hadoop, у вас данных мало...". Категорически не согласен: учиться плавать нужно на мелкой воде (не видел ни одного живого, кто делал наоборот, вопреки поговорке), сделать "много" данных мы можем (договоров — не так много, но это не единственная сущность), но что мы с ними будем делать (как только они не смогут быть переработаны "промышленной СУБД")
3. Полностью поддерживаю комментарий ниже — hadoop не только база, но и возможность параллельной обработки. Консультанты (особенно со стороны "промышленных СУБД") часто про это зачем-то забывают.

[Korolevmv]

а как я был скептичен (в юности разрабатывал параллельную файловую систему для немецких MPP суперкомпьютеров): распределенная файловая система? на Java? В user space? да ладно!

Но — блин мне — работает. Особенно радует spark: как он так быстро молотит, до сих пор удивляюсь.

Будет задачка (просто так обычно не получается ощутить) — попробуйте, интересно.

[Korolevmv]

тут важный момент — параллелизм: если есть сотня железяк, то я бы не взялся просто так соревноваться в обработке данных со sparkом (особенно — согласен — учитывая удобство)…
По бигдате — надо поискать, должна где-то быть (сам пока не искал, но скоро начну).

[sshikov]

>Я, наверное, что-то упустил — поможете найти (в комментариях)?
На мой взгляд, вы упустили много чего еще. Первое что приходит в голову — код ETL, написанный на API Dataset, намного лучше тестируется, чем код, написанный в форме SQL запросов. Во-вторых, в промежутках между формированием датасетов (я бы называл их так, потому что во 2 спарке это все-же в первую очередь Dataset, а не DataFrame) вы можете кое-что померять, и принять решения о ходе дальнейшей обработки. Например, репартиционировать промежуточные результаты в зависимости от их размера, числа доступных ядер, и возможно других параметров. А также возможно поменять находу параметры спарка, такие как spark.sql.shuffle.partitions, например. Ну и наконец — создавая Dataset при помощи API, вы намного легче сможете добавить например условия фильтрации, если у вашей таблицы (или файлов в HDFS) есть партиционирование, которое вы можете применить. Сделать тоже самое в запросе конечно можно — но обычно сильно менее удобно.

[Korolevmv]

спасибо за мысли! думаем и работаем дальше :-)

[kapusta007]

Хотелось бы сравнения производительности etl процесса на dataset-ax и классических rdd например. Насколько дороже (если вообще дороже) выйдет применять sql вместо классических трансформаций в нагруженном spark-streaming приложении.

[Korolevmv]

Производительность dataframe и sql подходов эквивалентна (об этом пишу), оба компилируются в rdd (по определению), из этого следует, что теоретически можно написать такие трансформации rdd, которые невозможно будет выразить через sql/dataframe.
Но практика — наверное — в том, что оно не всегда того стоит (писать на низком уровне), у меня (пока) нет данных, чтобы нормально дискутировать дальше в этом направлении...