/ фото Jason Tester Guerrilla Futures CC
Компания IDC сообщает, что в 2011 году человечеством было сгенерировано 1,8 зеттабайт информации. В 2012 году эта цифра составила уже 2,8 зеттабайт, а к 2020 она увеличится до 40 зеттабайт.
Существенную часть этих данных генерируют крупные мировые компании, такие как Google, Facebook, Apple. Им нужно не просто хранить данные, но и выполнять резервное копирование, следить за их актуальностью, обрабатывать, причем делать это с минимальными затратами. Поэтому ИТ-отделы крупных организаций разрабатывают собственные системы для решения этих задач.
По словам Шона Галлахера (Sean Gallagher), редактора Ars Technica, компания Google стала одним из первых веб-игроков, кто встретил проблему масштабирования хранилищ грудью. Ответ на вопрос компания нашла еще в 2003 году, разработав распределенную файловую систему – Google File System (GFS).
Если верить исследователю Санджаю Гхемавату (Sanjay Ghemawat) и старшим инженерам Говарду Гобиоффу (Howard Gobioff) и Шунь-Так Лэуну (Shun-Tak Leung) из Google, то GFS разработана с определенной спецификой. Её цель – превратить огромное количество дешевых серверов и жестких дисков в надежное хранилище для сотен терабайт данных, к которым имеют доступ множество приложений одновременно.
GSF является основой практически всех облачных сервисов Google. Google хранит данные приложений в огромных файлах, в которые сотни машин дописывают информацию одновременно. Более того, запись в файл может вестись прямо в тот момент, когда с ним ведется работа.
Система содержит мастер-серверы и серверы фрагментов (chunkservers), которые хранят данные. Обычно GFS-кластер состоит из одной главной мастер-машины и множества серверов фрагментов. Файлы в GFS разбиваются на куски с фиксированным, но настраиваемым размером, которые серверы фрагментов хранят как Linux-файлы на локальном жестком диске (однако для повышения надежности каждый фрагмент дополнительно реплицируется на другие серверы).
Что касается мастера, то он отвечает за работу с метаданными и контролирует всю глобальную деятельность системы: управление фрагментами, сборка мусора, перемещение фрагментов между серверами и т. д.
Одной из главных проблем подобной системы значатся частые сбои в работе её компонентов, поскольку она строится на базе большого количества дешевого оборудования. Сбой может быть вызван как недоступностью элемента системы, так и наличием испорченных данных. Но в Google были к этому готовы, поэтому GFS постоянно мониторит компоненты и в случае отказа какого-либо из них принимает необходимые меры для поддержания работоспособности системы.
Поврежденные фрагменты определяются при помощи вычисления контрольных сумм. Каждый кусок разбивается на блоки по 64 КБ с 32-битной контрольной суммой. Как и другие метаданные эти суммы хранятся в памяти и регулярно пишутся в логи отдельно от данных пользователя.
За все время существования GFS платформа Google развивалась и адаптировалась под новые требования, у поисковика появлялись новые сервисы. Получилось так, что размеры кластеров в GFS перестали подходить для эффективного хранения всех типов данных. К 2010 году исследователи компании изучили достоинства и недостатки GFS и применили приобретённые знания для создания новых программных систем.
Так на свет появились распределенная файловая система Colossus (GFS2), Spanner (развитие BigTable) – масштабируемое геораспределенное хранилище с поддержкой версионности данных, масштабируемая система обработки запросов Dremel, Caffeine – инфраструктура поисковых сервисов Google, использующая GFS2, итеративный MapReduce и next-generation BigTable, и др. Сегодня они решают более сложные задачи и обрабатывают большее количество информации, открывая новые возможности.
Однако с большими объемами данных «сражается» не только Google. Необычный подход к хранению данных и репликации нашла компания Uber. Вместо того чтобы постоянно синхронизировать базу данных между ЦОДами, специалисты сервиса по предоставлению автомобилей решили организовать внешнюю распределенную систему из телефонов водителей.
В компании отмечают, что главная цель этого решения – повышение отказоустойчивости. Такой подход надежно защищает данные от сбоев в дата-центрах. При использовании классической стратегии репликации гарантировать сохранение информации о поездке было сложно из-за особенностей систем управления сетями.
Обычное решение при сбоях в ЦОДе – передать данные с активного дата-центра на резервный, однако при наличии более чем двух ЦОДов сложность инфраструктуры резко возрастает, возникает задержка репликации между дата-центрами и требуется высокая скорость соединения.
В случае Uber, если в дата-центре произойдет какая-либо ошибка, информация о поездке всегда сохранится на мобильном устройстве водителя. Поскольку смартфон обладает самыми актуальными данными, то именно с него актуальная информация поступает в ЦОД, а не наоборот.
Мобильные телефоны водителей отправляют данные каждые 4 секунды. «По этой причине перед Uber стояла задача обработки миллионов операций записи в секунду», – отметил Мэтт Рэнни (Matt Ranney), главный разработчик архитектуры системы Uber, в ходе презентации о масштабировании платформы.
Весь процесс выглядит следующим образом. Водитель обновляет свой статус, например, в тот момент, когда забирает пассажира, и отправляет запрос в службу диспетчеризации. Последняя обновляет модель поездки и оповещает об этом службу репликации. Когда репликация выполнена, диспетчер обновляет хранилище данных и сообщает мобильному клиенту об успешном завершении операции.
В это же время служба репликации кодирует информацию и передает её службе обмена сообщениями, поддерживающей двунаправленный канал связи с водителями. Этот канал никак не связан с исходным каналом запросов, поэтому процессы восстановления данных не влияют на бизнес-процессы. Далее служба обмена сообщениями отправляет резервную копию на телефон.
«Цифровая платформа Uber агрегирует поразительное количество данных, – отметил Тайлер Джеймс Джонсон (Tyler James Johnson) в Convergent Technology Advisors. – Карты, маршруты, информация о предпочтениях клиентов, связи – это лишь малая часть содержимого хранилищ Uber. Компания много инвестирует в развитие цифровых технологий. Данные – это основа всего».
Эти данные важно сохранить, поскольку они пригодятся компании в будущем. Не за горами появление автопилотируемых автомобилей. Компания Gartner предсказывает, что одна из пяти машин в мире будет обладать беспроводным подключением уже к 2020 году, а это, на секундочку, 250 миллионов подключенных транспортных средств.
Пока что лидером на этом рынке остается Google, но параллельно с технологическим гигантом над подобными системами работают Tesla, Ford, Apple. Не отстает и Uber. У компании имеется Центр разработки передовых технологий, который работает в партнерстве с Университетом Карнеги – Меллона в Питтсбурге. В нем разрабатывают умные автомобили и другие технологии, способные помочь компании повысить качество предоставляемых сервисов и снизить их стоимость.
«Увеличение объемов создаваемого и потребляемого цифрового контента приведет к необходимости создания новых более сложных информационных систем, – сказал Джеймс Хайнс (James Hines), руководитель исследований в Gartner. – В то же время применение этих технологий в автосфере приведет к появлению новых бизнес-моделей и подходов к владению автомобилями в городской среде».
Автор: 1cloud.ru
