Как в Google научились обрабатывать сотни петабайтов данных

Как в Google научились обрабатывать сотни петабайтов данных
«Царѐм горы» среди поисковых систем уже больше десятилетия остаѐтся Google. По
данным Comscore, за два последних месяца 2013 года этот поисковик обработал 114,7
млрд. запросов — это соответствует 65,2 процентам мирового рынка поиска.
Показатели ближайшего конкурента, китайского Baidu, в восемь раз меньше. Да что
там говорить, у психологов даже специальный термин есть – Google Effect:
современным людям, оказывается, проще не запоминать факты, а в нужный момент
отыскать их в интернете.
Такая популярность означает, что размеры поискового индекса Google не просто
огромны – они трудновообразимы. Не все осознают, что когда мы вводим в поисковую
строку насущный для нас запрос, то обращаемся к одному из самых крупных хранилищ
данных в мире. Ещѐ поразительнее другое: для того, чтобы отыскать в петабайтах
информации ответ на наш запрос, Google хватает доли секунды. Вот уж где ‖большие
данные‖ в действии!
Как же поисковая система, стартовавшая со значительным отставанием от прежних
лидеров рынка, «докатилась» до такого могущества?
Kонечно же, дело тут не только в процессе поиска ресурсов, но и в инфраструктуре. И
вот в этой области разработчики Google не просто совершили прорыв. Решения,
впервые использованные поисковой системой, стали стандартом де-факто для
множества успешных компаний, которым приходится ворочать огромными массивами
зачастую слабоструктурированных данных. Тех самых Big Data.
Свой путь
Молодо-зелено. Когда в 1998 году Сергей Брин и Ларри Пейдж представили на суд
университетской общественности Стэнфорда статью «Анатомия крупномасштабной
поисковой системы», они были весьма скромны в прогнозах, связанных с
потенциальным объемом обрабатываемых их детищем данных.
В приложении к статье они пытаются оценить масштабы задачи, которая стоит перед
поисковой системой. Предположим, системе необходимо проиндексировать всѐ, что
жители США (на тот момент — примерно 250 миллионов душ) способны написать в
интернете за целый год. Пусть каждый американец каждый день строчит в Сети по 10
килобайтов текста. Это означает, что поисковику понадобится пропустить через себя
около 850 терабайт информации.
По расчѐтам будущих миллиардеров, если общеизвестный закон Мура продолжит
действовать, то централизованная вычислительная система, способная обработать
такой массив данных и доступная по цене даже небольшим компаниям, появится в
лучшем случае через пятнадцать лет. Именно поэтому статья завершается выводом, что
будущее – за распределенными системами индексации. Правда, сетуют Пейдж и Брин,
убедить мир использовать для поиска распределенные системы очень сложно. Уж
больно велики расходы на администрирование множества узлов, из которых они
состоят.
Цифры, обсуждаемые в статье, значительно превосходили возможности тогдашнего
Google. Маленький кластер поисковика, располагающийся в университетском кампусе,
хранил всего лишь 24 миллиона страниц и индексную базу. В ближайшей перспективе
у парней была цель увеличить этот объем до ста миллионов страниц. Дальше они не
загадывали и, скорее всего, даже представить не могли, что спустя пятнадцать лет их
детище будет обрабатывать невероятные 24 петабайта данных в день.
Кластер Google. От наколенного варианта в университетском кампусе до гигантских серверных ферм.
В немалой степени уникальная производительность Google связана с тем самым
предположением, согласно которому будущее поиска — за распределенными
вычислителями.
Такие компании, как Hewlett-Packard и Dell, поставляли на рынок продуманные
реализации высокопроизводительных и отказоустойчивых кластеров. Вот только
гугловцы, развивая свою систему, не воспользовались ими. Отчасти из-за дороговизны,
но в большей степени на это решение повлияли результаты тщательных исследований,
к которым в Google привлекли лучших специалистов. Эти исследователи и
продемонстрировали, что с информационным девятым валом лучше справится массив
относительно недорогих компьютеров, работающих под управлением системы с
открытыми исходниками — например, Linux.
Однако для того, чтобы это действительно произошло, буквально во всем придется
уйти от существовавших на тот момент стандартов и представлений.
Серверы Google
Когда Google начал стремительно обходить по эффективности поиска существующие
поисковики, стало ясно: у команды Брина и Пейджа действительно все получилось.
При этом ребята не напускали на свои деяния туман, а активно рассказывали о
посетивших их идеях на страницах научных публикаций.
Что же удалось сотворить команде Google?
Еѐ самым важным достижением является построение архитектурной пирамиды своего
детища – аппаратно-программной структуры системы хранения и индексирования вебконтента, допускающей практически неограниченное масштабирование.
В основании пирамиды лежит кластерный массив, единичным узлом которого был
недорогой и далеко не лучший по надежности компьютер – сервер Google. Его
архитектура была разработана в 2005 году талантливым Беном Джеем (Ben Jai). Свое,
детище, до поры хранившееся в секрете, Бен называл «манхеттенским проектом»
Google — и неспроста. В то время как дорогостоящие отказоустойчивые кластеры
использовали сложные системы резервного питания, каждый из серверов Google
толщиной в 3,5 дюйма (2U в стоечной терминологии) нѐс на борту… собственную
двенадцативольтовую батарейку.
Абсурд? Отнюдь. Использование в качестве резервного источника питания не
централизованной системы бесперебойного питания, а недорогих батарей,
монтируемых прямо на сервере, многократно снизило затраты на аппаратную
составляющую империи Google. Договориться с поставщиком материнских плат (на
первых порах эту роль играла компания Gigabyte) о небольшой модификации блока
распределения напряжения оказалось куда дешевле, чем городить отработанные кем-то
решения по резервированию питания.
Если бы не дешѐвое «железо», Google не смог бы расти с такой скоростью. К 2004 году
у компании насчитывалось несколько сотен тысяч серверов. Центры обработки данных
Google росли, как грибы после дождя. В них монтировали сотни стандартных морских
контейнеров, каждый из которых «упаковывался» стойками, содержащими 1160
серверов. Один такой контейнерный узел потреблял 250 киловатт.
Использование в архитектуре сервера резервной батареи, конечно же, снижает
финансовые затраты. Но что насчет надежности такой системы? В случае сбоя питания
на одной батарейке сервер протянет считанные минуты.
И пусть. Ведь следующий архитектурный уровень пирамиды Google – это
распределенная файловая система Google File System (GFS), которая как раз и
рассчитана на работу в условиях, когда аппаратные и сетевые являются нормой, а не
чрезвычайной ситуацией.
Google File System
Почему в Google избрали трудоемкий путь разработки собственной файловой системы?
Почему нельзя быо использовать готовые распределѐнные файловые системы,
например, NFS и AFS? Все дело в специализации.
Да, NFS – замечательная, отлично масштабируемая файловая система. Но она является
системой общего назначения, нацеленной на работу с файлами размером от нескольких
байт до сотен терабайт. В отличие от неѐ, GFS имеет узкую специализацию, и
побеждает универсальные решения именно на тех задачах, которые нужны Google.
По сути дела, поисковик Google методично выполняет всего несколько операций:
складирует поступающий от веб-роботов контент, сжимает его и создает на его основе
индексную базу. Распределенная файловая система должна помогать ему делать это
быстро и эффективно.
Идеолог проекта Говард Гобьов и его коллеги впервые публично изложили суть GFS в
2003 году, удивив мир решением использовать в распределенной среде
централизованное планирование. Между тем, ничего удивительного у такого решения
нет. Для заведомо ненадежной аппаратной среды совсем не обязательно городить
сложный планировщик распределения массивов данных по серверам.
Алгоритм работы GFS настолько не вписывается в идеологию функционирования
традиционных файловых систем, что сервера Google, работающие под управлением
Linux, обращаются к ней в обход драйвера Linux Virtual File System, который обычно
используется в таких случаях. GFS трудится в системе особняком, и взаимодействовать
с ней приходится через еѐ собственный программный интерфейс.
Безусловно, реализация GFS на гигантском массиве недорогих серверов является
выдающимся решением. Но у архитектурной пирамиды Google есть еще один «козырь
в рукаве».
MapReduce
Эффективно хранить в распределенной и склонной к отказам среде поступающий
контент и получаемую на его основе индексную базу, конечно же, здорово, однако
самая суть работы любого поисковика – быстрый и экономичный алгоритм создания
индексной базы. Ведь, в конце концов, именно благодаря ему, наши ключевые слова в
строке поиска превращаются в ссылки на конкретные ресурсы.
И здесь у Google сложно отнять пальму первопроходца. Представленная в 2004 году
Джеффри Дином (Jeffrey Dean) и Санджаем Гемаватом (Sanjay Ghemawat) технология
обработки данных на больших кластерах, получившая название MapReduce,
фактически стала синонимом Big Data.
Позаимствовав идею распараллеливания линейной, в общем-то, задачи индексации у
таких языков функционального программирования, как Lisp и Haskell, разработчики
MapReduce добились того, что выполнение сложной задачи создания индексной базы
над распределенным массивом контента также стало выполняться распределенно.
MapReduce — это проприетарное решение, но идея, которая лежит в его основе,
настолько прозрачна и эффективна, что она немедленно была подхвачена другими
разработчиками. Наиболее популярной альтернативной реализацией этой технологии
является проект Hadoop, начатый в Yahoo и развиваемый сообществом Open Source.
В современном дата-центре Google
В мире больших ИТ-систем было принято доверять надѐжное хранение данных
специально сконструированным отказоустройчивым кластерам-хранилищам, а
операции над ними производить с помощью специальных же высокопроизводительных
кластеров-вычислителей. Но у Google был свой взгляд и на это. Почему бы не
использовать один и тот же кластер для хранения контента и для создания индекса?
Именно поэтому архитектура файловой системы GFS и технология MapReduce в
кластере Google бесшовно интегрированы между собой. Как по блокам
обрабатываемых данных (64 мегабайта), так и в вопросах совместной работы
централизованных планировщиков файловой системы и системы индексирования.
На этом список инноваций Google в области технологий для работы с ―большими
данными‖ не заканчивается. Мы так и не затронули базу данных BigTable,
послужившую главным источником вдохновения для разработчиков систем хранения
данных NoSQL. Да и MapReduce или GFS стоит рассмотреть поподробнее. Именно
этим мы и займѐмся в следующих статьях.