Пользователь
0,0
рейтинг
19 сентября 2013 в 21:15

Разработка → Вам не нужен Hadoop — у вас просто нет столько данных перевод

Меня спросили: «Сколько у вас опыта с большими данными и Hadoop?» Я ответил, что часто использую Hadoop, но редко — с объёмами данных больше нескольких ТБ. Я новичок в больших данных — понимаю идеи, писал код, но не в серьёзных масштабах.

Следующий вопрос был: «Можете ли вы сделать простую группировку и сумму в Hadoop?» Разумеется, могу, и я попросил пример формата данных.

Они вручили мне флэш-диск со всеми 600 МБ данных (да, это были именно все данные, а не выборка). Не понимаю, почему, но им не понравилось моё решение, в котором был pandas.read_csv и не было Hadoop.

Hadoop ограничивает вас. Hadoop позволяет выполнять только один тип вычислений, который в псевдокоде выглядит так:

Scala: collection.flatMap( (k,v) => F(k,v) ).groupBy( _._1 ).map( _.reduce( (k,v) => G(k,v) ) )

SQL: SELECT G(...) FROM table GROUP BY F(...)

Несколько лет назад я уже объяснял это так:
Цель: подсчитать количество книг в библиотеке.

Map: Ты посчитай нечётные полки, а я посчитаю чётные (чем больше у нас людей, тем быстрее выполним эту часть).

Reduce: Мы соберёмся и сложим количества, полученные каждым из нас.

Единственное, что вы можете поменять в этом вычислении — F(k,v) и G(k,v). Ну ещё оптимизировать производительность (и это не самый приятный процесс) промежуточных вычислений. Всё остальное строго зафиксировано.

Hadoop требует оформлять все вычисления через преобразование, группировку и аггрегирование. Ещё допускаются последовательности таких вычислений. Многие вычисления в это прокрустово ложе не укладываются. Единственная причина им пользоваться — то, что он позволяет масштабировать вычисления на огромные объёмы данных. Скорее всего, ваши данные на несколько порядков меньше. Но из-за того, что Hadoop и big data — модные слова, полмира упорно пытается влезть на эту кровать без всякой нужды.

Но у меня сотни мегабайт данных! В Excel их не загрузить!


Слишком много для Excel это ещё не большие данные. Есть много отличных инструментов для них. Мой любимый — Pandas, сделанный на основе NumPy. Вы можете загрузить сотни мегабайт в память в удобном для быстрой обработки формате. На моём трёхлетнем ноутбуке NumPy перемножает 100 000 000 чисел с плавающей точкой в мгновение ока. Matlab и R тоже хороши для таких целей.

Кроме того, сотни мегабайт часто поддаются простому скрипту на Python, который читает файл построчно, обрабатывает результаты и записывает их в другой файл.

А у меня 10 ГБ!


Я только что купил новый ноутбук. 16 Гб оперативной памяти в нём стоили мне $141,98, а SSD на 256 Гб — ещё $200 (предустановлен Lenovo). Кроме того, если загрузить 10-гигабайтный CSV в Pandas, он часто займёт в памяти существенно меньше, благодаря тому, что численные строки вроде «17284932583», загружаются как целые в 4 или 8 байтах, а «284572452.2435723» — как числа с плавающей точкой. Ну в худшем случае не получится загрузить всё в память одновременно.

А у меня 100 ГБ/500 ГБ/1 ТБ!


Жёсткий диск на 2 ТБ стоит $94.99, на 4 — $169.99. Купите себе такой и поставьте на него Postgres.

Hadoop << SQL и Python


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

SQL — простой язык запросов с минимальной утечкой абстракций, который широко используется как программистами, так и бизнес-аналитиками. Запросы в SQL обычно довольно просты. Кроме того, они обычно очень быстро выполняются — если ваша база правильно проиндексирована, запросы редко должны занимать больше секунды.

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

Если ваши данные не структурированы как таблица SQL (например: обычный текст, JSON, двоичные файлы), то обычно достаточно просто написать небольшой скрипт на Python или Ruby, чтобы обработать данные построчно. В тех случаях, когда SQL плохо подходит для задачи, Hadoop будет раздражать меньше с точки зрения программирования, но не имеет никаких преимуществ перед простыми скриптами.

