«Царём горы» среди поисковых систем уже больше десятилетия остаётся Google. По данным Comscore, за два последних месяца 2012 года этот поисковик обработал 114,7 млрд запросов — это соответствует 65,2% мирового рынка поиска. Показатели ближайшего конкурента, китайского Baidu, в восемь раз меньше. Да что там говорить, у психологов даже специальный термин есть — Google Effect: современным людям, оказывается, проще не запоминать факты, а в нужный момент отыскать их в интернете.
Такая популярность означает, что размеры поискового индекса Google не просто огромны: они трудновообразимы. Не все осознают, что когда мы вводим в поисковую строку насущный для нас запрос, то обращаемся к одному из самых крупных хранилищ данных в мире. Ещё поразительнее другое: для того чтобы отыскать в петабайтах информации ответ на наш запрос, Google хватает доли секунды. Вот уж где «большие данные» в действии!
Как же поисковая система, стартовавшая со значительным отставанием от прежних лидеров рынка, «докатилась» до такого могущества?
Конечно же, дело тут не только в процессе поиска ресурсов, но и в инфраструктуре. И вот в этой области разработчики Google не просто совершили прорыв. Решения, впервые использованные поисковой системой, стали стандартом де-факто для множества успешных компаний, которым приходится ворочать огромными массивами зачастую слабоструктурированных данных. Тех самых Big Data.
Свой путь
Молодо-зелено. Когда в 1998 году Сергей Брин и Ларри Пейдж представили на суд университетской общественности Стэнфорда статью «Анатомия крупномасштабной поисковой системы», они были весьма скромны в прогнозах, связанных с потенциальным объёмом обрабатываемых их детищем данных.
В приложении к статье они пытаются оценить масштабы задачи, которая стоит перед поисковой системой. Предположим, системе необходимо проиндексировать всё, что жители США (на тот момент — примерно 250 миллионов душ) способны написать в интернете за целый год. Пусть каждый американец каждый день строчит в Сети по 10 килобайтов текста. Это означает, что поисковику понадобится пропустить через себя около 850 терабайт информации.
По расчётам будущих миллиардеров, если общеизвестный закон Мура продолжит действовать, то централизованная вычислительная система, способная обработать такой массив данных и доступная по цене даже небольшим компаниям, появится в лучшем случае через пятнадцать лет. Именно поэтому статья завершается выводом, что будущее — за распределёнными системами индексации. При этом Пейдж и Брин сетуют, что убедить мир использовать для поиска распределённые системы очень сложно. Уж больно велики расходы на администрирование множества узлов, из которых они состоят.
Цифры, обсуждаемые в статье, значительно превосходили возможности тогдашнего Google. Маленький кластер поисковика, располагающийся в университетском кампусе, хранил всего лишь 24 миллиона страниц и индексную базу. В ближайшей перспективе у парней была цель увеличить этот объём до ста миллионов страниц. Дальше они не загадывали и, скорее всего, даже представить не могли, что спустя пятнадцать лет их детище будет обрабатывать невероятные 24 петабайта данных в день.
В немалой степени уникальная производительность Google связана с тем самым предположением, согласно которому будущее поиска — за распределёнными вычислителями.
Такие компании, как Hewlett-Packard и Dell, поставляли на рынок продуманные реализации высокопроизводительных и отказоустойчивых кластеров. Вот только гугловцы, развивая свою систему, не воспользовались ими. Отчасти из-за дороговизны, но в большей степени на это решение повлияли результаты тщательных исследований, к которым в Google привлекли лучших специалистов. Эти исследователи и продемонстрировали, что с информационным девятым валом лучше справится массив относительно недорогих компьютеров, работающих под управлением системы с открытыми исходниками, — например, Linux.
Однако для того, чтобы это действительно произошло, буквально во всем придется уйти от существовавших на тот момент стандартов и представлений.
Серверы Google
Когда Google начал стремительно обходить по эффективности поиска существующие поисковики, стало ясно: у команды Брина и Пейджа действительно все получилось. При этом ребята не напускали на свои деяния туман, а активно рассказывали о посетивших их идеях на страницах научных публикаций.
Что же удалось сотворить команде Google?
Её самым важным достижением является построение архитектурной пирамиды своего детища — аппаратно-программной структуры системы хранения и индексирования веб-контента, допускающей практически неограниченное масштабирование.
В основании пирамиды лежит кластерный массив, единичным узлом которого был недорогой и далеко не лучший по надёжности компьютер — сервер Google. Его архитектура была разработана в 2005 году талантливым Беном Джеем (Ben Jai). Своё детище, до поры хранившееся в секрете, Бен называл «манхэттенским проектом» Google — и неспроста. В то время как дорогостоящие отказоустойчивые кластеры использовали сложные системы резервного питания, каждый из серверов Google толщиной в 3,5 дюйма (2U в стоечной терминологии) нёс на борту… собственную двенадцативольтовую батарейку.
Абсурд? Отнюдь. Использование в качестве резервного источника питания не централизованной системы бесперебойного питания, а недорогих батарей, монтируемых прямо на сервере, многократно снизило затраты на аппаратную составляющую империи Google. Договориться с поставщиком материнских плат (на первых порах эту роль играла компания Gigabyte) о небольшой модификации блока распределения напряжения оказалось куда дешевле, чем городить отработанные кем-то решения по резервированию питания.
Если бы не дешёвое «железо», Google не смог бы расти с такой скоростью. Вскоре у компании насчитывалось несколько сотен тысяч серверов. Центры обработки данных Google росли как грибы после дождя. В них монтировали сотни стандартных морских контейнеров, каждый из которых «упаковывался» стойками, содержащими 1 160 серверов. Один такой контейнерный узел потреблял 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 был свой взгляд и на это. Почему бы не использовать один и тот же кластер для хранения контента и для создания индекса?
Именно поэтому архитектура файловой системы GFS и технология MapReduce в кластере Google бесшовно интегрированы между собой. Как по блокам обрабатываемых данных (64 мегабайта), так и в вопросах совместной работы централизованных планировщиков файловой системы и системы индексирования.
На этом список инноваций Google в области технологий для работы с «большими данными» не заканчивается. Мы так и не затронули базу данных BigTable, послужившую главным источником вдохновения для разработчиков систем хранения данных NoSQL. Да и MapReduce или GFS стоит рассмотреть поподробнее. Именно этим мы и займёмся в следующих статьях.