ReadOnly is ok

For AWS, this is not possible. But the main question is "Why you need it?" ?

And this discussion looks like offtopic for this channel..

cheap data replication for cloud computing

"attach the same SSD" paradigm instead of BD-paradigms "move code to data" (and vice versa) ?

not for true BD but ...

Guys, who knows: is it possible to attach one SSD to multiple instances (GC? Azure?etc) at the same time?

I am not sure if it fits your requirements, but the most obvious option is to use NFS or iSCSI

latency is crucial

IOPS, etc

"attach the same SSD" paradigm instead of BD-paradigms "move code to data" (and vice versa) ?

how such 'dual' ssd interface should be implemented? o: // or can

Всем приветик есть ли программка для дебага апаче лог файла? У меня лог в 1,8гб и более 4м. Строк...

latency is crucial

In this case I would not recommend to use shared drive. This will always become bottleneck eventually

Ответ Желательно в пм

In this case I would not recommend to use shared drive. This will always become bottleneck eventually

It depends on data traffic profile, data consumption pattern.

And the real scale of the problem

Cloud instances can be located on any node in the datacenter. It looks impossible from a physical point of view.

thats why I said "not for true Big Data but.."

not for really large scale problems

You can order nodes with high network bandwidth )

It depends on data traffic profile, data consumption pattern.

Why did you decide not to use something like redis?

If latency is really crucial, do not use storage

RAM is way better

agree

found something

https://cloud.google.com/compute/docs/disks/add-persistent-disk#use_multi_instances

Also, if u use shared drive, u will face consistency, concurrent access and other problems u will have to manually resolve

If you attach a persistent disk to multiple instances, all of those instances must attach the persistent disk in read-only mode.

https://cloud.google.com/compute/docs/disks/add-persistent-disk#use_multi_instances

I believe it is based on iSCSI

I believe it is based on iSCSI

Under the hood?

maybe

Yes, under the hood

Also, if u use shared drive, u will face consistency, concurrent access and other problems u will have to manually resolve

read only mode gives me low or moderate risks.

For AWS, this is not possible. But the main question is "Why you need it?" ?

I want to copy a file from my PC to Hdfs for hive to put that data on to a table.

I want to copy a file from my PC to Hdfs for hive to put that data on to a table.

Use scp + hdfs put

scp to upload file to hadoop data node and hdfs put to upload it to hdfs

this is the easiest way

I believe you can also use S3 for that

When MySQL is used and when Derby is used as metastore for hive

Помимо newprolab есть ещё какие-нибудь нормальные очные курсы в Москве?

По Hadoop.

У hp посмотри

http://tiledb.io/

oO

пробовал уже?

пробовал уже?

не, но задумываюсь в диссер

я попробую посмотреть ближе к выхам

интересная шляпа

http://tiledb.io/

интересно, кто попробует не поленитесь плиз рассказать

Ну, что, вы так долго жадил (а вы ведь ждали?), так получите! Новый, офигенный, крутой Moscow Spark #3 https://rambler-co-e-org.timepad.ru/event/604814/

Ну, что, вы так долго жадил (а вы ведь ждали?), так получите! Новый, офигенный, крутой Moscow Spark #3 https://rambler-co-e-org.timepad.ru/event/604814/

занимайте скорее, а то сбербанк все места займет!

+1

Сбербанк не дремлет!

Можно ли как-то красиво и удобно отключить HDFS-команду? distcp, например.

Снять exec флаг на команду hadoop и обернуть ее вызов в свой скрипт?

Снять exec флаг на команду hadoop и обернуть ее вызов в свой скрипт?

К сожалению не красиво и не удобно.

Есть кто уже перешёл на стракчеред стримминг в спарке и решил не возвращаться?

Есть кто уже перешёл на стракчеред стримминг в спарке и решил не возвращаться?

пока как-то ощущения так себе. думаю переписать джобу на флинк

пока как-то ощущения так себе. думаю переписать джобу на флинк

а был опыт с агрегацией в какой-нибудь паркет ? ну есть поток, и скажем раз в час сливать в партицированный паркет его ( микробатч час )

или через базу агрегировали

Есть кто уже перешёл на стракчеред стримминг в спарке и решил не возвращаться?

те кто в 1.6 rdd в датафреймы превращает считаются?

те кто в 1.6 rdd в датафреймы превращает считаются?

не, как считать

если там(2.2) синки появились и прочие вкусности

ок, так то мы датафреймы пишем в орк партиционированный на стриминге

ок, так то мы датафреймы пишем в орк партиционированный на стриминге

микробатч в час? ( в смысле большие микробатчи )

не, мы не такие рисковые парни

ну в смысле большие

микробатч в минуту у нас

а проблему большого количества файлов как решаете?

оффлайн компакшен

месяц прошел - по старым данным read, repartition, write

у меня схема такая: данные из кафки агрегирую в пятиминутные окна, сливаю в другой топик кафки. потом раз в сутки агрегирую уже из этого топика обычным спарком почему не делаю окна больше - периодически дохнет чекпоинт (есть бага в 2.2, сейчас не нашел ссылки на этот issue), приходится перезапускать с удалением чекпоинта. меньше окно - меньше потеря данных при перезапуске вторая проблема - чекпоинт генерит нездоровое количество мелких файлов, что не айс для hdfs. наверное можно перенести папку чекпоинта на обычную файловую систему, но кажется не лучшим вариантом сама запись в паркет идет без проблем - как с обычным датафреймом. проблема в том, что до момента записи данные лежат в чекпоинте, что хреново по вышеуказанным причинам дисклеймер: возможно это у меня кривые руки и кто-то сможет докрутить до нормального состояния

ну и меня напрягает отсутствие ветвления потоков. хочешь другой агрегат - читай заново, начиная с самого источника

оффлайн компакшен

тож отдельна яджоба?

ага, кроном)

ага, кроном)

у меня так и будет!

ну вроде норм, чо)

ага, кроном)

Точнее, кроном 2.0! (с) @optician_owl

distributed strongly consistent cron 2.0 *

я смотрю, все примерно одни и те же костыли делают ?

нуачо, работает жи

я уже как только не пробовал

какое у тебя количество файлов на hdfs ?

теперь думаю в hbase писать с ttl и оттуда выгребать уже

какое у тебя количество файлов на hdfs ?

порядка нескольких миллионов блоков

теперь думаю в hbase писать с ttl и оттуда выгребать уже

это не плохая идея