Комментарии 14
2. Тут идет речь о ETL, а «любая промышленная СУБД» сама по себе — так себе инструмент для ETL, к ней еще придется рядом кластер пристроить, который этим будет заниматься. Впрочем, тут могут быть разные мнения.
3. При этом кластер хадуп — это одновременно хранилище, и процессорные мощности для обработки, причем в любом разумном сочетании пропорций, какие мы сможем придумать.
Банковские транзакции за несколько лет — это сколько по-вашему? Например, в петабайтах?
- Пример есть пример (договора страхования), он не меняет сути
- Многие наши "консультанты" так и говорят — "зачем вам Hadoop, у вас данных мало...". Категорически не согласен: учиться плавать нужно на мелкой воде (не видел ни одного живого, кто делал наоборот, вопреки поговорке), сделать "много" данных мы можем (договоров — не так много, но это не единственная сущность), но что мы с ними будем делать (как только они не смогут быть переработаны "промышленной СУБД")
- Полностью поддерживаю комментарий ниже — hadoop не только база, но и возможность параллельной обработки. Консультанты (особенно со стороны "промышленных СУБД") часто про это зачем-то забывают.
а как я был скептичен (в юности разрабатывал параллельную файловую систему для немецких MPP суперкомпьютеров): распределенная файловая система? на Java? В user space? да ладно!
Но — блин мне — работает. Особенно радует spark: как он так быстро молотит, до сих пор удивляюсь.
Будет задачка (просто так обычно не получается ощутить) — попробуйте, интересно.
На мой взгляд, вы упустили много чего еще. Первое что приходит в голову — код ETL, написанный на API Dataset, намного лучше тестируется, чем код, написанный в форме SQL запросов. Во-вторых, в промежутках между формированием датасетов (я бы называл их так, потому что во 2 спарке это все-же в первую очередь Dataset, а не DataFrame) вы можете кое-что померять, и принять решения о ходе дальнейшей обработки. Например, репартиционировать промежуточные результаты в зависимости от их размера, числа доступных ядер, и возможно других параметров. А также возможно поменять находу параметры спарка, такие как spark.sql.shuffle.partitions, например. Ну и наконец — создавая Dataset при помощи API, вы намного легче сможете добавить например условия фильтрации, если у вашей таблицы (или файлов в HDFS) есть партиционирование, которое вы можете применить. Сделать тоже самое в запросе конечно можно — но обычно сильно менее удобно.
Производительность dataframe и sql подходов эквивалентна (об этом пишу), оба компилируются в rdd (по определению), из этого следует, что теоретически можно написать такие трансформации rdd, которые невозможно будет выразить через sql/dataframe.
Но практика — наверное — в том, что оно не всегда того стоит (писать на низком уровне), у меня (пока) нет данных, чтобы нормально дискутировать дальше в этом направлении...
Apache Spark, lazy evaluation и многостраничные SQL запросы