Меня спросили: «Сколько у вас опыта с большими данными и 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 МБ Больших Данных.
Автор: alexeyrom