Кроме того, что его сложнее программировать, Hadoop практически всегда ещё и медленнее, чем простые альтернативы. SQL запросы могут выполняться очень быстро за счет рационального использования индексов — для вычисления join, PostgreSQL достаточно просто посмотреть индекс (если он есть, конечно) и посмотреть необходимое значение ключа. Hadoop требует полного сканирования таблицы, с последующей полной сортировкой. Сортировку можно ускорить за счёт разбиения данных на несколько машин, но с другой стороны, вам придётся рассылать данные по ним. В случае обработки двоичных данных, Hadoop потребует многократных обращений к NameNode точно так же, как скрипт на Python потребует многократных обращений к файловой системе.

А у меня данных больше 5 ТБ !


Ну могу только посочувствовать — вот вам без Hadoop не обойтись. Других разумных вариантов мало (хотя может хватить больших серверов со множеством жёстких дисков), и большинство из них стоят значительно дороже.Вам не нужно много других вариантов ( больших серверах с большим количеством жестких дисков все еще может быть в игре), и большинство из ваших другие варианты значительно дороже.

Единственное преимущество Hadoop — в масштабировании. Если у вас есть одна таблица, содержащая многие терабайты данных, Hadoop может быть хорошим вариантом. Если у вас нет такой таблицы, избегайте Hadoop как чумы. Он того не стоит, и вы получите результаты с меньшими усилиями и за меньшее время, придерживаясь традиционных методов.
PS. Реклама

У меня есть стартап, цель которого — предоставление анализа данных (как больших, так и маленьких), рекомендации в реальном времени и оптимизации для издателей и сайтов электронной коммерции. Если хотите стать бета-пользователем, пишите на stucchio@gmail.com.

Кроме того, я консультант. Если вашей компании нужна Стратегия Для Работы С Большими Данными В Облаке, могу помочь. Но предупреждаю сразу — вполне возможно, что я покажу вам Pandas и предложу сравнить, вместо того, чтобы сразу впаривать Hadoop.
PPS. Hadoop — отличный инструмент

