Подготовка

Перед тем, как приступить собственно говоря к установке Hadoop, необходимо выполнить два элементарных действия, необходимых для правильного функционирования системы:

• открыть доступ одному из пользователей по ssh к этому же компьютеру без пароля, можно например создать отдельного пользователя для этого [hadoop]:

  useradd -m -n hadoop
  

  Далее действия выполняем от его имени:

  su hadoop
  

  Генерируем RSA-ключ для обеспечения аутентификации в условиях отсутствия возможности использовать пароль:

  hadoop@localhost ~ $ ssh-keygen -t rsa -P ""
  Generating public/private rsa key pair.
  Enter file in which to save the key (/home/hadoop/.ssh/id_rsa):
  Your identification has been saved in /home/hadoop/.ssh/id_rsa.
  Your public key has been saved in /home/hadoop/.ssh/id_rsa.pub.
  The key fingerprint is:
  7b:5c:cf:79:6b:93:d6:d6:8d:41:e3:a6:9d:04:f9:85 hadoop@localhost
  

  И добавляем его в список авторизованных ключей:

  cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
  

  Этого должно быть более чем достаточно, проверить работоспособность соединения можно просто написав:

  ssh localhost
  

  Не забываем предварительно инициализировать sshd:

  /etc/init.d/sshd start
  

• Помимо этого необходимо убедиться в наличии установленной JVM версии 1.5.0 или выше, а также узнать директорию, где она располагается, вариантов сделать это множество, я нашел ее просто заглянув в самое логичное место — /usr/lib, но при желании никто не может Вам помешать воспользоваться услугами, например, slocate. Найденную директорию с JVM лучше запомнить или записать куда-нибудь, для меня она оказалась:

  /usr/lib/jvm/sun-jdk-1.6
  

Установка

Установка начинается с получения копии исходного кода системы, способов для этого существует несколько. Я перепробовал практически все, самую адекватную версию мне удалось получить из SVN. Для ее получения необходимо выполнить следующую команду:

svn checkout http://svn.apache.org/repos/asf/hadoop/core/branches/branch-0.16 ~

branch-0.16 — последняя доступная версия на данный момент, для определения ее номера достаточно заглянуть по тому же адресу браузером. Предполагается, что Hadoop будет располагаться прямо в /home/hadoop, но запросто можно использовать и другую директорию.

Сразу же стоит скомпилировать различные дополнительные компоненты системы, особенно это актуально из-за HBase, но и помимо него соберется много чего интересного, например plug-in для отличной IDE под названием Eclipse или Hadoop On Demand. Задача также элементарна:

cd ~
ant clean jar compile-contrib

Настройка

Конфигурационные файлы можно редактировать в произвольном порядке, самое главное ничего не забыть

• conf/hadoop-env.sh

  # The java implementation to use.  Required.
  export JAVA_HOME=/usr/lib/jvm/sun-jdk-1.6
  

  Единственная обязательная переменная окружения — JAVA_HOME, здесь как раз пригодится заранее найденный путь до JVM, все остальное — по желанию.

• conf/hadoop-site.xml

  
  
  
  
  
  
  
    hadoop.tmp.dir
    /home/hadoop/data/${user.name}
    A base for other temporary directories.
  
  
    fs.default.name
    hdfs://localhost:54310
    The name of the default file system.  A URI whose
    scheme and authority determine the FileSystem implementation.  The
    uri's scheme determines the config property (fs.SCHEME.impl) naming
    the FileSystem implementation class.  The uri's authority is used to
    determine the host, port, etc. for a filesystem.
  
  
    mapred.job.tracker
    localhost:54311
    The host and port that the MapReduce job tracker runs
    at.  If "local", then jobs are run in-process as a single map
    and reduce task.
    
  
  
    dfs.replication
    1
    Default block replication.
    The actual number of replications can be specified when the file is created.
    The default is used if replication is not specified in create time.
    
  
  
  
  

  Этот конфигурации файл является одним из ключевых, таким образом он выглядит для конфигурации, состоящей из одного компьютера (позаимствован из англоязычного мануала на ту же тему).

