Вопрос о Apache Hadoop / чтении файлов с HDFS

[OldTuzik]

Здравстуйте, может тут у нас есть люди работающие с Apache Hadoop у меня вопрос к ним.

Наша компания разрабатывает ПО для перевода данных из одного формата в другой, уже долго около 30 лет, последний раз когда я считал мы поддерживали более 70 файловых форматов. Распостраняется как stand alone user app and libraries used by different OEM clients.

Недавно босс загорелся идеей добавить поддержку Big Data i.e. Apache Hadoop. Он где то видел что пользователи Hadoop искали способ перегнать данные в такие пакеты как R, SAS, Stata и все что им предлогалось это копировать эти файлы с HDFS на локальную FS ну а затем уже как обычно, кто как может. Вот он и решил что если наш продукт сможет читать данные с HDFS через ODBC (о написании плагинов вопрос как то отпал сам собой) то на это будет большой спрос ну и плюс это очень модно сказать "Ну вот и мы поддерживаем Big Data, будущее за нами." Я по поводу этого довольно скептичен но полноценных доводов привести не могу потому как нет реального опыта работы с Hadoop, хотя я внимательно посмотрел на работу нескольких ODBC drivers доступных для разных Hadoop distributions (Cloudera, MapR).
Cобственно вот в чем вопрос (ответы желательно из практического опыта):

a) если возникает необходимость постобработки (перевода в другой формат) файлов расположенных на HDFS о каких размерах обычно идет речь? МB / GB/ TB ? Понятно что сама HDFS может хранить файлы колосального размера но ODBC это очень медленный интерфейс поэтому если обычно размер файлов требующих перевода в другой формат и последующего например стат. анализа будет более 1GB то вся эта идея не имеет смысла потому что чтение с HDFS будет очень медленным.

b) Parquet Data Files - на сколько это часто используемый формат, используется ли он для экспорта данных требующих перевода в другой формат и последующего например стат. анализа и какого размера (интересует порядок МB / GB/ TB ) эти файлы? Читать то я эти файлы с HDFS могу но опять же очень сомневаюсь что вся эта игра стоит свеч.

Может кто то может прокомментировать вышесказанное?

Спасибо.

[iDesperado]

опыт есть. если я верно понял, то у вас относительно просто есть возможность добавить ODBC hive как источник к своему продукту. ODBC конечно медленно, но работает. в каких-то случаях наверно пригодится.
если босс слышал про R,SAS,Stata то очень вероятно речь идет о data science, а им зачастую не нужны гигантские датасеты. на эту тему "Работа и Карьера в IT" лучше написать, видел туда несколько саинтистов захаживают, наши обычно берут очень небольшие выборки свежих данных для тренировки моделей. но R и SAS такие комбайны, что сами запросто читают что хочешь, слабо представляю кому может понадобится что-то третье для конвертации.

а) у нас в Qlik гоняют ежедневно многие гигабайты по ODBC. медленно, но в принципе работает.
б) parquet самый популярный формат, если воротить по взрослому, да - надо паркеты учится читать. после него идет orc, у него уже сильно меньшее распространение. скопировать 10 гб упакованных паркетов утилитой hadoop fs -get займет минуты, по ODBC тянуть распакованные данные - многие часы.

[OldTuzik]

Спасибо за ответ.

опыт есть. если я верно понял, то у вас относительно просто есть возможность добавить ODBC hive как источник к своему продукту. ODBC конечно медленно, но работает. в каких-то случаях наверно пригодится.

Уже добавил. Странно что ODBC drivers на Hadoop написанные разными конторами и людьми не очень высокого качества и не совсем соответсвуют ODBC стандарту (в том виде как его реализовал MS в своих драйверах а это по моим меркам является мерилом в этой нише). Есть только два пути через написание плагина и через ODBC поэтому для third party software ODBC is the only way to get access to data.

если босс слышал про R,SAS,Stata то очень вероятно речь идет о data science, а им зачастую не нужны гигантские датасеты. на эту тему "Работа и Карьера в IT" лучше написать, видел туда несколько саинтистов захаживают, наши обычно берут очень небольшие выборки свежих данных для тренировки моделей. но R и SAS такие комбайны, что сами запросто читают что хочешь, слабо представляю кому может понадобится что-то третье для конвертации.

R, SAS, Stata, SPSS и прочее очень мощные программы в плане анализа данных но огранниченны (я знаком с этой проблемой в деталях) в чтении foreign file formats, поэтому для нас всегда есть работа.

