Откуда все пошло, где мы сейчас, и что впереди |
Предыстория BigchainDB: ascribe
Летом 2013 года мы начали работать над проектом ascribe — установление авторства интеллектуальной собственности (ИС) на основе блокчейн. Когда мы рассказывали про него другим, ответ был, как правило, «серьезно?». Блокчейн не был широко распространенной идеей. На самом деле, даже сам биткойн тогда не был так уж известен! Биткойн достиг пика стоимости полтора года спустя, когда был пройден порог в $1000, но блокчейну потребовался еще один год, чтобы достичь достаточной популярности.
Мы решали «проблему слона в комнате»: как вы хотите хранить цифровое искусство? Как могут создатели цифрового искусства получить за него деньги? Ну серьезно, как мог любой музыкант, рассказчик, видеооператор, дизайнер и т.д. получить отчисления с продаж? Технология блокчейн могла бы решить эту проблему с помощью общего хранилища.
К лету 2014 года мы добились хороших результатов, и я мог полностью переключиться от работы в моем предыдущем стартапе — Solido. Мои кофаундеры Брюс и Маша тоже работали по полной. Мы собрали деньги, наняли несколько сотрудников и продолжали работать над продуктом, пока мы не были довольны им достаточно, чтобы выпустить его в начале 2015 года на базе блокчейна биткойна.
В начале 2014 года сотрудники Monegraph пришли к той же идее и выдали ее за результат посещения хакатона. Они пришли к тому же решению, ну надо же! Конечно, было неприятно видеть кого-то, кто объявился раньше. Несомненно, бесчисленное множество других стартапов испытывали похожее. Ну, да ладно. Наш урок был таков: надо объявлять о продукте как можно раньше, а потом уже доводить его до ума. «Если вас не пугает первая версия вашего продукта, значит вы запустили его слишком поздно» — Рейд Хоффман.
Проблемы масштабирования
В конце 2014 года один из потенциальных клиентов ascribe имел 20 миллионов пользователей и более 100000 работ в день, проходящих через их систему. Это примерно то же количество операций, которое вся сеть биткойн может поддерживать в день; и биткойн уже сталкивался с проблемами масштабирования.
Кроме того, проведение транзакций заметно подорожало: раньше это стоило всего долю цента, а сегодня уже около десяти, так что 100000 транзакций означает более $10000 операционных издержек в день. Чтобы зарегистрировать уже существующие на рынке сто миллионов работ, понадобилось бы десять миллионов долларов. Мда. Мы поняли, что это огромная проблема для нас. Осенью 2014 года я выступил с докладом на эту тему, и привел сравнение с производительностью «big data» баз данных.
Как стартап мы должны были сосредоточиться на чем-то одном. Мы выбрали путь защиты авторских прав. Мы надеялись, что кто-то решит проблему масштабируемости; мы даже уговаривали друзей работать над этим.
Проблема, которую нужно решить
К концу лета 2015 года всё больше и больше людей стали заниматься масштабированием блокчейна биткойна. Они брали существующий блокчейн, и пытались масштабировать его.
К тому времени ограничения на количество транзакций стали для нас огромной проблемой. Сам наш продукт мог обслуживать крупных клиентов и корпорации, тогда как блокчейн был не в состоянии этого сделать. Мы вынуждены были сбавить обороты, так как блокчейн биткойна не мог предоставить нам необходимую пропускную способностью.
У людей уходили десятилетия, чтобы понять, как масштабировать распределенные базы данных. Появилось огромное количество технологий, которые должны были решить эту проблему.
Я почти 20 лет разрабатывал алгоритмы машинного обучения. Один из моих самых больших уроков того времени заключался в том, что решение под большой масштаб нужно закладывать с самого начала. Вы не можете просто «расширить» какой-то алгоритм в тысячу или миллион раз. В своей работе по символической регрессии я впервые попробовал осуществить «масштабирование» и у меня ничего не вышло. Но используя радикально более простой подход я всё же получил то, что хотел. Я таким же образом отмасштабировал алгоритм оптимизации топологии, и алгоритм проверки памяти (с моими коллегами из Solido). Исследователи Google получили аналогичные результаты.
Вернемся к блокчейну. Что делать, если механизм хранения изначально и так был предназначен для масштабирования? Распределенные базы данных именно такие. Мы могли бы:
- Отмасштабировать распределенное хранилище: существующих БД умеют работать поверх многих физических машин. Это то, как Google, Facebook, Netflix (и другие) делают сервисы планетарного масштаба;
- Отмасштабировать консенсус: если у вас есть распределенная БД, то разные машины могут расходиться во мнении относительно состояния данных. Это проблема. Как осуществить синхронизацию данных? Этим занимаются алгоритмы консенсуса, которые также применяются в уже существующих распределенных базах данных. Порядок операций является сердцем консенсуса. Есть «отказоустойчивая» и «византийская отказоустойчивая» разновидности консенсусных протоколов, таких как Paxos и PBFT, некоторые из которых восходят к 80-м годам, а на самом деле опираются на работы 50-х и 60-х годов (ARPAnet).
Зная это, как мы могли соединить блокчейн и распределенную базу данных? Мы определили три характеристики блокчена:
- Децентрализованность: ни одна организация не владеет или управляет БД;
- Неизменность: более высокая стойкость к изменению данных, чем у обычной БД. На самом деле, существующие БД и технологии создания мгновенных снимков состояния и так позволяют добиться «неизменности» данных, но чуть в меньшей степени.
- Активы: можно регистрировать и передавать активы, при этом владелец закрытого ключа является владельцем актива.
Вперед, к первой версии BigchainDB!
В конце лета 2015 года, с описанными выше начальными условиями, мы должны были выбрать распределенную БД, чтобы начать работу. Мы протестировали Cassandra, MongoDB, Elasticsearch и многие другие. Неудивительно, что каждая из них имела гораздо лучшую масштабируемость, чем блокчейн (но я признаю, что они решают несколько иные проблемы!) Мы остановились на RethinkDB (лицензия AGPL) — хранилище документов с иерархическими ключами в стиле JSON. Основной причиной выбора RethinkDB был его отличный механизм сообщения об изменениях: каждый раз, когда какой-либо узел вносил изменения в данные, все остальные узлы информировались об этом. Это свойство могло оказаться чрезвычайно полезным для построения базовой функциональности, а также повышения отказоустойчивости.
Мы провели много итераций, чтобы максимизировать пропускную способность RethinkDB, параллельно улучшая и наш собственный алгоритм. Нашей целью являлся один миллион записей в секунду. Мы постепенно устраняли недостатки в нашем алгоритме, заодно упрощая его! Мы даже нашли некоторые ошибки в RethinkDB, которые ухудшали производительность. Но разработчики RethinkDB – отличные ребята, которые помогли решить это.
Прорыв случился, когда мы поняли, что упорядочивание/запись были самым узким местом нашей системы. Но зато эту проблему можно решить средствами самой RethinkDB. Как и многие другие распределенные БД, RethinkDB обладает тем свойством, что по мере добавления серверных узлов, пропускная способность линейно растет (максимально 64 узлов). Подумайте над этим. Это удивительный результат, хоть и неочевидный! Как RethinkDB увеличивает пропускную способность за счет добавления узлов? Секрет в шардировании: каждый узел хранит лишь часть данных. Каждая транзакция идет только к нужному узлу. Таким образом, нагрузка от входящих транзакций и записей распределяется между многими узлами.
Конечно, вы не хотите, чтобы данные потерялись, если этот узел выйдет из строя; поэтому у вас есть резервные копии, а также резервное копирование резервных копий. Каждый бэкап создает свой бэкап и так далее. Да, вы можете иметь «полную репликацию», где каждый узел хранит все данные, но, конечно, это отрицательно скажется на масштабируемости. Фактор репликации может быть настроен в соответствии с потребностями отказоустойчивости.
Таким образом, пропускная способность возрастает пропорционально числу узлов N. Но есть еще общение самих узлов между собой. Все узлы общаются со всеми узлами, поэтому число таких связей равно квадрату числа узлов. Возникает резонный вопрос: как же это не убивает масштабируемость? Ответ заключается в том, что RethinkDB поддерживает максимум 64 узла.
После того, как мы поняли, что для достижения консенсуса главным является порядок записей, мы смогли отложить голосование на более поздний этап, уже после упорядочивания/записи. Это позволило упростить архитектуру.
Блоки были не нужны, но требовалась большая оптимизация. Когда мы начали работу над BigchainDB, мы работали на уровне транзакций, то есть объект транзакции должен был содержать хэш объекта предыдущей транзакции. В конце концов, кому нужны блоки, если база данных и так хорошо упорядочивает транзакции? Всё очень просто! Тем не менее, цепочки на уровне транзакций означают, что необходимы цифровые подписи для каждой транзакции, а это уже дорого. Мы могли бы оптимизировать это путем объединения упорядоченных множеств операций в блоки, то есть цепочки на уровне блоков. Мы были готовы пойти на такую сложность во имя скорости. Но затем мы осознали: не нужна цепь блоков, чтобы получить характеристики блокчейна. Блоки — это просто оптимизация!
Можно задать вопрос: при условии, что каждый узел может иметь право голоса по каждому блоку, почему голосование не становится узким местом? Ответ: каждый узел работает в несколько десятков ядер/процессов/потоков, обрабатывая операции параллельно.
Версия v0.1
Начиная с рождения идеи осенью 2014 года, до интенсивных усилий в конце лета 2015 года, мы наконец-то объявили выход BigchainDB 10 февраля 2016 года, на блокчейн-конференции в Сан-Франциско. Это было очень смешно: все думали, что Брюс собирался говорить об авторских правах и интеллектуальной собственности. А вместо этого — BigchainDB! Мы выпустили систему с открытым кодом версии v0.1. Мы открыли каналы в Твиттере, группы Google.
Мы уже были научены опытом: сначала релиз, затем доведение до ума. К тому же версия «0.1» может подразумевать, что программное обеспечение было на стадии альфа-теста. Были заложены основы: создание активов, передачи активов, а также основной полезной нагрузки данных. Помогло то, что мы сидели на фундаменте большого, относительно зрелого кода RethinkDB. Документация была нормальной, но её было не много. Контроль уровня доступа был сделан довольно грубо: только на уровне транзакций. Систему было трудно развернуть в кластере. Мы нашли множество неисправностей/возможных атак (например, один из узлов удаляет кучу данных), но пока не торопились решать их. Таким образом, люди могли бы загрузить код и сделать всё сами, но это не было готовым продуктом.
В выложенном нами документе мы указали максимальные показатели производительности RethinkDB, упирающиеся в записи. Эти цифры позволилил оценить возможную производительность всей системы, если остальная часть алгоритма работала бы хорошо. Мы бы разработали алгоритм с простой идеей: максимально не мешать производительности самой базы данных. Мы видели, что ничто не мешает оптимизации, внедрению параллельной обработки и т.д.
Мы не выпускали тестов для транзакций — зачем? Мы должны были идти, прежде чем бежать. Мы представили цифры, которые мы имели на тот момент, зная, что с соответствующими оптимизациями мы могли бы добиться высокой производительности, и планировали выпустить другие данные вскоре.
Версии v0.2 и v0.3
Мы продолжили работу, чтобы сделать проще развертывание кластеров и тестирование производительности. Мы приложили тонну усилий (на самом деле больше, чем мы ожидали) и из-за этого мы были медленнее, чем ожидалось.
26 апреля 2016 года мы выпустили v0.2, куда входил улучшенный код развертывания кластера, улучшенная документация, исправления ошибок, и многое другое.
Параллельно с этим мы сделали транзакции, поддерживающие спецификацию Interledger. Это позволяло использовать несколько входов и выходов, пороговые условия, мультиподписи и многое другое – и все это было встроено в новый модуль криптоусловий. Мы выпустили эту версию 3 мая 2016 года как v0.3 сразу после выхода v0.2. Богатые транзакции принесли более богатые возможности контроля прав доступа.
BigchainDB: где мы сейчас
Стабилизировав развертывание кластера и расширив возможности транзакций, мы были в состоянии потратить больше времени на тестирование производительности. Сейчас мы оптимизируем код и приближаемся к выпуску результатов тестов, скорее всего, во второй половине мая. Со временем мы должны приблизиться к ожидаемой максимальной производительности.
Наше программное обеспечение по-прежнему в «альфа» стадии. Оно имеет богатую инфраструктуру активов и широкие возможности контроля прав доступа. Тем не менее, еще нет должной поддержки условного депонирования (escrow). К слову, мы никогда не будет стремиться к Тьюринг-полным транзакциям. По нашему мнению, это другая часть головоломки, решаемая людьми из Ethereum, Tendermint и т.д.
Вам придется изрядно потрудиться, чтобы использовать запросы. Но зато теперь мы можем гордиться нашей документацией. Стало проще развернуть BigchainDB в кластере. Мы по-прежнему исправляем только некоторые из выявленных недостатков, так что впереди еще много работы. Короче говоря: больше функциональных возможностей, проще в использовании, но еще не готово к боевому применению. Это нормально, так как большинство блокчейн проектов сейчас находятся на стадии Proof-of-Concept; люди могут создать какие-то свои PoC поверх BigchainDB и проверить их.
BigchainDB будут расти в качестве, а PoC постепенно превратятся в реальные жизнеспособные проекты.
Ошибка: неверные ожидания
Мы совершили ошибку, и задним числом мы ругаем себя за то, что случилось: мы не сообщили, где мы находимся и куда мы направляемся. В то время как мы много общались на GitHub (дорожная карта, контрольные точки, номера версий <1, и т.д.) и в разговорах, у нас не было простого высокоуровневого описания, например на посадочной странице thebigchaindb.com… Да и внутри GitHub всё было достаточно запутано. Мы не давали ожидаемых характеристик для различных сценариев развертывания, не рассказывали о проблемах и ошибках.
Это то, что я понял из недавних диалогов с большим количеством умных людей. Например, они загружают код и удивляются, получая очень низкие показатели производительности. Но ведь это наша работа — высокая производительность!
Короче говоря, мы не правильно описали ожидания, особенно высокоуровневый взгляд на систему. Для тех из вас, кто имел ожидания, которые отличаются от реальности: мы сожалеем. Мы стремимся быть лучше.
BigchainDB: Куда мы идем
Во-первых, мы принимаем краткосрочные меры по решению проблем коммуникации. К ним относятся:
- Улучшена связь на предмет того, над чем мы работаем сейчас и в ближайшем будущем, в целях повышения производительности, безопасности и так далее. Дорожную карту теперь проще понять. [Обновление: сделано, смотрите здесь]
- Хорошая документация по производительности для различных сценариев развертывания, поэтому любой человек может легко повторить наши тесты. [Обновление: сделано, смотрите здесь и здесь.]
- Хорошая документация о том, где есть не исправленные ошибки; более подробный FAQ и информация о отказоустойчивости
- Улучшилась страница bigchaindb.com
- Технические обновления, которые легко понять (как и этот блог)! Мы будем выпускать больше сообщений в блоге с большим количеством деталей.
Кроме того, мы будем продолжать работать над введением BigchainDB в продакшн. Это включает в себя улучшение производительности, безопасности и так далее в соответствии с целями версии. Мы также работаем над публичной версией BigchainDB; больше об том расскажем в ближайшие недели.
Если вы дочитали до этого момента: благодарим Вас за интерес, проявленный к BigchainDB! Мы очень рады этой технологии и тому, как она связывает блокчейн с современными распределенными БД. Впереди будет еще интереснее!
Источник: блог компании
Поделиться ссылкой:
Related
bitnovosti.com
Блокчейн + БигДата
Технология блокчейн в сочетании с возможностями Big Data — это мощная штука. Напомним, что Биг Дата — Большая Информация. Мы употребляем этот термин для обозначения океана информации, в котором мы купаемся. Все, что мы делаем, используя компьютеры, может быть записано, измерено, проанализировано. Все больше и больше вещей, которые мы привыкли считать всего лишь вещами, становятся компьютерами. Даже холодильники и наручные часы. Именно это мы называем IoT — Интернет Вещей. Объем информации нарастает.
Больше чем собственно информация, Биг Дэйта — это среда, позволяющая создавать умные вещи, используя сложные технологии записи, хранения и обработки данных.
Блокчейн
Главная мировая валюта, построенная на блокчейне — это Биткойн. Если не углубляться в технические детали, чтобы понять, насколько блокчейн шире, чем Биткойн, нужно оценить, что он создает. Блокчейн создает доверие. Задумайтесь о том доверии, которое необходимо для осуществления каждой электронной транзакции.
Доверие к банку, который вернет ваш вклад с процентами, доверие в правительству, которое мудро распорядится вашими налогами. Во всех этих случаях Блокчейн может быть использован и в перспективе способен заменить те промежуточные, посреднические звенья, которые сейчас используются для создания необходимого при заключении сделок доверия. Горе банкам.
Блокчейн — это публичная, прозрачная и распределенная база данных, в которой новые участники и новые сделки постоянно группируются в блоки. Эти блоки «подтверждаются» своеобразным голосованием сети, состоящей из множества пользовательских узлов, а затем соединяются друг с другом в постоянно удлиняющуюся цепь. Цепь из блоков — всё просто.
Длина цепочки и сложность её кодировки делают практически бессмысленной задачу по её дешифровке и фальсификации. В дополнение к этому Блокчейн постоянно укрепляет доверие, используя для общего блага тягловую лошадку личной корысти. Любые действия, укрепляющие целостность и безопасность системы Блокчейн, не остаются без вознаграждения.
Объединение технологий
Что же может произойти, если функционал Блокчейна и Биг Дата в какой-то момент объединится? Создают ли они вместе потенциал для социалистического преображения общества или напротив — укрепляют его фундамент?
Давайте для примера рассмотрим производство еды. Представьте себе будущее, в котором информация из каждого холодильника незримо сливается в блокчейн, чтобы впоследствии точно и прозрачно предсказывать продовольственные потребности целого государства.
Параметры вашего потребления молока в сочетании с информацией о складских запасах магазинов заранее сообщат сельхозпроизводителям, каковы потребности рынка. Предприятия будут точно знать, сколько молока, сыра, йогурта и сметаны необходимо произвести.
Такая осведомленность на государственном уровне расчищает площадку, создает условия для наступления социализма. Появляется возможность точнейшего распределения ресурсов и одномоментного производства, которые сделают весь процесс намного более эффективным, чем если бы он основывался на годовых статистических прогнозах.
Больше того, такое планирование будет эффективнее, чем рыночное. Вдумайтесь — сегодня по дороге от фермы до холодильника мы теряем около трети производимого продовольствия. В масштабах планеты это около триллиона долларов ежегодно.
Впрочем, та же самая осведомленность, если обладать ей будет не государство, а рыночные агенты, может сделать капитализм в равной степени эффективным.
Если улучшается центральное планирование, нет необходимости уничтожать рыночную среду и обобществлять ферму или завод. Все зависит от того, как эти технологии будут использоваться.
Точно так же, как ОПЕК поступает с нефтью; Facebook, Google, Microsoft, Apple, Amazon и другие, скорее всего, постараются защитить свои конкурентные преимущества, создавая барьеры для распространения информации и доступа к ней.
Именно здесь и вступает в игру Блокчейн. С его помощью можно создать публичные, прозрачные и распределенные базы данных, где БигДэйта будет по факту анонимна — то есть обобществлена. В Блокчейне наши личные данные становятся достоянием всех и вся, а не собственностью элитарной группы избранных, стремящихся извлекать свою выгоду.
Конечно, большие компании не расстанутся добровольно со своими базами данных. Поэтому государство должно будет снижать барьеры для доступа к информации, быть может, законодательно закрепив право пользователей скачивать свою личную информацию в легко читаемом формате. Но едва ли государства пойдут на это без общественной поддержки или давление.
Все это, конечно, нельзя назвать рецептом для революции, но есть все основания считать Блокчейн и БигДэйта важными инструментами для обеспечения доступа к информации и перераспределения богатства.
Одновременно — независимо от крупных компьютерных корпораций — капиталисты всего мира тоже наверняка оценят мощный потенциал этих технологий в ускорении процесса творческого разрушения, столь важного для любой рыночной экономики.
Подведем итог
Сами по себе Блокчейн и БигДата представляют идеологически нейтральные явления — не положительные и не отрицательные. Как и всегда, способ применения этих технологий зависит в первую очередь от устремлений и убеждений тех людей, в чьих руках они оказались. То есть каждый вариант возможен. Но в любом случае будущее, в котором информация приносит пользу, требует нашего коллективного действия и надзора.
Из зарубежных источников
1ethereum.ru
Принципы работы с большими данными, парадигма MapReduce / DCA (Data-Centric Alliance) corporate blog / Habr
Привет, Хабр! Этой статьёй я открываю цикл материалов, посвящённых работе с большими данными. Зачем? Хочется сохранить накопленный опыт, свой и команды, так скажем, в энциклопедическом формате – наверняка кому-то он будет полезен.
Проблематику больших данных постараемся описывать с разных сторон: основные принципы работы с данными, инструменты, примеры решения практических задач. Отдельное внимание окажем теме машинного обучения.
Начинать надо от простого к сложному, поэтому первая статья – о принципах работы с большими данными и парадигме MapReduce.
История вопроса и определение термина
Термин Big Data появился сравнительно недавно. Google Trends показывает начало активного роста употребления словосочетания начиная с 2011 года (ссылка):
При этом уже сейчас термин не использует только ленивый. Особенно часто не по делу термин используют маркетологи. Так что же такое Big Data на самом деле? Раз уж я решил системно изложить и освятить вопрос – необходимо определиться с понятием.
В своей практике я встречался с разными определениями:
· Big Data – это когда данных больше, чем 100Гб (500Гб, 1ТБ, кому что нравится)
· Big Data – это такие данные, которые невозможно обрабатывать в Excel
· Big Data – это такие данные, которые невозможно обработать на одном компьютере
И даже такие:
· Вig Data – это вообще любые данные.
· Big Data не существует, ее придумали маркетологи.
В этом цикле статей я буду придерживаться определения с wikipedia:
Большие данные (англ. big data) — серия подходов, инструментов и методов обработки структурированных и неструктурированных данных огромных объёмов и значительного многообразия для получения воспринимаемых человеком результатов, эффективных в условиях непрерывного прироста, распределения по многочисленным узлам вычислительной сети, сформировавшихся в конце 2000-х годов, альтернативных традиционным системам управления базами данных и решениям класса Business Intelligence.
Таким образом под Big Data я буду понимать не какой-то конкретный объём данных и даже не сами данные, а методы их обработки, которые позволяют распредёлено обрабатывать информацию. Эти методы можно применить как к огромным массивам данных (таким как содержание всех страниц в интернете), так и к маленьким (таким как содержимое этой статьи).
Приведу несколько примеров того, что может быть источником данных, для которых необходимы методы работы с большими данными:
· Логи поведения пользователей в интернете
· GPS-сигналы от автомобилей для транспортной компании
· Данные, снимаемые с датчиков в большом адронном коллайдере
· Оцифрованные книги в Российской Государственной Библиотеке
· Информация о транзакциях всех клиентов банка
· Информация о всех покупках в крупной ритейл сети и т.д.
Количество источников данных стремительно растёт, а значит технологии их обработки становятся всё более востребованными.
Принципы работы с большими данными
Исходя из определения Big Data, можно сформулировать основные принципы работы с такими данными:
1. Горизонтальная масштабируемость. Поскольку данных может быть сколь угодно много – любая система, которая подразумевает обработку больших данных, должна быть расширяемой. В 2 раза вырос объём данных – в 2 раза увеличили количество железа в кластере и всё продолжило работать.
2. Отказоустойчивость. Принцип горизонтальной масштабируемости подразумевает, что машин в кластере может быть много. Например, Hadoop-кластер Yahoo имеет более 42000 машин (по этой ссылке можно посмотреть размеры кластера в разных организациях). Это означает, что часть этих машин будет гарантированно выходить из строя. Методы работы с большими данными должны учитывать возможность таких сбоев и переживать их без каких-либо значимых последствий.
3. Локальность данных. В больших распределённых системах данные распределены по большому количеству машин. Если данные физически находятся на одном сервере, а обрабатываются на другом – расходы на передачу данных могут превысить расходы на саму обработку. Поэтому одним из важнейших принципов проектирования BigData-решений является принцип локальности данных – по возможности обрабатываем данные на той же машине, на которой их храним.
Все современные средства работы с большими данными так или иначе следуют этим трём принципам. Для того, чтобы им следовать – необходимо придумывать какие-то методы, способы и парадигмы разработки средств разработки данных. Один из самых классических методов я разберу в сегодняшней статье.
MapReduce
Про MapReduce на хабре уже писали (раз, два, три), но раз уж цикл статей претендует на системное изложение вопросов Big Data – без MapReduce в первой статье не обойтись J
MapReduce – это модель распределенной обработки данных, предложенная компанией Google для обработки больших объёмов данных на компьютерных кластерах. MapReduce неплохо иллюстрируется следующей картинкой (взято по ссылке):
MapReduce предполагает, что данные организованы в виде некоторых записей. Обработка данных происходит в 3 стадии:
1. Стадия Map. На этой стадии данные предобрабатываются при помощи функции map(), которую определяет пользователь. Работа этой стадии заключается в предобработке и фильтрации данных. Работа очень похожа на операцию map в функциональных языках программирования – пользовательская функция применяется к каждой входной записи.
Функция map() примененная к одной входной записи и выдаёт множество пар ключ-значение. Множество – т.е. может выдать только одну запись, может не выдать ничего, а может выдать несколько пар ключ-значение. Что будет находится в ключе и в значении – решать пользователю, но ключ – очень важная вещь, так как данные с одним ключом в будущем попадут в один экземпляр функции reduce.
2. Стадия Shuffle. Проходит незаметно для пользователя. В этой стадии вывод функции map «разбирается по корзинам» – каждая корзина соответствует одному ключу вывода стадии map. В дальнейшем эти корзины послужат входом для reduce.
3. Стадия Reduce. Каждая «корзина» со значениями, сформированная на стадии shuffle, попадает на вход функции reduce().
Функция reduce задаётся пользователем и вычисляет финальный результат для отдельной «корзины». Множество всех значений, возвращённых функцией reduce(), является финальным результатом MapReduce-задачи.
Несколько дополнительных фактов про MapReduce:
1) Все запуски функции map работают независимо и могут работать параллельно, в том числе на разных машинах кластера.
2) Все запуски функции reduce работают независимо и могут работать параллельно, в том числе на разных машинах кластера.
3) Shuffle внутри себя представляет параллельную сортировку, поэтому также может работать на разных машинах кластера. Пункты 1-3 позволяют выполнить принцип горизонтальной масштабируемости.
4) Функция map, как правило, применяется на той же машине, на которой хранятся данные – это позволяет снизить передачу данных по сети (принцип локальности данных).
5) MapReduce – это всегда полное сканирование данных, никаких индексов нет. Это означает, что MapReduce плохо применим, когда ответ требуется очень быстро.
Примеры задач, эффективно решаемых при помощи MapReduce
Word Count
Начнём с классической задачи – Word Count. Задача формулируется следующим образом: имеется большой корпус документов. Задача – для каждого слова, хотя бы один раз встречающегося в корпусе, посчитать суммарное количество раз, которое оно встретилось в корпусе.
Решение:
Раз имеем большой корпус документов – пусть один документ будет одной входной записью для MapRreduce–задачи. В MapReduce мы можем только задавать пользовательские функции, что мы и сделаем (будем использовать python-like псевдокод):
|
|
Функция map превращает входной документ в набор пар (слово, 1), shuffle прозрачно для нас превращает это в пары (слово, [1,1,1,1,1,1]), reduce суммирует эти единички, возвращая финальный ответ для слова.
Обработка логов рекламной системы
Второй пример взят из реальной практики Data-Centric Alliance.
Задача: имеется csv-лог рекламной системы вида:
<user_id>,<country>,<city>,<campaign_id>,<creative_id>,<payment></p>
11111,RU,Moscow,2,4,0.3
22222,RU,Voronezh,2,3,0.2
13413,UA,Kiev,4,11,0.7
…
Необходимо рассчитать среднюю стоимость показа рекламы по городам России.
Решение:
|
|
Функция map проверяет, нужна ли нам данная запись – и если нужна, оставляет только нужную информацию (город и размер платежа). Функция reduce вычисляет финальный ответ по городу, имея список всех платежей в этом городе.
Резюме
В статье мы рассмотрели несколько вводных моментов про большие данные:
· Что такое Big Data и откуда берётся;
· Каким основным принципам следуют все средства и парадигмы работы с большими данными;
· Рассмотрели парадигму MapReduce и разобрали несколько задач, в которой она может быть применена.
Первая статья была больше теоретической, во второй статье мы перейдем к практике, рассмотрим Hadoop – одну из самых известных технологий для работы с большими данными и покажем, как запускать MapReduce-задачи на Hadoop.
В последующих статьях цикла мы рассмотрим более сложные задачи, решаемые при помощи MapReduce, расскажем об ограничениях MapReduce и о том, какими инструментами и техниками можно обходить эти ограничения.
Спасибо за внимание, готовы ответить на ваши вопросы.
Youtube-Канал автора об анализе данных
Ссылки на другие части цикла:
Часть 2: Hadoop
Часть 3: Приемы и стратегии разработки MapReduce-приложений
Часть 4: Hbase
habr.com
Биг Брейн — Червепедия
| Биг Брейн | |
 | |
