company_banner

Hadoop, часть 3: Pig, обработка данных

  • Tutorial
des-48-5

В предыдущей публикации мы подробно рассмотрели процесс сбора данных при помощи специализированного инструмента Flume. Но чтобы полноценно работать с информацией, мало ее просто собрать и сохранить: ее нужно обработать и извлечь из нее нечто нужное и полезное.

Для обработки данных в Hadoop используется технология MapReduce.


Технология MapReduce



История



Обработка данных в Hadoop осуществляется с помощью технологии MapReduce. Изначально эта технология была разработана компанией Google в 2004 году.

Разработчики Google Джеффри Дин и Санджай Гемават в 2004 году опубликовали статью, в которой предложили следующее решение для обработки больших объемов «сырых» данных (индексированных документов, логов запросов и т.п.): огромный массив информации делится на части, и обработка каждой из этих частей поручается отдельному серверу. Как правило, данные обрабатываются на тех же серверах, где они и хранятся, что позволяет ускорить процесс обработки и избежать лишних перемещений данных между серверами. После этого полученные результаты объединяются в единое целое.

Специалисты Google в упомянутой выше статье ограничились лишь описанием основных алгоритмов, не останавливаясь на подробностях реализации. Однако этой информации оказалось для разработчиков Hadoop вполне достаточно, чтобы создать собственный фреймворк MapReduce.

Сегодня он используется во многих известных веб-проектах — Yahoo!, Facebook, Last.Fm и других.
Рассмотрим архитектуру и принципы работы Hadoop MapReduсе более подробно.

Архитектура и принципы работы



Архитектура MapReduce построена по принципу «главный — подчиненные» (master — workers). В качестве главного выступает сервер JobTracker, раздающий задания подчиненным узлам кластера и контролирующий их выполнение.

Архитектура и принципы работы

Обработка данных подразделяется на следующие этапы:
  1. Запуск приложения: передача кода приложения на главный (master) и подчиненные узлы (workers);
  2. Мастер назначает конкретные задачи (Map или Reduce) и распределяет части входных данных по вычислительным узлам (workers);
  3. Map-узлы читают назначенные им входные данные и начинают их обработку;
  4. Map-узлы локально сохраняют промежуточные результаты: каждый узел сохраняет полученный результат на локальные диски;
  5. Reduce-узлы читают промежуточные данные с Map-узлов и выполняют Reduce обработку данных;
  6. Reduce-узлы сохраняют итоговые результаты в выходные файлы, обычно в HDFS.


Создание приложений для MapReduce — дело достаточно трудоемкое. Написание всех функций, компилирование и упаковка занимают много времени. Чтобы облегчить работу компания Yahoo! разработала специализированный инструмент под названием Pig, повышающий уровень абстракции при обработке данных.

Pig


Pig состоит из двух частей:
  • язык для описания потоков Pig Latin;
  • исполнительная среда для запуска сценариев Pig Latin (доступны два варианта: запуск на локальной JVM или исполнение в кластере Hadoop).


Сценарий Pig включает серию операций (преобразований), которые необходимо применить к входным данным, чтобы получить выходные данные. Эти операции описывают поток данных, который затем преобразуется (компилируется) исполнительной средой Pig в исполняемое представление и запускается для выполнения. Во внутренней реализации Pig трансформирует преобразования в серию заданий MapReduce.

Изначально Pig был создан для работы из консоли (оболочка Grunt Shell). В реализации от Cloudera работа с Pig осуществляется через простой и удобный веб-интерфейс. Открыть его можно через уже знакомый нам интерфейс Hue http://[узел_на_котором_установлен_Hue]:8888/pig/

Pig

Веб-интерфейс включает полноценный редактор (есть даже автоподстановка операторов) и менеджер скриптов. С его помощью можно сохранять скрипты непосредственно в Hue, запускать их, просматривать список запущенных задач, результаты и логи запусков.

Тестовая задача


В качестве тестовой задачи мы выполним обработку логов доступа нашего хранилища за определенный день (сутки). Рассчитаем следующие параметры:
  • общее количество запросов;
  • количество запросов с каждого уникального IP;
  • количество запросов на каждый уникальный URL;
  • объем данных, переданных по каждому URL.

Ниже приводится скрипт, с помощью которого решается поставленная задача. Сразу же следует заметить, что этот скрипт (как и все скрипты в Pig) не выполняется построчно, как в интерпретируемых языках. Компилятор Pig разбирает зависимости и задает потоки данных. Компилирование скрипта начинается с конца, то есть с команды STORE. Для данных, после обработки которых нет команды сохранения, не будет создано никаких задач и сами данные не будут даже прочитаны. Это позволяет писать скрипт в достаточно произвольной форме, всю работу по оптимизации, определения порядка исполнения и распараллеливанию возьмет на себя Pig.

Полный листинг скрипта будет выглядеть так:
records = LOAD '/log/flume/events/14-02-20/' USING PigStorage('\t')
AS (
date:chararray,
clientip:chararray,
clientport:chararray,
proto:chararray,
statuscode:int,
bytes:int,
sq:chararray,
bq:chararray,
request:chararray );

count_total = FOREACH (GROUP records ALL) GENERATE COUNT(records);

count_ip = FOREACH (GROUP records BY clientip) GENERATE group AS ip, COUNT(records) AS cnt;
top_ip = ORDER count_ip BY cnt DESC;

filtered_req = FILTER records BY statuscode == 200 OR statuscode == 206;
count_req = FOREACH (GROUP filtered_req BY request) GENERATE group AS req, COUNT(filtered_req) AS cnt, SUM(filtered_req.bytes) AS bytes;
top_req = ORDER count_req BY bytes DESC;

%declare DT `date +%y%m%dT%H%M`
STORE count_total INTO '$DT/count_total';
STORE top_ip INTO '$DT/top_ip';
STORE top_req INTO '$DT/top_req';


Он состоит из трех частей: загрузка данных, обработка и сохранение. Такой порядок является общим для большинства задач. В некоторых случаях решение задач может включать и дополнительные этапы — например, генерацию данных (например, структурированных искусственных данных для проверки алгоритма) или сохранение промежуточных результатов вычислений. Подробное описание синтаксиса, типов данных и операторов вы можете найти в официальной документации.

Рассмотрим каждый этап более подробно.

Загрузка


records = LOAD '/log/flume/events/14-02-20/' USING PigStorage('\t')
AS (
date:chararray,
clientip:chararray,
clientport:chararray,
proto:chararray,
statuscode:int,
bytes:int,
sq:chararray,
bq:chararray,
request:chararray );


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

07/Dec/2013:20:05:13    95.153.193.56    37877    http    200    1492030    0    0    GET /745dbda3-894e-43aa-9146-607f19fe4428.mp3 HTTP/1.1
08/Dec/2013:15:00:28    178.88.91.180    13600    http    200    4798    0    0    GET /public/cars/bmw7l/down.png HTTP/1.1
08/Dec/2013:15:00:29    193.110.115.45    64318    http    200    1594    0    0    GET /K1/img/top-nav-bg-default.jpg HTTP/1.1


Вначале рассмотрим модель данных и терминологию. Основной объект в Pig Latin- это «отношение». Именно с отношениями работают все операторы языка. В форме отношений представляются входные и выходные данные.

Каждое отношение представляет собой набор однотипных объектов — «кортежей» (tuples). Аналоги в БД: кортеж — это строка, отношение — это таблица.

Кортежи соответственно состоят из нумерованных или именованных объектов — «полей», произвольных базовых типов (число, строка, булева переменная и т.д.).

Итак, в Pig Latin результатом любого оператора является отношение, представляющее собой набор кортежей.
Оператор LOAD создает отношение records из файлов в HDFS из директории ’/log/flume/events/14-02-20/’, используя стандартный интерфейс PigStorage (также укажем, что разделителем в файлах является символ табуляции ‘\t’). Каждая строка из файлов предстанет кортежем в отношении. Секция AS присваивает полям в кортеже типы и имена, по которым нам будет удобнее к ним обращаться.

Обработка


Посчитаем общее количество записей в логах с помощью оператора COUNT. Перед этим необходимо объединить все строки в records в одну группу операторами FOREACH и GROUP.

count_total = FOREACH (GROUP records ALL) GENERATE COUNT(records);
count_ip = FOREACH (GROUP records BY clientip) GENERATE group AS ip, COUNT(records) AS cnt;
top_ip = ORDER count_ip BY cnt DESC;


В переводе с Pig Latin на естественный язык приведенный скрипт выглядит так: для каждой записи (FOREACH), из records, сгруппированных вместе (GROUP ALL), выполнить подсчет записей в records (GENERATE COUNT).

Теперь посчитаем количество запросов с уникальных адресов. В наших кортежах в отношении records в поле clientip содержатся IP-адреса, с которых выполнялись запросы. Сгруппируем кортежи в records по полю clientip и определим новое отношение, состоящее из двух полей:
  • поле ip, значение которого берется из названия группы в отношении records;
  • количество записей в группе — cnt, посчитанное оператором COUNT, то есть количество записей, соответствующих определенному IP-адресу в поле IP.


Далее мы определяем еще одно отношение top_ip, состоящее из тех же данных, что и count_ip, но отсортированное по полю cnt оператором ORDER. Таким образом, в top_ip у нас будет список IP-адресов клиентов с которых чаще всего происходили запросы. В дальнейшем мы можем привязать эти данные к GEO-IP и посмотреть, в каких городах и странах наше хранилище пользуется наибольшей популярностью =)

filtered_req = FILTER records BY statuscode == 200 OR statuscode == 206;
count_req = FOREACH (GROUP filtered_req BY request) GENERATE group AS req, COUNT(filtered_req) AS cnt, SUM(filtered_req.bytes) AS bytes;
top_req = ORDER count_req BY bytes DESC;


После этого посчитаем количество успешных запросов на каждый URL, а также суммарный объем загруженных по каждому URL данных. Для этого сначала воспользуемся оператором фильтрации FILTER, отобрав только успешные запросы с HTTP кодами 200 OK и 206 Partial Content. Этот оператор определяет новое отношение filtered_req из отношения records, отфильтровав его по полю statuscode.

Далее аналогично подсчету IP-адресов посчитаем количество уникальных URL, группируя записи в отношении requests по полю request. Для нас также представляет интерес переданный объем данных по каждому URL: его можно рассчитать с помощью оператора SUM, складывающего поля bytes в сгруппированных записях отношения filtered_req.

Теперь осуществим сортировку по полю bytes, определяя новое отношение top_req.

Сохранение результатов



%declare DT `date +%y%m%dT%H%M`
STORE count_total INTO '$DT/count_total';
STORE top_ip INTO '$DT/top_ip';
STORE top_req INTO '$DT/top_req';


Предпочтительно сохранять результаты каждого выполнения скрипта в отдельную директорию, имя которой включает дату и время исполнения. Для этого можно воспользоваться функцией вызова произвольной шелл-команды прямо из Pig-скрипта (ее нужно написать в обратных кавычках). В примере результат команды date заносится в переменную DT, которая затем подставляется в пути сохранения данных. Сохраняем результаты командой STORE: каждое отношение — в свой каталог.

Просмотреть выходные данные можно через файловый менеджер в Hue; по умолчанию путь в HDFS указывается относительно домашней директории пользователя, запустившего скрипт.

File Browser

Информация о результатах выполнения задач будет отображена в логах Pig следующим образом:
http://cdh3:8888/pig/#logs/1100715
Input(s):
Successfully read 184442722 records (32427523128 bytes) from: "/log/flume/events/14-02-20"

Output(s):
Successfully stored 1 records (10 bytes) in: "hdfs://cdh3:8020/user/admin/140225T1205/count_total"
Successfully stored 8168550 records (1406880284 bytes) in: "hdfs://cdh3:8020/user/admin/140225T1205/top_req"
Successfully stored 2944212 records (49039769 bytes) in: "hdfs://cdh3:8020/user/admin/140225T1205/top_ip"

Counters:
Total records written : 11112763
Total bytes written : 1455920063


Отчет из Oozie:

Last Modified  Tue, 25 Feb 2014 00:22:00
Start Time     Tue, 25 Feb 2014 00:05:16
Created Time   Tue, 25 Feb 2014 00:05:15
End Time       Tue, 25 Feb 2014 00:22:00


Из приведенных логов видно, что при выполнении тестовой задачи было обработано более 180 миллионов записей общим объемом более 32 Гб. Вся процедура обработки заняла около 15 минут.

Во время активной фазы Map было задействовано 22 процессорных ядра и 91Гб оперативной памяти. Для небольшого кластера, состоящего из трех серверов пятилетней давности, такой результат можно считать вполне неплохим.

Выше уже было сказано, что Pig во время исполнения скрипта создает MapReduce задачи и отправляет их на выполнение в MR-кластер. Этот процесс наглядно показан на графиках статистики в панели управления Cloudera Manager:

Home - Cloudera Manager 1

Activities : mapreduce1

  1. Этап Map: процессоры и диски на каждом узле заняты обработкой своих частей данных.
  2. Этап Reduce: результаты, полученные на первом этапе, передаются по сети и объединяются.
  3. На третьем этапе результаты сохраняются в файловой системе (на графике виден скачок записи в HDFS).


На графиках можно увидеть, что решение задачи включало два прохода MapReducе. Во время первого прохода был выполнен подсчет уникальных записей, а во время второго — сортировка. Эти процедуры не могут быть распараллелены и выполнены за один проход, так как вторая процедура работает с результатами первой.

Заключение


В этой статье мы рассказали об архитектуре MapReduce, а также рассмотрели особенности его работы с использованием инструмента Pig. Написание программ для MapReduce представляет собой весьма непростую задачу, требующую особого подхода. Все сложности, однако, компенсируются мощностью, возможностями масштабирования и высокой скоростью обработки огромных объемов произвольных данных.

В ближайшее время мы планируем продолжить цикл статей о Hadoop. Следующая публикация будет посвящена работе с базой данных Impala.

Читателей, не имеющих возможности комментировать посты на Хабре, приглашаем к нам в блог.
Selectel
152,00
ИТ-инфраструктура для бизнеса
Поделиться публикацией

