Как стать автором
Обновить

Сериал: Big Data — как мечта. 6-я серия. BD (Bolt Data) — Быстрые Big Data данные

Время на прочтение5 мин
Количество просмотров8.6K
Всего голосов 12: ↑11 и ↓1+10
Комментарии9

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

Как понимаю рабы никуда не делись, мы просто задали им другой алгоритм работы?
Интересный аспект, спасибо за точный комментарий ))
Кстати, в этом аспекте переориентация 10 000 сотрудников IBM смотрится очень даже по Тутанхамонски ))
Под рабами подразумевал ядра/сервера. Если правильно подсчитал, то в вашей задаче имели порядка 3.6Gb данных каждый час, последовательная обработка 1k сообщений на одном ядре занимает порядка 2-ух часов.

Решение IBM вполне себе оправдано, где найдешь на рынке труда 10 000 готовых сотрудников?
Ага, спасибо за уточнение, теперь более понятно о чем речь. Данных на самом деле в несколько раз (3-5) больше, в том числе и «на входе». Поскольку, с одной стороны, в виду определенной специфики, распределенная система должна быть сильно децентрализована, во-вторых, символы =/= байты, и, главное, есть много сопутствующей информации (начиная от адреса ресурса и заканчивая гео-метками и списками друзей, читателей и пр.).

Кроме того, есть дополнительные расходы для оптимизации скорости Монго и Эластика, авторской базы и пр. и пр. Поэтому в нашей сфере мы обычно «не мыслим» Гбайтами трафика, а используем сущности «сообщение», «текст», «список», «автор» и пр. И лишь когда нужна грубая оценка ширины канала или дисковых массивов-кластеров, тогда «снижаемся» на уровень байт и бит.
«Быстрые Big Data данные» — это прямо бинго. Мало того что тавтология, так и еще бессмыслица — данные быстрыми быть не могут.
Уважаемый meta4, сложно ответить на комментарий в подобном духе (тональности). Тратить время на проблему различия-восприятия «цвета платья» или неколичественного уровня быстроты обработки лингвомодулей — бессмысленно.
Но по сути мы приходим к тому, о чем начали: если у нас есть данные, к ним нужна обработка. Если данных много — мы бьем их на кусочки, и обрабатываем каждый отдельно. Если может сделать это параллельно — прекрасно, просто добавляем серверы (тысячи их) и время у нас уменьшается (только главное правильно нарезать каждому работу).

Но вопрос никуда не делся: что сделать с _кусочком_ данных? Раб, таскающий камни, вовсе не факт что хорошо определит качество человека по его резюме, не говоря уже про навыки анализа сообщений в сторону Президента. А даже если каждый раб и примет какое-то решение (что при громадном числе рабов займет не годы, а часы), на втором шаге нужно сравнить и принять решения по результатам работы каждого раба.

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

Выскажу личную трактовку с «неприличной» аналогией (физики и химики гордо закидают яблоками) — ситуация аналогично неопределенности Гейзенберга и переход от атомов к молекулам: для «правильных» объемов Big Data нужно и достаточно столько, чтобы _совокупность данных_ производила НОВУЮ сущность-данные, которые будут вести себя совершенно _иначе_ (электрон превращается из частицы волной).

Если мы как о примере говорим про &A (data scientist), то до недавнего времени был только мозг человека, который на интуиции находил решение (Шеркол Холмс). Сейчас, с развитием инструментария, который хоть немного, но уже подвинул (расширил) «компьютерные мозги» от просто «молотилки чисел» в сторону лингвистики-семантики-взаимосвязей-анализа, появляется более широкое поле выявление НОВЫХ сущностей-связей-агрегаций.

Грубо говоря, как автомобиль позволил ЛЮБОМУ человеку убыстриться в 20 раз, как вертолет позволил прыгнуть в высоту в 1000 раз, так и Big Data должны позволить любому человеку, а не только Шерлоку Холмсу, в 100 раз повысить наблюдательность.
Кстати, не обязательно Hadoop и иже с ним. Вполне актуально не только направление «вширь», но и направление «вглубь» — SIMD, GPGPU, ASIC — очень интересно посмотреть на историю развития майнинга и самих криптовалют, где принцип «время — деньги» — основа бытия.

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

Но что объединяет в этом примере человечество и криптовалюты? Не каждый человек может себе позволить передвижение с помощью автомобиля, а тем более вертолёта. Космический транспорт — вообще до сих пор удел редких избранных, которых всё ещё можно перечислять по именам. Не каждая задача оправдывает подобные затраты.

Более скоростные перемещения требуют и более дорогой инфраструктуры, которые уже не могут себе позволить не только отдельные люди, но и целые страны — автобаны, высокоскоростные железные дороги, космопорты; сам скоростной транспорт и целая промышленность, которая требуется для строительства, производства, обслуживания. Экспансия упирается в эффективность каналов связи, стоимость энергии, ограниченность ресурсов получения энергии и лимиты «экологического долга». «Рост» вглубь — в затраты на производство более совершенной и миниатюрной модели.

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

Имхо, суть «новой сущности» — это всегда более короткий, более быстрый, более дешёвый, более энергоэкономный «путь из точки А в точку Б». При том, что все эти «более» — не взаимозаменяемы. Более короткий не значит более быстрый, более дешёвый и более энергоэкономный, если срезать придётся пешком и по болотам, вместо автомобиля по трассе в объезд. Так же и с данными: Hadoop — это не обязательно худшее решение, если данные таки не вмещаются в оперативную память или память при векторном процессоре. Само сравнение без подобных уточнений оказывается некорректным.

Такое вот вышло отрицание отрицания в отдельно взятом комментарии, которое на самом деле ничего не отрицает, а лишь подтверждает тезисы сериала )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий