Distributed File System, DFS) широко
Распределенные файловые системы ( Distributed File System, DFS) широко используются в поисковых системах для хранения огромного объема данных, собираемых в Internet, поскольку DFS обеспечивают масштабируемое, надежное и экономичное решение хранения данных. Компании, специализирующиеся на разработке поисковых систем, также создают на основе DFS параллельные вычислительные платформы для параллельного выполнения крупномасштабного анализа данных, сохраняемых в DFS. Например, у Google имеются GFS [10] и MapReduce [8]. Yahoo! использует Hadoop [11] – реализацию с открытыми исходными текстами, выполненную Apache Software Foundation и основанную на GFS и MapReduce компании Google. Компания Ask.com построила Neptune [5]. У Microsoft имеются Dryad [13] и Scope [4].
Hadoop привлекает внимание большого сообщества пользователей по причине открытости кодов и наличия серьезной поддержки со стороны Yahoo!. В Hadoop файлы разбиваются на блоки, и каждый блок несколько раз реплицируется в разных узлах для обеспечения отказоустойчивости и распараллеливания вычислений. Обычно Hadoop выполняется в кластерах, построенных на основе недорогой аппаратуры массового спроса. Hadoop легко устанавливается, и системой просто управлять. Загрузка данных в DFS производится более эффективно, чем в параллельную СУБД [15].
Текущая тенденция состоит в том, что компании начинают использовать Hadoop для крупномасштабного анализа данных. Хотя для начала использования Hadoop требуются совсем небольшие расходы, обычно Hadoop MapReduce значительно уступает параллельным СУБД в производительности: Hadoop в 2-3 раза медленнее, чем параллельная СУБД, решает простейшую задачу подсчета числа вхождений разных слов в файле/таблице, и в десятки раз медленнее справляется с более сложными задачами анализа данных [15]. Кроме того, программы MapReduce для сложного анализа данных пишутся гораздо дольше, чем соответствующие SQL-запросы. Нам известно, что одна из крупных Internet-компаний, имеющая крупные кластеры с Hadoop, переходит к использованию параллельной СУБД для производства некоторых наиболее сложных аналитических отчетов, поскольку руководители компании не удовлетворены тем, что в обстановке постоянно изменяющихся и усложняющихся бизнес-требований им приходится ждать по несколько дней, пока будут написаны и отлажены требуемые сложные программы MapReduce.
С другой стороны, из-за того, что в вычислительных центрах некоторых заказчиков Teradata в последние годы наблюдается быстрый рост объемов данных, некоторые данные, такие как Web-журналы, детальные данные об обращениях клиентов, сенсорные данные и данные RFID не управляются Teradata EDW. Частично это связано с очень высокой стоимостью загрузки этих исключительно объемных данных в РСУБД, особенно, если эти данные не слишком часто используются для поддержки принятия важных бизнес-решений.
Некоторые заказчики Teradata для хранения своих исключительно объемных данных используют DFS, поскольку DFS обеспечивают им ряд преимуществ. Например, одна из основных компаний, специализирующаяся на производстве телекоммуникационного оборудования, планирует протоколировать все действия пользователей по отношению ко всем своим устройствам, и журналы исходно будут сохраняться в DFS, но в конечном счете некоторые или все эти журналы должны будут управляться параллельной СУБД для выполнения над ними сложного бизнес-анализа.
Тем самым, у крупных компаний, имеющих данные, которые сохраняются в DFS и в Teradata EDW, имеется сильная бизнес-потребность в интеграции бизнес-анализа над данными обоих типов. Аналогичным образом, те компании, которые изначала стали использовать низкозатратный подход Hadoop, а теперь нуждаются в использовании параллельной СУБД, подобной Teradata, для обеспечения более высокой производительности и более развитых функциональных возможностей, испытывают насущную потребность в средствах интегрированного анализа данных Hadoop и данных, хранимых в Teradata EDW.
Очевидно, что первым важным шагом, требуемым для интеграции бизнес-анализа над данными, хранимыми в средах Hadoop и Teradata EDW, является обеспечение эффективной пересылки данных между этими средами. Прямолинейный подход, не требующий каких-либо новых разработок ни со стороны Hadoop, ни со стороны Teradata EDW, заключается в использовании имеющихся утилит загрузки и экспорта: файлы Hadoop можно скопировать в обычные файлы, которые можно загрузить в Teradata EDW, а таблицы из Teradata EDW можно экспортировать в файлы, которые можно загрузить в Hadoop (или использовать в потоковом стиле без материализации промежуточных файлов).
Однако одной из общих черт Hadoop и Teradata EDW является то, что данные в обеих системах для обеспечения параллельной обработки разделяются по нескольким узлам, что обеспечивает возможности оптимизации, недоступные для СУБД, выполняющихся в одном узле. В этой статье мы описываем три свои работы, направленные на достижение тесной и эффективной интеграции Hadoop и Teradata EDW.
Мы обеспечиваем утилиту полностью параллельной загрузки, называемую DirectLoad, для эффективной загрузки данных Hadoop в Teradata EDW. Ключевая идея подхода DirectLoad состоит в том, что сначала мы приписываем каждый блок данных файла Hadoop некоторому параллельно компоненту Teradata EDW, а затем напрямую параллельно загружаем данные в параллельные компоненты. Для поддержки подхода Teradata EDW мы также применяем внутри Teradata EDW новые методы для минимизации перемещения данных между узлами.
Мы обеспечиваем коннектор для Hadoop под названием TeradataInputFormat, который позволяет программам MapReduce напрямую читать данные из Teradata EDW через драйверы JDBC без потребности в каких-либо внешних шагах экспортирования данных (из СУБД) и их загрузки в Hadoop. TeradataInputFormat инспирирован подходом DBInputFormat [7], разработанным компанией Cloudera [6], но не основывается на нем. В отличие от подхода DBInputFormat, в котором каждый Mapper посылает в СУБД некоторый бизнес-запрос, представленный на SQL (и, таким образом, этот SQL-запрос выполняется столько раз, сколько имеется Mapper'ов Hadoop), коннектор TeradataInputFormat посылает в Teradata EDW бизнес-запрос только один раз, этот SQL-запрос выполняется только единожды, и каждый Mapper в параллель получает некотрую часть результатов прямо из узлов Teradata EDW.
Мы обеспечиваем табличную UDF (User Defined Function – определяемая пользователями функция), которая при вызове из любого стандартного SQL-запроса выполняется в каждом параллельном компоненте Teradata EDW для параллельной выборки данных Hadoop прямо из узлов Hadoop. Любые реляционные таблицы можно соединить с данными Hadoop, выбираемыми этой табличной UDF, и любое средство бизнес-анализа, обеспечиваемое процессором SQL Teradata, можно применить как к реляционным данным, так и к данным Hadoop.Не требуются какие-либо внешние шаги для экспортирования данных Hadoop и их загрузки в Teradata EDW.
Оставшаяся часть статьи организована следующим образом. В разд. 2, 3 и 4 мы обсуждаем по очереди три вышеупомянутых подхода. В разд. 5 мы обсуждаем родственные работы. Разд. 6 содержит заключение.
