close

Вход

Забыли?

вход по аккаунту

?

Google Platform

код для вставкиСкачать
Google Platform. Введение
Вводная статья цикла «Google Platform»
Хранение и обработка данных – это задача, которую человечество с переменным
успехом решает ни одну тысячу лет. Проблемы, связанные с решением этой
задачи, связаны не только с физическим объемом данных (volume), но и со
скоростью изменчивости этих данных (velocity) и многообразием (variety)
источников данных – то, что аналитики Gartner в своих статьях [11, 12] обозначили
как «3V».
Количественные изменения в системе неизменно переходят в качественные [13].
Изобретение письменности, книгопечатанье, автоматизированные средства
обработки данных разумно рассматривать, как ответ на вызов, который ставит
проблема 3V.
Современная Computer Science сейчас встретилась с проблемой Больших данных,
решения которой от ИТ ждут частные компании, правительства, научное
сообщество (которое не занято в computer science).
Но в мире есть одна компания, которая встретилась с проблемой Big Data еще
порядка 10 лет назад. По моему ощущению (т.к. чтобы заявить достоверно нужны
открытые данные, которых в свободном доступе нет) ни одна коммерческая или
некоммерческая организация не оперирует большим объемом данных, чем эта
компании.
Именно эта компания являлась основным контрибьютором идей платформы
Hadoop, а также многих компонентов экосистемы Hadoop, таких как HBase, Apache
Giraph, Apache Drill.
Как Вы догадались, речь идет о Google.
В цикле статей, посвященном платформе Google будут рассмотрены внутренние
программные продукты Google, с помощью которых Google решает задачи
хранения, структурирования и поиска по данным, детектирования спама,
повышения эффективности показов рекламных объявлений в сервисах
контекстной рекламы, поддержания консистентности данных в социальной сети
Google+, etc.
Хронология Big Data в Google
Условно историю развития «Big Data»-решений в Google можно поделить на 2
периода:
1-ый период (2003-2008): в этот период были описаны набор принципов и
концепций, которые сейчас де-факто являются стандартом в мире обработки
больших объемов данных (на commodity-оборудовании).

2-ой период (с 2009 по настоящий момент): были описаны технологии
обработки данных, которые, с большой долей вероятности, будут использоваться
для решения «Big Data»-задач уже в недалеком будущем.

2003-2008
В этот период инженерами Google были описаны и опубликованы в свободном
доступе research papers о 3-ех системах, которые в Google используют для решения
своих задач:

распределенная файловая система Google File System (GFS) [1];
высокопроизводительная база данных Bigtable [3], ориентированная на
хранение петабайт данных;

программная модель MapReduce [2], предназначенная для распределенной
обработки больших объемов данных.

Влияние работ, опубликованных Google, на первые шаги становления отрасли Big
Data сложно переоценить.
Наиболее известным примером реализации концепций, описанных Google,
является платформа Hadoop. Так прототипом файловой системы HDFS является
GFS; идеи, положенные в основу архитектуры HBase, взяты из BigTable; а
фреймворк вычислений Hadoop MapReduce (без YARN) является реализацией
принципов, заложенных в аналогичном фреймворке Google MapReduce.
Сама платформа Hadoop с 2008 года в течение нескольких лет будет набирать
популярность и к 2010-2011 году де-факто станет стандартом для работы с
Большими Данными. Сейчас Hadoop уже «локомотив» в мире Big Data и оказывает
огромное влияние на этот сегмент ИТ. Но когда-то такое же огромное влияние на
Hadoop оказали описанные в Google архитектурные подходы к построению Big
Data платформы.
Сама же платформа Google все это время развивалась, адаптировалась под все
новые и новые требования, у поисковика появлялись новые сервисы, в том числе
те, чья природа соответствовала скорее интерактивному режиму обработки, чем
пакетному; размеры chunk’ов (кластеров в GFS) не подходили для эффективного
хранения не всех типов данных; появлялись требования, связанные с
геораспределеность и поддержкой распределенных транзакций.
Эти новый вызовы были приняты и успешно решались инженерами Google.
2009-2013
К 2009-2010 годам как в самой компании Google, так и в академической среде
достаточно подробно исследовали достоинства и ограничения комплекса
подходов для построения Big Data платформы, описанного инженерами Google в
период с 2003 по 2008 год. Да и сама платформа Google за период до 2009 года
развивалась и эволюционировала.
Итак, в (условно) 2-ой этап развития Big Data платформы в Google – 2009-2013 исследователями компании с разной степенью детализации были описаны
следующие программные системы:
Colossus (GFS2) – распределенная файловая система, являющаяся развитием
GFS [10].

Spanner – масштабируемое геораспределенное хранилище с поддержкой
версионности данных, являющийся развитием BigTable [8].

Dremel – масштабируемая система обработки запросов в режиме близком к
режиму реального времени (near-real-time), предназначенная для анализа
связанных read-only данных [4].

Percolator – платформа для инкрементальной обработки данных, которая
используется для обновления поисковых индексов Google [9].

Caffeine – инфраструктура поисковых сервисов Google, использующая GFS2,
next-generation (итеративный) MapReduce и next-generation BigTable [6].

Pregel – масштабируемая, отказоустойчивая и распределенная система
обработки графов [7].

Photon – масштабируемая, отказоустойчивая и геораспределенная система
обработки потоковых данных [5].

В последующих статьях цикла обзорно будут рассмотрены большинство из
вышеперечисленных систем, а также приведены наиболее интересные концепции,
заложенные в основу этих систем, и архитектурные подходы, реализующие эти
концепции.
Вместо заключения
Вместо заключения приведу цитату человека, который уже доказал свою
способность успешно предсказывать будущего отрасли Big Data, CEO Cloudera
Майка Олсона:
If you want to know what the large-scale, high-performance data processing
infrastructure future looks like, my advice would be to read the Google research papers
that are coming out right now.Mike Olson, Cloudera CEO
Google File System (GFS)
Статья из цикла «Google Platform»
Google File System (GFS) – распределенная файловая система (ФС) Google. Система является
проприетарной, по некоторым сведениям работа над GFS была начата еще в 2000 году; общие
принципы построения были довольно подробно описаны в документе [1], представленном на
ACM SIGOPS Operating Systems Review в 2003 году.
Архитектура
GFS предназначена для хранения больших объемов данных (петабайты). Файлы в ФС поделены на
куски фиксированного размера (в терминологии GFS – «chunk») по 64 Мб (в общем случае).
Файлы данных хранятся на Chunk-узлах (в терминологии GFS – «Chunkserver»). Chunkserver на
аппаратном уровне представляет commodity-оборудование. Поэтому (и не только поэтому) для
обеспечения надежного хранения данных данные в GFS автоматически реплицируются как
минимум трижды.
Кроме Chunkserver'ов в GFS есть единственный Master-сервер. Master представляет собой
вычислительный узел, ответственный за координацию и мониторинг Chunkserver'ов. По аналогии
с NameNode в HDFS, Master в GFS отвечает за:

работу с метаданными – пространства имен, file-to-chunk маппинг, информация о
доступе к данным;

операции над chunk'ами, в т.ч. сборка мусора («осиротевших» chunk’ов);

мониторинг Chunkserver'ов посредством hearbeat-сообщений.
Как и в случае с NameNode в HDFS, Master-узел в GFS является потенциальным «узким местом»
системы, имеет избыточное число ответственностей и является единичной точкой отказа.
Иллюстрация 1. Архитектура GFS. Источник иллюстрации [1]
Базовые принципы
Описанная архитектура полностью удовлетворяет принципам, заложенным инженерами Google в
GFS, а именно:
1. Аппаратные неисправности в кластерных системах нужно рассматривать как норму, а
не как исключение;
2. Данные уже имеют огромный размер и их объем будет только расти. Система вводаввода должна быть спроектирована с расчетом на размер данных, которыми она будет
оперировать;
3. Файлы изменяются путем добавления новых данных в конец файла, а не путем
переписывания существующих данных. Запись в произвольные места, как не
непоследовательное чтение данных из файла гипернеэффективны. Эффективно
использование подхода «write once, read many»;
4. Дизайн распределенной ФС, не должен полагаться на дизайн приложений, его
использующих. Т.о. файловая система должна знать минимальное количество сведений о
клиентах и характере операций над данными, которые эти клиенты осуществляют.
Особенности GFS
GFS разделяет потоки данных и потоки команд. Так, как показано на иллюстрации 1, потоки
команд проходят от Master к клиентам и от Master к Chunkserver’ам. В то время как потоки данных
проходят от Chunkserver к клиентам напрямую, минуя Master. Это позволяет увеличить
способность к масштабируемости всего GFS кластера в целом, т.к. Master не является «узким
местом» при обмене данными с клиентами.
Кроме «стандартных» для ФС команд: create, delete, open, close, read, write – GFS также
поддерживает операции snapshot и record append. Snapshot эффективно создает копию файла или
директории, а record append позволяет добавлять данные в конец файла одновременно
нескольким клиентам с гарантией атомарности изменений.
Выше я упоминал, что, как и во всех системах, построенных по архитектуре Master-Slave, Master
сервер в GFS является единичной точкой отказа. Для того, чтобы максимально нивелировать
влияние недоступности Master на общую доступность системы в GFS функционирует система
логгирования операций и checkpoint'ов (при достижении лога определенных объемов).
Кроме того, есть:

система мониторинга за доступностью Master;

«Shadow» Master, которые позволяет минимизировать время «поднятия» нового Master;

каноническое имя Master, по которому обращаются к Master-серверу клиенты, позволяет с
помощь DNS alias за максимально короткий срок переключить клиентов на новый Master.
Будущее и итоги
GFS – распределенная файловая система, оптимизированная для работы с большими наборами
данных. Система рассчитана на многопоточное добавление данных и их последовательное
чтение, а также поддерживает стандартные для файловых систем операции.
GFS является масштабируемой высокодоступный системой с надежным хранением данных.
Инновационные принципы и концепции, описанные в [1], легли в основу HDFS – open-source
распределенной файловой системы, ключевой компоненты платформы Hadoop.
В то же время, GFS имела как ряд недостатком, которые в конечном итоге влияли на возможность
масштабируемости и доступность системы, так и ряд принципиальных ограничений неспособность к геораспределенности, невозможность работать в real-time и/или near-real-time
режиме.
Хотя в 2013 GFS уже не выглядит системой без недостатков, но на момент описания ее в research
paper [1] в 2003 году она шла на шаг вперед своего времени. Обновленная версия GFS имеет
название Colossus [10]. О Colossus речь пойдет в одной из следующих статей из цикла.
Список источников*

[1] Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung. The Google File System. ACM SIGOPS
Operating Systems Review, 2003.

[10] Andrew Fikes. Storage Architecture and Challenges. Google Faculty Summit, 2010.
Bigtable. Хранилище для петабайтов данных Google
Статья из цикла «Google Platform»
Bigtable – высокопроизводительная база данных, реализующая колоночную схему хранения и
построенная на основе GFS и некоторых других внутренних продуктах Google. Как и GFS, Bigtable –
проприетарная система, внутреннее устройство которой, тем не менее, было подробно описано
инженерами Google в research paper [3].
Bigtable – хорошо масштабирующееся хранилище данных, рассчитанное на хранение
петабайтов информации и работающее на commodity-серверах. Bigtable работает на
production-серверах с 2005 года. В разное время в BigTable хранили данные web-индексов,
сервисов Google Analytics, Google Earth, Google Finance [3].
До появления Spanner и других более узкоспециализированных внутренних хранилищ данных в
Google, Bigtable «работал» с клиентами с крайне разнообразными требованиями как по объему
данных (от URL до снимков спутника), так и по задержки в ответе (от пакетных режимов до
режимов близких к реальному времени). В свою очередь клиенты определяли схему хранимых
структурированных/полуструктурированных данных.
Модель данных
Big Table представляет собой разреженную распределенную многомерную отсортированную
карту (оригинал [3] - sparse, distributed, persistent multidimensional sorted map). Карты
проиндексирована по ключу строки (row key), ключу столбца (column key) и временной метке
(timestamp).
1. (row:string, column:string, timestamp:int64) -> string
На основе лексикографического анализа, поддерживаемого Bigtable, row key объединяются в
диапазоны строк, которые в терминах Bigtable называются Tablet. Tablet может динамически
партицироваться и является ключевым элементом балансировки нагрузки.
Column key, в свою очередь, объединяются в семейства столбцов (column family). Последние
представляют собой простейшую единицу доступа к данным.
Timestamp позволяет добавить в Bigtable версионность данных, а также реализовать append-only
модель хранения данных.
Базовые принципы
Основные компоненты, входящие в кластер Bigtable – это единственный Master-сервер,
многочисленные tablet-сервера и клиенты.
Master – это процесс, выполняющийся на отдельном узле. Принципиальные цели Master-сервера
– доступность, масштабируемость, отказоустойчивость. Поэтому в зону ответственности
Mater-сервера входят:

балансировка нагрузки между tablet-серверами;

размещение tablet'ов на tablet-серверах;

добавление/удаление tablet-серверов в кластер.
Tablet-сервер содержит в себе, в общем случае, около сотни tablet'ов. Поэтому сфера
ответственности tablet-сервера лежит в обработке запросов на чтение/запись к tablet'ам, а также
разделении слишком больших tablet'ов.
Кроме Master-сервер и tablet-серверов в работа Bigtable-кластера участвует распределенный
сервис блокировок Chubby (также внутренний продукт Google). Принципиальная цель Chubby в
Bigtable – это синхронизация (вполне уместна будет аналогия, что Chubby предоставляет
распределенные примитивы синхронизации).
Ограничения
Bigtable обладает рядом ограничений:
1. Не поддерживаются транзакции на уровне нескольких строк (только на уровне одной
строки);
2. Определение способа хранения данных – RAM или диск – ответственность клиента.
Bigtable не пытается определить наилучший способ хранения динамически;
3. На момент публикации research paper [3], описывающего принципы построения Bigtable,
системане обладала возможностью репликации через географически удаленные
датацентры;
4. На момент публикации [3], хранилище не обладало возможность построения вторичных
индексов;
5. Зависимость от сервиса распределенных блокировок Chubby – если Chubby не отвечает
(такое бывает менее 0,01% времени, то и Bigtable-кластер не доступен.
Будущее и итоги
Bigtable, без сомнения, была самой большим по объему хранимых данных NoSQL базой в мире.
Более того, концепции, лежащие в основе Bigtable и описанные в [3], легли в основу многих
популярных сегодня NoSQL-решений, в т.ч. HBase – NoSQL БД, входящая в экосистему Hadoop.
Тем не менее, хорошо знакомые сообществу достоинства и ограничения NoSQL-решений также
свойственны и Bigtable. В какой-то момент времени у некоторых из сервисов Google появилось
критичное требование – поддержка принципа ACID для распределенных транзакций. Ни NoSQLрешения, в общем случае, ни Bigtable, в частности, не могли реализовать поддержку данного
требования.
Так инженерами Google была начата работа над распределенным хранилищем нового поколения,
которое можно отнести к классу NewSQL. На сегодняшний день это хранилище известно
какSpanner. Архитектура этого хранилища будет описана в одной из следующих статей из цикла.
Список источников*

[3] Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A.Wallach, et al.
Bigtable: A Distributed Storage System for Structured Data. Proceedings of OSDI, 2006.
Google MapReduce
Статья из цикла «Google Platform»
MapReduce – это программная модель, описанная инженерами Google в research paper [2], и
ассоциированная с этой программной моделью реализация (фреймворк), позволяющий
обрабатывать большие объемы данных распределено.
В простейшем случае в программной модели MapReduce выделяют 2 фазы:

map(ƒ, c): принимает функцию ƒ и список c. Возвращает выходной список, являющийся
результатом применения функции ƒ к каждому элементу входного списка c.

reduce(ƒ, c): принимает функцию ƒ и список c. Возвращает объект, образованный
через свертку коллекции c через функцию ƒ.
Реализация
В программной реализации модели MapReduce выделяют следующие этапы
работы программы:
1. Input read
Входные данные делятся на блоки данных предопределенного размера (от 16 Мб до 64
Мб) – сплиты (от англ. split). За каждой функцией Map закрепляется определенный сплит.
2. Map
Каждая функция map() получает на вход список пар «ключ/значение» <k,v>, обрабатывает
их и на выходе получает ноль или более пар <k',v'>, являющихся промежуточным
результатом.
1. map(k, v) -> [(k', v')]
де k' - в общем случае, произвольный ключ, не совпадающий с k. Все операции map()
выполняются параллельно и не зависят от результатов работы друг друга. Каждая функция map()
получает на вход свой уникальный набор данных, не повторяющийся ни для какой другой
функции map().
3. Partition
Целью этапа partition (разделение) является распределение промежуточных результатов,
полученных на этапе map, по reduce-заданиям. Важная цель этапа partition – это
балансировка нагрузки. Так некорректно реализованная функция partition может привести
к неравномерному распределению данных между reduce-узлами.
4. Reduce
Функция reduce() вызывается для каждого уникального ключа k' в отсортированном списке
значений.
1. reduce(k', [v']) -> [v'']
Все операции reduce(), также как и map(), выполняются параллельно и не зависят от результатов
работы друг друга.
5. Output write
Результаты, полученные на этапе reduce, записываются в выходной поток (в общем случае,
файловые блоки в GFS). Каждый reduce-узел пишет в собственный выходной поток.
Источник иллюстрации [2]
Достоинства и ограничении программной модели MapReduce, в общем, и фреймворков,
реализующих эту программную модель (например, Hadoop MapReduce), в частности, ужедовольно
подробно описаны в технической литературе, в том числе [15].
Ниже обсудим только основные из них.
Достоинства
Работу по получению входных данных, распараллеливанию работы программы, планированию
выполнения, межмашинной коммуникации и обработке отказов выполняет фреймворк
MapReduce.
MapReduce проявила себя как прекрасно масштабирующая и крайне простая модель
распределенного исполнения приложений. Устойчивость к проваленным заданиям для
программной модели MapReduce реализуется довольно просто.
Разработчикам MapReduce предоставляет унифицированный и ясный поход к созданию
распределенных приложений. Кроме того, модель предоставляет довольно чистую абстракцию,
позволяющую разработчику распределенного приложения писать минимальное количество «не
прикладного» (инфраструктурного) кода (например, обработка отказов оборудования).
Ограничения

Смешение ответственности для Reducer (сортировка и агрегация данных). Таким образом,
Reducer – это все, что «не map»;

Отсутствие контроля над потоком данных у разработчика (поток данных управляется
фреймворком Hadoop MapReduce автоматически);

Как следствие предыдущего пункта, невозможность простыми средствами организовать
взаимодействие между параллельно выполняющимися потоками.

Применение MapReduce по производительности менее эффективно, чем
специализированные решения;

Эффективность применение MapReduce снижается при малом количество машин в
кластере (высоки издержки на взаимодействие, а степень распараллеливания невелика);

Невозможно предсказать окончание стадии map;

Этап свертки не начинается до окончания стадии map;

Как следствие предыдущего пункта, задержки в исполнении любого запущенного mapзадания ведут к задержке выполнения задачи целиком.
Влияние на Open source
Влияние работ, опубликованных Google, на первые шаги становления отрасли Big Data сложно
переоценить.
Программная модель MapReduce была реализована во многих коммерческих (таких как
Greenplum) и некоммерческих программных продуктах (CouchDB, MongoDB). Наиболее известным
примером реализации концепций, описанных Google, является фреймворк вычислений Hadoop
MapReduce.
Список источников*

[2] Jeffrey Dean, Sanjay Ghemawat. MapReduce: simplified data processing on large clusters.
Proceedings of OSDI, 2004.