Похожие публикации

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

    +3
    Прошу не закидывать меня помидорами, но лично мой опыт использования Pig оказался скорее негативным.

    1) Он действительно медленный. Это скорее болезнь Hadoop, лежащего в основе. Данные размером в 32Гб обрабатывались 15 минут, причем расход оперативки составил 91Гб? 180 млн записей? Простите, да банальнейший кластер Postgres сделал бы то же самое, да еще и (возможно) быстрее. С Hive та же беда.

    2) Подмножество Pig Latin SQL после перехода от «обычного» SQL, используемого в MySQL, Postgres и т.п. RDBMS, скорее мешает, нежели чем помогает. Парадигма Map-reduce не так уж сложна для восприятия, и лично мне намного проще накидать MR-воркер на том же Питоне, чем вникать в ограничения Pig SQL. Даже с Hive это чувствовалось.

    3) По деньгам — зачастую краткосрочная аренда мощного SSD сервера и обработка данных там, используя привычный инструментарий, дает бОльший бизнес-профит.

    3) На Хабре была уже статья — «у вас нет столько данных». Hadoop очень, очень медленный, сложный и неудобный (кто хоть раз пытался разобраться в exception логах, поймет). Его применения оправдано только в случае действительно больших данных (навскидку, от нескольких терабайт), и зоопарка серверов. Вы не поверите — простейший однопоточный скрипт на Питоне на данных порядка 200Гб оказывался быстрее, чем хваленый Хадуп (сравнивалась single-node инсталляция). Чего уж там говорить про Яву или Го или Си. Хадуп — один из немногих инструментов для обработки действительно больших данных, но на данных средних размеров он бесполезен.

    Все, что я написал выше — следствие многомесячных экспериментов в стартапе, у которого обработка данных — основной бизнес-процесс. Перепробовано было множество инструментов, и Хадуп, и Хайв, и Пиг, и Кассандра, и Монго, и Диско, и Постгрес с Мускулем и самописные решения на Питоне. Модные инструменты — не значит эффективные.

    P.S. Прошу прощения за кальки с английского — переключать постоянно раскладки слишком уж утомительно.

      0
      ни в коем случае не опровергая Вами сказанное (сам хотел добавить, что Vectorwise подобные подсчеты на 500 млн строк да еще и с джойном с таблицей из 10 млн строк выдал за 17 секунд в однонодовой конфигурации с 64 гигами и 8 ядрами), однако, в БД данные надо еще и загрузить. Прикинув свои данные, которые я запихиваю в VW при помощи DataStage, у меня получилось, что ETL съедает весь профит дальнейшего быстрого выполнения SQL запросов. Правда, тут все зависит от специфики задач. Все-таки данные загружаются один раз, а обращаться к ним можно вечно.
        0
        Vectorwise платная? На сайте цен нет, сколько там лицензии стоят?
          0
          да, платная. Однако, есть Ingres, которая Open Source и на движке которой построен Vectorwise. Привел в качестве примера быстродействия колоночной базы данных для таких подсчетов. По стоимости лицензий ничего, к сожалению, сказать не могу.
        +2
        Ваш 3 пункт всё объясняет. Да, даже 100Гб это не тот объем данных, для кторых стоит использовать Hadoop MR.
        Плюс вопрос масштабирования, вы сможете сделать кластер Postgres из 100 нод? Насколько хорошо при этом будет масштабироваться производительность? Hadoop MR масштабируется практически линейно.

        Если вы программист, то да, наверное проще написать свое MR приложение. Но если вам требуется делать различные выборки и экспериментировать с поиском, расчетами и алгоритмами, то зачастую проще и эффективне использовать Pig. К тому же он позволяет включатьв код произвольные внешние скрипты хоть на Python, хоть на Bash.

        Конечно для каждой задачи необходимо выбирать инструмент по «размеру» =) Эта статья- всего лишь пример для новичков в Hadoop.
          0
          Конечно, если нужно 100 нод, то здесь надо брать специализированные решения. Постгрес на 100 нод даже представлять страшно =) С другой стороны, пара-тройка серверов запросто способна обрабатывать те же 100 Гб значительно быстрее, чем за 15 минут. Про выборки и эксперименты… Наверное это дело субъективное, но в общем-то меня действительно сбивает с толку синтаксис Pig, да и отладка всего этого дела довольно мучительна. А Вы не смотрели в сторону других решений? Cassandra, к примеру, тоже использует подмножество SQL, и работать с ней (лично по моим ощущениям) оказалось очень приятно, просто и понятно. Или, к примеру Hive (у него синтаксис, насколько я помню, шире чем у Pig и даже Impala).
          +2
          Первое правило кластеростроения — тестировать производительность любого кластерного решения только на рельном физическом кластере. Никакие однонодовые инсталляции и всякие виртуализации в рамках одной ноды никогда не дадут вам реальных результатов. Вы не получите производительности больше, чем ее есть у вас физически, при этом, не кластерные продукты в рамках одной ноды, однозначно выиграют, т.к. утилизируют эту производительность эффективнее.
            0
            Не совсем понял, зачем здесь строить большие кластеры. Мы же не играем в игру «построй кластер», а решаем вполне конкретную задачу. 32Гб это очень, очень мало. Хватит одного мощного сервера. Да что там, такой объем данных даже в RAM поместиться может. О том и был мой комментарий — Хадуп для действительно больших данных и зоопарков из нод, в случае, если же big data не очень уж «big» — то эффективнее в большинстве случаев использовать что-то другое. Я просто по роду деятельности часто сталкиваюсь с тем, что люди лепят Хадуп где только ни попадя, разворачивая лишние ноды или просто используя single-node инсталляцию (неэффективную, Вы правы). Вот в этом и была основная мысль — летать в соседний магазин на вертолете конечно круто и трендово, но доехать на машине будет проще, быстрее и дешевле.
              +1
              Это довольно частое заблуждение, что кластеризация нужна только для обработки большого количества данных. Важно не количество данных, а характер выполняемых с ними операций. То, что ваши 32Гб легко влезают в память, не значит что для любой задачи вы сможете быстро, а в общем случае, вообще, обработать эти данные в памяти, или, даже, в рамках всех, включая дисковые, ресурсов одной ноды. Ваши «маленькие» данные могут легко породить декартово произведение фантастических размеров. Например, ваши 32Гб это логи посещений вашего ресурса, а получить вам нужно, скажем, список уникальных IP адресов никогда не загружавших одинаковые страницы в интервале 5 минут ))
                0
                Опять соглашусь с Вами и плюсану Ваш комментарий, если хватит кармы. Но есть одно «но» — Hadoop, а тем более Pig, абсолютно не предназначены для быстрой обработки данных. У автора поста на все ушло 15 минут — это довольно много. Тот же Spark, например, гораздо больше подходит для быстрой обработки. Стало даже классикой жанра сравнивать скорость Хадупа и Спарка и показывать, что Спарк может быть быстрее в сотни раз. Или какая-нибудь MemSQL, если данных не очень много. В общем, основная моя мысль — Hadoop это инструмент для обработки огромных объемов данных на сотнях машин, и больше. Задачи меньшего масштаба можно — зачастую — решить более привычными и удобными инструментами за меньшее время и деньги. Не то чтобы Хадуп вообще не подходит для мелких данных — конечно подходит — просто вопрос скорее оптимизации процессов, нежели чем решающего выбора инструмента.
                  0
                  Вы все время делаете отсылки к различным БД, но вся соль Pig и классического Hadoop в обработке очень больших объемов сырых данных (в общем случае просто файлов).
                  Проверил обработку 300Гб данных, выполнилась за 150 минут, т.е. имеем линейный рост. Если увеличить число нод в 10 раз, то и скорость увеличится в 10 раз. При этом никакой мороки по настройке и оптимизации, так сказать «грубая сила» =)

                  Если нужна скорость, то тут конечно надо использовать надстройки над HDFS с индексами и прочим, наример, Impala или Hive.
            +1
            1. Медленный по сравнению с чем? И это не болезнь, это называется batch processing.
            2. Это не SQL, Pig latin процедурный, а SQL- декларативный. Вы пытаетесь сравнить теплое со сладким.
            3. Если нет SLA и все можно сделать на коленке, то да.

            Вы не поверите —

            Конечно поверю, потому что Хадуп, это от 5 нод. Странно сравнивать распределенную систему, установленную на одном узле с однопоточной программой. Чего вы пытались добиться этим сравнением?
              0
              1. Медленный по сравнению с однопоточными скриптами, Spark'ом или хотя бы минимально настроенным Postgres'ом. Это — если мы берем сравнительно небольшие данные (а 32Гб — это небольшой объем).

              2. Не так важно, как это называется, как важно то, как это работает. А работает это — лично по моему мнению, да и не только по моему — довольно неудобно.

              3. О том и речь — ситуации разные.

              Вы наверное не полностью прочитали мой комментарий. Я писал, что Хадуп — это один из немногих инструментов, которые в принципе позволят обработать терабайты данных. Но для небольших объемов данных существует множество других инструментов, которые оказываются зачастую удобнее, проще, быстрее и в итоге дешевле.
                0
                1. Spark идеологически в корне отличается от всего остального Хадупного хозяйства. Между прочим, HDFS caching может вывести pig на скорость, соизмеримую со Спарком. Вы ставите рядом трактор и Феррари, а потом расстраиваетесь, потому что трактор медленно едет, а в Феррари не влезает картошка.

                2. Пытаться процедурный data flow язык сравнить с декларативным SQL? Конечно, это не важно. Ваша аргументация меня удивляет. Linkedin, Spotify, Yahoo, Netflix будут расстроены, узнав что pig работает «неудобно».

                Я читал ваши комментарии, меня смущает отсутствие объективности при оценке инструментов. Крайне любопытно узнать, что вас привело к такому.
                  0
                  Все как раз наоборот — люди пытаются на Феррари возить картошку, хотя явно дешевле ее загрузить в Жигули. Об этом я написал черным по белому — 32Гб это очень мало, даже single-node инсталляция того же Постгреса обработала бы данные за сравнимое время. Смысл городить Хадуп?

                  Вы, кстати, употребили слово «идеологически». Видимо Вам очень важна «идеология», раз Вы принципиально «за» одно решение и «против» других? Дело Ваше, мне же гораздо важнее удобство решения и его стоимость для бизнеса. Кстати, посмотрел Ваш профиль — видимо Вы фанат Хадупа, и Вам «из-за леса деревьев не видно».

                  Я не собираюсь ни с кем спорить и никому ничего доказывать, мой первый комментарий плюсанули 3 человека — следовательно, не я один так думаю. Простите, больше не вижу смысла продолжать дискуссию.
              0
              Напишите статью про результаты «многомесячных экспериментов» со сравнением испробованных альтернатив — это будет хит.
                0
                Вряд ли это будет хит, у нас всего лишь 2 терабайта данных суммарно и порядка миллиарда «строк» (в терминах SQL) на выходе — поэтому на фоне объемов Google или Facebook не будет ничего интересного. Могу только сообщить, что стоимость разовой обработки таких данных (а там целый конвейер и много архивирования\разархивирования) — порядка 70-100 руб., если посчитать в ценах Digital Ocean или Amazon. Используемые\использовавшиеся инструменты я примерно описал в первом комментарии, если что-то интересно под конкретную задачу — спрашивайте, с удовольствием поделюсь опытом.
                  +1
                  Не прибедняйтесь, очень мало у кого есть опыт экспериментов с кучей систем обработки данных, поэтому такое сравнение из первых рук будет крайне ценно. Обычно берут что-то одно, и вперед.

                  Хабр читают не только (читают ли?) сотрудники Гугла и Фейсбука, многие ребята с сопоставимым или даже меньшим объемом данных, чем у вас, сейчас думают о big data. Я таки думаю, что это будет хит.
                    0
                    ок, обязательно напишу — найти бы только времени…
              +1
              Кстати, не сочтите за оффтоп, но из всех серьезных MR-фреймворков лучше всего показал себя не особо известный Disco. Устанавливается в разы быстрее Хадупа, на среднего размера данных ведет себя намного быстрее, очень удобный веб-интерфейс, наглядные traceback ошибок, все «для людей». Не тестировал его на терабайтах данных, но по отзывам все должно быть ок. Тот самый случай, когда удобство сочетается с мощностью и производительностью (в отличие от монструозной Хадуп-экосистемы). Disclaimer: я не имею никакого отношения к разработчикам Disco, просто использую этот инструмент.
                +1
                Используя готовые дистрибутивы можно развернуть Hadoop за 30 минут и получить в комплекте замечательный Web-интерфейс =) habrahabr.ru/company/selectel/blog/198534/
                  0
                  … и муки отладки в довесок =) Нет, правда, мне есть с чем сравнить — стандартные питоновые traceback'и из Disco отличаются невероятной наглядностью и лаконичностью. Установка — дело не 30, а 10 минут. Вот прямо сейчас с ходу могу припомнить, что, к примеру, файловую систему на Disco форматировать не нужно. Это же очевидно — если человек только-только установил DDFS\HDFS, неужели нельзя отформатировать все автоматически? Вот эта избыточность в логах, необходимость лишних действий — это все, по ощущениям, очень близко к Java-way, где любят создавать классы на каждый чих. Только не подумайте, что я холивора ради это написал — нет конечно, на Java написаны многие отличные продукты, да и в целом язык очень хороший даже сегодня, несмотря на появления всяких модных штук типа Go. Просто Хадуп действительно монструозен, просто сравните с Disco ;)
                    0
                    Не совсем понял про муки отладки. В самом начале экспериментов писал всякие глупости с ошибками, но по логам Pig быстро понимал в чем проблема (те же трейсы там есть).
                +2
                Не бывает map и reduce узлов, бывают map и reduce tasks. И, скорее всего, reduce task будет запущен на том же узле, что и map task, чтобы избежать излишней передачи данных по сети. Data locality, вокруг этого построены все современные фреймворки. Не у всех есть деньги на infiniband.
                В результате парсинга скрипта получается DAG, он и исполняется.
                Было бы здорово, если бы схема была оформлена в терминологии HDFS+MapReduce; JobTracker, TaskTracker, DataNode.
                  0
                  Спасибо за комментарий, согласен, с терминологией всегда проблемы =) На самом деле если задача многоэтапная Map и Reduce таски в общем случае распределяются случайно между TaskTracker'ами.

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

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