Comments 38
Еще есть Cloudera Impala. Не сравнивали ее с этими двумя?
Стоит в планах, но руки пока не дошли )
По сути она похожа на Hive, т.к там тоже SQL, но должна быть в разы быстрее
По сути она похожа на Hive, т.к там тоже SQL, но должна быть в разы быстрее
На последних демо Hortonworks Hive летал быстрее Impala даже на мелких запросах (спасибо TEZ и реизпользованию контейнеров), не говоря уже о крупных.
Так же Impala совсем не fault-tolerance
Так же Impala совсем не fault-tolerance
Так же Impala совсем не fault-tolerance
А расскажите, в чём это выражается?
Если одна нода падает во время запроса — запрос падает целиком.
На самом деле это не большая проблема, потому что Impala обычно не используется для долгих запросов.
Надо заметить что Impala не использует Hadoop как средство вычисления, она использует тольео HDFS,
а вычислительный процесс организует сама.
На самом деле это не большая проблема, потому что Impala обычно не используется для долгих запросов.
Надо заметить что Impala не использует Hadoop как средство вычисления, она использует тольео HDFS,
а вычислительный процесс организует сама.
Импала даже HDFS толком-то не использует. Импаловые демоны кэшируют расположение блоков для того, чтобы при запросе locality factor был наивысшим. Если у вас периодически запускается HDFS balancer, то нужно делать REFRESH для таблиц, чтобы сбросить кэш локаций блоков, т.к. балансер перемещает блоки между датанодами. В отличие от MR, у Импалы нет слотов, она обеспечивает колоссальную экономию межузлового трафика. Можно добиться 100% data locality, если высаживать Демон импалы возле каждой ДатаНоды. И да, у импалы есть много-много недостатков. Это не база данных, а сёвая (язык Си ) нашлепка поверх файловой системы, где хранятся блоки HDFS.
если рассматривать базу данных с надеждой иметь update, то согласен что импала на нее не тянет.
если рассматривать как систему для выполнения sql и получения результатов, то очень даже вменяемая база данных.
p.s. с таким подходом любая база данных это нашлепка над блочным устройством
если рассматривать как систему для выполнения sql и получения результатов, то очень даже вменяемая база данных.
p.s. с таким подходом любая база данных это нашлепка над блочным устройством
Оки, я вас понял.
Разница между нашлепкой и БД в ожиданиях. Лично я ожидаю, что БД может делать джоин через диск. А очень дорогая БД может делать распеределнный джоин на десятках дисков и десятков узлов. Кроме того, хотелось бы чтобы БД не нуждалась в ручном напоминании (REFRESH TABLE_NAME) о том, что блоки на блочном устройстве поменяли своё расположение на дисках и узлах.
Под нашлепкой я понимаю то, что ожидания не сосуществуют действительности.
Разница между нашлепкой и БД в ожиданиях. Лично я ожидаю, что БД может делать джоин через диск. А очень дорогая БД может делать распеределнный джоин на десятках дисков и десятков узлов. Кроме того, хотелось бы чтобы БД не нуждалась в ручном напоминании (REFRESH TABLE_NAME) о том, что блоки на блочном устройстве поменяли своё расположение на дисках и узлах.
Под нашлепкой я понимаю то, что ожидания не сосуществуют действительности.
чем джойн через диск отличается от join в памяти?
скоростью работы и ограничением на объем.
И я считаю это хорошо, что она не пытается лезть на диск, так как работа с MR в свое время показала, что чем меньше диска мы трогаем, тем спокойней на душе. А распределенный join она и так умеет, следовательно размером памати одной ноды мы не ограниченны.
(offtop: www.memsql.com/ заявляют что такие супер-отличные in-mem база данных, но на практике это шардинг, для join данные сливаются на ОДИН узел и если в память не влазят, то валится весь запрос, распределенного join нету, но ведь никто не говорит что они не база данных)
REFRESH, как по мне, является временным решением, так как при большом желании не проблема сделать доп слушателя к namenode и чекать любые изменения в положении блоков, но раз до сих пор это не сделали, то следовательно не сильно то и мешает.
скоростью работы и ограничением на объем.
И я считаю это хорошо, что она не пытается лезть на диск, так как работа с MR в свое время показала, что чем меньше диска мы трогаем, тем спокойней на душе. А распределенный join она и так умеет, следовательно размером памати одной ноды мы не ограниченны.
(offtop: www.memsql.com/ заявляют что такие супер-отличные in-mem база данных, но на практике это шардинг, для join данные сливаются на ОДИН узел и если в память не влазят, то валится весь запрос, распределенного join нету, но ведь никто не говорит что они не база данных)
REFRESH, как по мне, является временным решением, так как при большом желании не проблема сделать доп слушателя к namenode и чекать любые изменения в положении блоков, но раз до сих пор это не сделали, то следовательно не сильно то и мешает.
скоростью работы и ограничением на объем.
Ну и зачем эта биг-дата, если есть ограничение на объем? Что с ней потом делать? Не отвечает требованиям и ожиданиям. Только многочасовые джобы через Хайв.
работа с MR в свое время показала, что чем меньше диска мы трогаем, тем спокойней на душе
Не понял мысль. Все MPP системы работают через диск. Например, самые дешевые узлы терадаты комплектуются десятками (40 и более) 15-тысячниками.
никто не говорит что они не база данных Это они говорят, что они База данных. Есть суть, есть контекст. В контексте Хадупа нет ни одной БД, либо нашлепки в виде Импалы, либо трансляторы SQL в граф MR джобов в виде Хайва. Про транзакции, ACID я вообще не говорю. www.memsql.com издали напоминает закос под лямбда архитектуру. Только вот лямбда архитектура не предусматривает каких либо ограничений по памяти или диску.
Пока что не понимаю идею сравнивать in-memory DB и MMP систему Импала (по словам её авторов)
www.cloudera.com/content/cloudera/en/products-and-services/cdh/impala.html
Cloudera Impala is the industry’s leading massively parallel processing (MPP) SQL query engine that runs natively in Apache Hadoop.MPP системы, это Терадата, Экзадата, Вертика и т.д. Если MPP система ограничена оперативной памятью, то это не MPP система, потому что есть рыночные стандарты де-факто и ожидания к MPP системе.
REFRESH, как по мне, является временным решениемкостыль, проще говоря.
сделать доп слушателя к namenode и чекать любые изменения в положении блоков,Неймнода не хранит информацию о блоках. ДатаНоды шлют блок-репорты о том, какие у них есть блоки. На основании репортов НеймНода получает знание о расположении блоков. Почему не сделали? Потому что ДатаНод сотни. Это сложная инженерная задача. Мы же не будем рассматривать БигДату на трех тестовых виртуалках :)
память нынче достаточно дешевая, чтобы суммарно на кластер иметь не один терабайт.
>> Пока что не понимаю идею сравнивать in-memory DB и MMP систему Импала (по словам её авторов)
MemSQL’s distributed in-memory data management platform utilizes in-memory data storage and a distributed, shared-nothing massively parallel (MPP) processing architecture to drive performance.
>> Не понял мысль. Все MPP системы работают через диск. Например, самые дешевые узлы терадаты комплектуются десятками (40 и более) 15-тысячниками.
мысль была в том, что чем меньше мы делаем сбросов на диск данных и последующих чтений, тем быстрее оказывается результат. именно поэтому сейчас у многих в моде spark (как замена mr, тут все понятно) / shark (запуск hive на spark, за счет того что все в памяти показывают хороший результат).
стоимость самых дешевых узлов терадаты можно узнать? импала как и хадуп решает задачу на доступном железе, на котором диски являются самым узким местом системы. А за стоимость Терадата/Экзадата можно поднять кластер не с одним десятком терабайт памяти, поэтому для разных задач и финансовых возможностей разные инструменты.
>> Неймнода не хранит информацию о блоках. ДатаНоды шлют блок-репорты о том, какие у них есть блоки.
на старте (чтобы собрать карту, где и что сейчас валяется, мало ли некоторые машинки не поднялись) и периодически дельту (мало ли диск вылетел, блоки покараптились или еще чего), чтобы гарантировать отсутствие рассинхронизации. любое выделение блока проходит через неймноду — запрашиваем у нее разрешение на запись, она возвращает id и токет с указанием datanode куда мы будем писать. Чтение в обратном порядке: запросили у нее по файлу id и токены с адресами откуда читать. fsck потому и проходит быстро, что он работает только с метаданными, проверяется уровень консистентности и все ли блоки присутсвуют в данный момент, конечно если у вас в этот момент вылетела нода, но мы исключим ее информацию с задержкой, т.е. когда посчитаем что ее уже нету или она не вернется и не пришлет новые данные. Поэтому к namenode и были такие требования по условиям хранения информации в памяти: все дерево каталогов и карта блоков хранится в памяти, и если у вас много больших файлов, то стоит увеличить у тех файлов blocksize для снижения потребления памяти.
>> костыль, проще говоря.
да, костыль решающий текущие задачи в текущих условиях, в следующих версиях по мере расширения api для namenode костыль скорее всего уберется.
>> Пока что не понимаю идею сравнивать in-memory DB и MMP систему Импала (по словам её авторов)
MemSQL’s distributed in-memory data management platform utilizes in-memory data storage and a distributed, shared-nothing massively parallel (MPP) processing architecture to drive performance.
>> Не понял мысль. Все MPP системы работают через диск. Например, самые дешевые узлы терадаты комплектуются десятками (40 и более) 15-тысячниками.
мысль была в том, что чем меньше мы делаем сбросов на диск данных и последующих чтений, тем быстрее оказывается результат. именно поэтому сейчас у многих в моде spark (как замена mr, тут все понятно) / shark (запуск hive на spark, за счет того что все в памяти показывают хороший результат).
стоимость самых дешевых узлов терадаты можно узнать? импала как и хадуп решает задачу на доступном железе, на котором диски являются самым узким местом системы. А за стоимость Терадата/Экзадата можно поднять кластер не с одним десятком терабайт памяти, поэтому для разных задач и финансовых возможностей разные инструменты.
>> Неймнода не хранит информацию о блоках. ДатаНоды шлют блок-репорты о том, какие у них есть блоки.
на старте (чтобы собрать карту, где и что сейчас валяется, мало ли некоторые машинки не поднялись) и периодически дельту (мало ли диск вылетел, блоки покараптились или еще чего), чтобы гарантировать отсутствие рассинхронизации. любое выделение блока проходит через неймноду — запрашиваем у нее разрешение на запись, она возвращает id и токет с указанием datanode куда мы будем писать. Чтение в обратном порядке: запросили у нее по файлу id и токены с адресами откуда читать. fsck потому и проходит быстро, что он работает только с метаданными, проверяется уровень консистентности и все ли блоки присутсвуют в данный момент, конечно если у вас в этот момент вылетела нода, но мы исключим ее информацию с задержкой, т.е. когда посчитаем что ее уже нету или она не вернется и не пришлет новые данные. Поэтому к namenode и были такие требования по условиям хранения информации в памяти: все дерево каталогов и карта блоков хранится в памяти, и если у вас много больших файлов, то стоит увеличить у тех файлов blocksize для снижения потребления памяти.
>> костыль, проще говоря.
да, костыль решающий текущие задачи в текущих условиях, в следующих версиях по мере расширения api для namenode костыль скорее всего уберется.
MemSQL’s distributed in-memory data management platform
С таким же детскими ограничениями. Потому ее тоже можно считать нашлепкой по сравнению с рыночными MPP, как и Impala. Я предлагаю не читать рекламные проспекты, а реально смотреть на жизнь. Ограничение по памяти, это серьезный стоппер. Суммарный терабайт памяти, это очень-очень мало. И, вам на заметку, сервера с 126-256 ГБ памяти стоят не дешево, это уже не low end и не commodity hardware.
стоимость самых дешевых узлов терадаты можно узнать?
Дорого, очень дорого :)
. А за стоимость Терадата/Экзадата можно поднять кластер не с одним десятком терабайт памяти
Встает вопрос о ToC. Что дешевле, обслуживать коробку Терадаты из 5-7 узлов, которые работают и каши не просят + имеют офф. саппорт, или стадо дешевого железа средней паршивости? Вы пробовали сделать DWH, хотя бы для хранения на базе хадупа? ToC, в итоге, выйдет в стоимость терадаты, которую нужно просто поставить и уже лить данные. С хадупом такой трюк не пройдет. Очень сложно, криво, косо, мало людей на рынке и у всех раздутые зарплаты по понятным причинам.
именно поэтому сейчас у многих в моде spark
У спарка нет ограничений по памяти. При желании, RDD можно хранить на диске. Потому у него прямо сейчас больше шансов на серьезный пром, чем у Импалы и прочих ин-мемори аналогов. И, как я понял со слов разработчиков Махута, в основном Спарк рассматривается как тул для реализации итеративных алгоритмов поверх HDFS. Объективно говоря, MR не подходит для итеративных алгоритмов. Он подходит для других задач.
чтобы собрать карту, где и что сейчас валяется
Не понял, как поверхностное описание работы НеймНоды помогает решать инженерную задачу по обновлению локаций блоков в режиме реального времени.
Мы ушли от темы, мой месседж в том, что продукты, называющие себя Database, MPP, и не способное решать задачи контекста, это не Database, MPP, а нашлепки. SQLite в контексте тестов Ruby On Rails, это база данных. В проме берут MySQL, Postgre. Потому что решаются пром задачи, для которых SQLite — неразумное ограничение и костыль.
MPP система, не способная выполнить Two-pass multi way merge sort любого объема данных при достаточном дисковом пространстве не может называться MPP. Это нашлепка, потому что рынок знает, эта проблема решена многими вендорами много лет назад. Память давно не ограничение, все извращаются, чтобы результат поскорее отправить пользователю.
Было приятно с вами пообщаться, спасибо!
И да, кстати, есть еще HDFS caching blog.cloudera.com/blog/2014/02/apache-hadoop-2-3-0-is-released-hdfs-caching-ftw/
еще одна уникальная возможность выстрелить себе в ногу, включив слабоуправляемый cluster-wide cache.
еще одна уникальная возможность выстрелить себе в ногу, включив слабоуправляемый cluster-wide cache.
>> Вы пробовали сделать DWH, хотя бы для хранения на базе хадупа?
пробовал, делал, крутится в проде и каши не просит, вот только постоянно приходится объяснять что он может, а что не стоит пытаться делать, результат получишь, но завтра.
>> У спарка нет ограничений по памяти. При желании, RDD можно хранить на диске.
ну что же, когда я его усиленно ковырал умел только в памяти держать, но не одновременно и память-диск.
>> Объективно говоря, MR не подходит для итеративных алгоритмов. Он подходит для других задач.
Вы бы знали насколько я с вами согласен, особенно по поводу итеративных алгоритмов. Жаль что большинству это приходится объяснять на пальцах и примерах спускаясь в дебри реализаций.
>> MPP система, не способная выполнить Two-pass multi way merge sort любого объема данных при достаточном дисковом пространстве не может называться MPP.
то есть мы скатываемся к тому, что судим MPP или не-MPP по умению работы с диском.
в том контексте в которых используют импалу и хадуп (обычные реляционки не справляются, вкладывать миллионы в терадату и тд желания нету) эти ограничения учитываются и не мешают сильно жить.
>> Не понял, как поверхностное описание работы НеймНоды помогает решать инженерную задачу по обновлению локаций блоков в режиме реального времени.
Неймнода всегда имеет полную картину где и что лежит. Это не хранится в метаданных в файле, там только структура каталогов и id элементов, но хранится в памяти после поднятия всего кластера (когда датаноды отрапортуют об поднятии). Если бы неймнода не имела этой картины, то не было бы возможности считать произвольный файл в произвольный момент времени. Граничный случаи: нода вывалилась и мы клиенту отдаем токен на чтение с этой ноды, клиент обвалился.
Кеширование метаданных демоном импалы ставит совсем другие задачи:
1) разгрузка namenode от лишних запросов
2) (более критичная) имея полную картину распределения блоков можно построить более оптимальный physical plan запроса. можно конечно каждый раз вытягивать данные на каждом запросе, но тогда встает пункт 1, что отписал.
>> еще одна уникальная возможность выстрелить себе в ногу
не понял посыла, файлы неизменяемы (хотя append местами портит эту картину), поэтому кеширование не проблема, только ускорит чтение с медленных дисков. точно так же импала кеширует не только метаданные, но и hdfs блоки целиком.
>> сервера с 126-256 ГБ памяти стоят не дешево
www.itcreations.com/show-server.asp?s=3613
Product Details: DELL POWEREDGE R910 SERVER 4 X INTEL 8C X7560 2.26GHZ 256GB RAM 4 X 146GB SAS HARD DRIVE
8319.00$, не скажу что сильно бюджетно, но и назвать сильно дорогой ее тоже нельзя.
десяток таких серверов + свичи + обвязка обойдется менее чем в 100к
на выходе будем иметь 2,5ТБ памяти.
пробовал, делал, крутится в проде и каши не просит, вот только постоянно приходится объяснять что он может, а что не стоит пытаться делать, результат получишь, но завтра.
>> У спарка нет ограничений по памяти. При желании, RDD можно хранить на диске.
ну что же, когда я его усиленно ковырал умел только в памяти держать, но не одновременно и память-диск.
>> Объективно говоря, MR не подходит для итеративных алгоритмов. Он подходит для других задач.
Вы бы знали насколько я с вами согласен, особенно по поводу итеративных алгоритмов. Жаль что большинству это приходится объяснять на пальцах и примерах спускаясь в дебри реализаций.
>> MPP система, не способная выполнить Two-pass multi way merge sort любого объема данных при достаточном дисковом пространстве не может называться MPP.
то есть мы скатываемся к тому, что судим MPP или не-MPP по умению работы с диском.
в том контексте в которых используют импалу и хадуп (обычные реляционки не справляются, вкладывать миллионы в терадату и тд желания нету) эти ограничения учитываются и не мешают сильно жить.
>> Не понял, как поверхностное описание работы НеймНоды помогает решать инженерную задачу по обновлению локаций блоков в режиме реального времени.
Неймнода всегда имеет полную картину где и что лежит. Это не хранится в метаданных в файле, там только структура каталогов и id элементов, но хранится в памяти после поднятия всего кластера (когда датаноды отрапортуют об поднятии). Если бы неймнода не имела этой картины, то не было бы возможности считать произвольный файл в произвольный момент времени. Граничный случаи: нода вывалилась и мы клиенту отдаем токен на чтение с этой ноды, клиент обвалился.
Кеширование метаданных демоном импалы ставит совсем другие задачи:
1) разгрузка namenode от лишних запросов
2) (более критичная) имея полную картину распределения блоков можно построить более оптимальный physical plan запроса. можно конечно каждый раз вытягивать данные на каждом запросе, но тогда встает пункт 1, что отписал.
>> еще одна уникальная возможность выстрелить себе в ногу
не понял посыла, файлы неизменяемы (хотя append местами портит эту картину), поэтому кеширование не проблема, только ускорит чтение с медленных дисков. точно так же импала кеширует не только метаданные, но и hdfs блоки целиком.
>> сервера с 126-256 ГБ памяти стоят не дешево
www.itcreations.com/show-server.asp?s=3613
Product Details: DELL POWEREDGE R910 SERVER 4 X INTEL 8C X7560 2.26GHZ 256GB RAM 4 X 146GB SAS HARD DRIVE
8319.00$, не скажу что сильно бюджетно, но и назвать сильно дорогой ее тоже нельзя.
десяток таких серверов + свичи + обвязка обойдется менее чем в 100к
на выходе будем иметь 2,5ТБ памяти.
Мне кажется в статье упущен важный фактор — скорость, а кластеры стоят достаточно дорого.
Я не фанат Hive и в целом не специалист в Hadoop environment, но вот мои доводы в пользу Hive:
— В Hadoop с версии 2.4.0 используется механизм TEZ, который представляет процесс вычисление как ацикличный граф.
Hive 13+ умеет пользоваться TEZ, Pig пока нет.
— Hive поддерживает бинарный формат хранения данных Orc, котороый дает огромный прирост данных в сравнении с CSV.
— Hive из коробки поддерживает partition-механизм, на сколько мне известно Pig без HCatalog этого не умеет.
У Hive раньше были большие проблемы со скоростью, как и у Pig,
но по заявлениям ребят из Hortonworks им удалось разогнать его в 100 раз (The Stinger initiative).
Также надо понимать что Hadoop environment развивается очень быстро и все меняется,
каждый Hadoop-провайдер (AWS EMR, Hortonworks, Cloudera) предоставляет разный набор компонент и версий.
Получилось сумбурно, но надеюсь, что основную мысль я выразил.
Я не фанат Hive и в целом не специалист в Hadoop environment, но вот мои доводы в пользу Hive:
— В Hadoop с версии 2.4.0 используется механизм TEZ, который представляет процесс вычисление как ацикличный граф.
Hive 13+ умеет пользоваться TEZ, Pig пока нет.
— Hive поддерживает бинарный формат хранения данных Orc, котороый дает огромный прирост данных в сравнении с CSV.
— Hive из коробки поддерживает partition-механизм, на сколько мне известно Pig без HCatalog этого не умеет.
У Hive раньше были большие проблемы со скоростью, как и у Pig,
но по заявлениям ребят из Hortonworks им удалось разогнать его в 100 раз (The Stinger initiative).
Также надо понимать что Hadoop environment развивается очень быстро и все меняется,
каждый Hadoop-провайдер (AWS EMR, Hortonworks, Cloudera) предоставляет разный набор компонент и версий.
Получилось сумбурно, но надеюсь, что основную мысль я выразил.
Да, спасибо.
В моём случае, Hive и Pig тестировались из Clouderа-вского дистрибутива, но рассматривались как вендоро-независимые продукты.
Xотелось показать именно структурные отличия. В следующий раз попробую поковырять с точки зрения производительности. Но наверно это будут решения уже из другой весовой категории, например Impala — Spark/Shark.
В моём случае, Hive и Pig тестировались из Clouderа-вского дистрибутива, но рассматривались как вендоро-независимые продукты.
Xотелось показать именно структурные отличия. В следующий раз попробую поковырять с точки зрения производительности. Но наверно это будут решения уже из другой весовой категории, например Impala — Spark/Shark.
Ну не в сто раз, а до ста раз на отдельных запросах. Так или иначе, все такие бенчмарки нужно читать так: «На нашем наборе данных и на вот этих специальных запросах, которые мы хотели вам показать, наши последние наработки дают лучший результат». В зависимости от деталей реальной задачи показатели могут сильно варьироваться.
Как уже сказали выше, кроме Hive и его нового ORC есть ещё Imapala и Parquet. Parquet — это такой колончатый формат файла, который на наших тестах давал сжатие в 5-7 раз и ускорение в 6-10 раз по сравнению с текстовыми файлами. Это при том, что оба теста проводились в Impala, которая на тот момент была сама по себе раз в 10 быстрее, чем Hive.
Ребята из Hortonworks, правда, заявляют, что ORC круче Parquet, но клаудеровцем есть что ответить по этому поводу. Но для меня самым приятным в паркете является то, что его уже все знают и многие любят. Например, Spark SQL из коробки умеет работать только с двумя форматами — текстовыми файлами, и паркетом (остальные тоже можно подключить, но сложнее).
Кстати, признание и любовь другими проектами — это вообще замечательная штука, и именно она заставляет меня довольно скептически относиться к Pig: будь он хоть в 10 раз круче HQL/SQL, но без интеграции с популярными проектами, без растущего сообщества он разно или поздно попросту останется за бортом.
Как уже сказали выше, кроме Hive и его нового ORC есть ещё Imapala и Parquet. Parquet — это такой колончатый формат файла, который на наших тестах давал сжатие в 5-7 раз и ускорение в 6-10 раз по сравнению с текстовыми файлами. Это при том, что оба теста проводились в Impala, которая на тот момент была сама по себе раз в 10 быстрее, чем Hive.
Ребята из Hortonworks, правда, заявляют, что ORC круче Parquet, но клаудеровцем есть что ответить по этому поводу. Но для меня самым приятным в паркете является то, что его уже все знают и многие любят. Например, Spark SQL из коробки умеет работать только с двумя форматами — текстовыми файлами, и паркетом (остальные тоже можно подключить, но сложнее).
Кстати, признание и любовь другими проектами — это вообще замечательная штука, и именно она заставляет меня довольно скептически относиться к Pig: будь он хоть в 10 раз круче HQL/SQL, но без интеграции с популярными проектами, без растущего сообщества он разно или поздно попросту останется за бортом.
Тем не менее Hive перестал болеть недугом Hadoop-based систем, когда надо ждать минуты для выполнения самого элементарного запроса на маленьком наборе данных. Hive теперь приблизился по скорости к Impala на небольших запросах, но Impala по-прежнему недоступны долгие запросы (я про fault-tolerance)
Ничего не мешает использовать Parquet в Hive, ORC я привел как одну из альтернатив plain text формату.
Я плохо знаком c Impala, посему не сочтите за холивар)
Ничего не мешает использовать Parquet в Hive, ORC я привел как одну из альтернатив plain text формату.
Я плохо знаком c Impala, посему не сочтите за холивар)
Правильно ли я понимаю применение Parquet?
Если у вас есть фиксированный набор данных, над которым нужно делать много разных Ad hoc выборок, то есть смысл привести данные к Parquet — формату. Но если в систему валится большое количество обычных зазипованных логов, над которыми систематично запускается предопределенный MR, что то считает, экспортирует, а потом просто выкидывает сырые данные, то и нет смысла приводить всё к паркету, ибо дороже будет?
Если у вас есть фиксированный набор данных, над которым нужно делать много разных Ad hoc выборок, то есть смысл привести данные к Parquet — формату. Но если в систему валится большое количество обычных зазипованных логов, над которыми систематично запускается предопределенный MR, что то считает, экспортирует, а потом просто выкидывает сырые данные, то и нет смысла приводить всё к паркету, ибо дороже будет?
Есть старая поговорка: единственный способ узнать, какой вариант быстрее, — это запустить и проверить :) С одной стороны, если вы выкидываете данные сразу после использования, то конвертация в Parquet занимает лишнее время. С другой, Parquet гораздо быстрее для чтения, так что выигрыш от него может перекрыть дополнительные расходы на конвертацию даже для одноразового использования. (Сравните, например, интерпретацию и JIT-компиляцию кода в JVM). Ну и вообще, если вы не накапливаете данные, то возможно имеет смысл вообще обойти запись на HDFS, и обрабатывать данные прямо по ходу считывания их источника. Например, если вы читаете данные из RDBMS, то можно написать свой RecordReader (для MR) или RDD (для Spark) для них, обрабатывать на лету и сохранять на диск только уже обработанные записи.
Кстати, одно из важнейших преимуществ Parquet перед текстовыми файлами в том, что это всё-таки структурированный формат. Если в CSV файле вам придётся хранить свободный текст или JSON или ещё что-нибудь кроме примитивных типов, то будьте готовы к семи кругам ада с эскапрированием специальных символов (запятых, ковычек и т.д.). Паркет (равно как и любой другой структурированный формат, естественно) избавляет от этой проблемы.
Кстати, одно из важнейших преимуществ Parquet перед текстовыми файлами в том, что это всё-таки структурированный формат. Если в CSV файле вам придётся хранить свободный текст или JSON или ещё что-нибудь кроме примитивных типов, то будьте готовы к семи кругам ада с эскапрированием специальных символов (запятых, ковычек и т.д.). Паркет (равно как и любой другой структурированный формат, естественно) избавляет от этой проблемы.
Преимущества паркета:
1. Схема
2. Читальщики для Pig, hive, MR. Очень-очень удобные, с версии 1.4.3 В ранних версиях (до 1.2.5 включительно) есть куча проблем с чтением паркета из MR
3. Компрессия
По факту: avro+snappy и parquet+snappy. При раздутых размерах страниц и блоков паркета, можно добиться до +30% к сжатию по сравнению с avro+snappy. Из минусов — жрет память, если у вас на ноде менее 32 ГБ, можно допрыгаться до OOM и хард ресета узла.
4. Стр-ра файла представляет собой своеобразную сетку. Есть возможность селективного чтения, для того, чтобы вытащить значение из колонки, не обязательно читать весь ряд.
ORC обладает неоспоримым преимуществом — встроенным индексом. Если хранить сортированные файлы, то можно добиться устрашающего прироста производительности при джоинах и фулл-сканах.
Паркетчики грозятся вклеить индекс, и, тем не менее, его все еще нет, а в ORC он есть.
Как сомнительный плюс, Teradata приблуды для хадупа умеют работать с ORC.
1. Схема
2. Читальщики для Pig, hive, MR. Очень-очень удобные, с версии 1.4.3 В ранних версиях (до 1.2.5 включительно) есть куча проблем с чтением паркета из MR
3. Компрессия
По факту: avro+snappy и parquet+snappy. При раздутых размерах страниц и блоков паркета, можно добиться до +30% к сжатию по сравнению с avro+snappy. Из минусов — жрет память, если у вас на ноде менее 32 ГБ, можно допрыгаться до OOM и хард ресета узла.
4. Стр-ра файла представляет собой своеобразную сетку. Есть возможность селективного чтения, для того, чтобы вытащить значение из колонки, не обязательно читать весь ряд.
ORC обладает неоспоримым преимуществом — встроенным индексом. Если хранить сортированные файлы, то можно добиться устрашающего прироста производительности при джоинах и фулл-сканах.
Паркетчики грозятся вклеить индекс, и, тем не менее, его все еще нет, а в ORC он есть.
Как сомнительный плюс, Teradata приблуды для хадупа умеют работать с ORC.
>> Для UDF используется Jython. Это может ограничить в использовании некоторых библиотек.
наглая ложь, как и для hive все пишется на любом языке который поддерживается jvm, ограничений нету
дополнительно в режиме стриминга hive может гонять данные в любою прилагу которая читае из stdin и пишет в stdout (HDInsight от майкрософта так и работает, только через стриминг на c# можно писать задачи) ссылка на офф доку
lateral view
не помню сильно удобной конструкции в термнах PIG, все остальные агрегаты и тд есть и Hive
к тому же даже кубинг в Hive запилили уже и оконные функции, в пиге до сих пор их нету
Вообще по производительности Pig всегда немного отставал, у Hive был чуть более шустрый оптимизатор запросов, на какое-то время вышли на паритет, но тут вышел на сцену Tez и Project Stinger.
С ORC есть проблемы, так как его только в hive пока можно использовать, хотя в JIRA уже и висит тикет по причесыванию его интерфейса к вменяемому виду, чтобы можно было и из других систем использовать. ORC vs Parquet на данный момент больше холиварный вопрос чем практичный, пока в проде нету статистики кто лучше, так как у них схожести больше чем различий.
наглая ложь, как и для hive все пишется на любом языке который поддерживается jvm, ограничений нету
дополнительно в режиме стриминга hive может гонять данные в любою прилагу которая читае из stdin и пишет в stdout (HDInsight от майкрософта так и работает, только через стриминг на c# можно писать задачи) ссылка на офф доку
lateral view
не помню сильно удобной конструкции в термнах PIG, все остальные агрегаты и тд есть и Hive
к тому же даже кубинг в Hive запилили уже и оконные функции, в пиге до сих пор их нету
Вообще по производительности Pig всегда немного отставал, у Hive был чуть более шустрый оптимизатор запросов, на какое-то время вышли на паритет, но тут вышел на сцену Tez и Project Stinger.
С ORC есть проблемы, так как его только в hive пока можно использовать, хотя в JIRA уже и висит тикет по причесыванию его интерфейса к вменяемому виду, чтобы можно было и из других систем использовать. ORC vs Parquet на данный момент больше холиварный вопрос чем практичный, пока в проде нету статистики кто лучше, так как у них схожести больше чем различий.
Зачем же так сразу? ))
Hive — действительно поддерживает рассовый Python. А вот с Pig-ом у меня такое не прошло. Там Jython
Hive — действительно поддерживает рассовый Python. А вот с Pig-ом у меня такое не прошло. Там Jython
надо было и указать, что Python хотели использовать, а то фраза «Для UDF используется Jython» вводит людей в заблуждение, что только на нем можно писать. Более корректно было бы «Для UDF используется любой JVM совместимый язык. Если нужны сторонние библиотеки, то необходимо написание дополнительных оберток или реализация нужного языка под JVM, например Jython для запуска Python скриптов, но это накладывает ограничения на разнообразие доступных библиотек»
Я пишу UDF для пига на jython (короткие функции фильтрации со счетчиками, например), Java (когда нужен перфоманс), Groovy (когда нужно написать прототип). Посмотрите документацию. pig.apache.org/docs/r0.10.1/udf.html
Java, Jython. JavaScript, Ruby добавлены в качестве эксперимента.
Java, Jython. JavaScript, Ruby добавлены в качестве эксперимента.
ой, с разверткой пропустил случайно когда говорил про lateral view
>> Pig — развертка агрегатов (FLATTEN)
cube
Windowing and Analytics Functions
к тому же перекинуть разработчиков-аналитиков с какой sql базы на большие объемы и hive будет проще, чем застравлять их учить hive и писать свои udf
>> Pig — развертка агрегатов (FLATTEN)
cube
Windowing and Analytics Functions
к тому же перекинуть разработчиков-аналитиков с какой sql базы на большие объемы и hive будет проще, чем застравлять их учить hive и писать свои udf
Я смотрю все примеры из анализа данных сводится либо к рекламе, либо к очередному look-alike для магазинов или рекомендательных сервисов ))
Такова структура рынка :) Судя по вакансиям и текущим проектам, большие данные, и их анализ, нужны только рекламному бизнесу.
О, отнюдь. Взгляните, например, на Data Science Challenge от Cloudera — компания предлагает посоревноваться в поиске аномалий при лечении пациентов по страховке. А Kaggle вот даёт на выбор целый список задач — от предсказания рисков в бизнесе до поиска базона Хиггса. Ещё вот Hortonworks приводит отличный набор юз кейсов из совершенно разных областей. Да и по своему личному опыту могу сказать, что анализ данных можно применить практически к любой задаче — от сегментации базы пользователей до диагностики медленного пинга.
Это верно, можно найти много действительно полезных применений. Но я об насущном :)
Открываем hh.ru и смотрим вакансии :)
Открываем hh.ru и смотрим вакансии :)
Ну вот я открыл первые 4 вакансии по ключевому слову Hadoop: компания Vi, занимающаяся обработкой видео, предлагает построить им систему обработки данных и работать над профилями пользователей; mail.ru хочет с помощью хадупа масштабировать свой поиск; а дальше идут две вакансии от Альфа-банка (data scientist и big data разработчик), который явно ни рекламой, ни рекоммендательными сервисами не занимается.
Впрочем, я это не для спора, а просто как другую точку зрения :)
Впрочем, я это не для спора, а просто как другую точку зрения :)
Мне кажется, у рынка есть стабильное непонимание возможностей бигдаты.
Пошел новый тренд — рекомендательные сервисы. Люди читают про них, читают про бигдата, заполняют рынок вакансиями по поиску бигдата специалистов для реализации рекомендеров.
На самом деле возможностей применения масса. Например не так давно участвовал в реализации сервиса аналитики данных для екоммерс. Мускуль перестал нормально справляться после накопления 20М «записей» о посетителях. Перешли на хадуп — появилась масса возможностей, красивые графики, кучи отчетов, и счастье для аналитиков.
Пошел новый тренд — рекомендательные сервисы. Люди читают про них, читают про бигдата, заполняют рынок вакансиями по поиску бигдата специалистов для реализации рекомендеров.
На самом деле возможностей применения масса. Например не так давно участвовал в реализации сервиса аналитики данных для екоммерс. Мускуль перестал нормально справляться после накопления 20М «записей» о посетителях. Перешли на хадуп — появилась масса возможностей, красивые графики, кучи отчетов, и счастье для аналитиков.
Мне кажется, те у кого данные есть, знают о возможностях бигдаты, а у кого их нет — тем и не надо.
Что касается вашего проекта, то как бы там ни было, вы работаете с «записями о посетителях», по сути сейчас вся бигдата и крутится вокруг этих записей (рекомендации, выяснение соц. дема, интересов, поведения...).
Даже ритейлеры типа Ленты, не даром подсаживают всех на свои скидочные карточки. Это же история поведения клиента, со всеми вытекающими…
Что касается вашего проекта, то как бы там ни было, вы работаете с «записями о посетителях», по сути сейчас вся бигдата и крутится вокруг этих записей (рекомендации, выяснение соц. дема, интересов, поведения...).
Даже ритейлеры типа Ленты, не даром подсаживают всех на свои скидочные карточки. Это же история поведения клиента, со всеми вытекающими…
Sign up to leave a comment.
Hive vs Pig. На что мне столько ETL?