Я не имею ничего против Hadoop. Я регулярно использую его для задач, которые было бы сложно сделать без него. (Совет: я предпочитаю Scalding вместо Hive и Pig. Он позволяет использовать Scala (хороший язык программирования) и легко писать сцепленные задачи, не скрывая лежащего в основе MapReduce.) Hadoop — отличный инструмент, который идёт на известные компромиссы и ориентирован на конкретные сценарии использования. Я просто надеюсь убедить вас серьёзно подумать, прежде чем выбирать на автомате Hadoop в Облаке для обработки 500 МБ Больших Данных.
Перевод: Chris Stucchio
Алексей Романов @alexeyrom
карма
128,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (50)

  • +9
    Давно ждал эту статью. Особенно после спора на форуме что 10-ки ГБ в день это много данных и как раз для хадупа =).
    • –4
      На форуме спор закончился, решили продолжить здесь? :)
    • +7
      А по-моему, без понимания того, что размер данных имеет пренебрежительно малое значение по сравнению с их структурой и паттернами запросов, вообще стоит прекратить спорить про data warehousing. Хоть на форумах, хоть здесь
      • +5
        Абсолютно с Вами согласен.
        И еще один момент: нельзя все измерять в байтах-гигабайтах; когда мы говорим о BigData, то это еще и большое количество «записей», и 1ТБ данных из 1млн «записей» будет работать в разы быстрее, нежели этот же 1ТБ из 1 млрд «записей».
        • 0
          Как объяснил камрад ffriend в своей статье, преимущество MapReduce — в минимизации передвижения данных между узлами и локальности вычислений. Так какая разница сколько записей?
          • 0
            Передвижение данных тут не при чем. Чтобы с данными что-то сделать, провести какую-то обработку, треубется доступ к этим данным, и доступ к 1млрд записей общим объемом 1ТБ будет занимать больше времени, нежели 1млн того же объема.

            Для наглядности могу привести такой
            пример абстрактной задачки со смешными цифрами
            Есть 10 серверов, общий объем полезных данных ~74ГБ и 10млрд записей равномерно распределенные по этим серверам.
            В каждой записи есть 64-битный Integer(т.е. запись занимает 8 байт).
            Вам нужно высчитать среднее по всем записям. Каждый юнит в таком случае высчитывает среднее из 1млрд записей, после чего сливаются воедино 10 записей и из них высчитывается среднее.

            Теперь возьмем эту же задачу, только данных будет не 10млрд, а 80млрд, и будет не Int64, а Byte(т.е. занимает, не 8 байт, а 1). Теперь при том же общем объеме данных каждый юнит должен высчитать среднее не из 1млрд записей, а из 8млрд записей.


            Скажите, пожалуйста, теперь мне удалось объяснить разницу?
            • 0
              Я думаю, я понял вашу идею, но пример не очень удачный. Вы предполагаете, что полное время на обработку одного int8 будет равно полному времени на обработку int64, что может быть совсем не так. На самом деле, я бы поставил на то, что на таких простых задачах как вычисление среднего большая часть времени будет уходить на считывание данных с диска в память, и эта величина для int8 и int64 будет одинаковой и зависеть от размера буффера.

              Можно даже придумать контрпример. Например, возьмём стандартный WordCount. У нас есть миллион строк, в каждой в среднем по 10 слов. Если мы объеденим каждые 8 строк в одну, то получим всего 125 тысяч строк… но ведь и слов в каждой из них будет уже не по 10, а по 80! Т.е. суммарная работа всё равно останется той же, как бы вы не делили или не объединяли строки.

              А в некоторых случаях множество небольших записей может быть даже выгодней. Например, если вам нужно построить лексическое дерево текста, при этом время работы зависит от количества слов как O(n^2), то чем больше слов в одной записи, тем дольше будет выполняться вся работа.
              • 0
                Я описывал пример мап-редьюса в принципе.
                Ваш пример не описывает что это за строки и как к ним получается доступ, потому что основной посыл в моем предыдущем комментарии про доступ к данным, а не только про их обработку.

                А последнее про то, что иногда для конкретных задач маленькие записи выгоднее, ну естественно, кто же спорит? Но…
                то чем больше слов в одной записи, тем дольше будет выполняться вся работа.

                То, что Вы описали похоже только на оптимизацию работы одной ноды, а где же сам map-reduce? Чем меньше работы у одной ноды, тем больше будет у мастера и наоборот (это только в вашем случае, для моего примера это не играет роли).
                • +1
                  Значит, примера я не понял, причём совсем. Так что давайте начнём сначала: на каком этапе MR задания небольшое количество int64 будет обрабатываться быстрее, чем большое количество int8?
            • 0
              Да, я понимаю, что при большем количестве записей, время расчетов будет больше. Но время будет пропорционально больше каким бы инструментом вы не пользовались — MapReduce на 10 компах или все на одном компе c подсчетом скриптом. Отчего в контексте статьи (выбора технологии) я не понимаю почему нужно отдать препочтение одной технологии над другой в зависимости от количества записей.
      • 0
        Было бы не плохо, если бы Вы подкрепили свое высказывание реальным примером. Ну например, вот кусок данных и с ними надо сделать то-то.
        • +1
          Вот кусок данных, представьте что у вас всего лишь миллион записей:

          Field_А, Field_B, Field_X
          1111111, 2222222, 333333

          333333, 2222222, 444444

          Надо сделать JOIN Field_A = Field_X
          • 0
            Задача очень расплывчата, но это и не важно — Вычитали множество логов, распарсили. Создали мапу, как ключ положили Field_A, значение — лог. Проитерировались по коллекции логов, проверили вхождение в мапе Field_X — если нашли, положили в аутпут.

            Если миллион записей — ~500мб на диске, в памяти это займет ~1ГБ. Алгоритму нужно вдвое больше. Вам надо 2 ГБ оперативы. Простой джарник запроцесит такой объем за несколько десятков секунд, а то и меньше в зависимости от железа. В то время как на поднятие хадуп нод уйдет от 5 мин.
            • 0
              70 секунд у меня уходит на инициализацию джобы и 86 секунд на обработку 4 миллионов записей
              • 0
                Ну так вопрос вдругом — зачем тут хадуп?
                • 0
                  А что мешает? Если задача, хорошо ложиться на хадуп, дак почему бы им не воспользоваться? Если он у вас есть, то накидать джобу на питоне — это 10 минут работы. Смотрите на него как на эксель. Кроме того мы стираем грани, что 4 что 44 миллиона записей обрабатываются просто. Естественно, можно самому написать совой велосипед, можно даже его распаралелить, это тоже интересно. Но какие преимущества от этого?

                  Совсем другой вопрос, если парадигда m/r не подходит к задаче, а её начинают усилинно на неё натягивать…
    • +1
      Данные бывают разные. Иногда обработка какого-то маленького кусочка может занимать минуты. И в случае даже одного гигабайта такого типа данных обработка на одном хосте не целесообразна. Из практики: на 100 достаточно мощных машинках подобного рода задача занимала около 1 часа.

      Так что, если данные тривиальны для процессинга и 100терабайт для хадупа может быть мало. Все зависит от того, что и как вы делаете.
      • 0
        Хорошо, можете привести пример этого маленького кусочка и задачу по обработке, которая ставилась?
        • +1
          Например задача пропустить миллион Regexp против какого-то набора данных и собрать все хиты. Время прогона такого количества регулярных выражений против 5-10 килобайт данных занимает несколько секунд. Таких кусочков данных может быть по несколько миллионов, что в сумме дает несколько сотен гигабайт. Мелоч, даже пол терабайта нет. Но долго очень.
          • 0
            Хороший пример, тут даже нечего возразить. Лишь вопрос по «миллион Regexp» — рилли? Что за задача, если не секрет?
            • 0
              К сожалению я не могу рассказать о чем речь.
              Но можно сказать, что таким образом можно классифицировать данные.
              Если правильно проставить score для каждого регулярного выражения, то сумма все очков и классов регулярных выражений может определить в какую категорию попадает тот или иной кусок данных, причем с ОЧЕНЬ высоким качество близким к 99.99999% — это куда лучше чем человек может сделать в ручную. Кстати, проблема проставления скоров для всех этих рег. выражений та еще задачка, при задействовании достаточно мощных вычислительных ресурсов это занимает более 2-х суток чтобы добиться вот этого 99.99999%.

              зы. Миллион это цифра с потолка, на самом деле их гораздо больше. Большая часть из них генерируется автоматически.
              • 0
                Очень похоже на задачу, которую может решить lucene/solr, нет?
                • 0
                  К сожалению не может. Совсем не может.
              • 0
                судя по описанию, очень похоже на фильтрацию запросов в Web Application Firewall (WAF)
  • +26
    Большие Данные это когда они не помещаются на 1 машину. Все.
    • +4
      Вы чуть ошибаетесь, ИМХО. Большие данные — когда приходится их горизонтально масштабировать.
      • +7
        Утолите, пожалуйста, мой интерес: в чем ошибается olku и как горизонтально масштабировать на одной машине?
        • +1
          Ошибается лишь чуть. Всё же на одной машине не учтены параметры этой машины и возможности улучшения производительности.
          • +11
            Возможности улучшения производительности в разрезе «этой» машины — это вертикальное масштабирование.
            • +1
              Я именно это и имел в виду. Вряд ли требуется сильно менять алгоритмы работы при вертикальном масштабировании.
        • 0
          Горизонтальное масштабирование на одной машине может использоваться в случае, если исходная обработка не может утилизировать хотя бы один из ресурсов машины (например, упирается в CPU и при этом является однопоточной при наличии свободных ядер).

          В узком смысле big data можно воспринимать как «уперлись в диск», как необходимость горизонтального масштабирования по дисковому пространству. В широком можно притащить за уши «упор» в любой ресурс (будь то disk, iops, cpu, mem), тогда, например, grid computing станет big data…

          Опять же, в случае исчерпания какого-либо ресурса есть джва пути масштабирования: вертикально или горизонтально. И этот выбор, как правило, определяется тем, что за данные. Если это неизменяемые данные, то может хватить увеличения ресурсов в рамках одной машины без «вступания» в big data. Если же это, например, пополняемые данные, которые будут расти и расти — «вступать» придется.

          • 0
            Я понял Вашу мысль.
            Но, если есть еще в запасе неиспользуемые ядра, которые можно использовать(вы не описали в примере обратное), то почему их не использовать и почему они не были использованы сразу? Сомневаюсь, что это можно отнести к горизонтальному масштабированию, это просто подгонка под свободные ресурсы в разрезе одного сервера. Иначе, исходя из Вашего комментария можно отнести к горизонтальному масштабированию увеличение количества воркеров какого-нибудь гирмана для одной очереди.

            И тем не менее это ведь не исключает высказывание olku
            • +2
              По сути, распараллеливание задачи по потокам/процессам — это собственно горизонтальное масштабирование. Происходит это в рамках одной машины или сети — не суть важно.

              Я скорее не согласен со StamPit. Далеко не любая задача, требующая горизонтального масштабирования является big data.

              К варианту от olku я бы добавил «не помещаются на один commodity server по какому-либо ресурсу».
  • +15
    Опять начинается.
    Вы можете докупить себе второй винт и пострайпить, чтоб увеличь пропускную способность диска вдвое, вы можете заменить восьмиядерный сервер шестнадцатиядерным, чтоб увеличь вычислительную мощность вдвое (да-да, я знаю про старика Амдала), но ни в коем случае не используйте шардинг, чтоб увеличить доступ к данным вдвое. Либо у Вас один big-ass сервер — либо несколько сотен тысяч в датацентрах по всему миру. Иначе просто никак. Ну то есть вообще никак. Нет, ну правда, кому вообще может прийти в голову, что распараллеливание доступа к данным вдвое (впятеро, вдесятеро) может кому-нибудь когда-нибудь понадобиться? Забудьте эту ересь и никогда не вспоминайте — у Вас просто нет столько данных.

    А если серьезно, то у меня возникли какие то смутные сомнения в компетентности чувака.
    Что значит «слишком много для Excel»? Excel, знаете ли, может принимать данные из любых источников, включая все тот же SQL. Ему вообще плевать откуда они приходят.

    Что за фиксация на размере данных. Что за утверждения, что распараллеливание НИКОГДА не может быть эффективнее SQL (скажем прямо, некоторые запросы на SQL попросту невыразимы вменяемо — для этого даже языки запросов новые выдумывают от XQuery до MDX). Вот как раз когда есть одна таблица с парой колонок, то совершенно неважно 500 мегабайт там или 5 терабайт — би-деревья все прожуют и выплюнут даже не успев толком осознать что происходит. А вот если у меня 500 мегабайт (5 гигабайт? 10? 1007) данных структурированных по двум десяткам измерений, причем эти данные постоянно обновляются, то тут уж мне либо сутки (двое? трое? неделю?) и анализировать его в PowerPivot (во всем том же Excel) с молниеносными запросами по любой комбинации измерений, либо кинуть запрос в кластер, где каждый каждый «прожует» свой небольшой кусочек и потом сагрегировать это все. Да, суммарно запрос будет все так же неэффективен как и обычный SQL (ну хреново SQL работает с многомерным датамайнингом — ну чего тут делать), но зато он будет ускорен ровно во столько раз сколько нод в кластере.

    PS: Hadoop и BigData это сейчас «модно», но так же модно сейчас и быть «илитой» и начисто отрицать применимость MapReduce в любых сеттингах, кроме кеша Гугла
    • 0
      то тут уж мне либо сутки (двое? трое? неделю?)

      то тут уж мне либо сутки (двое? трое? неделю?) считать кубик
    • +7
      > Что значит «слишком много для Excel»?
      У него есть лимит, больше которого ни через sql, ни как по-другому в одну таблицу не влезет (кажется, 1 млн). Кажется, это ограничение и в 2013 версии до сих пор есть. Наверное, чел имеет в виду его.
    • +1
      Простенькая функция «сцепить» на не самой слабой машине на таблице из 250 тыс строк выполняется около 30 секунд.
    • –1
      некоторые запросы на SQL попросту невыразимы вменяемо


      Можно примеры?
  • +16
    Для меня вся польза от статьи свелась к тому, что я узнал про pandas.

    Остальное уже многократно обсуждалось разными авторами и сводится к тривиальному: используйте инструмент соразмерный задаче. Короче, не стоит забивать гвозди микроскопом и смотреть что-то в молоток. Могут не так понять.
    • 0
      вся польза от статьи свелась к тому, что я узнал про pandas

      Аналогично. Заодно на сайте pandas увидел интересную книжку Python for Data Analysis. Кто-нибудь читал? Стоит потраченного времени?
      • 0
        Дык качните да полистайте ;)
  • 0
    Основной вопрос в том, что с данными делать, как мне кажется.
  • +2
    Как по мне, так статья ни о чем. Как вообще можно говорить о надобности Hadoop, опираясь только лишь на объемы данных? Привожу простой пример — берем базу из конкурса netflix, называется, по-моему, 1М Songs Database — простой набор, там реально csv размером 100Мб.
    Так вот: попробуйте-ка провести user-based коллаборативную фильтрацию по всем пользователям на том же Mahout! Всего-то 10 тысяч человек. На моем i7 обрабатывается всего 10 тысяч пар в секунду при корреляции Пирсона… Ну куплю я ssd, и что?

    А что если захотеть все это делать в реальном времени? Вот тут нам действительно пригодится Hadoop — просто, мне кажется, не стоит ограничиваться только тем, что Hadoop медленный и на питоне мы это сделаем быстрее — пишите тогда сразу на ассемблере. Hadoop — это прежде всего ИНСТРУМЕНТ и он еще много чего умеет и много всего упрощает. Я сомневаюсь, что автор сможет сходу найти решение, которое запустит его мега-SQL код на сотне-другой Амазоновских инстансов.

    Быстрота и упрощение разработки — вот что выгодно компаниям на данный момент, поэтому Hadoop и популярен.
    • +2
      Если не хватает производительности для обработки, то вам нужно больше памяти и больше вычислительных ядер, а не больше машин с Hadoop-ом. Современные сервера спокойно держат по 32+ ядер и 128Гб+ RAM, так что правильно распараллелинные процессы выдадут вам результат практически мгновенно и без оверхеда Хадупа. Если и этого мало, 100Мб можно разделить и очень быстро скопировать части на несколько серверов, обработав их параллельно и независимо друг от друга.

      С другой стороны, если данных у вас 5Тб, то быстро скопировать их на несколько машин… да что уж там, даже быстро считать их с диска в память у вас уже не получится. И вот тогда Hadoop даёт настоящий параллелизм и серьёзное повышение производительности.
      • 0
        Абсолютно с Вами согласен, но я сейчас не рассматриваю гаражные стартапы, а мыслю корпорациями, что сводит Ваше утверждение
        Если не хватает производительности для обработки, то вам нужно больше памяти и больше вычислительных ядер, а не больше машин с Hadoop-ом.

        к тому, что мне нужно именно БОЛЬШЕ машин с Hadoop-ом, так как в них больше именно вычислителей и мне со всем этим
        Если и этого мало, 100Мб можно разделить и очень быстро скопировать части на несколько серверов, обработав их параллельно и независимо друг от друга.

        не придется долго возиться. Причем в корпорации действительно может быть мало данных, а вся ее деятельность строится на сложных вычислениях. Всё мое мнение заключается в том, что автор строит выводы о Hadoop'e только на основе конкретной его задачи, а я привожу контрпример
        • 0
          Ну это если на Hadoop есть готовые алгоритмы, которые можно просто взять и использовать. Писать свои алгоритмы, ограничиваясь парадигмой MR, таки на порядок сложнее.
  • 0
    А еще он, ЕМНП, из коробки поддерживает резервированние. А это очень важная фича
    • 0
      Если они таки допилили нормальное резервирование NameNode. Иначе есть SPOF.
      • 0
        Опс… Я был лучшего о нем мнения.
        Тут преимущество тоже вилами на воде писанное.

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