Hive vs Pig. На что мне столько ETL?

  • Tutorial
image

Лучше день потерять, но потом за пять минут долететь (с)



Привет коллеги.
Хочу поделиться с вами соображениями о том, чем отличаются фреймворки Hive и Pig, входящие в экосистему Hadoop. По сути, это два очень похожих продукта, цель у которых одна — взять на себя всю техническую реализацию MapReduce, предоставив взамен возможность описывать процесс обработки данных на более абстрактном уровне. В этой статье мы увидим как выглядят выборки в этих двух системах, и попытаемся понять, в каких случаях надо использовать то или иное решение.

Hive


Итак, начнем с Hive. Его основная фишка — это SQL-подобный язык запросов HQL (Hive query language). Он позволяет работать с данными привычным нам способом, так, как если бы мы работали с обычной реляционной базой. Скрипты можно запускать как через консоль, так и с помощью командной строки.

Hive это:
  • SQL-подобный язык HQL
  • Интерактивная консоль
  • Встроенные функции агрегации
  • Поддержка пользовательских функций (UDF)
  • Данные — как таблица

Hive умеет работать:
  • с текстовыми файлами (можно задать разграничительный символ)
  • с сжатыми текстовыми файлами (Gzip, Bzip)
  • с массивами, словарями, объединениями (union)
  • имеет огромное количество встроенных функций для работы с: коллекциями, датами, строками, JSON-ми
  • с математическими функциями (округление, логарифмы, корни, тригонометрия)
  • с функциями агрегации (sum, min, max, avg...)
  • Если всего перечисленного выше не хватило, то можно использовать кастомные функции, а также мэпперы и редьюсеры (python, java)


Простой пример:
--Создадим внешнюю таблицу. (Описание структуры лога)
CREATE EXTERNAL TABLE win_bids_log (
date_field string,
request_id string,
user_ssp_id string,
dsp_id string,
win_price int
)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY '\t'
LOCATION 'hdfs://inpit/bid-logs';

CREATE EXTERNAL TABLE win_bids_by_dsp (
dsp_id string,
win_bids_cout int,
win_price int
) 
ROW FORMAT DELIMITED
FIELDS TERMINATED BY '\t'
STORED AS TEXTFILE
LOCATION ''hdfs://output/win-bids-by-dsp'';

INSERT OVERWRITE TABLE win_bids_by_dsp
SELECT dsp_id, COUNT(dsp_id), SUM(win_price) FROM win_bids_log  GROUP BY dsp_id;

Как видите, всё довольно просто и понятно. Довольно таки приятно писать запросы, на знакомом языке. Но продолжается это счастье до тех пор, пока не приходится столкнуться с более сложными запросами.

Пример посложнее:
INSERT OVERWRITE TABLE movieapp_log_stage 
SELECT * FROM ( 
	SELECT custid, movieid, 
	 CASE WHEN genreid > 0 THEN genreid ELSE -1 END genreid, time, 
	 CAST((CASE recommended WHEN 'Y' THEN 1 ELSE 0 END) AS INT) recommended, activity, 
	 CAST(null AS INT) rating, price 
	 FROM movieapp_log_avro 
	 WHERE activity IN (2,4,5,11) 
	UNION ALL 
	SELECT 
	 m1.custid, m1.movieid, 
	 CASE WHEN m1.genreid > 0 THEN m1.genreid ELSE -1 END genreid, m1.time, 
	 CAST((CASE m1.recommended WHEN 'Y' THEN 1 ELSE 0 END) AS INT) recommended, 
	 m1.activity, m1.rating, 
	 CAST(null as float) price 
	 FROM movieapp_log_avro m1 
	 JOIN (
		 SELECT custid,movieid, 
		 CASE WHEN genreid > 0 THEN genreid ELSE -1 END genreid,MAX(time) max_time, 
		 activity 
		 FROM movieapp_log_avro 
		 GROUP BY custid, movieid, genreid, activity 
	 ) m2 
	 ON ( 
		 m1.custid = m2.custid 
		 AND m1.movieid = m2.movieid 
		 AND m1.genreid = m2.genreid 
		 AND m1.time = m2.max_time 
		 AND m1.activity = 1 
		 AND m2.activity = 1 
	 ) 
) union_result;


Разобраться конечно можно, но всё же стоит признать, что в данном случае определенно не хватает какой-то упорядоченности. Разложить бы это всё по полочкам, да с комментариями. Не так ли?

Итого:

Hive плюсы:
  • Старый, добрый SQL — хорош для описания выборок. Да и просто все его знают.
  • MapReduce под капотом. Уходит много оверхеда, связанного с обвязкой вокруг MR. Описание моделей данных, входных и выходных форматов, цепочек MR задач.
  • Интерактивность. Хорош для анализа данных в разных срезах.
  • Быстрота разработки
  • Отсутствие зависимостей, компиляции, сборки (всё это скрыто)


Hive Минусы:
  • Не всё можно уложить в парадигму HQL
  • Это хорошо ложится в голову, при простых выборках. Но с ростом сложности становится всё труднее и труднее их понимать. Особенно если выборку писали не вы


Pig



Поговорим теперь о Pig. Он основан на процедурном языке Pig Latin. Чтобы в нем разобраться нужно потратить какое то время.
Давайте разберемся и походу выясним отличия от Hive

Pig это:
  • язык Pig Latin
  • Интерактивная консоль
  • Встроенные функции агрегации
  • Поддержка пользовательских функций (UDF)
  • Данные — в виде структур (Tuple, Bag)

Pig умеет работать:
  • с текстовыми файлами (можно задать разграничительный символ)
  • с сжатыми текстовыми файлами (Gzip, Bzip)
  • с массивами, словарями, объединениями (union)
  • имеет огромное количество встроенных функций для работы с: датами, строками, структурами
  • с математическими функциями (округление, логарифмы, корни, тригонометрия)
  • с функциями агрегации (sum, min, max, avg...)
  • Если всего перечисленного выше не хватило, то можно использовать кастомные функции (jython, java)

Как видите, Pig умеет всё то же, что и Hive. Отличие лишь в представлении данных и в языке. Но именно это отличие выводит работу с Pig совершенно на другой уровень.

Рассмотрим Pig подробнее.
Данный фреймфорк работает со специальными структурами данных — Tuple и Bag.
  • Tuple — упорядоченный набор полей. Структура, к полям которой можно обращаться по индексу и/или имени.
  • Bag — коллекция (множество) Tuple.


Pig Latin базовые функции:
  • LOAD
  • STORE
  • GENERATE
  • JOIN
  • GROUP
  • FILTER
  • UNION
  • DISTINCT
  • ORDER

Давайте рассмотрим на примере, как можно трансформировать данные в процессе работы с Pig. Работать будем с log файлом RTB биржи. Данные представлены в следующем виде:
  • time — врмемя
  • bid_id — идентификатор ставки,
  • user_id — идентификатор пользователя,
  • dsp_id — идентификатор биддера (игрока)
  • bid — ставка

Pig — загрузка данных (LOAD)

Для загрузки используется функция LOAD, также мы указываем разделительный символ '\t' и сигнатуру данных (при необходимости можно указывать тип).
--почистим выходную директорию HDFS (Pig поддерживает команды Hadoop)
fs -rm -f -r -skipTrash /data/pig/out

--загрузим данные в переменную 'raw_data'
raw_data = LOAD '/data/pig/example/' USING PigStorage('\t') AS (time, bid_id, user_id, dsp_id, bid:int);

На выходе мы получим вот такую структуру (Tuple). В запросах к её полям можно обращаться через точку. Например: raw_data.dsp_id
raw_data -> tuple с именованными полями.
------------------------------------------------------------------------------------------- 
time,  bid_id,  user_id,  dsp_id,  bid
------------------------------------------------------------------------------------------- 
(2014.02.14 14:08:27.711,  56949,  45234534553459,  DSP-2,  12)
(2014.02.14 14:08:28.712,  61336,  45221696259999,  DSP-1,  56)
(2014.02.14 14:08:29.713,  74685,  45221699381039,  DSP-2,  89)
(2014.02.14 14:08:30.714,  56949,  45221695781716,  DSP-1,  21)
(2014.02.14 14:08:25.715,  27617,  45221682863705,  DSP-3,  22)

