1. Свій шлях
2. сервери Google
3. Google File System
4. MapReduce

"Царем гори" серед пошукових систем вже більше десятиліття залишається Google. За даними Comscore, за два останніх місяці 2012 року цей пошуковик обробив 114,7 млрд запитів - це відповідає 65,2% світового ринку пошуку. Показники найближчого конкурента, китайського Baidu, у вісім разів менше. Так що там говорити, у психологів навіть спеціальний термін є - Google Effect : Сучасним людям, виявляється, простіше не запам'ятовувати факти, а в потрібний момент відшукати їх в інтернеті.

Така популярність означає, що розміри пошукового індексу Google не просто величезні: вони трудновообразіми. Не всі усвідомлюють, що коли ми вводимо в пошуковий рядок насущний для нас запит, то звертаємося до одного з найбільших сховищ даних в світі. Ще більш вражаючим інше: для того щоб відшукати в петабайт інформації відповідь на наш запит, Google вистачає частки секунди. Ось вже де "великі дані" в дії!

Архітектура типової пошукової системи. Сховища контенту і індексної бази в ній грають найважливішу роль.

Як же пошукова система, яка стартувала зі значним відставанням від колишніх лідерів ринку, «докотилася» до такого могутності?

Звичайно ж, справа тут не тільки в процесі пошуку ресурсів, але і в інфраструктурі. І ось в цій області розробники Google не просто зробили прорив. Рішення, вперше використані пошуковою системою, стали стандартом де-факто для безлічі успішних компаній, яким доводиться перевертати величезними масивами найчастіше слабоструктурованих даних. Тих самих Big Data.

Свій шлях

Молодо-зелено. Коли в 1998 році Сергій Брін і Ларрі Пейдж представили на суд університетської громадськості Стенфорда статтю « Анатомія великомасштабної пошукової системи », Вони були вельми скромні в прогнозах, пов'язаних з потенційним обсягом оброблюваних їх дітищем даних.

У додатку до статті вони намагаються оцінити масштаби завдання, яке стоїть перед пошуковою системою. Припустимо, системі необхідно проіндексувати все, що жителі США (на той момент - приблизно 250 мільйонів душ) здатні написати в інтернеті за цілий рік. Нехай кожен американець щодня строчить в Мережі по 10 кілобайт тексту. Це означає, що пошуковику знадобиться пропустити через себе близько 850 терабайт інформації.

За розрахунками майбутніх мільярдерів, якщо загальновідомий закон Мура продовжить діяти, то централізована обчислювальна система, здатна обробити такий масив даних і доступна за ціною навіть невеликим компаніям, з'явиться в кращому випадку через п'ятнадцять років. Саме тому стаття завершується висновком, що майбутнє - за розподіленими системами індексації. При цьому Пейдж і Брін нарікають, що переконати світ використовувати для пошуку розподілені системи дуже складно. Аж надто великі витрати на адміністрування безлічі вузлів, з яких вони складаються.

Цифри, обговорювані в статті, значно перевершували можливості тодішнього Google. Маленький кластер пошукача, що розташовується в університетському кампусі, зберігав лише 24 мільйони сторінок і індексну базу. У найближчій перспективі у хлопців була мета збільшити цей обсяг до ста мільйонів сторінок. Далі вони не загадували і, швидше за все, навіть уявити не могли, що через п'ятнадцять років їх дітище буде обробляти неймовірні 24 петабайта даних в день.

Кластер Google. Від наколенного варіанту в університетському кампусі до гігантських серверних ферм.

У чималому ступені унікальна продуктивність Google пов'язана з тим самим припущенням, згідно з яким майбутнє пошуку - за розподіленими обчислювачами.

Такі компанії, як Hewlett-Packard і Dell, поставляли на ринок продумані реалізації високопродуктивних і стійких до відмов кластерів. Ось тільки гугловці, розвиваючи свою систему, не скористалися ними. Почасти через дорожнечу, але більшою мірою на це рішення вплинули результати ретельних досліджень, до яких в Google залучили кращих фахівців. Ці дослідники і продемонстрували, що з інформаційним дев'ятим валом краще впорається масив недорогих комп'ютерів, що працюють під управлінням системи з відкритим кодом, - наприклад, Linux.

Однак для того, щоб це дійсно відбулося, буквально у всьому доведеться піти від існуючих на той момент стандартів і уявлень.

сервери Google

Коли Google почав стрімко обходити по ефективності пошуку існуючі пошукові системи, стало ясно: у команди Бріна і Пейджа дійсно все вийшло. При цьому хлопці не напускали на свої діяння туман, а активно розповідали про відвідали їх ідеях на сторінках наукових публікацій.

Що ж вдалося створити команді Google?

Її найважливішим досягненням є побудова архітектурної піраміди свого дітища - апаратно-програмної структури системи зберігання та індексування веб-контенту, що допускає практично необмежену масштабування.

Ось вона, технологічна піраміда Google.

В основі піраміди лежить кластерний масив, одиничним вузлом якого був недорогий і далеко не кращий за надійністю комп'ютер - сервер Google. Його архітектура була розроблена в 2005 році талановитим Беном Джеєм (Ben Jai). Своє дітище, до пори зберігалося в секреті, Бен називав «манхеттенським проектом» Google - і неспроста. У той час як дорогі відмовостійкі кластери використовували складні системи резервного живлення, кожен з серверів Google товщиною в 3,5 дюйма (2U в стоечной термінології) ніс на борту ... власну двенадцатівольтових батарейку.

Абсурд? Ні в якому разі. Використання в якості резервного джерела живлення не централізованої системи безперебійного живлення, а недорогих батарей, що монтуються прямо на сервері, багаторазово знизило витрати на апаратну складову імперії Google. Домовитися з постачальником материнських плат (на перших порах цю роль грала компанія Gigabyte) про невелику модифікації блоку розподілу напруги виявилося куди дешевше, ніж городити відпрацьовані кимось рішення щодо резервування харчування.

Недорогий стієчний сервер Google з батарейкою на борту.

Якби не дешеве "залізо", 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.

У світі великих ІТ-систем було прийнято довіряти надійне зберігання даних спеціально сконструйованим отказоустройчівим кластерам-сховищ, а операції над ними робити за допомогою спеціальних же високопродуктивних кластерів-обчислювачів. Але у Google був свій погляд і на це. Чому б не використати один і той же кластер для зберігання контенту і для створення індексу?

Саме тому архітектура файлової системи GFS і технологія MapReduce в кластері Google бесшовно інтегровані між собою. Як по блокам оброблюваних даних (64 мегабайта), так і в питаннях спільної роботи централізованих планувальників файлової системи і системи індексування.

На цьому список інновацій Google в області технологій для роботи з "великими даними" не закінчується. Ми так і не торкнулися базу даних BigTable, яка послужила головним джерелом натхнення для розробників систем зберігання даних NoSQL. Та й MapReduce або GFS варто розглянути детальніше. Саме цим ми і займемося в наступних статтях.