Эволюция масштабируемости аналитических систем

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

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

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

Хочу еще раз напомнить, что данная книга — не практическое пособие. Эта глава, а также главы 5 и 6 посвящены техническим деталям, однако они рассматриваются на концептуальном уровне, поэтому вне зависимости от подготовки вы сможете разобраться в концепциях. Некоторые вопросы излагаются очень упрощенно. При необходимости более детально разобраться в той или иной теме вы можете обратиться к другим, специализированным книгам.

История масштабируемости

Вплоть до 1900-х годов проведение анализа было очень, очень трудной задачей. Глубокий анализ, связанный, скажем, с моделью прогнозирования, требовал вычисления вручную всех статистических данных. Для выполнения линейной регрессии следовало вручную вычислить матрицу, а затем — также вручную — обратную матрицу. Все остальные вычисления, необходимые для оценки параметров, производились вручную или с помощью простейших механических счетных машин. Сто и более лет назад собрать данные было очень трудно, но использовать их было еще труднее. Ни о какой масштабируемости не могло быть и речи.

Логарифмические линейки со временем облегчили положение, а в 1970-х годах появились калькуляторы, которые упростили процесс использования большего объема данных. Однако объем данных, который можно обработать с помощью калькулятора, все еще был очень небольшим. Компьютеры, которые получили распространение в 1980-х годах, позволили людям навсегда забыть о произведении вычислений вручную. Хотя компьютеры существовали и до 1980-х годов, они были доступны только избранным, а работа с ними была сложна и связана с большими затратами.

По прошествии десятилетий объем данных вышел далеко за рамки того, что человек в состоянии обработать вручную. Количество данных росло так же быстро, как и вычислительная мощность машин, которые использовались для их обработки. И хотя нет необходимости напрягаться и до головной боли производить вычисления вручную, очень легко перегрузить компьютер и систему хранения данных.

Технология продолжала развиваться такими темпами, что объем данных возрастал год от года. Десять лет назад обработка терабайта данных была доступна только крупнейшим компаниям и богатейшим правительствам. В 2000 году организация, у которой в базе данных содержался терабайт данных, считалась передовой. Теперь вы можете купить терабайтный диск для вашего компьютера за $100! В 2012 году даже многие небольшие компании имели системы, содержащие терабайт данных или больше. Объем данных передовых компаний сегодня измеряется в петабайтах*. Это тысячекратное увеличение всего за десять лет!

Более того, появление новых источников больших данных раздвигает границы еще шире. Многие источники больших данных могут генерировать от терабайта до петабайта данных за несколько дней или недель, а то и часов. В настоящее время испытываются пределы того, что может быть обработано. Тем не менее со временем волна больших данных будет укрощена так же, как в прошлом были укрощены другие пугающие потоки данных.

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

Они также будут ожидать получения ответов в течение секунд или минут, а не часов или дней. В табл. 4.1 приведены известные на сегодняшний день единицы измерения объема данных, а также значения, следующие за ними по данной шкале. Люди, которые первыми использовали предельные объемы данных, получали в прошлом значительные преимущества, и так будет продолжаться и в дальнейшем.

Таблица 4 .1

Единицы измерения объема данных

* Петабайт — единица измерения количества информации, равная 1015 байт.
** Эксабайт — единица измерения количества информации, равная 1018 байт.
*** Зеттабайт — единица измерения количества информации, равная 1021 байт.

Слияние аналитической среды со средой данных

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

Существует любопытная параллель между тем, чем занимались аналитики в самом начале, и тем, что собой представляют хранилища данных. Многих людей удивляет это. Аналитики в течение многих лет работали с «наборами данных». Между «набором данных» и «таблицей» в базе данных существует не так уж много различий. И набор данных, и таблица содержат строки и столбцы. Часто одна строка представляет некую сущность, например потребителя. Столбцы заключают в себе информацию о потребителях, например имя, уровень расходов или статус.

Аналитики годами производили «слияние» наборов данных, а это то же самое, что «соединение» таблиц в базе данных. В обоих случаях происходит объединение двух или более наборов данных или таблиц. Как правило, это делается для того, чтобы объединить конкретные строки одного набора данных или таблицы со строками другого набора или таб лицы. В нашем примере с потребителем один набор данных / таблица может содержать демографические данные, а другой — информацию о расходах. При объединении наборов данных / таблиц демографические данные и сведения о расходах по каждому потребителю оказываются в одном и том же месте.

Аналитики занимаются тем, что называется «подготовкой данных». Этот процесс подразумевает сведение воедино всех данных из различных источников для создания необходимых для проведения анализа переменных. В случае с хранилищами данных этот процесс называется «извлечение, преобразование и загрузка данных (ETL)». По сути, аналитики создавали пользовательские витрины данных и мини-хранилища данных еще до того, как появились термины «витрины данных» или «хранилища данных»! Просто они это делали при работе над каждым проектом для собственного пользования, а не для использования другими.

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

Системы управления реляционными базами данных (СУРБД) начали становиться не только популярными, но и более масштабируемыми и широко применяемыми. Сегодня СУРБД — стандарт управления данными. Бóльшая часть данных, используемых в настоящее время в процессе анализа, берется из реляционных баз данных. Исключение составляет обработка неструктурированных данных с помощью парадигмы MapReduce, о которой говорится далее в этой главе в разделе под названием «Модель MapReduce».

Мощь централизации

Тенденция использования централизованных корпоративных хранилищ данных сильно повлияла на сферу передовой аналитики. Когда данные находятся в одном и том же месте, нет необходимости заниматься их объединением перед проведением анализа. Данные уже ждут, чтобы их проанализировали! Это обеспечивает новый уровень масштабируемости и огромные возможности.

Поначалу базы данных, которые имели аналитические системы, создавались для каждой конкретной цели или команды, а реляционные базы данных распространялись по всей организации. Такие одноцелевые базы данных часто называют «витринами данных». Хотя многие организации до сих пор используют витрины данных, ведущие организации предпочитают объединять различные системы баз данных в одну большую систему, называемую корпоративным хранилищем данных (КХД).

Цель КХД заключается в том, чтобы собрать все важные корпоративные данные в одной центральной базе данных. Это дает возможность объединить различные сведения, что позволяет создавать отчеты и смешивать данные, относящиеся к разным темам или предметным областям. Данные, касающиеся маркетинга, больше не отделены от финансовых данных.

Вот где начинается самое интересное! Как только все данные оказываются в одном и том же месте, больше не существует разнородных источников, которые необходимо объединять для проведения анализа.

Кроме того, там, где собраны все данные, можно проводить более подробный анализ. Рис. 4.1 и 4.2 иллюстрируют разницу между старым и новым способами ведения дел.

Рис. 4.1-4.2. Традиционная и современная архитектура аналитической системы

В среде корпоративного хранилища данных аналитических систем бóльшая часть источников данных уже собрана в одном месте. Если некоторые мелкие фрагменты данных отсутствуют в КХД, то нет смысла собирать 90–95% данных, находящихся в корпоративном хранилище данных, и сопоставлять их в режиме офлайн с остальными 5–10%. Гораздо целесообразнее поместить остальные 5–10% данных в КХД и проанализировать все данные там. Другими словами, проще наладить процесс анализа там, где находятся данные, вместо того чтобы перемещать данные туда, где находятся средства анализа. В этом заключается суть концепции аналитики, встроенной в базу данных.

Модернизируйте архитектуру

Зачем тратить время, усилия и деньги на перемещение данных в среду для анализа, когда можно переместить средства анализа в среду данных? Эта простая предпосылка, лежащая в основе концепции аналитики, встроенной в базу данных, оказывает огромное влияние на масштабируемость. Без использования аналитики, встроенной в базу данных, укротить большие данные намного сложнее.

Корпорация Teradata первой стала развивать встроенную в базу данных аналитику в 1990-х годах, однако сегодня эту концепцию используют все поставщики баз данных. Корпоративные хранилища данных и витрины данных на сегодняшний день достаточно масштабируемы и гибки, чтобы обеспечить возможность проведения анализа в базе данных. Это особенно актуально для массивно-параллельных систем обработки, о которых пойдет речь далее. Ключевая идея, как уже говорилось, состоит в перемещении средств анализа в среду данных вместо перемещения данных в среду для проведения анализа. Позвольте системе баз данных делать то, что она делает лучше всего, — обрабатывать большие массивы информации.

Студенты университетов сегодня мало что знают о мейнфреймах и не могут представить себе способа проведения анализа с использованием ленточных накопителей. А вскоре студентам будет непонятно, почему среда для проведения углубленного анализа и среда данных когда-то были разделены. Для них не окажется различий между средами хранения и анализа данных. Эти среды станут представлять для них одно и то же. Так и должно быть!

См. в Библиотеке: Укрощение больших данных / Билл Фрэнкс.