Hadoop: что, где и зачем



    Развеиваем страхи, ликвидируем безграмотность и уничтожаем мифы про железнорождённого слона. Под катом обзор экосистемы Hadoop-а, тенденции развития и немного личного мнения.

    Поставщики: Apache, Cloudera, Hortonworks, MapR



    Hadoop является проектом верхнего уровня организации Apache Software Foundation, поэтому основным дистрибутивом и центральным репозиторием для всех наработок считается именно Apache Hadoop. Однако этот же дистрибутив является основной причиной большинства сожжённых нервных клеток при знакомстве с данным инструментом: по умолчанию установка слонёнка на кластер требует предварительной настройки машин, ручной установки пакетов, правки множества файлов конфигурации и кучи других телодвижений. При этом документация чаще всего неполна или просто устарела. Поэтому на практике чаще всего используются дистрибутивы от одной из трёх компаний:

    Cloudera. Ключевой продукт — CDH (Cloudera Distribution including Apache Hadoop) — связка наиболее популярных инструментов из инфраструктуры Hadoop под управлением Cloudera Manager. Менеджер берёт на себя ответсвенность за развёртывание кластера, установку всех компонентов и их дальнейший мониторинг. Кроме CDH компания развивает и другие свои продукты, например, Impala (об этом ниже). Отличительной чертой Cloudera также является стремление первыми предоставлять на рынке новые фичи, пусть даже и в ущерб стабильности. Ну и да, создатель Hadoop — Doug Cutting — работает в Cloudera.

    Hortonworks. Так же, как и Cloudera, они предоставляют единое решение в виде HDP (Hortonworks Data Platform). Их отличительной чертой является то, что вместо разработки собственных продуктов они больше вкладывают в развитие продуктов Apache. Например, вместо Cloudera Manager они используют Apache Ambari, вместо Impala — дальше развивают Apache Hive. Мой личный опыт с этим дистрибутивом сводится к паре тестов на виртуальной машине, но по ощущениями HDP выглядит стабильней, чем CDH.

    MapR. В отличие от двух предыдущих компаний, основным источником доходов для которых, судя по всему, является консалтинг и партнёрские программы, MapR занимается непосредственно продажей своих наработок. Из плюсов: много оптимизаций, партнёрская программа с Amazon. Из минусов: бесплатная версия (M3) имеет урезанный функционал. Кроме того, MapR является основным идеологом и главным разработчиком Apache Drill.

    Фундамент: HDFS



    Когда мы говорим про Hadoop, то в первую очередь имеем в виду его файловую систему — HDFS (Hadoop Distributed File System). Самый простой способ думать про HDFS — это представить обычную файловую систему, только больше. Обычная ФС, по большому счёту, состоит из таблицы файловых дескрипторов и области данных. В HDFS вместо таблицы используется специальный сервер — сервер имён (NameNode), а данные разбросаны по серверам данных (DataNode).

    image

    В остальном отличий не так много: данные разбиты на блоки (обычно по 64Мб или 128Мб), для каждого файла сервер имён хранит его путь, список блоков и их реплик. HDFS имеет классическую unix-овскую древовидную структуру директорий, пользователей с триплетом прав, и даже схожий набор консольных комманд:

    # просмотреть корневую директорию: локально и на HDFS
    ls /
    hadoop fs -ls /
    
    # оценить размер директории 
    du -sh mydata
    hadoop fs -du -s -h mydata
    
    # вывести на экран содержимое всех файлов в директории
    cat mydata/*
    hadoop fs -cat mydata/* 
    


    Почему HDFS так крута? Во-первых, потому что она надёжна: как-то при перестановке оборудования IT отдел случайно уничтожил 50% наших серверов, при этом безвозвратно было потеряно всего 3% данных. А во-вторых, что даже более важно, сервер имён раскрывает для всех желающих расположение блоков данных на машинах. Почему это важно, смотрим в следующем разделе.

    Движки: MapReduce, Spark, Tez



    При правильной архитектуре приложения, информация о том, на каких машинах расположены блоки данных, позволяет запустить на них же вычислительные процессы (которые мы будем нежно называть англицизмом «воркеры») и выполнить большую часть вычислений локально, т.е. без передачи данных по сети. Именно эта идея лежит в основе парадигмы MapReduce и её конкретной реализации в Hadoop.

    Классическая конфигурация кластера Hadoop состоит из одного сервера имён, одного мастера MapReduce (т.н. JobTracker) и набора рабочих машин, на каждой из которых одновременно крутится сервер данных (DataNode) и воркер (TaskTracker). Каждая MapReduce работа состоит из двух фаз:

    1. map — выполняется параллельно и (по возможности) локально над каждым блоком данных. Вместо того, чтобы доставлять терабайты данных к программе, небольшая, определённая пользователем программа копируется на сервера с данными и делает с ними всё, что не требует перемешивания и перемещения данных (shuffle).
    2. reduce — дополняет map агрегирующими операциями


    На самом деле между этими фазами есть ещё фаза combine, которая делает то же самое, что и reduce, но над локальными блоками данных. Например, представим, что у нас есть 5 терабайт логов почтового сервера, которые нужно разобрать и извлечь сообщения об ошибках. Строки независимы друг от друга, поэтому их разбор можно переложить на задачу map. Дальше с помощью combine можно отфильтровать строки с сообщением об ошибке на уровне одного сервера, а затем с помощью reduce сделать то же самое на уровне всех данных. Всё, что можно было распараллелить, мы распараллелили, и кроме того минимизировали передачу данных между серверами. И даже если какая-то задача по какой-то причине упадёт, Hadoop автоматически перезапустит её, подняв с диска промежуточные результаты. Круто!

    Проблема в том, что большинство реальных задач гораздо сложней одной работы MapReduce. В большинстве случаев мы хотим делать параллельные операции, затем последовательные, затем снова параллельные, затем комбинировать несколько источников данных и снова делать параллельные и последовательные операции. Стандартный MapReduce спроектирован так, что все результаты — как конечные, так и промежуточные — записываются на диск. В итоге время считывания и записи на диск, помноженное на количество раз, которые оно делается при решении задачи, зачастую в несколько (да что там в несколько, до 100 раз!) превышает время самих вычислений.

    И здесь появляется Spark. Спроектированный ребятами из университета Berkeley, Spark использует идею локальности данных, однако выносит большинство вычислений в память вместо диска. Ключевым понятием в Spark-е является RDD (resilient distributed dataset) — указатель на ленивую распределённую колекцию данных. Большинство операций над RDD не приводит к каким-либо вычислениям, а только создаёт очередную обёртку, обещая выполнить операции только тогда, когда они понадобятся. Впрочем, это проще показать, чем рассказать. Ниже приведён скрипт на Python (Spark из коробки поддерживает интерфейсы для Scala, Java и Python) для решения задачи про логи:

    sc = ...                                                        # создаём контекст (SparkContext)
    rdd = sc.textFile("/path/to/server_logs")     # создаём указатель на данные
    rdd.map(parse_line) \                                # разбираем строки и переводим их в удобный формат
          .filter(contains_error) \                         # фильтруем записи без ошибок
          .saveAsTextFile("/path/to/result")         # сохраняем результаты на диск
    


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

    Такая модель оказалась настолько эффективной и удобной, что проекты из экосистемы Hadoop начали один за другим переводить свои вычисления на Spark, а над самим движком сейчас работает больше людей, чем над морально устаревшим MapReduce.

    Но не Spark-ом единым. Компания Hortonworks решила сделать упор на альтернативный движок — Tez. Tez представляет задачу в виде направленного ациклического графа (DAG) компонентов-обработчиков. Планировщик запускает вычисление графа и при необходимости динамически переконфигурирует его, оптимизируя под данные. Это очень естественная модель для выполнения сложных запросов к данным, таких как SQL-подобные скрипты в Hive, куда Tez принёс ускорение до 100 раз. Впрочем, кроме Hive этот движок пока мало где используется, поэтому сказать, насколько он пригоден для более простых и распространённых задач, довольно сложно.

    SQL: Hive, Impala, Shark, Spark SQL, Drill



    Несмотря на то, что Hadoop является полноценной платформой для разработки любых приложений, чаще всего он используется в контексте хранения данных и конкретно SQL решений. Собственно, в этом нет ничего удивительного: большие объёмы данных почти всегда означают аналитику, а аналитику гораздо проще делать над табличными данными. К тому же, для SQL баз данных гораздо проще найти и инструменты, и людей, чем для NoSQL решений. В инфраструктуре Hadoop-а есть несколько SQL-ориентированных инструментов:

    Hive — самая первая и до сих пор одна из самых популярных СУБД на этой платформе. В качестве языка запросов использует HiveQL — урезанный диалект SQL, который, тем не менее, позволяет выполнять довольно сложные запросы над данными, хранимыми в HDFS. Здесь надо провести чёткую линию между версиями Hive <= 0.12 и текущей версией 0.13: как я уже говорил, в последней версии Hive переключился с классического MapReduce на новый движок Tez, многократно ускорив его и сделав пригодным для интерактивной аналитики. Т.е. теперь вам не надо ждать 2 минуты, чтобы посчитать количество записей в одной небольшой партиции или 40 минут, чтобы сгруппировать данные по дням за неделю (прощайте длительные перекуры!). Кроме того, как Hortonworks, так и Cloudera предоставляют ODBC-драйвера, позволяя подключить к Hive такие инструменты как Tableau, Micro Strategy и даже (господи, упаси) Microsoft Excel.

    Impala — продукт компании Cloudera и основной конкурент Hive. В отличие от последнего, Impala никогда не использовала классический MapReduce, а изначально исполняла запросы на своём собственном движке (написанном, кстати, на нестандартном для Hadoop-а C++). Кроме того, в последнее время Impala активно использует кеширование часто используемых блоков данных и колоночные форматы хранения, что очень хорошо сказывается на производительности аналитических запросов. Так же, как и для Hive, Cloudera предлагает к своему детищу вполне эффективный ODBC-драйвер.

    Shark. Когда в экосистему Hadoop вошёл Spark с его революционными идеями, естественным желанием было получить SQL-движок на его основе. Это вылилось в проект под названием Shark, созданный энтузиастами. Однако в версии Spark 1.0 команда Spark-а выпустила первую версию своего собственного SQL-движка — Spark SQL; с этого момента Shark считается остановленным.

    Spark SQL — новая ветвь развития SQL на базе Spark. Честно говоря, сравнивать его с предыдущими инструментами не совсем корректно: в Spark SQL нет отдельной консоли и своего хранилища метаданных, SQL-парсер пока довольно слабый, а партиции, судя по всему, вовсе не поддерживаются. По всей видимости, на данный момент его основная цель — уметь читать данные из сложных форматов (таких как Parquet, см. ниже) и выражать логику в виде моделей данных, а не программного кода. И, честно говоря, это не так и мало! Очень часто конвеер обработки состоит из чередующихся SQL-запросов и программного кода; Spark SQL позволяет безболезненно связать эти стадии, не прибегая к чёрной магии.

    Hive on Spark — есть и такое, но, судя по всему, заработает не раньше версии 0.14.

    Drill. Для полноты картины нужно упомянуть и Apache Drill. Этот проект пока находится в инкубаторе ASF и мало распространён, но судя по всему, основной упор в нём будет сделан на полуструктурированные и вложенные данные. В Hive и Impala также можно работать с JSON-строками, однако производительность запроса при этом значительно падает (часто до 10-20 раз). К чему приведёт создание ещё одной СУБД на базе Hadoop, сказать сложно, но давайте подождём и посмотрим.

    Личный опыт
    Если нет каких-то особых требований, то серьёзно воспринимать можно только два продукта из этого списка — Hive и Impala. Оба достаточно быстры (в последних версиях), богаты функционалом и активно развиваются. Hive, однако, требует гораздо больше внимания и ухода: чтобы корректно запустить скрипт, часто нужно установить десяток переменных окружения, JDBC интерфейс в виде HiveServer2 работает откровенно плохо, а бросаемые ошибки мало связаны с настоящей причиной проблемы. Impala также неидеальна, но в целом гораздо приятней и предсказуемей.


    NoSQL: HBase



    Несмотря на популярность SQL решений для аналитики на базе Hadoop, иногда всё-таки приходится бороться с другими проблемами, для которых лучше приспособлены NoSQL базы. Кроме того, и Hive, и Impala лучше работают с большими пачками данных, а чтение и запись отдельных строк почти всегда означает большине накладные расходы (вспомним про размер блока данных в 64Мб).

    И здесь на помощь приходит HBase. HBase — это распределённая версионированная нереляционная СУБД, эффективно поддерживающая случайное чтение и запись. Здесь можно рассказать про то, что таблицы в HBase трёхмерные (строковый ключ, штамп времени и квалифицированное имя колонки), что ключи хранятся отсортированными в лексиграфическом порядке и многое другое, но главное — это то, что HBase позволяет работать с отдельными записями в реальном времени. И это важное дополнение к инфраструктуре Hadoop. Представьте, например, что нужно хранить информацию о пользователях: их профили и журнал всех действий. Журнал действий — это классический пример аналитических данных: действия, т.е. по сути, события, записываются один раз и больше никогда не изменяются. Действия анализируются пачками и с некоторой периодичностью, например, раз в сутки. А вот профили — это совсем другое дело. Профили нужно постоянно обновлять, причём в реальном времени. Поэтому для журнала событий мы используем Hive/Impala, а для профилей — HBase.

    При всём при этом HBase обеспечивает надёжное хранение за счёт базирования на HDFS. Стоп, но разве мы только что не сказали, что операции случайного доступа не эффективны на этой файловой системе из-за большого размера блока данных? Всё верно, и в этом большая хитрость HBase. На самом деле новые записи сначала добавляются в отсортированную структуру в памяти, и только при достижении этой структурой определённого размера сбрасываются на диск. Консистентность при этом поддерживается за счёт write-ahead-log (WAL), который пишется сразу на диск, но, естественно, не требует поддержки отсортированных ключей. Подробнее об этом можно прочитать в блоге компании Cloudera.

    Ах да, запросы к таблицам HBase можно делать напрямую из Hive и Impala.

    Импорт данных: Kafka





    Обычно импорт данных в Hadoop проходит несколько стадий эволюции. Вначале команда решает, что обычных текстовых файлов будет достаточно. Все умеют писать и читать CSV файлы, никаких проблем быть не должно! Затем откуда-то появляются непечатные и нестандартные символы (какой мерзавец их вставил!), проблема экранирования строк и пр., и приходится перейти на бинарные форматы или как минимум переизбыточный JSON. Затем появляется два десятка клиентов (внешних или внутренних), и не всем удобно посылать файлы на HDFS. В этот момент появляется RabbitMQ. Но держится он недолго, потому что все вдруг вспоминают, что кролик старается всё держать в памяти, а данных много, и не всегда есть возможность их быстро забрать.

    И тогда кто-то натыкается на Apache Kafka — распределённую систему обмена сообщениями с высокой пропускной способностью. В отличие от интерфейса HDFS, Kafka предоставляет простой и привычный интерфейс передачи сообщений. В отличие от RabbitMQ, он сразу пишет сообщения на диск и хранит там сконфигурированный период времени (например, две недели), в течение которого можно прийти и забрать данные. Kafka легко масштабируется и теоретически может выдеражать любой объём данных.

    Вся эта прекрасная картина рушится, когда начинаешь пользоваться системой на практике. Первое, что нужно помнить при обращении с Kafka, это то, что все врут. Особенно документация. Особенно официальная. Если авторы пишут «у нас поддерживается X», то зачастую это значит «мы бы хотели, чтобы у нас поддерживалось X» или «в будущих версиях мы планиуем поддержку X». Если написано «сервер гарантирует Y», то скорее всего это значит «сервер гарантирует Y, но только для клиента Z». Бывали случаи, когда в документации было написано одно, в комментарии к функции другое, а в самом коде — третье.

    Kafka меняет основные интерфейсы даже в минорных версиях и уже долгое время не может совершить переход от 0.8.x к 0.9. Сам же исходный код, как структурно, так и на уровне стиля, явно написан под влиянием знаменитого писателя, давшего название этому чудовищу.

    И, несмотря на все эти проблемы, Kafka остаётся единственным проектом, на уровне архитектуры решающим вопрос импорта большого объёма данных. Поэтому, если вы всё-таки решите связаться с этой системой, помните несколько вещей:
    • Kafka не врёт насчёт надёжности — если сообщения долетели до сервера, то они останутся там на указанное время; если данных нет, то проверьте свой код;
    • группы потребителей (consumer groups) не работают: вне зависимости от конфигурации все сообщения из партиции будут отдаваться всем подключённым потребителям;
    • сервер не хранит сдвиги (offsets) для пользователей; сервер вообще, по сути, не умеет идентифицировать подключённых потребителей.


    Простой рецепт, к которому мы постепенно пришли, это запускать по одному потребителю на партицию очереди (topic, в терминологии Kafka) и вручную контролировать сдвиги.

    Потоковая обработка: Spark Streaming



    Если вы дочитали до этого абзаца, то вам, наверное, интересно. А если вам интересно, то вы, наверное, слышали про лямбда-архитектуру, но я на всякий случай повторю. Лямбда-архитектура предполагает дублирование конвеера вычислений для пакетной и потоковй обработки данных. Пакетная обработка запускается периодически за прошедший период (например, за вчера) и использует наиболее полные и точные данные. Потоковая обработка, напротив, производит рассчёты в реальном времени, но не гарантирует точности. Это бывает полезно, например, если вы запустили акцию и хотите отслеживать её эффективность ежечасно. Задержка в день здесь неприемлима, а вот потеря пары процентов событий не критична.

    За потоковую обработку данных в экосистеме Hadoop-а отвечает Spark Streaming. Streaming из коробки умеет забирать данные из Kafka, ZeroMQ, сокета, Twitter и др… Разработчику при этом предоставляется удобный интерфейс в ввиде DStream — по сути, коллекции небольших RDD, собранной из потока за фиксированный промежуток времени (например, за 30 секунд или 5 минут). Все плюшки обычных RDD при этом сохраняются.

    Машинное обучение





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

    Mahout — первая большая библиотека, реализовавшая многие популярные алгоритмы средствами MapReduce. Включает в себя алгоритмы для кластеризации, коллаборативной фильтрации, случайных деревьев, а также несколько примитивов для факторизации матриц. В начале этого года организаторы приняли решение перевести всё на вычислительное ядро Apache Spark, которое гораздо лучше поддерживает итеративные алгоритмы (попробуйте прогнать 30 итераций градиентного спуска через диск при стандартном MapReduce!).

    MLlib. В отличие от Mahout, который пытается перенести свои алгоритмы на новое ядро, MLlib изначально является подпроектом Spark. В составе: базовая статистика, линейная и логистическая регрессия, SVM, k-means, SVD и PCA, а также такие примитивы оптимизации как SGD и L-BFGS. Scala интерфейс использует для линейной алгебры Breeze, Python интерфейс — NumPy. Проект активно развивается и с каждым релизом значительно прибавляет в функционале.

    Форматы данных: Parquet, ORC, Thrift, Avro



    Если вы решите использовать Hadoop по полной, то не помешает ознакомиться и с основными форматами хранения и передачи данных.

    Parquet — колончатый формат, оптимизированный для хранения сложных структур и эффективного сжатия. Изначально был разработан в Twitter, а сейчас является одним из основных форматов в инфраструктуре Hadoop (в частности, его активно поддерживают Spark и Impala).

    ORC — новый оптимизированный формат хранения данных для Hive. Здесь мы снова видим противостояние Cloudera c Impala и Parquet и Hortonworks с Hive и ORC. Интересней всего читать сравнение производительности решений: в блоге Cloudera всегда побеждает Impala, причём со значительным перевесом, а в блоге Hortonworks, как несложно догадаться, побеждает Hive, причём с не меньшим перевесом.

    Thrift — эффективный, но не очень удобный бинарный формат передачи данных. Работа с этим форматом предполагает определение схемы данных и генерацию соответсвующего кода клинета на нужном языке, что не всегда возможно. В последнее время от него стали отказываться, но многие сервисы всё ещё используют его.

    Avro — в основном позиционируется как замена Thrift: он не требует генерации кода, может передавать схему вместе с данными или вообще работать с динамически типизированными объектами.

    Прочее: ZooKeeper, Hue, Flume, Sqoop, Oozie, Azkaban



    Ну и напоследок коротко о других полезных и бесполезных проектах.

    ZooKeeper — главный инструмент координации для всех элементов инфраструктуры Hadoop. Чаще всего используется как сервис конфигурации, хотя его возможности гораздо шире. Простой, удобный, надёжный.

    Hue — веб-интерфейс к сервисам Hadoop, часть Cloudera Manager. Работает плохо, с ошибками и по настроению. Пригоден для показа нетехническим специалистам, но для серьёзной работы лучше использовать консольные аналоги.

    Flume — сервис для организации потоков данных. Например, можно настроить его для получения сообщений из syslog, агрегации и автоматического сбрасывания в директорию на HDFS. К сожалению, требует очень много ручной конфигурации потоков и постоянного расширения собственными Java классами.

    Sqoop — утилита для быстрого копирования данных между Hadoop и RDBMS. Быстрого в теории. На практике Sqoop 1 оказался, по сути, однопоточным и медленным, а Sqoop 2 на момент последнего теста просто не заработал.

    Oozie — планировщик потоков задач. Изначально спроектирован для объединения отдельных MapReduce работ в единый конвеер и запуска их по расписанию. Дополнительно может выполнять Hive, Java и консольные действия, но в контексте Spark, Impala и др., этот список выглядит довольно бесполезным. Очень хрупкий, запутанный и практически не поддаётся отладке.

    Azkaban — вполне годная замена Oozie. Является частью Hadoop-инфраструктуры компании LinkedIn. Поддерживает несколько типов действий, главное из которых — консольная команда (а что ещё надо), запуск по расписанию, логи приложений, оповещения об упавших работах и др. Из минусов — некоторая сыроватость и не всегда понятный интерфейс (попробуйте догадаться, что работу нужно не создавать через UI, а заливать в виде zip-архива с текстовыми файлами).

    На этом всё. Всем спасибо, все свободны.
    Поделиться публикацией

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

    Комментарии 26
      +4
      Отличная статья, спасибо! Можно еще добавить, что у Cloudera, Hortonworks и IBM есть готовые образы виртуальных машин с установленной в них инфраструктурой Hadoop, на которой можно все посмотреть, поиграться и пройти туториалы (что сильно снижает порог вхождения)

      Еще есть много онлайн курсов на сайте bigdatauniversity.com/
        +1
        Хрюшка (Apache Pig) предана забвению?
          0
          Ах, а ведь крутилась же в голове!
          Но, честно говоря, я ни разу не слышал, чтобы её использовали на практике. Возможно, вы можете поделиться success story?
            0
            Мы активно использовали Pig для обработки 10М+ данных (из нескольких коллекций, которые нужно было объединять). Справлялся он на ура, хоть и слегка сложен в освоении за счет собственного синтаксиса запросов.
              +1
              А можно узнать, когда почему Pig, а не тот же Hive, например? Какие именно свойства «хрюши» стали решающими?
                +1
                Честно говоря, я на тот момент занимался веб разработкой, и на пиге писал всего-лишь пару скриптов, этим занимался другой отдел. По этому всех тонкостей я не знаю. Но насколько я помню, Hive с необходимыми коллекциями и объемами данных работал значительно медленней, чем Pig.
                  0
                  Насчет последнего согласен — производительность PIG-скриптов зачастую более предсказуема, чем на Hive. Заранее знаешь, сколько примерно будут выполняться какие конструкции. Плюс благодаря более низкоуровневому подходу можно более гибко управлять обработкой данных.

                  У нас был такой случай — один клиент дал нам доступ к логам своей системы, мы на своей стороне реализовали обработку на PIG. Скрипт работал что-то около часа на 4 машинах.

                  Когда клиент узнал, сколько занимает у нас обработка его данных, у него отпала челюсть. Оказалось, что они сами обрабатывали логи своего сервера с помощью Hive. Обычный дневной процессинг у них занимал что-то около 6 часов на кластере из десятка машин. Подозреваю, что их программисты получили втык за перерасход вычислительных ресурсов :-)

                  Позже они показывали нам свои Hive-запросы. Оптимизировать там мне ничего не удалось — по сути, и оптимизировать-то было нечего, пара фильтров, группировки, сортировки, снова группировки. Честно говоря, я так и не понял, что же они делали не так, но факт остается фактом — тормозило оно безбожно.
                  0
                  Например, потому, что именно она используется в лабах на самом популярном курсе Coursera про Big Data. Ну и затем люди переносят её на реальные проекты
                0
                Рановато скидываете его со счетов! Удобнейшая вещь.

                Мы используем PIG для парсинга логов сторонних систем, с которыми мы интегрированы. Объем логов — от 10М до 500М записей в день.

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

                pig незаменим, когда нужно много работать с текстом. Например, из URL выдернуть все параметры, отфильтровать их, по каждому параметру собрать статистику по встречаемости значений по отдельности, плюс посчитать ковариации разных значений для пар параметров. С трудом представляю, как это сделать в SQL, а на свинье пишется в пару строк.

                Свой «птичий язык» свинтуса сначала не внушает доверия, но со временем привыкаешь. ИМХО сложные скрипты на нем выглядят более читабельно, чем на SQL засчет того, что вместо двух сложнейших запросов на PIG как правило пишут 10 коротких и простых выражений.

                Увы, для аналитики pig latin мало пригоден по причине наличия этого своего нестандартного языка (аналитикам его учить сложно, императивные языки для них в новинку, а SQL привычен), своей низкой интерактивности и некоторой задумчивости. Даже на наборах данных в пару тысяч строк и простых скриптах (фильтр-группировка-фильтр-сортировка) может генерироваться по несколько MR-задач.
                  0
                  Это имеет смысл, спасибо!
                  Тогда вопрос в другую степь: а вы не сравнивали его с тем же Spark-ом, например? Лично я в своё время остался очень доволен обработкой как раз текстовых логов с помощью PySpark, и тогда я уж точно не мог подумать, что Pig для этого тоже годится.
                    0
                    Насколько понимаю, основное преимущество Spark — выполнение запросов прямо в памяти. Но это похоже на наш случай: наборы данных у нас бывают довольно большие, 2-10 терабайт, а обработка логов производится раз в день, т.ч. время отклика критичным не является, а по общей длительности обработки PIG вполне устраивает — поэтому замены ему не ищем.

                    Готовая статистика имеет небольшой объем, и заливается либо в SQL-базу, либо в Hive (в зависимости от объема и потребности в интерактивной аналитике). И вот тут мы посматриваем в сторону Impala и Spark SQL как интерактивной замены/дополнения Hive.

                    С Impala был прототип, но она оказалась менее функциональна, чем Hive. Например, та версия, что мы пробовали, при сохранении результатов запроса в файл не умела их сжимать. Получение больших кусков данных через JDBC в Impala (да и в Hive) довольно медленное, порой прочитать результат занимает дольше, чем сам запрос, поэтому вместо ResultSet-а мы сохраняли результат запроса в CSV, и загружали через HDFS готовый файл. В результате с Hive получался выигрыш в 5-10 раз, что довольно критично. А из-за отсутствия сжатия в Impala преимущество было куда как скромнее. Есть конечно workaround-ы, но как-то Impal-ой мы не прониклись.
                      0
                      Я бы сказал, что Spark — это как раз такой «низкоуровневый» фреймворк, который даёт большой уровень контроля над распределённым набором данных, поэтому в голову и пришло сравнение с Pig.

                      Что касается Impala, а не помните, какая это была версия? Сейчас Impala по умолчанию использует Parquet + сжатие Snappy — в итоге в среднем получается в 7-10 раз меньше, чем CSV, так что по идее должно было бы получиться не хуже, чем с Hive.
              +3
              Статья хорошая, хотелось бы еще статей с примерами использования технологий.
                0
                На самом деле Oozie как служба весьма надежен и он единственный из подобных имеет годный UI.
                Вот написать стабильный workflow под него — действительно непросто. И функционально слабоват — костылить приходится.
                  0
                  Вот написать стабильный workflow под него — действительно непросто

                  Примерно это я и имел ввиду :) Oozie имеет очень много зависимостей, и не всегда «правильных». Например, если заглянуть внутрь Hive action, оказывается, что запросы вызываются через консольный клиент под своим пользователем и в своём окружении. Добавьте к этому кучу генерируемых временных файлов (извлечь которые, естественно, довольно сложно) и невнятные логи, и отладка превращается в сплошное «удовольствие».
                  Насчёт UI, мне не понравилось, что вокрфловы и координаторы, созданные через API, не отображаются в веб-интерфейсе. Т.е. список запущенных и отработавших работ есть, но открыть и, например, отредактировать конкретный воркфлоу уже нельзя.
                    0
                    Это вы про Hue сейчас?
                      0
                      Да. Родной интерфейс Oozie, насколько я помню, read-only, а через HDP и пр. я с ним не работал.
                        0
                        Ну это да, известная штука. Обычно не возникает проблем, те кто работают через апи — всегда работают через апи. А те кто через Хью — те не умеют пользовать апи.
                  –2
                  Складывается ощущение, что автор нахватался чего-то по верхам и сделал поверхностный обзор на основе своего небольшого опыта.
                  Про flume, sqoop, oozie написан бред.
                  Основные преимущества TEZ, которые можно использовать прямо сейчас, это checkpointing и MRR jobs, когда reduce-фаза пишет локально, а не в HDFS, экономя кучу времени. Можно изменять алгоритм сортировки. Судя по диз. доку, TEZ всего лишь устраняет ограничения MR фреймфорка, в которые уперлись разработчики спустя годы после первого релиза. Все таки в 2007 году сложно было представить, что захотят юзеры в 2012

                  Хорошая оценочка пигу.
                  Но, честно говоря, я ни разу не слышал, чтобы её использовали на практике.

                  Чуваки типа по фану срелизили 0.13.0 версию, другие чуваки от безделия добавили pig-action в oozie, а третьи лежебоки добавили интерактивную веб-консоль в hue.
                  На каких фактах вы строите свои предположения и делаете выводы?
                    +2
                    На каких фактах вы строите свои предположения и делаете выводы?

                    Выводы о чём? О том, что я никогда не слышал, как Pig используют на практике? Нуу, на том, что я об этом никогда не слышал. Никаких выводов относительно того, нужен ли он, полезен ли он и если да, то в каких ситуациях, я как бы и не делал. Наоборот, мне интересна его роль в экосистеме Hadoop и преимущества перед Hive, Impala, R байндингами, Python/Pandas/Spark/Impyla и т.д. Если у вас есть примеры его использования, так поделитесь.

                    Складывается ощущение, что автор нахватался чего-то по верхам и сделал поверхностный обзор на основе своего небольшого опыта.
                    Про flume, sqoop, oozie написан бред.

                    Давайте конкретней. Я всегда готов обсудить, как Oozie прекрасно подхватывает oozie.libpath, и почему «sharelib» не имеет никакого отношения к общим пользовательским библиотекам. Или как в нём передать нестроковые параметры между экшенами без использования HDFS. Или как настроить HDFS sink во Flume, чтобы он распределял файлы по директориям на основе кастомного атрибута данных. Ну и если у вас есть удачный опыт использования Sqoop, опишите, не стесняйтесь. У нас с ним не сложилось, о чём в статье вполне чётко написано.
                    Ну и да, естетсвенно, обзор поверхностный. Про любую из этих технологий можно написать отдельную статью, и не одну. Только это уже не будет обзором, и цели у такого подробного описания будут совсем другие. А так, конечно, я готов побеседовать про любой из вышеперечисленных инструментов, причём как рассказать, так и послушать.

                    –2
                    Отличительной чертой Cloudera также является стремление первыми предоставлять на рынке новые фичи

                    Вранье. HDP пушит самый свежаок, клоудера крайне консервативна. Я >2 лет сижу на клоудере. Единственное, что сделала нового клоудера, так это втащила спарк, который ставится при помощи человеко-машинного комплекса. Позже, эта проблема была устранена.

                    Hive — самая первая и до сих пор одна из самых популярных СУБД на этой платформе. В качестве языка запросов использует HiveQL — урезанный диалект SQL,

                    Бред, это не СУБД. Это транслятор SQL в каскад MR job. Про диалект так же спорно, он не ANSI compliant, это да. По сути, это клиентская тула. Просто посмотрите код, как он устроен. Где-то год назад в джире читал, что девелоперы озаботились о том, чтобы распилить хайв на модули. Потому что вместе с артефактом-jdbc хайва, вы еще получаете метастор и кучу всего, не относящегося к «дровам». Почитайте Programming hive, он по версии 0.8, но даст вам понять, почему это не СУБД.

                    HBase — это распределённая версионированная нереляционная СУБД
                    это не бд, это hashmap of hashmaps с рядом интересных свойств. Почитайте HBase definitive guide. Даже это вам даст понимание того, насколько hbase далек от СУБД.

                    Oozie
                    одно из самых вменяемых решений. Для отладки есть dryrun и e2e тесты. Для hive/impala и т.д. есть java action. Что у вас там за проблемы с либами, я вообще не понял. Что за пользовательские библиотеки? Делайте бандл и все что нужно коориднатору, воркфле кладите в lib каталог «приложения». Ози сам зацепит ресурсы в classpath. Не превращайте окружение в помойку джарников, и все будет хорошо.

                    Hue — Работает плохо, с ошибками и по настроению.

                    По настроению, ок, исчерпывающее описание.

                    Sqoop — на практике Sqoop 1 оказался, по сути, однопоточным и медленным

                    Бред, до 3-5 млн строк в минуту без каких-либо ухищрений/костылей, терадат и экзадат. Обычное загруженное хранилище оралка.

                    JDBC интерфейс в виде HiveServer2 работает откровенно плохо, а бросаемые ошибки мало связаны с настоящей причиной проблемы.
                    cool story. Откровенно плохо, это как, как это проявляется? Бросаемые ошибки связаны со спецификой инструмента. попробуйте beeswax интерфейс, тогда поймете, что значит плохо — DoS зукиперов и т.д.
                      0
                      Бред, это не СУБД. Это транслятор SQL в каскад MR job


                      We built NoSQL so you don't need to learn SQL, then we added SQL so you can use NoSQL. © не помню кто.
                      Скажете неправда? :-)

                      И цитата из классика twitter.com/DEVOPS_BORAT

                      Attention devops: «learn NoSQL» is not same as «learn no SQL»!

                      Is no such thing as Big Data. Is only data you not sampled sufficient yet so it fit in RAM and it process with SQLite.


                      И вот в последней много мудрости. То что не интерактивно (не в RAM) не подходит для интенсивного анализа. А то, что должно быть обработано все и по отдельности — не требует интенсивного анализа и обычно по природе своей параллельно.
                      +3
                      Вранье. HDP пушит самый свежаок, клоудера крайне консервативна. Я >2 лет сижу на клоудере. Единственное, что сделала нового клоудера, так это втащила спарк, который ставится при помощи человеко-машинного комплекса. Позже, эта проблема была устранена.

                      За 2 последних года весь Hadoop сильно изменился, и Cloudera сейчас поддерживает эти изменения. Поэтому говорить, что Клаудера ничего нового не втянула, мягко говоря, не корректно. Дальше вспоминаем Impala: когда там Hortonworks разогнал Hive до реал тайма? Impala к этому времени уже отлично отвечала на быстрые интерактивные запросы. Spark дошёл до версии 1.0 что-то около полугода назад, но Cloudera уже пытается перевести Hive на него, Hortonworks, судя по всему, даже не собирается в это соваться. Примеров много. Конечно, у вас могут другие примеры, где Hortonworks окажется новатором, но это уже называется «обмен мнениями», хотя вы почему-то назвали это «враньём».

                      Бред, это не СУБД. Это транслятор SQL в каскад MR job.

                      Да ладно, а метаданные Hive не хранит? А форматами данных не управляет? А пользовательский и программный интерфейс не предоставляет? А если так, то чем он не СУБД?
                      Вообще, если посмотреть определения понятий «база данных» и «СУБД» в словарях (ну или той же Википедии), то вдруг оказывается, что БД и СУБД — это очень общие понятия. Что, например, Lucene-овский индекс — это вполне себе база данных, а сам Lucene — СУБД. Что property файл на диске — это база данных, а программа, которая его формирует и парсит — это СУБД. Hive на этом фоне — гораздо более классическая СУБД, и уж точно не просто транслятор из SQL в MR.

                      это не бд, это hashmap of hashmaps с рядом интересных свойств. Почитайте HBase definitive guide. Даже это вам даст понимание того, насколько hbase далек от СУБД.

                      Аналогично.

                      Бред, до 3-5 млн строк в минуту без каких-либо ухищрений/костылей, терадат и экзадат. Обычное загруженное хранилище оралка.

                      3-5 миллионов в минуту — это как раз и есть один поток, верно? Смысл был в том, чтобы всасывать данные в параллели, как это делает, например, Vertica с их адаптером (или по крайней мере они это обещают). В любом случае, здорово, что у вас получилось, у нас опыт получился совсем иным.

                      По настроению, ок, исчерпывающее описание.

                      Нет, стоп. Вы определитесь, вы хотите сказать, что автор мудак, или что в статье мало деталей? Если первое, то так и говорите: автор врёт, Hue — хорошая программа, никогда не даёт сбоев и проверенно работает в любых условиях. Если второе, то да, очевидно, что многие детали опущены, и о них автора можно спросить отдельно.

                      На всех 4-х кластерах, которые у меня сейчас под рукой:

                      1. Hue работает медленно. Сам интерфейс, будучи довольно простым, заставляет ждать.
                      2. Hue падает с эксепшенами на простейших действиях. Можно просто перейти по совершенно законной, активной и незаэкспайреной ссылке и увидеть страницу со стектрейсом. А через минуту перезагрузить страницу и увидеть нормальный результат.
                      3. Логи ошибок практически бесполезны. Либо стектрейс ведёт вглубь самого Hue, либо отображается только общая ошибка вроде «server error», и никаких намёков, чем она вызвана.

                      cool story. Откровенно плохо, это как, как это проявляется?

                      Откровенно плохо — это когда сервер падает с OOM из-за утечки памяти. Возможно, утечка справоцирована внешними факторами (например, как-то мы отловили незакрытые соедниения), но если серверная программа не имеет защиты от таких банальных проблем, то я её считаю нестабильной. Именно «я считаю» — это моё мнение, и мой личный опыт, поэтому вся эта «cool story» и вынесена в спойлер с соответсвующей пометкой.

                      В общем, давайте так. Если видите техническую ошибку — говорите, исправлю. Если у вас другая точка зрения — тоже говорите, обсудим: область узкая, и услышать мнение другого человека всегда интересно. Но просто сказать «автор мудак, это же очевидно!» — не прокатит.

                        –1
                        я люблю тебя шериф трумен
                        www.youtube.com/watch?v=l9ivnxx_EoE

                        have a nice weekend :)
                          0
                          Плюс ставить поздно посту, напишу просто спасибо.
                            0

                            Пожалуйста!

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

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