б) parquet самый популярный формат, если воротить по взрослому, да - надо паркеты учится читать. после него идет orc, у него уже сильно меньшее распространение. скопировать 10 гб упакованных паркетов утилитой hadoop fs -get займет минуты, по ODBC тянуть распакованные данные - многие часы.

Отлично, с parquet проблем нет совсем он читается через ODBC без проблем но медленно, про ork не слышал, после погуглю. У нас parquet через ODBC читается record by record (ODBC driver по другому не дает), затем data optimization / character conversion (ODBC driver returns data in UTF-16 (or whatever native code page is), the app converts it to UTF-8) поэтому если придется читать 10 GB то это просто не реально в принципе.

Но идея понятна, спасибо, значит босс прав и это тоже по свойму хорошо.

[iDesperado]

не, вы что-то смешиваете разные понятия.
ODBC это одно, parquet это чуть о другом. имеется ввиду вместо того, что бы подключатся по ODBC, копировать файлы parquet.gz и читать прямо файлы с локальной файловой системы.

качество ODBC видимо связано с тем что мало кому нужно, индустрия больше на JDBC сидит.

[OldTuzik]

не, вы что-то смешиваете разные понятия.
ODBC это одно, parquet это чуть о другом. имеется ввиду вместо того, что бы подключатся по ODBC, копировать файлы parquet.gz и читать прямо файлы с локальной файловой системы.

В начале был пплан читать individual parquet files но позже оказалось что они запросто читаются через ODBC поэтому вопрос о самостоятельном распарсивании parquet файлов отпал сам собой. Но если Вы считаете что чтение отдельных parquet файлов сохраненных вне HDFS имеет больше смысла то это немного меняет картину. Я доложу боссу об этом,возможно он просто еще не думал о таком повороте событий.

[iDesperado]

В начале был пплан читать individual parquet files но позже оказалось что они запросто читаются через ODBC поэтому вопрос о самостоятельном распарсивании parquet файлов отпал сам собой. Но если Вы считаете что чтение отдельных parquet файлов сохраненных вне HDFS имеет больше смысла то это немного меняет картину. Я доложу боссу об этом,возможно он просто еще не думал о таком повороте событий.

прежде чем выбирать путь, я бы все таки перепроверил. имеют ли ваши пользователи доступ к hdfs напрямую, хватит ли среднестатическому пользователю мозгов выкачать файлики. ну и по инструментам, очень странно слышать про R и SAS, я их видел. наши саинтисты используют R, качают данные с Hive по jdbc, либы читать напрямую parquet у R тоже есть. SAS подключается по ODBC. не представляю на кой там ваша прослойка.

зы. мы на hdfs пускаем только аналитиков и саинтистов, остальные видят данные исключительно по JDBC/ODBC

[OldTuzik]

очень странно слышать про R и SAS, я их видел. наши саинтисты используют R, качают данные с Hive по jdbc, либы читать напрямую parquet у R тоже есть. SAS подключается по ODBC.

Я думаю Вы просто не в теме. Например SAS - поддерживает (некоторые платформы умерли) WINDOWS_32, HP_32 / MIPS_32 / RS600_32 / SOLARIS_32, HP_64 / HP_IA64 / RS600_64 / SOLARIS_64, INTEL_ABI_32 / LINUX_32, OS2_32, MVS_32, ALPHA_OSF_64, ALPHA_VMS_64, WINDOWS_64, ALPHA_VMS. Стоимость лицензии для одной OS -XXXX$. Допустим у Вас SAS 32 bit Windows, Ваш коллега прислал Вам датасет и каталог созданные на Windows 64 bit - Вы просто не сможете открыть 64 битный каталог в SAS 32 бита и это Windows, the situation with other platforms is even worse. Или например Вы хотите использовать датасет созданный на Линукс а использовать каталог созданный на Windows - you are out of luck.
Другой пример - Вы - большая фармацевтическая компания, хх лет назад Вы сохранили данные в SAS v.6.X < 6.12 а вот теперь Вам надо прочитать их - you are out of luck. Вы обратитесь в SAS и Вас отправят к нам потому что мы те файлы читаем (и пишем на современных OS) и так далее.

R и SAS, SAS подключается по ODBC. не представляю на кой там ваша прослойка.

Скажу Вам по секрету некоторые из перечисленных выше стат. программ или использовали или используют наши библиотеки для чтения данных из различных источников. Так что пользователи тех программ пользуются нашей "прослойкой" но они просто не в курсе.

зы. мы на hdfs пускаем только аналитиков и саинтистов, остальные видят данные исключительно по JDBC/ODBC

Это важное замечание, спасибо.