[15] Hadoop Insight и другие статьи ресурса. 0xСode.in: { Big Data, Cloud Computing, HPC }
Blog.
Colossus. Распределенная файловая система от Google
Статья из цикла «Google Platform»
Colossus (или GFS2) – это проприетарная распределенная файловая система от Google,
запущенная в production-режиме в 2009 году. Colossus является эволюционным развитием GFS.
Как и ее предшественник GFS, Colossus оптимизирована для работы с большими наборами
данных, прекрасно масштабируется, является высокодоступной и отказоустойчивой системой, а
также позволяет надежно хранить данные.
В то же время, Colossus решает часть задач, с которыми GFS не справлялась, и устраняет
некоторые узкие места предшественника.
З Ограничения GFS
Одно из таких принципиальных ограничений было то, что связка «GFS + Google MapReduce», как и
аналогичная связка «HDFS + Hadoop MapReduce (Classic)» (до появления YARN)
былаориентирована на пакетную обработку данных. В то время как все больше сервисов
Google – социальные сервисы, облачное хранилище, картографические сервисы – требовали
значительно меньших задержек, чем те, которые свойственны пакетной обработке данных.
Таким образом, в Google столкнулись с необходимостью поддержки near-real-time ответов для
некоторых типов запросов.
Кроме того, в GFS chunk имеет размер 64 Мб (хотя размер chunk конфигурируемый), что, в общем
случае, не подходит для сервисов Gmail, Google Docs, Google Cloud Storage - бОльшая часть места
выделенного под chunk остается незанятой.
Уменьшение размера chunk автоматически привело бы к увеличению таблицы метаданных, в
которой хранится file-to-chunk маппинг. А так как:

доступ, поддержка актуальности и репликация метаданных – это зона ответственности
Master сервера;

в GFS, как и в HDFS, метаданные полностью загружаются в оперативную память сервера,
то очевидно, что один Master на GFS-кластер - потенциально узкое место в распределенной
файловой системе с большим числом chunk'ов.
Кроме того, современные сервисы являются географически распределенными.
Геораспределенность позволяет как остаться сервису доступным во время форс-мажоров, так и
сокращает время доставки контента до пользователя, который его запрашивает. Но архитектура
GFS, описанная в [1], как классическая «Master-Slave»-архитектура, не предполагает реализацию
географической распределенности (во всяком случае без существенных издержек).
Архитектура
(Disclaimer: я не нашел ни одного достоверного источника, в полной мере описывающего
архитектуру Colossus, поэтому в описании архитектуры имеются как пробелы, так и
предположения.)
Colossus был призван решить проблемы GFS, описанные выше. Так размер chunk'а был
уменьшендо 1 Мб (по умолчанию), хотя по-прежнему остался конфигурируемым. Возрастающие
требования Master-серверов к объему оперативной памяти, необходимой для поддержания
таблицы метаданных, были удовлетворены новой «multi cell»-ориентированной
архитектуройColossus.
Так в Colossus есть пул Master-серверов и пул chunk-серверов, разделенных на логические ячейки.
Отношение ячейки Master-серверов (до 8 Master-серверов в ячейке) к ячейкам Сhunk-серверов
является один ко многим, то есть одна ячейка Master-серверов обслуживает одну и более ячейку
Сhunk-серверов.
Внутри ЦОД группа ячейка Master-серверов и управляемые ей ячейки Chunk-серверов образуют
некоторую автономную - не зависящую от других групп такого типа – файловую систему (далее
для краткости SCI, Stand-alone Colossus Instance). Такие SCI расположены в нескольких ЦОД Google
и взаимодействуют друг с другом по средством специально разработанного протокола.
Т.к. в открытом доступе нет подробного описанного инженерами Google внутреннего устройства
Colossus, то не ясно, как решается проблема конфликтов, как между SCI, так и внутри ячейки
Master-серверов.
Один из традиционных способов решения конфликтов между равнозначными узлами – этокворум
серверов. Но если в кворуме четное количество участников, то не исключены ситуации, когда
кворум ни к чему и не придет – половина «за», половина «против». А так как в информации о
Colossus очень часто звучит, что в ячейке Master-серверов может находится до 8 узлов, то
решение конфликтов с помощью кворума ставится под сомнение.
Также совершенно не ясно, каким образом одна SCI знает, какими данными оперирует другая
SCI. Если предположить, что такими званиями SCI и не обладает, то это означает, что этими
знаниями должен обладать:

либо клиент (что еще менее вероятно);

либо (условно) Supermaster (который опять же является единичной точкой отказа);

либо это информация (по сути critical state) должна находится в разделяемом всеми SCI
хранилище. Тут ожидаемо возникают проблемы блокировок, транзакций, репликации. С
последними успешно справляется PaxosDB, либо хранилище реализующее алгоритм Paxos
(или аналогичный).
В общем Colossus в целом пока скорее «черный ящик», чем «ясная архитектура» построения
геораспределенных файловых систем, оперирующих петабайтами данных.
Заключение
Как видно, изменения в Colossus коснулись почти всех элементов файловой системы
предшественника (GFS) – от chunk, до композиции кластера; вместе с тем, сохранена
преемственность идей и концепций, заложенных в GFS.
Одним из наиболее «звездных» клиентов Colossus является Caffeine - новейшая инфраструктура
поисковых сервисов Google.
Список источников*

[1] Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung. The Google File System. ACM SIGOPS
Operating Systems Review, 2003.

[10] Andrew Fikes. Storage Architecture and Challenges. Google Faculty Summit, 2010.
Spanner. NewSQL СУБД от Google
Статья из цикла «Google Platform»
Spanner – географически распределенная высокомасштабируемая мультиверсионная база
данных с поддержкой распределенных транзакций. База данных была разработана инженерами
Google для внутренних сервисов корпорации. Research paper [8], описывающие базовые
принципы и архитектуру Spanner, был представлен на научной конференции 10th USENIX
Symposium on Operating Systems Design and Implementation в 2012 году.
Spanner является эволюционным развитием NoSQL-предшественника – Google Bigtable. Сам же c
Spanner относят к семейству NewSQL-решений. В research paper [8] заявляется, что дизайн Spanner
позволяет системе масштабироваться на миллионы вычислительных узлов через сотни датацентров и работать с триллионами строк данных.
Spanner использует Colossus (GFS нового поколения) как слой хранения (storage) и алгоритм
разрешения коллизий Paxos. В свою очередь на основе (on top) Spanner построена
распределенная СУБД Google F1.
Spanner используется в социальной сети Google+, в почтовом сервисе GMail; построенная на
основе Spanner СУБД Google F1 используется в сервисе Google Ad Service.
Базовые принципы
Данные в Spanner хранятся в полуреляционных таблицах, имеющих схему. Все данные имеют
версию – временную метку (timestamp) подтверждения записи этих данных (commit). Spanner
имеет SQL-подобный язык запросов, возможность конфигурировать количество реплик и
политики Garbage Collector, ответственного за удаление записей со «старыми» временными
метками.
Кроме уже «привычных» для NoSQL-мира возможностей, Spanner обладает и рядом сложно
реализуемых в распределенных системах свойств. Таких как:

поддержка распределенных транзакций;

глобальная согласованность операций чтения между географически распределенными
ДЦ, т.о. данные, которые возвращают операции чтения из разных ДЦ, всегда согласованны
и непротиворечивы.
Кроме того Spanner обладает возможностями, больше свойственными для СУБД, такими как:

неблокирующее чтение данных «из прошлого» (in past);

отсутствие блокировок для read-only транзакций;

атомарное изменение схемы таблиц данных;

синхронная репликация;

автоматическая обработка отказов как вычислительных узлов, так и ДЦ;

автоматическая миграция данных как между вычислительными узлами, так и между ДЦ.
Архитектура
Каждый развернутый экземпляр (deployment) Spanner именуется Universe и содержит в себе:

Universe master – мастер-процесс, координирующий работу множества зон (в
терминологии Spanner - Zone);

Множество Zone – географически-распределенные (в общем случае) зоны Spanner. Zone –
это единица как логической изоляции, так и физической.
Каждый из Zone, в свою очередь, содержит в себе:

ZoneMaster – мастер-процесс зоны (синглтон);

Множество - от сотни до нескольких тысяч - Spanservers;

Location proxy – раскрывают клиентам расположение Spanservers, ответственных за
необходимые данные;

Placement driver – процесс (также, как и Zonemaster, синглтон), управляющий
перемещением данных между различными Zone.
В research paper [8] подробно описаны функции и внутренне устройство только Spanserver.
Каждый Spanserver содержит в себе от 100 до 1000 структур данных называемых tablet.
1. (key: string, timestamp: int64) -> string
В отличии от Bigtable, Spanner добавляет к структуре хранимых данных метку времени добавления
этих данных, что является важным введением для реализации поддержки мульти-версионности
данных.
Модель данных в Spanner – полуреляционные таблицы с поддержкой схем данных (schematized),
SQL-подобного языка запросов и распределенных транзакций.
Реализация последних (транзакций) стала возможна благодаря одному из наиболее
инновационных нововведений для такого рода программных систем – программного
интерфейсаTrueTime API.
TrueTime
Обычная задача для систем предоставления глобального времени (в частности атомных часов) –
это предоставление максимально точного времени. TrueTime API же предоставляет
клиентамглобальное время + некоторую неопределенность - TTinterval.
Это нужно потому, что для распределенных систем очень сложно гарантировать мгновенность
отклика узлов, что важно для обеспечения согласованности данных в распределенном
хранилище.
При подходе, когда вместо точного времени, возвращается некоторых временной интервал
выполнение 2-ух конкурентных транзакций сводится (упрощенно) к сравнению TTinterval этих
транзакций. Если TTinterval транзакций не пересекается, то можно однозначно узнать, какая из
транзакций должна быть выполнена раньше. Если TTinterval – пересекается, то сказать можно
только с определенной степенью вероятности.
В самом же Spanner согласованность данных при проведении транзакций
обеспечиваетсяпротоколом двухфазной фиксации транзакции (2-Phase Commit Protocol),
реализованным с помощью алгоритма Paxos.
Ограничения и CAP
На момент публикации research paper [8] Spanner не поддерживал вторичные
индексы иавтоматический resharding для целей балансировки нагрузки. Кроме того, авторы [8]
отмечают, что Spanner не способен эффективно исполнять сложные SQL-запросы.
Spanner также не является «опровержением» CAP-теоремы. Spanner не является AP-системой,
несмотря на свою NoSQL-природу; как и не является CA-системой, несмотря на стремление
поддержки принципов ACID. Spanner «жертвует» доступностью (availability) для
поддержания целостности данных (consistency) и поэтому является CP-системой.
Итоги
Spanner взял лучшие идеи двух миров - реляционных СУБД и NoSQL – и представляет из себяСУБД
поколения NewSQL.
Поддержка распределенных транзакций между дата-центрами на объеме данных, идущим на
петабайты, с такой способностью к масштабированию – это безусловно крайне впечатляющее
свойство для любой системы хранения структурированных и полуструктурированных данных.
Данная возможность во многом стала следствием симбиоза двух подходов: подхода к хранению
данных – данные иммутабельны и содержат метку времени коммита – и инновационной
концепции получения глобального времени - TrueTime.
Список источников*

[8] James C. Corbett, Jeffrey Dean, Michael Epstein, Andrew Fikes, Christopher Frost, JJ Furman,
et al. Spanner: Google’s Globally-Distributed Database. Proceedings of OSDI, 2012.
Dremel. Как Google считает в real-time?
Статья из цикла «Google Platform»
Dremel – масштабируемая система обработки запросов в режиме близком к режиму реального
времени (near-real-time), предназначенная для анализа неизменяемых данных [4].
Авторы research paper [4] (среди которых, судя по всему, и наши соотечественники - Сергей
Мельник и Андрей Губарев), в котором описываются базовые принципы и архитектура Dremel,
заявляют, что система в силах:

выполнять агрегирующие запросы над боле чем над триллионом строк за секунды;

масштабируется на тысячи CPU;

предназначена для работы с петабайтами данных;

имеет тысячи пользователей внутри Google (дословно «at Google»).
Dremel является проприетарным продуктом Google, находится в эксплуатации с 2006 года,
официально сообществу был представлен на конференции Very Large Data Base (VLDB)
Endowmentв 2010 году.
Dremel используется в задачах анализа собранных поисковым роботом документов, трекинге
данных об установке приложений в Android Market, сервисах Google Books и спам-анализе.
В 2012 году Google открыл доступ к Dremel для разработчиков через сервис Google BigQuery [14].
Модель данных
Как и многие системы такого класса, Dremel обладает возможностью масштабироваться на
несколько тысяч узлов, запускается на commodity-оборудовании, обеспечивает надежное
хранение данных, отказоустойчивость и репликацию, работает с неизменяемыми данными и
имеет собственный SQL-подобный язык запросов.
Dremel для хранения данных использует распределенную файловую систему GFS, а единицей
хранения данных является tablet.
Но, без сомнения, ключевой инновацией в Google Dremel – модель данных, которая в [4] звучит
как «nested columnar storage», или, в переводе, колоночное хранилище вложенных данных.
Основные принципы nested columnar storage: данные, чья схема явно определена, хранятся в
хранилище, ориентированном на столбцы (column-striped storage), вместе со связанными с
ними данными.
Разберем преимущества и недостатки такого выбора.
Колоночные хранилище позволяет с наибольшей скоростью, по сравнению с хранилищем,
ориентированным на построчное хранение данных, читать большие объему данных, а также
эффективно их сжимать (т.к. данные одинаковых типов хранятся в одном месте). С другой стороны
операции записи в колоночных хранилищах являются более дорогими по сравнению с row-striped
хранилищами, а поддержка транзакционности изменений является нетривиальной задачей.
Хранение данных вместе со связанными (в т.ч. вложенными) данными также, как и колоночная
схема хранения, позволяет увеличить скорость чтения данных. Одновременно такой способ
хранения подразумевает наличие некоторой избыточности данных и, как следствие,
необходимость решения проблемы согласованности разных копий этих данных.
Инженеры Google решили эту задачу следующим образом: Dremel работает с immutable-данными,
а проблема избыточности решается за счет введения для каждого столбца двух дополнительных
уровней: уровня определения (definition level) и уровня повторения (repetition level).
Источник
иллюстрации [4, Figure 2]
Источник
иллюстрации [4, Figure 3]
В каждой колонке храниться набор блоков. В свою очередь, каждый блок представляет
собойсжатые данные и целочисленные значения уровня определения и уровня повторения.
Таким образом, Dremel, зная все о структуре и расположении данных, которые необходимы для
выполнения запроса, может получить необходимую информацию «на месте» (в терминологии [4]
- «in situ»).
Кодирование каждого блока колонки по схеме <value, repetition_level, definition_level> приводит к
тому, что структура хранения уже содержит в себе алгоритм сборки, представляющий собой
конечный автомат, где:

множество состояний – множество столбцов, на которые разделен документ;

переходы – значения уровней повторений.
Источник иллюстрации [4,
Figure 4]
Исполнение запросов
Для исполнения запросов Dremel использует архитектуру многоуровневого дерева
обслуживания(multi-level serving tree): root-сервер получает от клиента запрос на выполнение,
читает необходимые метаданные tablet'ов и направляет (route) запросы на следующие уровни
дерева. И так пока запрос не достигнет листьев дерева обслуживания. Листья
дерева взаимодействуют уже непосредственно с GFS для получения необходимых данных.
Так разные запросы на Dremel выполняются одновременно, планировкой запросов на основе их
приоритета и наилучшей балансировки нагрузки занимается Query dispatcher. Query dispatcher
также ответственен за обработку отказов на уровне tablet'ов, ставших недоступными во время
выполнения запроса и «меленных» tablet'ов.
Интересным решением является также то, что результат выполнения запроса вернется не после
того, как будут обработаны 100% записей, а раньше – в [4] приводится цифра 98%, как
наиболее типичная. С одной стороны это избавляет Dremel от ожидания окончания работы
«медленных» листьев дерева выполнения запроса; с другой приводит к некоторой погрешности в
конечном результате, что вполне приемлемо для OLAP-систем и вряд ли допустимо в OLTPсистемах.
Результаты экспериментов
В результате экспериментов, начальные данные которых - 3К вычислительных узлов, 85 млрд.
строк - Dremel выполняет запросы на порядки быстрее, чем алгоритмы MapReduce, запущенные
как на record-oriented хранилищах, так и на columnar-oriented хранилищах.
Источник иллюстрации [4]
Кроме того, в [4] заявляется, что в ходе экспериментов некоторые скорость сканирования
таблицна некоторых запросах напрямую приближалась к 100 млрд. записей в секунду.
Влияние на Open Source
К Open Source аналогам Dremel относят Cloudera Impala, Apache Drill, Parquet (Twitter).
Список источников*

[4] Sergey Melnik, Andrey Gubarev, Jing Jing Long, Geoffrey Romer, et al. Dremel: Interactive
Analysis of Web-Scale Datasets. Proceedings of the VLDB Endowment, 2010.

[14] Google BigQuery. Google Developers.
Google Photon. Обработка данных со скоростью света
Статья из цикла «Google Platform»
Photon – масштабируемая, отказоустойчивая и географически распределенная система обработки
потоковых данных в режиме реального времени. Система является внутренним продуктом Google
и используется в Google Advertising System. Research paper [5], описывающие базовые принципы и
архитектуру Photon, был представлен на научной конференции ACM SIGMOD в 2013 году.
В research paper [5] заявлено, что пиковая нагрузка на систему может составлять миллионы
событий в минуту со средней end-to-end задержкой менее 10 секунд.
Photon решает вполне конкретную задачу: необходимо соединить (выполнить операцию join)
два непрерывных потока данных в режиме реального времени. Так в упоминаемой уже Google
Advertising System один из этих потоков – поток поисковых запросов, другой – поток переходов по
рекламным объявлениям.
Photon является географически распределенной системой и автоматически способен
обрабатывать случаи деградации инфраструктуры, в т.ч. отказа дата-центра. В
геораспределенных системах крайне непросто гарантировать время доставки сообщений (в
первую очередь, из-за сетевых задержек), поэтому Photon допускает, что обрабатываемые
потоковые данные могут быть не упорядочены по времени.
Используемые сервисы: GFS, PaxosDB, TrueTime.
Базовые принципы
В [5] объяснение принципов работы Photon идет в следующем контексте: пользователь ввел
поисковый запрос (query) в момент времени t1 и перешел по рекламному объявлению (click) в
момент времени t2. В этом же контексте, если не задано иного, в этой статье будут объяснены
принципы работы Photon.
Принцип объединения потоков (join) взят из мира РСУБД: поток query имеет уникальный
идентификатор query_id (условно Primary Key), поток click имеет уникальный
идентификаторclick_id и включает в себя некоторый query_id (условно Foreign Key). Объединение
потоков происходит по query_id.
Следующий важный момент: ситуация, когда один click event посчитан дважды, либо, наоборот,
не посчитан, будет вести, соответственно, либо к судебным искам со стороны рекламодателей,
либо к упущенным выгодам со стороны Google. Отсюда, крайне важно обеспечить at-mostonceсемантику обработки событий.
Другое требование – обеспечить near-exact семантику, т.е. чтобы большая часть событий была
посчитана в режиме близкому real-time. События, не посчитанные в real-time, все равно должны
быть посчитаны - exactly-once семантика.
Кроме того, для экземпляров Photon, работающих в разных дата-центрах,
необходимосинхронизированное состояние (точнее только critical state, так как между ДЦ весь
state слишком «дорого» реплицировать). Таким синхронизируемым critical
state выбрали event_id (по сути, click_id). Critical state храниться в структуре IdRegistry – in-memory
key-value хранилище, построенное на основе PaxosDB.
Последний – PaxosDB – реализует алгоритм Paxos для поддержки отказоустойчивости и
согласованности данных.
Взаимодействие с клиентами
Worker-узлы взаимодействуют с IdRegistry по клиент-серверной модели. Архитектурно
взаимодействие Worker-узлов с IdRegistry – это сетевое взаимодействие с очередью асинхронных
сообщений.
Так клиенты – Worker-узлы - отправляют к IdRegistry только 1) запрос на поиск event_id (если
event_id найден, значит он уже был обработан) и 2) запрос на вставку event_id (для случая, если на
шаге 1 event_id не был найден). На стороне сервера запросы принимают RPC-обработчики, целью
которых поставить запрос в очередь. Из очереди запросы забирает специальный процесс Registry
Thread (синглтон), который и выполнит запись в PaxosDB и инициализирует обратный вызов
(callback) клиенту.
Источник
иллюстрации [5, Figure 3]
Масштабируемость
Т.к. реплика IdRegistry происходит между географическим регионами, сетевые задержки между
которыми могут достигать 100 мс [5], то это автоматически ограничивает пропускную
способность IdRegistry до десяти последовательных транзакций (event_id commits) в секунду, в то
время как требование к IdRegistry было равно 10K транзакций в секунду. Но и отказаться от
геораспределенности и/или от синхронной репликации critical state с поддержкой решений
конфликтов в кворуме также нельзя.
Тогда инженеры Google внедрили еще 2 практики, знакомые многим из мира СУБД:

пакетная отправка запросов (batching) – «полезная» информация по event_id занимает
менее 100 байт; запросы отправляются пакетами на IdRegistry Client. Там они попадают в
очередь, которую разбирает процесс Registry Thread, в обязанности которого входит
решение конфликтов, связанные с тем, что в очереди может быть более одного элемента с
одинаковым event_id.

sharding (+ динамический resharding) – все event_id делятся по диапазонам; транзакции по
каждому из диапазонов отправляются на определенный IdRegistry.
Пакетная отправка запросов имеет и обратную сторону: кроме смешения семантики (Photon
обрабатывает данные real-time, а некоторые его части работают в batching-режиме), batchingсценарий не подойдет для систем c небольшим количеством событий – время сбора полного
пакета может занимать существенный интервал времени.
Компоненты
В рамках одного ДЦ выделают следующие компоненты:

EventStore – обеспечивает эффективный поиск по queries (поток поисковых запросов в
поисковой системе);

Dispatcher – чтение потока кликов по рекламным объявлениям (clicks) и передача (feed)
прочитанного Joiner;

Joiner – stateless RPC-сервер, принимающий запросы от Dispatcher, обрабатывающий их и
соединяющий (join) потоки queries и clicks.
Алгоритм добавления записи представлен ниже:
Источник
иллюстрации [5, Figure 5]
Взаимодействие между ДЦ:
Источник иллюстрации [5, Figure 6]
Алгоритм добавления записи в Joined Click Logs опустим, отметив, что в работы систем с частым
сетевым взаимодействием применение retry-политик и асинхронных вызовов является крайне
эффективным способом увеличения надежности и масштабируемости системы, соответственно,
без усложнения общего алгоритма работы.
Этими же приемами – retry-политик и асинхронных вызов – и воспользовались создатели Photon.
Логика повтора запросов (щелкните, чтобы открыть)
Dispatcher
Dispatcher – процесс, ответственный за чтение логов кликов - clicks. Эти логи растут во времени
непрерывно.
Для того, чтобы эффективно их читать, Dispatcher периодически сканирует директорию с логами и
идентифицирует новые файлы и/или измененные, сохраняет состояние каждого файла в
локальной GFS ячейке. Это состояние содержит список файлов и сдвиг от начала файла для
данных, которые уже были обработаны. Таким образом при изменении файла, последний
вычитывается не с начала, а с того момента, на котором обработка закончилась в прошлое чтение.
Обработка новых данных осуществляется параллельно несколькими процессами, каждый из
которых расшаривает свое состояние, что позволяет различным процессам бесконфликтно
работать на разными частями одного и того же файла.
Joiner
Joiner – реализация stateless RPC-сервера, принимающего запросы от Dispatcher. Приняв запрос от
Dispatcher, Joiner извлекает из него click_id и query_id. После чего по query_id пытается получить
информацию из EventStore.
В случае успеха, EventStore возвращает поисковый запрос соответствующий обрабатываемому
click.
Далее Joiner удаляет дубликаты (с помощью IdRegistry) и генерирует выходной лог, содержащий
объединенные (joined) значения – Joined Click Logs.
Если Dispatcher для обработки отказов использовал retry-логику, то в Joiner инженеры Google
добавили еще один прием. Прием работает в случаях, когда Joiner отправил запрос к IdRegistry;
последний успешно зарегистрировал click_id, но из-за сетевых проблем, либо по таймауту Joiner
так и не получил ответ об успехе от IdRegistry.
Для этого с каждым «commit click_id»-запросом, который Joiner отправляет на IdRegistry,
ассоциируется специальный токен. Токен сохраняется в IdRegistry. В случае, если ответ от
IdRegistry не был получен, Joiner повторяет запрос с тем же токеном, что и в прошлом запросе, и
IdRegistry без труда «понимает», что пришедший запрос уже обрабатывался.
Генерация уникальных токенов / Event_Id (щелкните, чтобы открыть)
EventStore
EventStore – это сервис, принимающий на вход query_id и возвращающий соответствующий query
(информацию о поисковом запросе).
В Photon для EventStore имеются 2 реализации:
1. CacheEventStore – распределенное [sharding по hash(query_id)] in-memory хранилище, к
котором хранится полная информация по query. Таком образом, для ответа на запрос не
требуется чтение с диска.
2. LogsEventStore - key-value хранилище, где key – query_id, а value – имя log-файла, в котором
хранится информацию по соответствующему query, и смещение (byte offset) в этом файле.
Так как Photon работает в режиме близком к реальному времени, то можно с уверенностью
гарантировать, что вероятность нахождения query в CacheEventStore (при условии, что в query в
него попадают с минимальной задержкой) будет очень высокой, а сам CacheEventStore может
хранить события за относительно небольшой промежуток времени.
В researching paper [5] приводится статистика, что только 10% запросов «проходят мимо» inmemory кэша и, соответственно, обрабатываются LogsEventStore.
Результаты
Конфигурация
На момент публикации [5], т.е. в 2013 году, реплики IdRegistry развернуты в 5-ти датацентрах в 3ех географических регионах, причем сетевые задержки между регионами превышают 100 мс.
Другие компоненты Photon – Dispatchers, Joiners, etc. – развернуты в 2-ух географических регионах
на западном и восточном побережье США.
В каждом из ДЦ количество IdRegistry-шардов превышает сотню, а количество экземпляров
процессов Dispatcher и Joiner превышает тысячи.
Производительность
Photon обрабатывает миллиарды joined событий в день, в том числе, в периоды пиковых
нагрузокмиллионы событий в минуту. Объем clicks-логов, обрабатываемых за 24 часа,
превышает терабайт, а объем суточных query-логов исчисляется десятками терабайт.
90% всех событий обрабатываются (join'ятся в один stream) в первые 7 секунд, после их
появления.
Исто
чник иллюстрации [5, Figure 7]
В заключении
В заключении research paper [5], инженеры Google поделились хорошими практиками и своим
планами на будущее.
Принципы не новы, но для полноты и законченности статьи, я их перечислю:

Используйте RPC-коммуникации вместо записи на диск. Запросы, выходящие за
физические границы узла, должны выполняться асинхронно, а клиент всегда должен
рассчитывать, что не получит ответ по таймауту или из-за сетевых проблем.

Минимизируйте критическое состояние (critical state) системы, т.к. его, в общем случае,
приходится синхронно реплицировать. В идеале в критическое critical state системы
должен включать в себя только метаданные системы.

Sharding – друг масштабируемости :) Но и эту идею инженеры Google улучшили, сделав
динамический resharding.
В планах создателей Photon уменьшить end-to-end задержки за счет того, что сервера, которые
генерируют clicks и queries будут напрямую отправлять RPC-запросы к Joiner'ам (сейчас Dispatcher
«ждет» этих событий). Также планируется Photon «научить» объединять несколько потоков
данных (в текущей реализации Photon умеет объединять только 2 потока).
Пожелаем создателям Photon удачи в реализации их планов! И ждем новых research paper!
Список источников*

[5] Rajagopal Ananthanarayanan, Venkatesh Basker, Sumit Das, Ashish Gupta, Haifeng Jiang,
Tianhao Qiu, et al. Photon: Fault-tolerant and Scalable Joining of Continuous Data Streams,
2013.
Основные источники

[1] Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung. The Google File System. ACM SIGOPS
Operating Systems Review, 2003.

[2] Jeffrey Dean, Sanjay Ghemawat. MapReduce: simplified data processing on large clusters.
Proceedings of OSDI, 2004.

[3] Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A.Wallach, et al.
Bigtable: A Distributed Storage System for Structured Data. Proceedings of OSDI, 2006.

[4] Sergey Melnik, Andrey Gubarev, Jing Jing Long, Geoffrey Romer, et al. Dremel: Interactive
Analysis of Web-Scale Datasets. Proceedings of the VLDB Endowment, 2010.

[5] Rajagopal Ananthanarayanan, Venkatesh Basker, Sumit Das, Ashish Gupta, Haifeng Jiang,
Tianhao Qiu, et al. Photon: Fault-tolerant and Scalable Joining of Continuous Data Streams,
2013.

[6] Our new search index: Caffeine. Google Official blog.

[7] Grzegorz Malewicz, Matthew H. Austern, Aart J. C. Bik, James C. Dehnert, Ilan Horn, et al.
Pregel: A System for Large-Scale Graph Processing. Proceedings of the 2010 international
conference on Management of data, 2010.

[8] James C. Corbett, Jeffrey Dean, Michael Epstein, Andrew Fikes, Christopher Frost, JJ Furman,
et al. Spanner: Google’s Globally-Distributed Database. Proceedings of OSDI, 2012.

[9] Daniel Peng, Frank Dabek. Large-scale Incremental Processing Using Distributed Transactions
and Notifications. Proceedings of the 9th USENIX Symposium on Operating Systems Design and
Implementation, 2010.

[10] Andrew Fikes. Storage Architecture and Challenges. Google Faculty Summit, 2010.
Дополнительные источники

[11] Douglas, L. 3D Data Management: Controlling Data Volume, Velocity and Variety. Gartner,
2001.

[12] Christy Pettey, Laurence Goasduff. Gartner Says Solving 'Big Data' Challenge Involves More
Than Just Managing Volumes of Data. Gartner, 2011.

[13] Закон перехода количественных изменений в качественные. Свободная
энциклопедия Википедия.

[14] Google BigQuery. Google Developers.

[15] Hadoop Insight и другие статьи ресурса. 0xСode.in: { Big Data, Cloud Computing, HPC }
Blog.
Google создаст к 2017 году единую
платформу, объединив Chrome OS
и Android
Фото: архив 66.ru
Это позволит интернет-гиганту за счет ноутбуков расширить пользовательскую
базу своей мобильной платформы, на которой уже работают смартфоны,
планшеты, умные часы, телевизоры и машины.
Материнская компания Google — Alphabet — хочет к 2017 году объединить
операционные системы (ОС) Chrome OS и Android: нишевую операционную систему,
предназначенную для настольных компьютеров и работающую сейчас на лэптопах
Chromebook от Google, и самую распространенную в мире мобильную ОС.
Предварительную версию единой платформы презентуют на конференции Google I/O
в 2016 году, сообщает The Verge. Для пользователей объединенная система станет
доступна в 2017 году, уточняет WSJ.
Инженеры Google работают над объединением ОС уже два года: хоть обе системы
базируются на дистрибутивах Linux, слияние проходит с техническими трудностями.
Google планирует дать новое название и единой операционной платформе, и серии
ноутбуков Chromebook.
Объединение Chrome OS и Android позволит интернет-гиганту за счет ноутбуков
расширить пользовательскую базу своей мобильной платформы, на которой уже работают
смартфоны, планшеты, умные часы, телевизоры и машины. Кроме того, объединение
систем облегчит задачу разработчикам: их приложения будут работать на всех
устройствах сразу. По мнению специалистов, единая ОС позволит пользователям
компьютеров и ноутбуков получить доступ к приложениям из магазина Google Play —
сейчас они доступны владельцам Chrome OS лишь частично.
При этом планов по закрытию Chrome OS у Google нет, но скорее всего, корпорация
сделает акцент на интеграцию Android в персональные компьютеры.
Как отмечает РБК, единая операционная система уже есть у IТ-гиганта Microsoft: ОС
Windows 10, вышедшая в 2015 году, работает и на мобильных устройствах,
и на персональных компьютерах. У корпорации Apple для смартфонов и планшетов
предназначена iOS, для компьютеров Mac — OS X.
Автор
golovkoop73
Документ
Категория
Компьютеры, Программирование
Просмотров
77
Размер файла
950 Кб
Теги
google, platforma
1/--страниц
Пожаловаться на содержимое документа