Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 50
Давно ждал эту статью. Особенно после спора на форуме что 10-ки ГБ в день это много данных и как раз для хадупа =).
На форуме спор закончился, решили продолжить здесь? :)
А по-моему, без понимания того, что размер данных имеет пренебрежительно малое значение по сравнению с их структурой и паттернами запросов, вообще стоит прекратить спорить про data warehousing. Хоть на форумах, хоть здесь
Абсолютно с Вами согласен.
И еще один момент: нельзя все измерять в байтах-гигабайтах; когда мы говорим о BigData, то это еще и большое количество «записей», и 1ТБ данных из 1млн «записей» будет работать в разы быстрее, нежели этот же 1ТБ из 1 млрд «записей».
И еще один момент: нельзя все измерять в байтах-гигабайтах; когда мы говорим о BigData, то это еще и большое количество «записей», и 1ТБ данных из 1млн «записей» будет работать в разы быстрее, нежели этот же 1ТБ из 1 млрд «записей».
Передвижение данных тут не при чем. Чтобы с данными что-то сделать, провести какую-то обработку, треубется доступ к этим данным, и доступ к 1млрд записей общим объемом 1ТБ будет занимать больше времени, нежели 1млн того же объема.
Для наглядности могу привести такой
Скажите, пожалуйста, теперь мне удалось объяснить разницу?
Для наглядности могу привести такой
пример абстрактной задачки со смешными цифрами
Есть 10 серверов, общий объем полезных данных ~74ГБ и 10млрд записей равномерно распределенные по этим серверам.
В каждой записи есть 64-битный Integer(т.е. запись занимает 8 байт).
Вам нужно высчитать среднее по всем записям. Каждый юнит в таком случае высчитывает среднее из 1млрд записей, после чего сливаются воедино 10 записей и из них высчитывается среднее.
Теперь возьмем эту же задачу, только данных будет не 10млрд, а 80млрд, и будет не Int64, а Byte(т.е. занимает, не 8 байт, а 1). Теперь при том же общем объеме данных каждый юнит должен высчитать среднее не из 1млрд записей, а из 8млрд записей.
В каждой записи есть 64-битный Integer(т.е. запись занимает 8 байт).
Вам нужно высчитать среднее по всем записям. Каждый юнит в таком случае высчитывает среднее из 1млрд записей, после чего сливаются воедино 10 записей и из них высчитывается среднее.
Теперь возьмем эту же задачу, только данных будет не 10млрд, а 80млрд, и будет не Int64, а Byte(т.е. занимает, не 8 байт, а 1). Теперь при том же общем объеме данных каждый юнит должен высчитать среднее не из 1млрд записей, а из 8млрд записей.
Скажите, пожалуйста, теперь мне удалось объяснить разницу?
Я думаю, я понял вашу идею, но пример не очень удачный. Вы предполагаете, что полное время на обработку одного int8 будет равно полному времени на обработку int64, что может быть совсем не так. На самом деле, я бы поставил на то, что на таких простых задачах как вычисление среднего большая часть времени будет уходить на считывание данных с диска в память, и эта величина для int8 и int64 будет одинаковой и зависеть от размера буффера.
Можно даже придумать контрпример. Например, возьмём стандартный WordCount. У нас есть миллион строк, в каждой в среднем по 10 слов. Если мы объеденим каждые 8 строк в одну, то получим всего 125 тысяч строк… но ведь и слов в каждой из них будет уже не по 10, а по 80! Т.е. суммарная работа всё равно останется той же, как бы вы не делили или не объединяли строки.
А в некоторых случаях множество небольших записей может быть даже выгодней. Например, если вам нужно построить лексическое дерево текста, при этом время работы зависит от количества слов как O(n^2), то чем больше слов в одной записи, тем дольше будет выполняться вся работа.
Можно даже придумать контрпример. Например, возьмём стандартный WordCount. У нас есть миллион строк, в каждой в среднем по 10 слов. Если мы объеденим каждые 8 строк в одну, то получим всего 125 тысяч строк… но ведь и слов в каждой из них будет уже не по 10, а по 80! Т.е. суммарная работа всё равно останется той же, как бы вы не делили или не объединяли строки.
А в некоторых случаях множество небольших записей может быть даже выгодней. Например, если вам нужно построить лексическое дерево текста, при этом время работы зависит от количества слов как O(n^2), то чем больше слов в одной записи, тем дольше будет выполняться вся работа.
Я описывал пример мап-редьюса в принципе.
Ваш пример не описывает что это за строки и как к ним получается доступ, потому что основной посыл в моем предыдущем комментарии про доступ к данным, а не только про их обработку.
А последнее про то, что иногда для конкретных задач маленькие записи выгоднее, ну естественно, кто же спорит? Но…
То, что Вы описали похоже только на оптимизацию работы одной ноды, а где же сам map-reduce? Чем меньше работы у одной ноды, тем больше будет у мастера и наоборот (это только в вашем случае, для моего примера это не играет роли).
Ваш пример не описывает что это за строки и как к ним получается доступ, потому что основной посыл в моем предыдущем комментарии про доступ к данным, а не только про их обработку.
А последнее про то, что иногда для конкретных задач маленькие записи выгоднее, ну естественно, кто же спорит? Но…
то чем больше слов в одной записи, тем дольше будет выполняться вся работа.
То, что Вы описали похоже только на оптимизацию работы одной ноды, а где же сам map-reduce? Чем меньше работы у одной ноды, тем больше будет у мастера и наоборот (это только в вашем случае, для моего примера это не играет роли).
Да, я понимаю, что при большем количестве записей, время расчетов будет больше. Но время будет пропорционально больше каким бы инструментом вы не пользовались — MapReduce на 10 компах или все на одном компе c подсчетом скриптом. Отчего в контексте статьи (выбора технологии) я не понимаю почему нужно отдать препочтение одной технологии над другой в зависимости от количества записей.
Было бы не плохо, если бы Вы подкрепили свое высказывание реальным примером. Ну например, вот кусок данных и с ними надо сделать то-то.
Вот кусок данных, представьте что у вас всего лишь миллион записей:
Field_А, Field_B, Field_X
1111111, 2222222, 333333
…
333333, 2222222, 444444
Надо сделать JOIN Field_A = Field_X
Field_А, Field_B, Field_X
1111111, 2222222, 333333
…
333333, 2222222, 444444
Надо сделать JOIN Field_A = Field_X
Задача очень расплывчата, но это и не важно — Вычитали множество логов, распарсили. Создали мапу, как ключ положили Field_A, значение — лог. Проитерировались по коллекции логов, проверили вхождение в мапе Field_X — если нашли, положили в аутпут.
Если миллион записей — ~500мб на диске, в памяти это займет ~1ГБ. Алгоритму нужно вдвое больше. Вам надо 2 ГБ оперативы. Простой джарник запроцесит такой объем за несколько десятков секунд, а то и меньше в зависимости от железа. В то время как на поднятие хадуп нод уйдет от 5 мин.
Если миллион записей — ~500мб на диске, в памяти это займет ~1ГБ. Алгоритму нужно вдвое больше. Вам надо 2 ГБ оперативы. Простой джарник запроцесит такой объем за несколько десятков секунд, а то и меньше в зависимости от железа. В то время как на поднятие хадуп нод уйдет от 5 мин.
70 секунд у меня уходит на инициализацию джобы и 86 секунд на обработку 4 миллионов записей
Ну так вопрос вдругом — зачем тут хадуп?
А что мешает? Если задача, хорошо ложиться на хадуп, дак почему бы им не воспользоваться? Если он у вас есть, то накидать джобу на питоне — это 10 минут работы. Смотрите на него как на эксель. Кроме того мы стираем грани, что 4 что 44 миллиона записей обрабатываются просто. Естественно, можно самому написать совой велосипед, можно даже его распаралелить, это тоже интересно. Но какие преимущества от этого?
Совсем другой вопрос, если парадигда m/r не подходит к задаче, а её начинают усилинно на неё натягивать…
Совсем другой вопрос, если парадигда m/r не подходит к задаче, а её начинают усилинно на неё натягивать…
Данные бывают разные. Иногда обработка какого-то маленького кусочка может занимать минуты. И в случае даже одного гигабайта такого типа данных обработка на одном хосте не целесообразна. Из практики: на 100 достаточно мощных машинках подобного рода задача занимала около 1 часа.
Так что, если данные тривиальны для процессинга и 100терабайт для хадупа может быть мало. Все зависит от того, что и как вы делаете.
Так что, если данные тривиальны для процессинга и 100терабайт для хадупа может быть мало. Все зависит от того, что и как вы делаете.
Хорошо, можете привести пример этого маленького кусочка и задачу по обработке, которая ставилась?
Например задача пропустить миллион Regexp против какого-то набора данных и собрать все хиты. Время прогона такого количества регулярных выражений против 5-10 килобайт данных занимает несколько секунд. Таких кусочков данных может быть по несколько миллионов, что в сумме дает несколько сотен гигабайт. Мелоч, даже пол терабайта нет. Но долго очень.
Хороший пример, тут даже нечего возразить. Лишь вопрос по «миллион Regexp» — рилли? Что за задача, если не секрет?
К сожалению я не могу рассказать о чем речь.
Но можно сказать, что таким образом можно классифицировать данные.
Если правильно проставить score для каждого регулярного выражения, то сумма все очков и классов регулярных выражений может определить в какую категорию попадает тот или иной кусок данных, причем с ОЧЕНЬ высоким качество близким к 99.99999% — это куда лучше чем человек может сделать в ручную. Кстати, проблема проставления скоров для всех этих рег. выражений та еще задачка, при задействовании достаточно мощных вычислительных ресурсов это занимает более 2-х суток чтобы добиться вот этого 99.99999%.
зы. Миллион это цифра с потолка, на самом деле их гораздо больше. Большая часть из них генерируется автоматически.
Но можно сказать, что таким образом можно классифицировать данные.
Если правильно проставить score для каждого регулярного выражения, то сумма все очков и классов регулярных выражений может определить в какую категорию попадает тот или иной кусок данных, причем с ОЧЕНЬ высоким качество близким к 99.99999% — это куда лучше чем человек может сделать в ручную. Кстати, проблема проставления скоров для всех этих рег. выражений та еще задачка, при задействовании достаточно мощных вычислительных ресурсов это занимает более 2-х суток чтобы добиться вот этого 99.99999%.
зы. Миллион это цифра с потолка, на самом деле их гораздо больше. Большая часть из них генерируется автоматически.
Большие Данные это когда они не помещаются на 1 машину. Все.
Вы чуть ошибаетесь, ИМХО. Большие данные — когда приходится их горизонтально масштабировать.
Утолите, пожалуйста, мой интерес: в чем ошибается olku и как горизонтально масштабировать на одной машине?
Ошибается лишь чуть. Всё же на одной машине не учтены параметры этой машины и возможности улучшения производительности.
Горизонтальное масштабирование на одной машине может использоваться в случае, если исходная обработка не может утилизировать хотя бы один из ресурсов машины (например, упирается в CPU и при этом является однопоточной при наличии свободных ядер).
В узком смысле big data можно воспринимать как «уперлись в диск», как необходимость горизонтального масштабирования по дисковому пространству. В широком можно притащить за уши «упор» в любой ресурс (будь то disk, iops, cpu, mem), тогда, например, grid computing станет big data…
Опять же, в случае исчерпания какого-либо ресурса есть джва пути масштабирования: вертикально или горизонтально. И этот выбор, как правило, определяется тем, что за данные. Если это неизменяемые данные, то может хватить увеличения ресурсов в рамках одной машины без «вступания» в big data. Если же это, например, пополняемые данные, которые будут расти и расти — «вступать» придется.
В узком смысле big data можно воспринимать как «уперлись в диск», как необходимость горизонтального масштабирования по дисковому пространству. В широком можно притащить за уши «упор» в любой ресурс (будь то disk, iops, cpu, mem), тогда, например, grid computing станет big data…
Опять же, в случае исчерпания какого-либо ресурса есть джва пути масштабирования: вертикально или горизонтально. И этот выбор, как правило, определяется тем, что за данные. Если это неизменяемые данные, то может хватить увеличения ресурсов в рамках одной машины без «вступания» в big data. Если же это, например, пополняемые данные, которые будут расти и расти — «вступать» придется.
Я понял Вашу мысль.
Но, если есть еще в запасе неиспользуемые ядра, которые можно использовать(вы не описали в примере обратное), то почему их не использовать и почему они не были использованы сразу? Сомневаюсь, что это можно отнести к горизонтальному масштабированию, это просто подгонка под свободные ресурсы в разрезе одного сервера. Иначе, исходя из Вашего комментария можно отнести к горизонтальному масштабированию увеличение количества воркеров какого-нибудь гирмана для одной очереди.
И тем не менее это ведь не исключает высказывание olku
Но, если есть еще в запасе неиспользуемые ядра, которые можно использовать(вы не описали в примере обратное), то почему их не использовать и почему они не были использованы сразу? Сомневаюсь, что это можно отнести к горизонтальному масштабированию, это просто подгонка под свободные ресурсы в разрезе одного сервера. Иначе, исходя из Вашего комментария можно отнести к горизонтальному масштабированию увеличение количества воркеров какого-нибудь гирмана для одной очереди.
И тем не менее это ведь не исключает высказывание olku
По сути, распараллеливание задачи по потокам/процессам — это собственно горизонтальное масштабирование. Происходит это в рамках одной машины или сети — не суть важно.
Я скорее не согласен со StamPit. Далеко не любая задача, требующая горизонтального масштабирования является big data.
К варианту от olku я бы добавил «не помещаются на один commodity server по какому-либо ресурсу».
Я скорее не согласен со StamPit. Далеко не любая задача, требующая горизонтального масштабирования является big data.
К варианту от olku я бы добавил «не помещаются на один commodity server по какому-либо ресурсу».
Опять начинается.
Вы можете докупить себе второй винт и пострайпить, чтоб увеличь пропускную способность диска вдвое, вы можете заменить восьмиядерный сервер шестнадцатиядерным, чтоб увеличь вычислительную мощность вдвое (да-да, я знаю про старика Амдала), но ни в коем случае не используйте шардинг, чтоб увеличить доступ к данным вдвое. Либо у Вас один big-ass сервер — либо несколько сотен тысяч в датацентрах по всему миру. Иначе просто никак. Ну то есть вообще никак. Нет, ну правда, кому вообще может прийти в голову, что распараллеливание доступа к данным вдвое (впятеро, вдесятеро) может кому-нибудь когда-нибудь понадобиться? Забудьте эту ересь и никогда не вспоминайте — у Вас просто нет столько данных.
А если серьезно, то у меня возникли какие то смутные сомнения в компетентности чувака.
Что значит «слишком много для Excel»? Excel, знаете ли, может принимать данные из любых источников, включая все тот же SQL. Ему вообще плевать откуда они приходят.
Что за фиксация на размере данных. Что за утверждения, что распараллеливание НИКОГДА не может быть эффективнее SQL (скажем прямо, некоторые запросы на SQL попросту невыразимы вменяемо — для этого даже языки запросов новые выдумывают от XQuery до MDX). Вот как раз когда есть одна таблица с парой колонок, то совершенно неважно 500 мегабайт там или 5 терабайт — би-деревья все прожуют и выплюнут даже не успев толком осознать что происходит. А вот если у меня 500 мегабайт (5 гигабайт? 10? 1007) данных структурированных по двум десяткам измерений, причем эти данные постоянно обновляются, то тут уж мне либо сутки (двое? трое? неделю?) и анализировать его в PowerPivot (во всем том же Excel) с молниеносными запросами по любой комбинации измерений, либо кинуть запрос в кластер, где каждый каждый «прожует» свой небольшой кусочек и потом сагрегировать это все. Да, суммарно запрос будет все так же неэффективен как и обычный SQL (ну хреново SQL работает с многомерным датамайнингом — ну чего тут делать), но зато он будет ускорен ровно во столько раз сколько нод в кластере.
PS: Hadoop и BigData это сейчас «модно», но так же модно сейчас и быть «илитой» и начисто отрицать применимость MapReduce в любых сеттингах, кроме кеша Гугла
Вы можете докупить себе второй винт и пострайпить, чтоб увеличь пропускную способность диска вдвое, вы можете заменить восьмиядерный сервер шестнадцатиядерным, чтоб увеличь вычислительную мощность вдвое (да-да, я знаю про старика Амдала), но ни в коем случае не используйте шардинг, чтоб увеличить доступ к данным вдвое. Либо у Вас один big-ass сервер — либо несколько сотен тысяч в датацентрах по всему миру. Иначе просто никак. Ну то есть вообще никак. Нет, ну правда, кому вообще может прийти в голову, что распараллеливание доступа к данным вдвое (впятеро, вдесятеро) может кому-нибудь когда-нибудь понадобиться? Забудьте эту ересь и никогда не вспоминайте — у Вас просто нет столько данных.
А если серьезно, то у меня возникли какие то смутные сомнения в компетентности чувака.
Что значит «слишком много для Excel»? Excel, знаете ли, может принимать данные из любых источников, включая все тот же SQL. Ему вообще плевать откуда они приходят.
Что за фиксация на размере данных. Что за утверждения, что распараллеливание НИКОГДА не может быть эффективнее SQL (скажем прямо, некоторые запросы на SQL попросту невыразимы вменяемо — для этого даже языки запросов новые выдумывают от XQuery до MDX). Вот как раз когда есть одна таблица с парой колонок, то совершенно неважно 500 мегабайт там или 5 терабайт — би-деревья все прожуют и выплюнут даже не успев толком осознать что происходит. А вот если у меня 500 мегабайт (5 гигабайт? 10? 1007) данных структурированных по двум десяткам измерений, причем эти данные постоянно обновляются, то тут уж мне либо сутки (двое? трое? неделю?) и анализировать его в PowerPivot (во всем том же Excel) с молниеносными запросами по любой комбинации измерений, либо кинуть запрос в кластер, где каждый каждый «прожует» свой небольшой кусочек и потом сагрегировать это все. Да, суммарно запрос будет все так же неэффективен как и обычный SQL (ну хреново SQL работает с многомерным датамайнингом — ну чего тут делать), но зато он будет ускорен ровно во столько раз сколько нод в кластере.
PS: Hadoop и BigData это сейчас «модно», но так же модно сейчас и быть «илитой» и начисто отрицать применимость MapReduce в любых сеттингах, кроме кеша Гугла
то тут уж мне либо сутки (двое? трое? неделю?)
то тут уж мне либо сутки (двое? трое? неделю?) считать кубик
Простенькая функция «сцепить» на не самой слабой машине на таблице из 250 тыс строк выполняется около 30 секунд.
некоторые запросы на SQL попросту невыразимы вменяемо
Можно примеры?
Для меня вся польза от статьи свелась к тому, что я узнал про
Остальное уже многократно обсуждалось разными авторами и сводится к тривиальному: используйте инструмент соразмерный задаче. Короче, не стоит забивать гвозди микроскопом и смотреть что-то в молоток. Могут не так понять.
pandas.Остальное уже многократно обсуждалось разными авторами и сводится к тривиальному: используйте инструмент соразмерный задаче. Короче, не стоит забивать гвозди микроскопом и смотреть что-то в молоток. Могут не так понять.
Основной вопрос в том, что с данными делать, как мне кажется.
Как по мне, так статья ни о чем. Как вообще можно говорить о надобности Hadoop, опираясь только лишь на объемы данных? Привожу простой пример — берем базу из конкурса netflix, называется, по-моему, 1М Songs Database — простой набор, там реально csv размером 100Мб.
Так вот: попробуйте-ка провести user-based коллаборативную фильтрацию по всем пользователям на том же Mahout! Всего-то 10 тысяч человек. На моем i7 обрабатывается всего 10 тысяч пар в секунду при корреляции Пирсона… Ну куплю я ssd, и что?
А что если захотеть все это делать в реальном времени? Вот тут нам действительно пригодится Hadoop — просто, мне кажется, не стоит ограничиваться только тем, что Hadoop медленный и на питоне мы это сделаем быстрее — пишите тогда сразу на ассемблере. Hadoop — это прежде всего ИНСТРУМЕНТ и он еще много чего умеет и много всего упрощает. Я сомневаюсь, что автор сможет сходу найти решение, которое запустит его мега-SQL код на сотне-другой Амазоновских инстансов.
Быстрота и упрощение разработки — вот что выгодно компаниям на данный момент, поэтому Hadoop и популярен.
Так вот: попробуйте-ка провести user-based коллаборативную фильтрацию по всем пользователям на том же Mahout! Всего-то 10 тысяч человек. На моем i7 обрабатывается всего 10 тысяч пар в секунду при корреляции Пирсона… Ну куплю я ssd, и что?
А что если захотеть все это делать в реальном времени? Вот тут нам действительно пригодится Hadoop — просто, мне кажется, не стоит ограничиваться только тем, что Hadoop медленный и на питоне мы это сделаем быстрее — пишите тогда сразу на ассемблере. Hadoop — это прежде всего ИНСТРУМЕНТ и он еще много чего умеет и много всего упрощает. Я сомневаюсь, что автор сможет сходу найти решение, которое запустит его мега-SQL код на сотне-другой Амазоновских инстансов.
Быстрота и упрощение разработки — вот что выгодно компаниям на данный момент, поэтому Hadoop и популярен.
Если не хватает производительности для обработки, то вам нужно больше памяти и больше вычислительных ядер, а не больше машин с Hadoop-ом. Современные сервера спокойно держат по 32+ ядер и 128Гб+ RAM, так что правильно распараллелинные процессы выдадут вам результат практически мгновенно и без оверхеда Хадупа. Если и этого мало, 100Мб можно разделить и очень быстро скопировать части на несколько серверов, обработав их параллельно и независимо друг от друга.
С другой стороны, если данных у вас 5Тб, то быстро скопировать их на несколько машин… да что уж там, даже быстро считать их с диска в память у вас уже не получится. И вот тогда Hadoop даёт настоящий параллелизм и серьёзное повышение производительности.
С другой стороны, если данных у вас 5Тб, то быстро скопировать их на несколько машин… да что уж там, даже быстро считать их с диска в память у вас уже не получится. И вот тогда Hadoop даёт настоящий параллелизм и серьёзное повышение производительности.
Абсолютно с Вами согласен, но я сейчас не рассматриваю гаражные стартапы, а мыслю корпорациями, что сводит Ваше утверждение
к тому, что мне нужно именно БОЛЬШЕ машин с Hadoop-ом, так как в них больше именно вычислителей и мне со всем этим
не придется долго возиться. Причем в корпорации действительно может быть мало данных, а вся ее деятельность строится на сложных вычислениях. Всё мое мнение заключается в том, что автор строит выводы о Hadoop'e только на основе конкретной его задачи, а я привожу контрпример
Если не хватает производительности для обработки, то вам нужно больше памяти и больше вычислительных ядер, а не больше машин с Hadoop-ом.
к тому, что мне нужно именно БОЛЬШЕ машин с Hadoop-ом, так как в них больше именно вычислителей и мне со всем этим
Если и этого мало, 100Мб можно разделить и очень быстро скопировать части на несколько серверов, обработав их параллельно и независимо друг от друга.
не придется долго возиться. Причем в корпорации действительно может быть мало данных, а вся ее деятельность строится на сложных вычислениях. Всё мое мнение заключается в том, что автор строит выводы о Hadoop'e только на основе конкретной его задачи, а я привожу контрпример
А еще он, ЕМНП, из коробки поддерживает резервированние. А это очень важная фича
Если они таки допилили нормальное резервирование NameNode. Иначе есть SPOF.
Опс… Я был лучшего о нем мнения.
Тут преимущество тоже вилами на воде писанное.
Тут преимущество тоже вилами на воде писанное.
Рекомендую глянуть статью от hortonworks hortonworks.com/blog/ha-namenode-for-hdfs-with-hadoop-1-0-part-1/#.UjxAp6DHkm8
По части ha развитие идет. И счастье началось с hadoop-1.0.
По части ha развитие идет. И счастье началось с hadoop-1.0.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вам не нужен Hadoop — у вас просто нет столько данных