Spark гибкий и надо писать код, собирать приложение, сабмитить в кластер

и всё?

автоматизировать это можно

А в presto просто завел подключился и выполнил код

Но меньше задач им решить можно

Короче если задачи решаются только ansi SQL и ctas то престо подойдёт как обработчик, если более сложные вещи нужно делать типа графов, ml, кастомных UDF то в спарк.

У меня сейчас в проде и то и то, но престо в основном для доступа к обработанным данным

А дистрибутив у вас какой?

Был ли опыт интеграции престо с хдп?

Amazon EMR

Spark гибкий и надо писать код, собирать приложение, сабмитить в кластер

Не надо. Откройте spark-sql или цеппелин или из datagrip прицепитесь к спарк трифту или сделайте hive on spark.

И пишите такой же sql как и в престо, только без престо. Под который ещё и отдельные серваки нужны, чтобы он норм работал.

И пишите такой же sql как и в престо, только без престо. Под который ещё и отдельные серваки нужны, чтобы он норм работал.

Да у меня в общем то нет проблем с этими особенностями Спарка

Spark гибкий и надо писать код, собирать приложение, сабмитить в кластер

%spark2.sql в запилине - и не надо ни код писать, ни собирать его потом

Первый раз слышу, чтобы кто-то юзал престо. Ну кроме презенташек втб про "бесшовную интеграцию с терадатой и прочим".

Ноутбуки в проде это не серьезно)

Да, пентахо и прочие датастейджи за $$$ рулят

Вынести spark.sql в кусочек обёртки с датой - неделя работы датаинженера

Чтобы написать свой пайплайн для любого такого процесса

Первый раз слышу, чтобы кто-то юзал престо. Ну кроме презенташек втб про "бесшовную интеграцию с терадатой и прочим".

Нужно было чем то отдавать данные в bi по jdbc, покурили трубку и выбрали престо

Первый раз слышу, чтобы кто-то юзал престо. Ну кроме презенташек втб про "бесшовную интеграцию с терадатой и прочим".

есть тулзы которые умеют только jdbc, например табло, тогда и используют

А под табло разве не надо что-то супер производительное типа вертики?

Первый раз слышу, чтобы кто-то юзал престо. Ну кроме презенташек втб про "бесшовную интеграцию с терадатой и прочим".

А чем вы дашборды рисуете?

А под табло разве не надо что-то супер производительное типа вертики?

нет, смотря сколько данных, нам хватало

А чем вы дашборды рисуете?

Подключать BI к Ходуп-идея, в моём представлении, крайне плохая. В нашей архитектуре BI подключается к традиционной реляционной СУБД.

Возможно, потом появится что-то вроде Ignite + GreenPlum, но это неточно.

А чем вы дашборды рисуете?

И быстро bi работает в таком варианте? Я его соединял с хайвом, но тот ещё мрак

Отлично работает, затык только на больших дашбордах бывает

И вообще, я неаелся говна, делая DWH-звезду в Hadoop. То ещё удовольствие. Больше не буду.

Это при том что данные слабо агрегированные

Поколоночное хранение решает

Никакая реляционка нормально bi не потянет, там так или иначе будет прослойка какая то для хранения агрегатов и прочих кубов

Никакая реляционка нормально bi не потянет, там так или иначе будет прослойка какая то для хранения агрегатов и прочих кубов

Опять орнул.

Ну будет, и что?

Хотя у нас данных не так много, возможно из за этого быстро все ?

Это называется слой витрин.

Опять орнул.

потише, пожалуйста, мы работаем.

Попробуйте в реляционку хотя бы залить 300 млрд записей в одну таблицу)

Попробуйте в реляционку хотя бы залить 300 млрд записей в одну таблицу)

есть такое, в чем проблема?

Попробуйте в реляционку хотя бы залить 300 млрд записей в одну таблицу)

?у меня сейчас так хотят в mysql сделать

Вообще, можно, например ClickHouse, если особо джойнить не надо будет.

И как, быстро заливается?)

Попробуйте в реляционку хотя бы залить 300 млрд записей в одну таблицу)

Во-первых, я и больше заливал. Во-вторых, а вы что, BI на таблице 300 млрд запускаете? Витринки там, то сё?

Во-первых, я и больше заливал. Во-вторых, а вы что, BI на таблице 300 млрд запускаете? Витринки там, то сё?

я вот тож не понял кейс

Вообще, можно, например ClickHouse, если особо джойнить не надо будет.

кликхаус может данные легко угробить

длительное хранение и кликхаус плохая идея

Основная витрина, к ней больше половины запросов идёт

Попробуйте в реляционку хотя бы залить 300 млрд записей в одну таблицу)

когда залью, что мне делать с ней?

кликхаус может данные легко угробить

не, ну в нем витрины а сырье в хадупе А в кликхаусе тройная репликация + бекапы. А почему он данные может угробить? Я с таким не сталкивался.

когда залью, что мне делать с ней?

Как что? Считать агрегаты за полгода для 100 млн юзеров)

длительное хранение и кликхаус плохая идея

кх хорош как сервис слой, а базовый слой в халупе

Основная витрина, к ней больше половины запросов идёт

И что, все вычитывают по 300 млрд? Тогда у меня для вас плохие новости.

Как что? Считать агрегаты за полгода для 100 млн юзеров)