Pig — итеративная обработка данных (FOREACH — GENERATE)
FOREACH — GENERATE позволяет итеративно «бежать» по набору данных и применять к каждой записи какие-либо операции, или просто отдать на выход определенные поля, убрав всё не нужное.
--Нормализуем данные. Обрежем timestamp с помощью SUBSTRING
norm_data = FOREACH raw_data GENERATE SUBSTRING(time, 0,10) AS date, dsp_id, bid;

На выходе получаем то же самое множество, но с обрезанной датой, и только двумя полями: dsp_id, bid.

norm_data -> tuple с именованными полями и обрезанной датой
---------------------------------------
date,   dsp_id,   bid
---------------------------------------
(2014.02.14,   DSP-2,   12)
(2014.02.14,   DSP-1,   56)
(2014.02.14,   DSP-2,   89)
(2014.02.14,   DSP-1,   21)

Pig — группировка данных (GROUP)
GROUP — позволяет группировать данные, при этом выдавая на выход нетривиальную структуру.
--Сгруппируем по dsp_id и date 
group_norm_data = GROUP norm_data BY (dsp_id, date);

На выходе имеем:
группу в качестве ключа. К ней можно обращаться через префикс group.
и коллекцию агрегатов с префиксом norm_data
group_norm_data -> (группа как ключ) : [ (norm_data), (norm_data) ]
----------------------------------------------------------------------------------
 ( group),  array of norm_data
----------------------------------------------------------------------------------
( (DSP-1,  2014.02.14),  {(2014.02.14,  DSP-1,  56),  (2014.02.14,  DSP-1,  21)} )
( (DSP-1,  2014.02.17),  {(2014.02.17,  DSP-1,  34),  (2014.02.17,  DSP-1,  24)} )
( (DSP-2,  2014.02.14),  {(2014.02.14,  DSP-2,  89),  (2014.02.14,  DSP-2,  12)} )

Pig — развертка агрегатов (FLATTEN)
Иногда необходимо развернуть агрегаты в линейную структуру («выпрямить»).
Для этого существует функция FLATTEN
-- Разворачиваем агрегаты в линейную структуру
ft_group_norm_data = FOREACH group_norm_data GENERATE FLATTEN(group), FLATTEN(norm_data);

Из сложной сгруппированной структуры мы получаем прямолинейный набор Tuples.
ft_group_norm_data -> tuple с именованными полями
----------------------------------------------------------------------
dsp_id, date date dsp_id bid
-----------------------------------------------------------------------
(DSP-1, 2014.02.14, 2014.02.14, DSP-1, 56)
(DSP-1, 2014.02.14, 2014.02.14, DSP-1, 21)
(DSP-1, 2014.02.15, 2014.02.15, DSP-1, 15)
(DSP-1, 2014.02.15, 2014.02.15, DSP-1, 31)

Pig — функции агрегации (SUM)
Давайте что-нибудь посчитаем. Например, сумму дневных ставок, сделанных каждым биддером.
--Вычислим сумму дневных ставок, сделанных каждым биддером
sum_bids_dsp = FOREACH group_norm_data GENERATE group, SUM(norm_data.bid) AS bids_sum;


sum_bids_dsp -> группа : bids_sum
------------------------------------------------------
   group,   bids_sum
------------------------------------------------------
( (DSP-1, 2014.02.16),    82)
( (DSP-1, 2014.02.17),    58)
( (DSP-2, 2014.02.14),    101)
( (DSP-2, 2014.02.16),    58)

Pig — GROUP ALL
Часто необходимо посчитать количество «записей» в выборке. Просто применить COUNT к выборке — не удастся. Данные надо свернуть в одну группу и уже затем применить функции агрегации.
--Вычислим общую сумму, и количество групп.
--Для этого свернем всё в одну группу.

group_all = GROUP sum_bids_dsp ALL;