• src/contrib/hbase/conf/hbase-site.xml

  
  
  
  
       hbase.master
       localhost:60000
       The host and port that the HBase master runs at
     
  
       hbase.rootdir
       /hbase
       location of HBase instance in dfs
     
  
  

  Как не сложно заметить, этот файл необходим для функционирования HBase, по-моему все просто и очевидно, <description> говорят сами за себя.

Запуск

Начать стоит с ознакомления с кратким описанием доступных команд Hadoop, сделать это можно просто набрав ~/bin/hadoop:

Usage: hadoop [--config confdir] COMMAND
where COMMAND is one of:
  namenode -format     format the DFS filesystem
  secondarynamenode    run the DFS secondary namenode
  namenode             run the DFS namenode
  datanode             run a DFS datanode
  dfsadmin             run a DFS admin client
  fsck                 run a DFS filesystem checking utility
  fs                   run a generic filesystem user client
  balancer             run a cluster balancing utility
  jobtracker           run the MapReduce job Tracker node
  pipes                run a Pipes job
  tasktracker          run a MapReduce task Tracker node
  job                  manipulate MapReduce jobs
  version              print the version
  jar             run a jar file
  distcp   copy file or directories recursively
  daemonlog            get/set the log level for each daemon
 or
  CLASSNAME            run the class named CLASSNAME
Most commands print help when invoked w/o parameters.

Первым делом необходимо отформатировать Namenode:

~/bin/hadoop namenode -format

И дело останется лишь за малым, запустить на выполнение пару bash-скриптов, которые без вашего дальнейшего участия инициализируют всю систему, включая HBase:

~/bin/hadoop/start-all.sh && ~/src/contrib/hbase/bin/start-hbase.sh

Как только они закончат все необходимые действия, у Вас появится возможность удостовериться, что все в порядке. Самым простым способом является запуск клиента Hbase Shell:

~/bin/src/contrib/hbase/bin/hbase shell

Если в ответ Вы получили соответствующее приглашение клиента, значит все было сделано верно!

Вот собственно говоря и все, псевдо-кластер функционирует, доступ к HBase имеется, можно приступать к разработке

P.S.: Остановка системы производится по тому же принципу скриптами stop-all.sh и stop-hbase.sh.

• Масштабируемость: с помощью Hadoop возможно надежное хранение и обработка огромных объемов данных, которые могут измеряться петабайтами;
• Экономичность: информация и вычисления распределяются по кластеру, построенному на самом обыкновенном оборудовании. Такой кластер может состоять из тысяч узлов;
• Эффективность: распределение данных позволяет выполнять их обработку параллельно на множестве компьютеров, что существенно ускоряет этот процесс;
• Надежность: при хранении данных возможно предоставление избыточности, благодаря хранению нескольких копий. Такой подход позволяет гарантировать отсутствие потерь информации в случае сбоев в работе системы;
• Кроссплатформенность: так как основным языком программирования, используемым в этой системе является Java, развернуть ее можно на базе любой операционной системы, имеющей JVM.

HDFS

В основе всей системы лежит распределенная файловая система под незамысловатым названием Hadoop Distributed File System. Представляет она собой вполне стандартную распределенную файловую систему, но все же она обладает рядом особенностей:

• Устойчивость к сбоям, разработчики рассматривали сбои в оборудовании скорее как норму, чем как исключение;
• Приспособленность к развертке на самом обыкновенном ненадежном оборудовании;
• Предоставление высокоскоростного потокового доступа ко всем данным;
• Настроена для работы с большими файлами и наборами файлов;
• Простая модель работы с данными: один раз записали — много раз прочли;
• Следование принципу: переместить вычисления проще, чем переместить данные;

Архитектура HDFS

Проще всего ее демонстрирует схема, позаимствованная с официального сайта проекта и переведенная мной на руский:

Действующие лица:

Namenode

Этот компонент системы осуществляет всю работу с метаданными. Он должен быть запущен только на одном компьютере в кластере. Именно он управляет размещением информации и доступом ко всем данным, расположенным на ресурсах кластера. Сами данные проходят с остальных машин кластера к клиенту мимо него.

Datanode

На всех остальных компьютерах системы работает именно этот компонент. Он располагает сами блоки данных в локальной файловой системе для последующей передачи или обработки их по запросу клиента. Группы узлов данных принято называть Rack, они используются, например, в схемах репликации данных.

Клиент

Просто приложение или пользователь, работающий с файловой системой. В его роли может выступать практически что угодно.

Пространство имен HDFS имеет классическую иерархическую структуру: пользователи и приложения имеют возможность создавать директории и файлы. Файлы хранятся в виде блоков данных произвольной (но одинаковой, за исключением последнего; по-умолчанию 64 mb) длины, размещенных на Datanode‘ах. Для обеспечения отказоустойчивости блоки хранятся в нескольких экземплярах на разных узлах, имеется возможность настройки количества копий и алгоритма их распределения по системе. Удаление файлов происходит не сразу, а через какое-то время после соответствующего запроса, так как после получения запроса файл перемещается в директорию /trash и хранится там определенный период времени на случай если пользователь или приложение передумают о своем решении. В этом случае информацию можно будет восстановить, в противном случае — физически удалить.

Для обнаружения возникновения каких-либо неисправностей, Datanode периодически отправляют Namenode‘у сигналы о своей работоспособности. При прекращении получения таких сигналов от одного из узлов Namenode помечает его как «мертвый», и прекращает какой-либо с ним взаимодействие до возвращения его работоспособности. Данные, хранившиеся на «умершем» узле реплицируются дополнительный раз из оставшихся «в живых» копий и система продолжает свое функционирование как ни в чем не бывало.

Все коммуникации между компонентами файловой системы проходят по специальным протоколам, основывающимся на стандартном TCP/IP. Клиенты работают с Namenode с помощью так называемого ClientProtocol, а передача данных происходит по DatanodeProtocol, оба они обернуты в Remote Procedure Call (RPC).

Система предоставляет несколько интерфейсов, среди которых командная оболочка DFSShell, набор ПО для администрирования DFSAdmin, а также простой, но эффективный веб-интерфейс. Помимо этого существуют несколько API для языков программирования: Java API, C pipeline, WebDAV и так далее.

MapReduce

Помимо файловой системы, Hadoop включает в себя framework для проведения масштабных вычислений, обрабатывающих огромные объемы данных. Каждое такое вычисление называется Job (задание) и состоит оно, как видно из названия, из двух этапов:

Map

Целью этого этапа является представление произвольных данных (на практике чаще всего просто пары ключ-значение) в виде промежуточных пар ключ-значение. Результаты сортируются и групируются по ключу и передаются на следующий этап.

Reduce

Полученные после map значения используются для финального вычисления требуемых данных. Практические любые данные могут быть получены таким образом, все зависит от требований и функционала приложения.

Задания выполняются, подобно файловой системе, на всех машинах в кластере (чаще всего одних и тех же). Одна из них выполняет роль управления работой остальных — JobTracker, остальные же ее бесприкословно слушаются — TaskTracker. В задачи JobTracker‘а входит составление расписания выполняемых работ, наблюдение за ходом выполнения, и перераспределение в случае возникновения сбоев.

В общем случае каждое приложение, работающее с этим framework’ом, предоставляет методы для осуществления этапов map и reduce, а также указывает расположения входных и выходных данных. После получения этих данных JobTracker распределяет задание между остальными машинами и предоставляет клиенту полную информацию о ходе работ.

Помимо основных вычислений могут выполняться вспомогательные процессы, такие как составление отчетов о ходе работы, кэширование, сортировка и так далее.

HBase

В рамках Hadoop доступна еще и система хранения данных, которую правда сложно назвать СУБД в традиционном смысле этого слова. Чаще проводят аналогии с проприетарной системой этого же плана от Google — BigTable.

HBase представляет собой распределенную систему хранения больших объемов данных. Подобно реляционным СУБД данные хранятся в виде таблиц, состоящих из строк и столбцов. И даже для доступа к ним предоставляется язык запросов HQL (как ни странно — Hadoop Query Language), отдаленно напоминающий более распространенный SQL. Помимо этого предоставляется итерирующмй интерфейс для сканирования наборов строк.

Одной из основных особенностей хранения данных в HBase является возможность наличия нескольких значений, соответствующих одной комбинации таблица-строка-столбец, для их различения используется информация о времени добавления записи. На концептуальном уровне таблицы обычно представляют как набор строк, но физически же они хранятся по столбцам, достаточно важный факт, который стоит учитывать при разработки схемы хранения данных. Пустые ячейки не отображаются каким-либо образом физически в хранимых данных, они просто отсутствуют. Существуют конечно и другие нюансы, но я постарался упомянуть лишь основные.

HQL очень прост по своей сути, если Вы уже знаете SQL, то для изучения его Вам понадобится лишь просмотреть по диагонали коротенький вывод команды help;, занимающий всего пару экранов в консоли. Все те же SELECT, INSERT, UPDATE, DROP и так далее, лишь со слегка измененным синтаксисом.

Помимо обычно командной оболочки HBase Shell, для работы с HBase также предоставлено несколько API для различных языков программирования: Java, Jython, REST и Thrift.

Заключение

Hadoop является отличным решением для построения высоконагруженных приложений, которое уже активно используется множеством интернет-проектов. В последующих постах на эту тему я постараюсь описать процесс развертывания этой системы и написания приложений, работающих по принципу MapReduce. Не пропустить момент их публикации Вам может помочь подписка на RSS-ленту.

Google — Король масштабируемости.

Каждый хоть раз слышал о Google благодаря их всеобъемлющему, «умному» и быстрому поисковому сервису, но ни для кого не секрет, что они не ограничиваются только им. Их платформа для построения масштабируемых приложений позволяет выпускать множество удивительно конкурентноспособных интернет-приложений, работающих на уровне всего Интернета вцелом. Они ставят перед собой цель постоянно строить все более и более производительную и масштабируемую архитектуру для поддержки своих продуктов. Как же им это удается?

Источники информации

Сразу хочу сказать, что эта запись является переводом с английского, автор оригинальной версии — Todd Hoff. Оригинал написан приблизительно в середине 2007 года, но по-моему до сих пор очень даже актуально.

Далее следует перечисление источников информации из оригинала:

• Video: Построение больших систем в Google
• Google Lab: Файловая система Google (GFS)
• Google Lab: MapReduce: упрощенная обработка данных на больших кластерах
• Google Lab: BigTable.
• Video: BigTable: система распределенного хранения данных.
• Как работает Google от David Carr в Baseline Magazine.
• Google Lab: интерпретирование данных. Параллельный анализ с помощью Sawzall.
• Записи с конференции по масштабированию от Dare Obasonjo.

Платформа

• Linux
• Большое разнообразие языков программирования: Python, Java, C++

Что внутри?

Статистика

• На 2006 год система включала в себя 450000 недорогих серверов
• За 2005 год было проиндексировано 8 миллиардов страниц. На данный момент… кто знает?
• На момент написания оригинала Google включает в себя более 200 GFS кластеров. Один кластер может состоять из 1000 или даже 5000 компьютеров
• Десятки и сотни тысяч компьютеров получают данные из GFS кластеров, которые насчитывают более 5 петабайт дискового пространства. Суммарные пропускная способность операций записи и чтения между дата центрами может достигать 40 гигабайт в секунду
• BigTable позволяет хранить миллиарды ссылок (URL), сотни терабайт снимков со спутников, а также настройки миллионов пользователей

// Цифры не первой свежести конечно, но тоже неплохо.

Стек

Google визуализирует свою инфраструктуру в виде трехслойного стека:

• Продукты: поиск, реклама, электронная почта, карты, видео, чат, блоги
• Распределенная инфраструктура системы: GFS, MapReduce и BigTable
• Вычислительные платформы: множество компьютеров во множестве датацентров
• Легкое развертывание для компании при низком уровне издержек
• Больше денег вкладывается в оборудование для исключения возможности потерь данных

Надежное хранение данных с помощью GFS

• Надежное масштабируемое хранение данных крайне необходимо для любого приложения. GFS является основой их платформы хранения информации
• GFS — большая распределенная файловая система, способная хранить и обрабатывать огромные объемы информации
• Зачем строить что-либо самим вместо того, чтобы просто взять это с полки? Они контролируют абсолютно всю систему и именно эта платформа отличает их от всех остальных. Она предоставляет:

  – высокую надежность дата центров

  – масштабируемость до тысяч сетевых узлов

  – высокую пропускную способность операций чтения и записи

  – поддержку больших блоков данных, размер которых может измеряться в гигабайтах

  – эффективное распределение операций между датацентрами для избежания возникновения «узких мест» в системе

• В системе существуют мастер-сервера и сервера, собственно хранящие информацию:

  – Мастер-сервера хранят метаданные для всех файлов. Сами данные хранятся блоками по 64 мегабайта на остальных серверах. Клиенты могут выполнять операции с метаданными на мастер-серверах, чтобы узнать на каком именно сервере расположены необходимые данные.

  – Для обеспечения надежности один и тот же блок данных хранится в трех экземплярах на разных серверах, что обеспечивает избыточность на случай сбоев в работе какого-либо сервера.

  – Новые приложения могут пользоваться как существующими кластерами, так и новыми, созданными специально для них.

  – Ключ успеха заключается в том, чтобы быть уверенными в том, что у людей есть достаточно вариантов выбора для реализации их приложений. GFS может быть настроена для удовлетворения нужд любого конкретного приложения.

Работаем с данными при помощи MapReduce

• Теперь, когда у нас есть отличная система хранения, что же делать с такими объемами данных? Допустим, у нас есть много терабайт данных, равномерно распределенных между 1000 компьютерами. Коммерческие базы данных не могут эффективно масштабироваться до такого уровня, именно в такой ситуации в дело вступает технология MapReduce.
• MapReduce является программной моделью и соответствующей реализацией обработки и генерации больших наборов данных. Пользователи могут задавать функцию, обрабатывающую пары ключ/значение для генерации промежуточных аналогичных пар, и сокращающую функцию, которая объединяет все промежуточные значения, соответствующие одному и тому же ключу. Многие реальные задачи могут быть выражены с помощью этой модели. Программы, написанные в таком функциональном стиле автоматически распараллеливаются и адаптируются для выполнения на обширных кластерах. Система берет на себя детали разбиения входных данных на части, составления расписания выполнения программ на различных компьютерах, управления ошибками, и организации необходимой коммуникации между компьютерами. Это позволяет программистам, не обладающим опытом работы с параллельными и распределенными системами, легко использовать все ресурсы больших распределенных систем.
• Зачем использовать MapReduce?

  – Отличный способ распределения задач между множеством компьютеров

  – Обработка сбоев в работе

  – Работа с различными типами смежных приложений, таких как поиск или реклама. Возможно предварительное вычисление и обработка данных, подсчет количества слов, сортировка терабайт данных и так далее

  – Вычисления автоматически приближаются к источнику ввода-вывода

• MapReduce использует три типа серверов:

  – Master: назначают задания остальным типам серверов, а также следят за процессом их выполнения

  – Map: принимают входные данные от пользователей и обрабатывают их, результаты записываются в промежуточные файлы

  – Reduce: принимают промежуточные файлы от Map-серверов и сокращают их указанным выше способом

• Например, мы хотим посчитать количество слов на всех страницах. Для этого нам необходимо передать все страницы, хранимые в GFS, на обработку в MapReduce. Этот процесс будет происходить на тысячах машин одновременно с полной координацией действий, в соответствии с автоматически составленным расписанием выполняемых работ, обработкой потенциальных ошибок, и передачей данных выполняемыми автоматически.

  – Последовательность выполняемых действий выглядела бы следующим образом: GFS → Map → перемешивание → Reduce → запись результатов обратно в GFS

  – Технология MapReduce состоит из двух компонентов: соответственно map и reduce. Map отображает один набор данных в другой, создавая тем самым пары ключ/значение, которпыми в нашем случае являются слова и их количества.

  – В процессе перемешивания происходит аггрегирование типов ключей.

  – Reduction в нашем случае просто суммирует все результаты и возвращает финальный результат.

• В процессе индексирования Google подвергает поток данных обработке около 20 разных механизмов сокращения. Сначала идет работа над всеми записями и аггрегированными ключами, после чего результат передается следующему механизму и второй механизм уже работает с результатами работы первого, и так далее.
• Программы могут быть очень маленькими, всего лишь от 20 до 50 строк кода.
• Единственной проблемой могут быть «отстающие компьютеры». Если один компьютер работает существенно медленнее, чем все остальные, это будет задерживать работу всей системы в целом.
• Транспортировка данных между серверами происходит в сжатом виде. Идея заключается в том, что ограничивающим фактором является пропускная способность канала и ввода-вывода, что делает резонным потратить часть процессорного времени на компрессию и декомпрессию данных.

Хранение структурированных данных в BigTable

• BigTable является крупномасштабной, устойчивой к потенциальным ошибкам, самоуправляемой системой, которая может включать в себя терабайты памяти и петабайты данных, а также управлять миллионами операций чтения и записи в секунду.
• BigTable представляет собой распределенный механизм хэширования, построенный поверх GFS, а вовсе не реляционную базу данных и, как следствие, не поддерживает SQL-запросы и операции типа Join.
• Она предоставляет механизм просмотра данных для получения доступа к структурированным данным по имеющемуся ключу. GFS хранит данные не поддающиеся пониманию, хотя многим приложениям необходимы структурированные данные.
• Коммерческие базы данных попросту не могут масштабироваться до такого уровня и, соответственно, не могут работать с тысячами машин одновременно.
• С помощью контролирования своих низкоуровневых систем хранения данных, Google получает больше возможностей по управлению и модификации их системой. Например, если им понадобится функция, упрощающая координацию работы между датацентрами, они просто могут написать ее и внедрить в систему.
• Подключение и отключение компьютеров к функционирующей системе никак не мешает ей просто работать.
• Каждый блок данных хранится в ячейке, доступ к которой может быть предоставлен как по ключу строки или столбца, так и по временной метке.
• Каждая строка может храниться в одной или нескольких таблицах. Таблицы реализуются в виде последовательности блоков по 64 килобайта, организованных в формате данных под названием SSTable.
• В BigTable тоже используется три типа серверов:

  – Master: распределяют таблицы по Tablet-серверам, а также следят за расположением таблиц и перераспределяют задания в случае необходимости.

  – Tablet: обрабатывают запросы чтения/записи для таблиц. Они раделяют таблицы, когда те превышают лимит размера (обычно 100-200 мегабайт). Когда такой сервер прекращает функционирование по каким-либо причинам, 100 других серверов берут на себя по одной таблице и система продолжает работать как-будто ничего не произошло.

  – Lock: формируют распределенный сервис ограничения одновременного доступа. Операции открытия таблицы для записи, анализа Master-сервером или проверки доступа должны быть взаимноисключающими.

• Локальная группировка может быть использована для физического хранения связанных данных вместе, чтобы обеспечить лучшую локализацию ссылок на данные.
• Таблицы по возможности кэшируются в оперативной памяти серверов.

Оборудование

• Как эффективно организовать большую группу компьютеров с точки зрения издержек и производительности?
• Используется самое обыкновенное ультра-дешевое оборудование и поверх него строится программное обеспечение, способное спокойно пережить смерть любой части оборудования.
• Тысячекратный рост вычислительной мощности может быть достигнут с издержками в 33 раза меньшими, если воспользоваться толерантной к сбоям инфраструктурой, по сравнению с инфраструктурой, построенной на высоконадежных компонентах. Надежность строится поверх ненадежных компонентов.
• Linux, домашнее размещение серверов, материнске платы предназначенные для персональных компьютеров, дешевые средства хранения данных.
• Цена за каждый ватт энергии в расчете на производительность не становится меньше, что ведет к большим проблемам связанным с энергообеспечением и охлаждением.
• Использование совместного размещения в своих и арендуемых датацентрах.

Разное

• Быстрый выпуск изменений более предпочтителен, чем ожидание.
• Библиотеки — превалирующий метод построения программ.
• Некоторые приложения предоставляются в виде сервисов.
• Инфраструктура управляет определением версий приложений таким образом, что они могут выпускать новые продукты, не боясь сломать работу какого-либо компонента системы.

Пути развития

• Поддержка географически распределенных кластеров.
• Создание единого глобального пространства имен для всех данных. На данный момент данные распределены по кластерам.
• Более автоматизированные передача и обработка данных
• Решение вопросов, связанных с поддержанием работоспособности сервисов даже в тех случаях, когда целый кластер отключается от системы в связи с техническими работами или каким-либо сбоем в работе.

Подводим итоги

• Инфраструктура может быть конкурентным преимуществом. Это определенно так для Google. Они могут выпускать новые интернет сервисы быстрее, с меньшими издержками, на таком уровне, что мало кто сможет составить им конкуренцию. Подход многих компаний сильно отличается от подхода Google, эти компании рассматривают инфраструктуру как статью расходов, они обычно используют совсем другие технологии и совсем не задумываются о планировании и организации своей системы. Google позиционирует себя как компанию по построению систем, что является очень современным подходом к разработке программного обеспечения.
• Охватывание нескольких дата центров до сих пор является нерешенной проблемой. Большинство сайтов базируется в одном или двух дата центрах. Полное распределение сайта между несколькими датацентрами является хитрой задачей.
• Взгляните на Hadoop, если у Вас нет времени на собственноручное построение всей архитектуры с нуля. Hadoop явялется opensource воплощением в жизнь многих идей здесь представленных.
• Часто недооцениваемым преимуществом платформенного подхода является тот факт, что даже неопытные разработчики могут быстро и качественно реализовывать трудоемкие приложения на базе платформы. Но если бы каждый проект требовал одинаково распределенной архитектуры, то это создало бы много проблем, так как люди, которые понимают как это делается, являются достаточно большой редкостью.
• Совместная деятельность не всегда является таким уж плохим занятием. Если все части системы работают взаимосвязанно, то улучшение в одной из них сразу и абсолютно прозрачно отразится положительным образом и на остальных компонентах системы. В противном случае такой эффект наблюдаться не будет.
• Построение самоуправляемых систем позволяет более легко перераспределять ресурсы между серверами, расширять систему, отключать некоторые компьютеры и элегантно проводить обновления.
• Производить длительные операции стоит параллельно.
• Всему, что было сделано Google, предшествовало искусство, а не только крупномасштабное развертывание системы.
• Учитывайте возможность компрессии данных, она является очень неплохим решением, если остается лишнее процессорное время, но присутствует нехватка пропускной способности.