NK
Ну, если, например, хранилище, которое внизу - это ClickHouse, то прав ли я, что мне не очень-то нужен Spark?
Size: a a a
2018 July 02
ЕГ
Не знаю, можно ли назвать это успехом, но у нас один товарищ одним sql-запросом нагенерил 100ГБ/с трафика на внешней СХД, которая использовалась вместо темп-дисков. Думаю, в качестве хранилки её тоже вполне можно использовать, но это $$$)
t
ID:282687363
А не подскажете истории успеха Spark без HDFS/Hive/S3 в качестве источника данных (то есть не когда Spark Streaming пишет куда-то не в Hadoop)? Я что-то навскидку не могу нагуглить.
мне кажется тысячи их
ЕГ
Если уже есть hpc-кластер, то на нём можно развернуть бигдату, но завлабы не отдают свои кластеры😆
t
мы пишем в хдфс, кассандру, ластик, кафку из стриминга
PK
ID:282687363
Ну, если, например, хранилище, которое внизу - это ClickHouse, то прав ли я, что мне не очень-то нужен Spark?
Боря, я буквально на днях тестил спарк поверх кликхауса. Это шняга, почему-то через odbc драйвер не прокидываются оптимизации прямо в клик. Ну и да, коннектора нормального нет, поэтому посчитать что-то быстрее одним кликом.
PK
Но если у тебя есть внешний поток и ты его обрабатываешь в спарке и пишешь в клик, а потом считаешь только кликом, то почему нет
FL
HBase, Accumulo, Cassandra нормально работают в качестве источников. ES тоже работает. Видел, люди пытаются Ceph вместо HDFS прикрутить.
AP
ID:282687363
А не подскажете истории успеха Spark без HDFS/Hive/S3 в качестве источника данных (то есть не когда Spark Streaming пишет куда-то не в Hadoop)? Я что-то навскидку не могу нагуглить.
Зависит от конкретного storage, точнее, реализации соответствующего коннектора. Например, для Cassandra или MongoDB относительно нормальные. Один из критериев - насколько эффективно работает pushdown нагрузки.
FL
Надо понимать, что разделяя вычислительные ресурсы и хранилище, ты теряешь преимущества от data locality. При хорошей сети это не критично, а при плохой - ...
NK
мы пишем в хдфс, кассандру, ластик, кафку из стриминга
да, истории успеха по записи Spark Streaming-ом куда-то я видел. Вопрос был именно про чтение из.
NK
Боря, я буквально на днях тестил спарк поверх кликхауса. Это шняга, почему-то через odbc драйвер не прокидываются оптимизации прямо в клик. Ну и да, коннектора нормального нет, поэтому посчитать что-то быстрее одним кликом.
мне вот тоже не понравилось читать из CH Spark-ом:(
AV
Для Spark внизу может быть любая BigTable-подобная базюка (если под нее уже написан годный конектор). Тогда данные хранятся в ней.
То есть БД должна быть исходно заточена под то, чтобы из нее вычитывали/записывали данные большими батчами.
То есть БД должна быть исходно заточена под то, чтобы из нее вычитывали/записывали данные большими батчами.
AV
Про CH: в него надо писать уже денормализованные и подготовленные данные. Делать серьезный ETL поверх CH то еще извращение.
PK
Про CH: в него надо писать уже денормализованные и подготовленные данные. Делать серьезный ETL поверх CH то еще извращение.
Тем, Боря про чтение, вроде
AV
Я про это же и говорю.
Просто чтобы не нужен был Spark, в CH нужно до записи в него готовить данные.
Просто чтобы не нужен был Spark, в CH нужно до записи в него готовить данные.
NK
HBase, Accumulo, Cassandra нормально работают в качестве источников. ES тоже работает. Видел, люди пытаются Ceph вместо HDFS прикрутить.
Да, забыл ещё эти слова:) Но в них совсем не силён. И мне казалось, что хороший HBase/Accumulo не бывает без HDFS? 🤔
AV
AV
Неправильно прочитал вопрос.
Можно использовать без HDFS
Можно использовать без HDFS
NK
@art_vybor, @fediq, @pklemenkov спасибо. Про то, что если хранить где-то совсем сбоку, то теряется локальность данных, и про то, что на CH сложно делать ETL от сырых данных до сложных агрегатов, но если кто-то добрый уже записал, то CH проживёт из без Spark - хорошие пойнты:)