пахнет булшитом в головах аналитиков

кх хорош как сервис слой, а базовый слой в халупе

да, только вот мне в нём или марие надо будет хранить сессии

кликхаус может данные легко угробить

и тут ты такой с пруфами

Как что? Считать агрегаты за полгода для 100 млн юзеров)

ок, Vertica это переварит, КХ скорее всего тоже без проблем

и тут ты такой с пруфами

ну у меня у 4 клиентов на консалтинге он дох с данными, поэтому они в нём ток считать предпочитают и грохать

ок, Vertica это переварит, КХ скорее всего тоже без проблем

А как там по стоимости?

? чет разгорелось, нрмально же общались

А как там по стоимости?

По разному

По сравнению с хдп кластером, в котором спарк крутится

Да да, рядом вот сидят и крутят

Вот только не стоит путать DWH и спарк для RND

да и железки тоже не халява, если уж говорить на чистоту

Да, да, я уже понял , двх - это где хранят данные, а спарк - это где обрабатывают?

что то уже совсем все в кучу слетелось системы для разных кейсов подходящие сравниваются на абстрактных 300млрд записей за абстрактные полгода и на абстрактных аггрегатах

да и железки тоже не халява, если уж говорить на чистоту

а где железки холява

есть тулзы которые умеют только jdbc, например табло, тогда и используют

а спарк что JDBC перестал отдавать?

на 3 ноды вертики навскидку приходится более 10 хадуп серверов

что то уже совсем все в кучу слетелось системы для разных кейсов подходящие сравниваются на абстрактных 300млрд записей за абстрактные полгода и на абстрактных аггрегатах

в общем случае тут и база не нужна, один диск и итератором пройтись

у меня вон фантазёры хотели хадуп на дисках по 12 тб запилить

Да, да, я уже понял , двх - это где хранят данные, а спарк - это где обрабатывают?

давайте не путать, где и что обрабатывают между прочим, обычно как раз наоборот, хадуп хранит, а в хранилище обработка

кстати, именно так сделано у yota

давайте не путать, где и что обрабатывают между прочим, обычно как раз наоборот, хадуп хранит, а в хранилище обработка

Назад в будущее - обработка данных на sql)

Назад в будущее - обработка данных на sql)

кто сказал про sql?

Назад в будущее - обработка данных на sql)

а чем cql лучше?

что-то я совсем запутался

Как встроить бустец на витринке из 5к полей в ваши вертики?

В спарке пишем pandas udf за полдня - и готово

а спарк что JDBC перестал отдавать?

иногда медленно работает, встречаются вот такие косяки: https://issues.apache.org/jira/browse/SPARK-12126

В спарке пишем pandas udf за полдня - и готово

а как тебе взять 90-120к ключей и по ним данных из hbase на магнитках, перетащить в быстрое на ignite и выдать по ним олап, с тенденциями?

выбирайте

иногда медленно работает, встречаются вот такие косяки: https://issues.apache.org/jira/browse/SPARK-12126

Не, jdbc datasource это же вроде про spark.read.jdbc

а как тебе взять 90-120к ключей и по ним данных из hbase на магнитках, перетащить в быстрое на ignite и выдать по ним олап, с тенденциями?

Если нужно что-то быстрее минуты, тут спарк не самый лучший вариант, согласен)

Не, jdbc datasource это же вроде про spark.read.jdbc

вообщем я помню там были заморочки с push down, спарк слишком много вычитывал

вообщем я помню там были заморочки с push down, спарк слишком много вычитывал

Да, такая проблема есть, он не пробрасывает ни лимит, ни сложные условия, которые записаны с использованием спарковских functions

Ну, потому что они тупо бывает не переводятся на ту базу данных, к которой идёт обращение

Хотя могли бы и допилить уже хотя бы лимит-то)

вообщем я помню там были заморочки с push down, спарк слишком много вычитывал

Да, но это можно решить заменой имени таблицы на подзапрос.

Да, но это можно решить заменой имени таблицы на подзапрос.

скажите вот зачем эти заморочки, плюс как это протаскивать в инструмент BI, если есть presto которое работает из коробки?

Никто не сталкивался с копированием файлов с HDFS на S3? При попытке использовать команду: hadoop distcp hdfs://IP:50070/dir/file s3://key:secret@backet_name/data ошибка Caused by: org.apache.hadoop.ipc.RpcException: RPC response exceeds maximum data length пытался менять в core-site.xml значения ipc.maximum.data.length - не помогает.

скажите вот зачем эти заморочки, плюс как это протаскивать в инструмент BI, если есть presto которое работает из коробки?

Я не спорю, что для BI нужны витрины, которые можно вертеть) Каждый раз гонять Spark - это слишком.

Никто не сталкивался с копированием файлов с HDFS на S3? При попытке использовать команду: hadoop distcp hdfs://IP:50070/dir/file s3://key:secret@backet_name/data ошибка Caused by: org.apache.hadoop.ipc.RpcException: RPC response exceeds maximum data length пытался менять в core-site.xml значения ipc.maximum.data.length - не помогает.

Я конечно идиот, но я бы это спарком делал :) (при условии что это какие-нибудь паркеты конечно)

Я конечно идиот, но я бы это спарком делал :) (при условии что это какие-нибудь паркеты конечно)

спасибо, почитаю ?

спарк имееться ?

спарк (имееться)