Любая компания, рассматривающая свои данные в качестве ценного актива, который постоянно используется при принятии решений, сталкивается с проблемой роста объемов данных и необходимостью работы с разнообразными форматами и структурами. На начальном этапе своего развития компания может вести учет ресурсов и финансовых транзакций в электронных таблицах, а в случае роста числа транзакций развернуть полноценную реляционную базу данных с разграничением доступа и запустить автоматизированную систему управления предприятием. Постепенно, с увеличением объемов данных происходит осознание необходимости выделения аналитических задач в отдельный изолированный контур — так появляется хранилище данных. До этого момента данные еще могут быть представлены в табличной структуре, и перед подразделением ИТ пока стоят типовые регламентные задачи, связанные с масштабированием вычислительной мощности платформы и обеспечением бесперебойной доступности данных. Компания продолжает развиваться — появляются новые системы, генерирующие новые форматы данных (например, журналы посещения сайтов или показания сенсорных датчиков), которые логично использовать для аналитики. В результате подразделению ИТ поручают интегрировать новые форматы, создавать новые приложения аналитики, и тут есть два варианта. Можно и дальше развивать аппаратную мощность хранилища и наращивать слой трансформаций и приведения данных к нормальным формам, еще до конца не понимая, как эти данные будут использоваться в аналитике. А можно просто загрузить пока все данные как есть в файловую систему, сместив логику преобразований на уровень семантического слоя, применив, таким образом, обратный подход в работе с данными, при котором схема размещения данных объявляется в момент обращения к ним (scheme on read). Второй вариант выглядит привлекательнее, так как дает большую гибкость в планировании ресурсов, однако он не применим там, где постоянно необходим высокий уровень обслуживания, — без жесткой схемы размещения данных сложно гарантировать требуемый показатель производительности системы.

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

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

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

По мере развития компании департамент ИТ все больше выполняет роль оператора хранилища, фокусируясь на вопросах эксплуатации и обслуживания. Понятно, что бизнес мечтает об одной кнопке, нажав на которую можно решить сразу все проблемы. Но если раньше соблюдался своего рода паритет, когда производители предлагали инструменты и знания по их правильному использованию, а заказчик был носителем экспертизы, настраивал правила и наполнял их контентом, то сейчас заказчик уже не в состоянии эффективно использовать инструменты настройки, одновременно инвестируя в знание множества технологий. В результате заказчик обращается к интегратору с просьбой обеспечить среду, в которой уже будут заложены возможности реализации его функциональных требований. Роль интеграции компонентов сегодня возросла как никогда: успешная интеграция компонентов определяет успешность реализации проекта в целом.

В качестве средства интеграции компания Teradata представила методологию Unified Data Architecture [1], определяющую набор связанных воедино компонентов и инструментов обработки данных. Задача TUDA — обеспечить выполнение любого запроса с использованием любых типов данных и любых инструментов в любой момент времени. Для хранения любых типов данных предлагается три процессорных «движка», реализованных на архитектуре массово-параллельной обработки: классическая реляционная СУБД Teradata 15, платформа исследования данных Teradata Aster 6 и сборка кластерной файловой системы Teradata Appliance for Hadoop 4.

Классическая база данных подходит для решения задач аналитики, когда заранее понятна схема размещения структурированных данных, развитие схемы идет предсказуемо стабильно и можно использовать индустриальную модель данных для ее поддержки и развития. Платформа Aster содержит не только специализированную реляционную базу с поддержкой безразмерных типов данных и предустановленный на уровне базы данных набор функций MapReduce, но и собственную файловую систему, схожую по API с Hadoop и используемую для размещения данных вне базы. Для  расширения  методологии TUDA предлагается сборка системы Hadoop, которая в большей степени позиционируется как платформа для решения утилитарных задач предобработки и хранения исторических данных. Целесообразность использования той или иной платформы определяется решаемой задачей, типами данных и доступными инструментами обработки. Если данные изначально структурированы, то, например, для хранения исторических данных стоит использовать аппаратно-программное решение Teradata 1700 с классической базой, которая по цене сопоставима с кластером Hadoop.

Несмотря на то что каждая из платформ самодостаточна, для построения экосистемы логического хранилища данных на их основе нужна единая унифицированная среда функционирования, контроля и управления. Такой межсистемной средой взаимодействия платформ стала Teradata QueryGrid (см. рисунок), представляющая собой функциональный набор операторов баз данных и функций-коннекторов, обеспечивающих выполнение любого SQL-запроса вне зависимости от того, где физически размещены данные: в Teradata, Aster или Hadoop. При этом классическая база может быть представлена как шлюз, с которым соединяется конечный потребитель данных, а уже оптимизатор Teradata определит, какую часть запроса на какой платформе необходимо выполнить.

 

Teradata QueryGrid
Teradata QueryGrid

 

Среда QueryGrid помогает реализовать нужный уровень абстракции при создании аналитических приложений, позволяя оптимизировать и упростить единое управление обработкой данных в рамках TUDA. Это означает, что разработчик аналитического приложения может: использовать преимущества специализированной платформы для работы с логикой размещения и обработки данных; избежать излишнего тиражирования данных между платформами — запросы могут выполняться над данными вне зависимости от места их размещения; унифицировать доступ в виде понятного всем языка SQL с использованием табличных операторов.

В основе QueryGrid лежат: физическое соединение всех платформ по единому каналу InfiniBand на аппаратном уровне, технология табличных операторов на программном уровне и непосредственно программные функции-коннекторы, реализованные по технологии табличных операторов. Табличные операторы впервые были представлены в Teradata 14.10, а в версии 15 получили дальнейшее развитие. Расширяя стандартные возможности пользовательских функций UDF в базе данных, табличный оператор позволяет реализовать функцию, на входе и выходе которой таблица. С таким подходом появляется гибкость процедурного программирования — на вход одного оператора можно подать результат работы другого или соединить его с обычной таблицей. Фактически этот механизм позволяет реализовать парадигму Map/Reduce в реляционной базе данных Teradata — оператор обрабатывает не строку базы данных, а блок. При этом сохраняется преимущество использования платформы с параллельной обработкой — каждый экземпляр функции-оператора выполняется параллельно на своем логическом участке  дискового пространства базы данных. В Aster и Hadoop возможность установки пользовательских табличных операторов в виде библиотек функций на Cи и Java существует изначально, а теперь эти пользовательские библиотеки можно устанавливать и в Teradata.

В рамках развития идеи QueryGrid была расширена поддержка разнообразных языков программирования. Добавлена специальная функция — табличный оператор SCRIPT, — позволяющая запускать пользовательские скрипты на любых языках, включая Ruby, Python, Perl и R. Созданы специальные команды установки скриптов в базу данных, причем в качестве таких UIF (User Installed Files) могут быть скрипты, файлы конфигурации, текстовые файлы, бинарные или плоские файлы, что в итоге расширяет инструментарий разработчика аналитических приложений. Возможность установки UIF напрямую на узлы — обработчики базы данных позволяет избежать многократного обмена промежуточными результатами между СУБД и сервером приложений, возложив подготовку конечного набора данных на производительную платформу базы данных и оставив серверу приложений только задачу визуализации результата.

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

C выпуском Teradata 15 упрощен и унифицирован механизм вызова функций-коннекторов. Если раньше в каждом вызове нужно было объявлять параметры вызова внешнего кластера, такие как IP-адрес пользователя и пароль, то теперь создан специальный объект, позволяющий определить все внешние серверы, к которым требуется установить подключение при выполнении SQL-запроса. Новые правила определения серверов используются и в новых версиях функций импорта и экспорта. Также возможно описание множественных объектов базы данных для одного и того же внешнего сервера с разными свойствами, чтобы обеспечить доступ к ним разным пользователям.   Кроме того, имеются отдельные хранимые процедуры для создания и удаления таблиц на стороне Hadoop — это позволяет создавать таблицы и наполнять их в Hadoop из Teradata, используя только SQL.

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

***

Пользователи хранилищ данных все чаще требуют от ИТ-подразделений реализации полномасштабной инфраструктуры для будущей  бизнес-системы, однако эффективность приложений часто зависит от того, где физически размещены данные. Главный принцип QueryGrid — кросс-платформность, предполагающая, что любая платформа может стать поставщиком данных по мере появления новых функций-коннекторов. Например, недавно компании Teradata и MongoDB заключили соглашение о создании высокоскоростного двунаправленного коннектора обмена данными между своими СУБД на основе формата обмена данными JSON (JavaScript Object Notation).

Литература

  1. Михаил Ганюшкин. Вам TUDA // Открытые системы.СУБД. — 2013. — № 2. — С. 27–29. URL: http://www.osp.ru/os/2013/02/13034552 (дата обращения 18.09.2014).

Михаил Ганюшкин (Mikhail.Ganyushkin@Teradata.com) — архитектор решений, компания Teradata (Москва).