Развитие горизонтально масштабируемых систем

Развитие горизонтально масштабируемых систем

Колоссальный объем генерируемых данных и потребность экономично их хранить и обрабатывать вынуждают организации широко применять для этих задач горизонтально масштабируемые системы — кластеры серверов стандартной архитектуры без совместно используемых ресурсов (памяти, систем хранения и т. п.), связанные по протоколу TCP/IP и использующие параллельную модель распределенных вычислений, например MapReduce. Облака — предоставление по требованию горизонтально масштабируемых вычислительных ресурсов с оплатой по мере использования—являются идеальным инструментом организации обработки Больших Данных. Например, сервис Netflix хранит фильмы и сериалы, a Dropbox — файлы пользователей в Amazon Simple Storage Service. Сайт локального поиска Yelp пользуется не только облаком хранения Amazon, но и сервисом Amazon Elastic MapReduce для анализа пользовательского поведения. Похожие возможности предоставляют Microsoft Windows Azure и IBM SmartCloud Enterpriser Молодые компании (например, Cloudera, Hortonworks и MapR Technologies) разрабатывают как коммерческое ПО, так и решения на базе проекта Apache Hadoop.

В последние годы горизонтально масштабируемые хранилища данных на базе систем NoSQL быстро набирают популярность как решения для обслуживания крупномасштабных интернет-приложений. Среди таких хранилищ есть как коммерческие системы (Amazon DynamoDB, Google BigTable и PNUTS от Yahoo), так и системы с открытым кодом (Cassandra, HBase и MongoDB). Обычно эти хранилища предоставляют более скромные, в сравнении с реляционными СУБД, интерфейсы программирования (реализующие лишь операции создания, чтения, обновления и удаления) и ориентированы прежде всего на масштабируемость, гибкость и работу на стандартном оборудовании. Такие платформы особенно хороши для приложений, выполняющих относительно простые операции, но нуждающихся в гарантированно быстром отклике при масштабировании до больших размеров. Гибкость схем и эластичность, свойственные системам NoSQL, лишают их ограничений, присущих реляционным СУБД, но при этом приходится жертвовать частью гарантий ACID (Atomicity — атомарность, Consistency — согласованность, Isolation — изоляция, Durability — долговечность хранения). Соответственно, при реализации систем, обрабатывающих Большие Данные, возникают определенные сложности.

Модели данных и высокоуровневые абстракции

Реляционные модели данных и SQL создают уровень абстракции между базой данных и приложением — SQL позволяет составить запрос на понятном языке, а механизм исполнения оптимизирует его и автоматически ставит в очередь для запуска. Для анализа Больших Данных подобных решений нет. Хранилище на базе NoSQL поддерживает различные структуры данных (документ, граф, строка-столбец, пара «ключ — значение»), с которыми пользователю приходится работать напрямую. Программисту нужно знать физическую организацию данных и для манипуляций с ними пользоваться интерфейсами программирования, причем уникальными для каждого хранилища. В последнее время предпринимаются попытки создавать уровни SQL поверх NoSQL, но без абстрактной модели данных. Подобные проекты разрозненны, и каждый зависит от конкретной низкоуровневой технологии.

Инкрементальная обработка и приблизительный результат

Выполнить требование по обработке больших объемов данных с высокой скоростью непросто — в систему стремительно поступает огромное количество данных, и теми же темпами должны происходить и анализ, и интерпретация. В традиционном бизнес-анализе транзакционные данные вначале обрабатываются в системе оперативной обработки транзакций (OnLine Transaction Processing, OLTP), а затем в пакетном режиме передаются механизму извлечения, преобразования и загрузки (Extract — Transform — Load, ETL). В конечном счете данные загружаются в хранилище для оперативной аналитической обработки (OnLine Analytical Processing, OLAP), где происходит извлечение ценных для бизнеса знаний. При использовании цепочки OLTP — ETL — OLAP оперативность приносится в жертву точности, поскольку между поступлением данных и извлечением знаний проходит довольно много времени.

В некоторых системах Больших Данных, например в механизмах распознавания финансовых мошенничеств и автоматизации маркетинга, длительные задержки недопустимы. Появившаяся недавно парадигма поточных вычислений подразумевает непрерывную обработку потоковых данных — например, лент социальных СМИ или журналов работы оборудования. Поточные вычисления—это шаг к аналитике реального времени, сопряженный со своими сложностями, и одна из них состоит в балансировке между построением модели обработки и просмотром потоков в реальном времени. С одной стороны, накопленные исторические данные помогают построить статистическую модель для управления потоковой обработкой — например, определиться, за какими именно показателями надо следить и какие выбрать пороговые значения. С другой, вновь поступившие данные из потока должны использоваться для подстройки этой модели, чтобы она отражала последние тенденции. Важнейшим элементом этой балансировки является механизм инкрементальной обработки данных и подстройки модели.

Еще одно возможное решение проблемы объема и скорости — выдавать оперативные, но приблизительные результаты на запросы, либо приоритизировать различные запросы, выделяя им разный объем ресурсов. В этом случае возможны различные уровни согласованности данных: одни результаты будут точными, но медленными, другие — приблизительными, но быстрыми.

NoSQL, масштабируемый SQL и NewSQL

Для преодоления трудностей обработки Больших Данных создатели систем NoSQL ослабляют ограничения ACID, реализуют свободно масштабируемые решения с базовыми функциями СУБД, а затем постепенно добавляют особенности, присущие реляционным системам, например поддержку индексации и транзакций. Эту тенденцию можно наблюдать на примере эволюции Google BigTable в Spanner.

Разработчики реляционных СУБД, в свою очередь, меняют архитектуру для расширения масштабирования путем создания среды без разделения ресурсов. Добавляются механизмы автоматического секционирования и масштабирования данных, а также возможность пожертвовать согласованностью ради быстродействия. Есть также так называемые проекты NewSQL, в рамках которых предпринимаются попытки модернизировать архитектуру реляционной СУБД, чтобы обеспечить ей масштабируемость и быстродействие NoSQL с сохранением гарантий ACID, присущих традиционным одноузловым базам данных.

Требуется составить рекламную компанию? Обратитесь к холдингу Интервидео,  качественная реклама interkaluga.ru поможет вам провести вашу рекламную компанию к успеху.