| Имя: | Максим Захаров |
| Дата рождения: | 13.08.1983 (35 лет) |
| Род деятельности: | Стример |
big_brain (русс. Биг Брейн) – коллега Дмитрия Киселёва, соведущий тетралогии «Тошнольгия». Заторможен, но эксцентричен, не стесняется обильно использовать ненормативную лексику. Ранее отметился чередой зело психоделических обзоров, за что был удостоен первого места в Киселёвском топе худших обзорщиков. Так они, собственно, и познакомились. Именно благодаря такому вот пиару со стороны Киселёва (а также Мэддисона) Брейн и стал более-менее известен. В их творческом дуэте Брейн отыгрывает роль потешного дурачка, на которого сквозь фейспалм смотрит его гораздо более интеллектуально одаренный напарник. Киселёв же, в свою очередь, несколько увлекается гнусными подколками своего тормознутого товарища, перебивая и высмеивая его по каждому удобному случаю.
Звёздный час Брейна наступил в третьем выпуске «Тошнольгии», где он просто паровым катком проехался по наиболее явным Кинамано- и АВГНоподражателям. Зрителям явно пришелся по нраву этот концентрированный поток ненависти, не разбодяженный обычными Киселёвскими заумствованиями (самого Дмитрия в ролике почти нет, он появляется лишь в конце), отчего многие считают эту «Тошнольгию», пожалуй, самой доставляющей из всех четырёх.
Интересные факты[править]
- Одной из жертв Брейна в «Тошнольгии 3» стал некий Aneekes, который позже стал частым гостем Червестримов, проходя игры пока Максим энд сотоварищи увлекательно зачесывали о последних тенденциях Кинамании;
- Некоторое время раздавал торренты одной известной личности в интернете под псевдонимом Иван Гамаз. Но спустя 2 года «дружбы» ему это надоело. После чего Гамаз записал критику на Биг Брейна, за что последний слил в сеть постыдные видео Гамаза, в одном из которых Иван Гамаз дрочит на срущих коров (в других видео он срал). За это Брейна заклеймили педофилом, выяснив, что тот очень тесно общался с Гамазом и присылал ему порно в обмен на видео с дрочкой. Гамаз хотя и выглядел лет на 14-15 в действительности был взрослым (1990 года рождения). Хотя это и снимает с Брейна обвинения в педофилии, но пидорасом он этого быть не перестает;
- В одном из роликов обозвал Кинамана мумией, чем и доставил. Есть мнение, что Брейн только зачитал текст, написанный Киселёвым.
Ссылки
chervepedia.com