На выходе имеем группу — «all» и коллекцию всех предыдущих агрегатов.
( all, { ((DSP-1,2014.02.14),77), ((DSP-1,2014.02.15),67), ((DSP-1,2014.02.16),82),((DSP-1,2014.02.17),58),((DSP-2,2014.02.14),101),((DSP-2,2014.02.16),58),((DSP-2,2014.02.17),123),((DSP-3,2014.02.14),22),((DSP-3,2014.02.15),109),((DSP-3,2014.02.16),136),((DSP-3,2014.02.17),81) } )

теперь вычислим количество и сумму
summary = FOREACH group_all GENERATE COUNT(sum_bids_dsp), SUM(sum_bids_dsp.bids_sum);

Выход
------------------------------------------------------
  count,   sum
------------------------------------------------------
(11,         914)

По-моему, это то, что нужно. Обработка данных представлена в упорядоченном виде. Всё легко разбивается на шаги. Каждый этап можно снабжать комментариями.

Итого:

Pig плюсы:
  • Процедурный подход. Упорядоченность! Язык позволяет разбивать логику на блоки, каждый шаг можно развернуто описывать комментариями.
  • Формирование MapReduce под капотом. Уходит много оверхеда, связанного с обвязкой вокруг MR. Описание моделей данных, входных и выходных форматов, цепочек MR задач.
  • Интерактивность. Хорош для анализа данных в разных срезах.
  • Быстрота разработки. Отсутствие зависимостей, сборки

Pig Минусы:
  • Не всё можно уложить в язык Pig Latin
  • Pig Latin вместе со структурами данных более сложен, в отличии от HQL
  • Для UDF используется Jython. Это может ограничить в использовании некоторых библиотек.

Резюме:

  • Hive хорош для небольших и несложных выборок. HQL похож на SQL, поэтому можно очень быстро начать работать с данным фреймворком.
  • Pig Требует изучения языка и структур данных. Но зато, разобравшись один раз, вы получаете более мощный инструмент, в котором легче реализовывать сложные и многоступенчатые выборки. Вы получаете простой и упорядоченный код, с доступными и уместными комментариями.

Если вы и ваши коллеги отлично знаете SQL, работаете с ним ежедневно, и вас не смущают зубодробительные запросы, то Hive это отличное решение. Однако, если вы работаете с SQL эпизодично и ваш data workflow не укладывается в простые запросы, то однозначно стоит потратить день и разобраться с Pig. В дальнейшем это может сэкономить много времени вам, и вашим коллегам.
Поделиться публикацией

Комментарии 38

    +1
    Еще есть Cloudera Impala. Не сравнивали ее с этими двумя?
      +1
      Стоит в планах, но руки пока не дошли )
      По сути она похожа на Hive, т.к там тоже SQL, но должна быть в разы быстрее
        +1
        На последних демо Hortonworks Hive летал быстрее Impala даже на мелких запросах (спасибо TEZ и реизпользованию контейнеров), не говоря уже о крупных.
        Так же Impala совсем не fault-tolerance
          0
          Так же Impala совсем не fault-tolerance

          А расскажите, в чём это выражается?
            +1
            Если одна нода падает во время запроса — запрос падает целиком.
            На самом деле это не большая проблема, потому что Impala обычно не используется для долгих запросов.

            Надо заметить что Impala не использует Hadoop как средство вычисления, она использует тольео HDFS,
            а вычислительный процесс организует сама.
              0
              Импала даже HDFS толком-то не использует. Импаловые демоны кэшируют расположение блоков для того, чтобы при запросе locality factor был наивысшим. Если у вас периодически запускается HDFS balancer, то нужно делать REFRESH для таблиц, чтобы сбросить кэш локаций блоков, т.к. балансер перемещает блоки между датанодами. В отличие от MR, у Импалы нет слотов, она обеспечивает колоссальную экономию межузлового трафика. Можно добиться 100% data locality, если высаживать Демон импалы возле каждой ДатаНоды. И да, у импалы есть много-много недостатков. Это не база данных, а сёвая (язык Си ) нашлепка поверх файловой системы, где хранятся блоки HDFS.
                0
                если рассматривать базу данных с надеждой иметь update, то согласен что импала на нее не тянет.
                если рассматривать как систему для выполнения sql и получения результатов, то очень даже вменяемая база данных.

                p.s. с таким подходом любая база данных это нашлепка над блочным устройством
                  0
                  Оки, я вас понял.
                  Разница между нашлепкой и БД в ожиданиях. Лично я ожидаю, что БД может делать джоин через диск. А очень дорогая БД может делать распеределнный джоин на десятках дисков и десятков узлов. Кроме того, хотелось бы чтобы БД не нуждалась в ручном напоминании (REFRESH TABLE_NAME) о том, что блоки на блочном устройстве поменяли своё расположение на дисках и узлах.
                  Под нашлепкой я понимаю то, что ожидания не сосуществуют действительности.
                    +1
                    чем джойн через диск отличается от join в памяти?
                    скоростью работы и ограничением на объем.

                    И я считаю это хорошо, что она не пытается лезть на диск, так как работа с MR в свое время показала, что чем меньше диска мы трогаем, тем спокойней на душе. А распределенный join она и так умеет, следовательно размером памати одной ноды мы не ограниченны.
                    (offtop: www.memsql.com/ заявляют что такие супер-отличные in-mem база данных, но на практике это шардинг, для join данные сливаются на ОДИН узел и если в память не влазят, то валится весь запрос, распределенного join нету, но ведь никто не говорит что они не база данных)

                    REFRESH, как по мне, является временным решением, так как при большом желании не проблема сделать доп слушателя к namenode и чекать любые изменения в положении блоков, но раз до сих пор это не сделали, то следовательно не сильно то и мешает.
                      0
                      скоростью работы и ограничением на объем.

                      Ну и зачем эта биг-дата, если есть ограничение на объем? Что с ней потом делать? Не отвечает требованиям и ожиданиям. Только многочасовые джобы через Хайв.

                      работа с 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 и чекать любые изменения в положении блоков,
                      Неймнода не хранит информацию о блоках. ДатаНоды шлют блок-репорты о том, какие у них есть блоки. На основании репортов НеймНода получает знание о расположении блоков. Почему не сделали? Потому что ДатаНод сотни. Это сложная инженерная задача. Мы же не будем рассматривать БигДату на трех тестовых виртуалках :)
                        +2
                        память нынче достаточно дешевая, чтобы суммарно на кластер иметь не один терабайт.

                        >> Пока что не понимаю идею сравнивать 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 костыль скорее всего уберется.
                          0
                          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. Это нашлепка, потому что рынок знает, эта проблема решена многими вендорами много лет назад. Память давно не ограничение, все извращаются, чтобы результат поскорее отправить пользователю.

                          Было приятно с вами пообщаться, спасибо!
                            0
                            И да, кстати, есть еще HDFS caching blog.cloudera.com/blog/2014/02/apache-hadoop-2-3-0-is-released-hdfs-caching-ftw/
                            еще одна уникальная возможность выстрелить себе в ногу, включив слабоуправляемый cluster-wide cache.
                              0
                              >> Вы пробовали сделать 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ТБ памяти.
      +4
      Мне кажется в статье упущен важный фактор — скорость, а кластеры стоят достаточно дорого.
      Я не фанат 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) предоставляет разный набор компонент и версий.

      Получилось сумбурно, но надеюсь, что основную мысль я выразил.

        0
        Да, спасибо.
        В моём случае, Hive и Pig тестировались из Clouderа-вского дистрибутива, но рассматривались как вендоро-независимые продукты.
        Xотелось показать именно структурные отличия. В следующий раз попробую поковырять с точки зрения производительности. Но наверно это будут решения уже из другой весовой категории, например Impala — Spark/Shark.
          +1
          Ну не в сто раз, а до ста раз на отдельных запросах. Так или иначе, все такие бенчмарки нужно читать так: «На нашем наборе данных и на вот этих специальных запросах, которые мы хотели вам показать, наши последние наработки дают лучший результат». В зависимости от деталей реальной задачи показатели могут сильно варьироваться.

          Как уже сказали выше, кроме Hive и его нового ORC есть ещё Imapala и Parquet. Parquet — это такой колончатый формат файла, который на наших тестах давал сжатие в 5-7 раз и ускорение в 6-10 раз по сравнению с текстовыми файлами. Это при том, что оба теста проводились в Impala, которая на тот момент была сама по себе раз в 10 быстрее, чем Hive.

          Ребята из Hortonworks, правда, заявляют, что ORC круче Parquet, но клаудеровцем есть что ответить по этому поводу. Но для меня самым приятным в паркете является то, что его уже все знают и многие любят. Например, Spark SQL из коробки умеет работать только с двумя форматами — текстовыми файлами, и паркетом (остальные тоже можно подключить, но сложнее).

          Кстати, признание и любовь другими проектами — это вообще замечательная штука, и именно она заставляет меня довольно скептически относиться к Pig: будь он хоть в 10 раз круче HQL/SQL, но без интеграции с популярными проектами, без растущего сообщества он разно или поздно попросту останется за бортом.
            0
            Тем не менее Hive перестал болеть недугом Hadoop-based систем, когда надо ждать минуты для выполнения самого элементарного запроса на маленьком наборе данных. Hive теперь приблизился по скорости к Impala на небольших запросах, но Impala по-прежнему недоступны долгие запросы (я про fault-tolerance)

            Ничего не мешает использовать Parquet в Hive, ORC я привел как одну из альтернатив plain text формату.

            Я плохо знаком c Impala, посему не сочтите за холивар)

              0
              Правильно ли я понимаю применение Parquet?
              Если у вас есть фиксированный набор данных, над которым нужно делать много разных Ad hoc выборок, то есть смысл привести данные к Parquet — формату. Но если в систему валится большое количество обычных зазипованных логов, над которыми систематично запускается предопределенный MR, что то считает, экспортирует, а потом просто выкидывает сырые данные, то и нет смысла приводить всё к паркету, ибо дороже будет?
                0
                Есть старая поговорка: единственный способ узнать, какой вариант быстрее, — это запустить и проверить :) С одной стороны, если вы выкидываете данные сразу после использования, то конвертация в Parquet занимает лишнее время. С другой, Parquet гораздо быстрее для чтения, так что выигрыш от него может перекрыть дополнительные расходы на конвертацию даже для одноразового использования. (Сравните, например, интерпретацию и JIT-компиляцию кода в JVM). Ну и вообще, если вы не накапливаете данные, то возможно имеет смысл вообще обойти запись на HDFS, и обрабатывать данные прямо по ходу считывания их источника. Например, если вы читаете данные из RDBMS, то можно написать свой RecordReader (для MR) или RDD (для Spark) для них, обрабатывать на лету и сохранять на диск только уже обработанные записи.

                Кстати, одно из важнейших преимуществ Parquet перед текстовыми файлами в том, что это всё-таки структурированный формат. Если в CSV файле вам придётся хранить свободный текст или JSON или ещё что-нибудь кроме примитивных типов, то будьте готовы к семи кругам ада с эскапрированием специальных символов (запятых, ковычек и т.д.). Паркет (равно как и любой другой структурированный формат, естественно) избавляет от этой проблемы.
                  0
                  Преимущества паркета:
                  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.
              0
              >> Для 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 на данный момент больше холиварный вопрос чем практичный, пока в проде нету статистики кто лучше, так как у них схожести больше чем различий.
                0
                Зачем же так сразу? ))
                Hive — действительно поддерживает рассовый Python. А вот с Pig-ом у меня такое не прошло. Там Jython
                  0
                  надо было и указать, что Python хотели использовать, а то фраза «Для UDF используется Jython» вводит людей в заблуждение, что только на нем можно писать. Более корректно было бы «Для UDF используется любой JVM совместимый язык. Если нужны сторонние библиотеки, то необходимо написание дополнительных оберток или реализация нужного языка под JVM, например Jython для запуска Python скриптов, но это накладывает ограничения на разнообразие доступных библиотек»
                    0
                    Я пишу UDF для пига на jython (короткие функции фильтрации со счетчиками, например), Java (когда нужен перфоманс), Groovy (когда нужно написать прототип). Посмотрите документацию. pig.apache.org/docs/r0.10.1/udf.html
                    Java, Jython. JavaScript, Ruby добавлены в качестве эксперимента.
                      0
                      пишите, нет проблем,
                      но перечитайте мой комментарий: я просто хотел указать, что первоначальная фраза о том, что НАДО использовать для udf именно jython некорректна, правильно было бы указать о любом jvm языке.
                        0
                        А вот с Pig-ом у меня такое не прошло. Там Jython

                        Веточкой промахнулся :)
                        Спасибо, пишу.
                  0
                  ой, с разверткой пропустил случайно когда говорил про lateral view
                  >> Pig — развертка агрегатов (FLATTEN)

                  cube
                  Windowing and Analytics Functions

                  к тому же перекинуть разработчиков-аналитиков с какой sql базы на большие объемы и hive будет проще, чем застравлять их учить hive и писать свои udf
                    0
                    что-то после отпуска мысли путаются =)

                    «учить hive и писать свои udf» нужно читать как «учить PIG и писать свои udf», так как с sql на hql перейти заметно проще
                      0
                      я понял )
                      UDF и в Hive могут пригодится, особенно когда что то трансформировать нужно, или сматчить.
                  +1
                  Я смотрю все примеры из анализа данных сводится либо к рекламе, либо к очередному look-alike для магазинов или рекомендательных сервисов ))
                    0
                    Такова структура рынка :) Судя по вакансиям и текущим проектам, большие данные, и их анализ, нужны только рекламному бизнесу.
                      +1
                      О, отнюдь. Взгляните, например, на Data Science Challenge от Cloudera — компания предлагает посоревноваться в поиске аномалий при лечении пациентов по страховке. А Kaggle вот даёт на выбор целый список задач — от предсказания рисков в бизнесе до поиска базона Хиггса. Ещё вот Hortonworks приводит отличный набор юз кейсов из совершенно разных областей. Да и по своему личному опыту могу сказать, что анализ данных можно применить практически к любой задаче — от сегментации базы пользователей до диагностики медленного пинга.
                        0
                        Это верно, можно найти много действительно полезных применений. Но я об насущном :)
                        Открываем hh.ru и смотрим вакансии :)
                          0
                          Ну вот я открыл первые 4 вакансии по ключевому слову Hadoop: компания Vi, занимающаяся обработкой видео, предлагает построить им систему обработки данных и работать над профилями пользователей; mail.ru хочет с помощью хадупа масштабировать свой поиск; а дальше идут две вакансии от Альфа-банка (data scientist и big data разработчик), который явно ни рекламой, ни рекоммендательными сервисами не занимается.

                          Впрочем, я это не для спора, а просто как другую точку зрения :)
                            0
                            Комания Vi занимается рекламой, к видео она конечно тоже имеет отношение, но только в срезе рекламного бизнеса
                      0
                      Мне кажется, у рынка есть стабильное непонимание возможностей бигдаты.
                      Пошел новый тренд — рекомендательные сервисы. Люди читают про них, читают про бигдата, заполняют рынок вакансиями по поиску бигдата специалистов для реализации рекомендеров.
                      На самом деле возможностей применения масса. Например не так давно участвовал в реализации сервиса аналитики данных для екоммерс. Мускуль перестал нормально справляться после накопления 20М «записей» о посетителях. Перешли на хадуп — появилась масса возможностей, красивые графики, кучи отчетов, и счастье для аналитиков.
                        0
                        Мне кажется, те у кого данные есть, знают о возможностях бигдаты, а у кого их нет — тем и не надо.
                        Что касается вашего проекта, то как бы там ни было, вы работаете с «записями о посетителях», по сути сейчас вся бигдата и крутится вокруг этих записей (рекомендации, выяснение соц. дема, интересов, поведения...).
                        Даже ритейлеры типа Ленты, не даром подсаживают всех на свои скидочные карточки. Это же история поведения клиента, со всеми вытекающими…

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое