И анализ больших данных
жүктеу/скачать 2,33 Mb. Pdf көрінісі
|
|
3.3 Системы для больших данных: конвергенция архитектур Происходящий последние десять лет экспоненциальный рост объемов данных привел к появлению нового класса систем, их обрабатывающих, а на переднем крае здесь оказались онлайн-компании, такие как Google и Amazon, работающие с огромными репозиториями данных. Системы, работающие с большими объемами данных, традиционно строились на реляционных СУБД, которые по мере роста нагрузки и потребностей в хранении масштабируются в основном вертикально за счет более быстрых процессоров и накопителей. В связи с присущими таким базам ограничениями вертикального масштабирования появились новые продукты, нестрого выполняющие фундаментальные требования к СУБД. Жестко заданные модели данных, обеспечивающие надежные гарантии консистентности данных (требование, согласно которому все клиенты при считывании получают одни и те же данные) и строгое следование стандарту SQL, уступили место моделям, лишенным жестких схем и преднамеренно денормализованным, со слабой консистентностью и с проприетарным API. Распределенные базы данных имеют фундаментальные ограничения с точки зрения качества обслуживания, определяемые теоремой CAP Эрика Брюера о консистентности, доступности (на каждый запрос возвращается отклик об успешном выполнении либо отказе) и устойчивости к разделению. Когда происходит разделение сети, вызывающее потерю связи между узлами кластера, система должна принести консистентность в жертву доступности. Дэниел Абади предлагает PACELC — практическую интерпретацию теоремы CAP: если происходит разделение (P), система обязана принести доступность (A) в жертву консистентности (C). Иначе (E) в обычной ситуации отсутствия разделения система обязана принести в жертву задержку (L) в пользу консистентности (C). Трудности проектирования масштабируемых систем обработки больших объемов данных обусловлены тремя проблемами. Во-первых, достижение высокой масштабируемости и доступности требует наличия сильно распределенных систем на всех уровнях, от ферм веб-серверов и систем кэширования до систем хранения данных. Во- вторых, при большом масштабе трудно с помощью SQL-подобного языка запросов обеспечить абстрактную репрезентацию системы как единого целого — с транзакционными операциями записи и консистентным считыванием. Приложения должны: «знать» о существовании копий данных; компенсировать несоответствия, возникающие при конфликтующих обновлениях копий; продолжать работу, несмотря на неизбежные сбои процессоров, сетей и программных систем. В-третьих, при использовании любой NoSQL-системы приходится идти на определенные компромиссы, обычно выбирая между быстродействием, масштабируемостью, надежностью и консистентностью. Архитекторы должны тщательно оценивать имеющиеся технологии баз данных и выбирать те из них, которые в наибольшей степени подходят для конкретного приложения. Нередко прибегают к использованию разных технологий для хранения различных срезов данных в пределах одной и той же системы, чтобы удовлетворить соответствующие требования к атрибутам качества. 25 Особенности приложений для работы с большими данными Приложения работы с Большими Данными проникают во многие области, и одна из них — аэронавигация. Современные коммерческие авиалайнеры генерируют по 500 Гбайт операционных данных за рейс, необходимых для диагностики неполадок в реальном времени, оптимизации расходов топлива и прогнозирования потребностей в ремонтно-техническом обслуживании. Для повышения безопасности и снижения затрат авиакомпаниям необходимо создавать масштабируемые системы с целью регистрации данных, их анализа и управления ими. Еще одна область — здравоохранение, где, по некоторым оценкам, средства анализа Больших Данных могли бы принести экономию 450 млрд долл. (данные для США. — Прим. перев.). Анализ петабайтов данных по пациентам, накапливаемых в страховых компаниях, медицинских учреждениях и клинических исследованиях, поможет снизить затраты за счет повышения результативности лечения. Кроме того, аналитические системы позволят получать новые знания, помогающие в лечении и предотвращении заболеваний. Для всех систем работы с Большими Данными характерны четыре общих требования, которые нужно учитывать при проектировании и которые в совокупности вынуждают существенно отклониться от архитектуры традиционных бизнес-систем, имеющих ограничения на рост объема данных и функциональности. Во-первых, системы Больших Данных, от сайтов социальных СМИ до датчиков в энергосетях, должны справляться с большим объемом операций записи. Поскольку запись затратнее, чем считывание, можно пользоваться сегментированием данных (секционированием и распределением), чтобы разделять операции записи между накопителями, а для обеспечения высокой доступности можно прибегать к тиражированию. Однако операции сегментирования и тиражирования создают проблемы с доступностью и консистентностью, которые надо как-то компенсировать. Второе требование — способность справляться с переменной нагрузкой. Уровень загрузки в коммерческих и государственных системах может сильно варьироваться: распродажи, экстренные ситуации, сдача налоговых деклараций и т. п. Чтобы избежать затрат на резервные ресурсы на случай подобных эпизодических скачков, облачные платформы делаются эластичными, позволяя приложениям подключать новые ресурсы для распределения нагрузки и высвобождать их, когда уровень загруженности падает. Для эффективного использования этого механизма нужны архитектуры, способные распознавать скачки нагрузки на различные приложения, быстро добавлять новые ресурсы и высвобождать их по мере необходимости. Третье требование — возможность выполнения аналитики с большим объемом вычислений. Большинство систем Больших Данных должны справляться с комбинированными рабочими задачами, когда часть запросов требует быстрого ответа, а жүктеу/скачать 2,33 Mb. Достарыңызбен бөлісу:
|