Параллельная загрузка данных Hadoop в Teradata EDW
В этом разделе мы представляем подход DirectLoad, который мы разработали для эффективной параллельной загрузки данных Hadoop в Teradata EDW. Сначала мы кратко описываем утилиту/протокол FastLoad [2], широко используемую в производственных условиях для загрузки данных в таблицы Teradata EDW. Клиент FastLoad, прежде всего, подключается к процессу Gateway, выполняющемуся в одном из узлов системы Teradata EDW, которая представляет из себя кластер узлов. Клиент FastLoad образует столько сессий, сколько указывается пользователем Teradata EDW. Каждый узел в системе Teradata EDW конфигурируется таким образом, что в нем выполняется несколько виртуальных параллельных компонентов, называемых AMP (Access Module Processor – процессор модуля доступ) [2]. В Teradate AMP является единицей параллелизма; он отвечает за выполнение сканирования, соединений и других задач управления данными над данными, которыми он управляет. Каждая сессия управляется одним AMP, и число сессий, образуемых клиентом FastLoad, Teradata EDW не может превосходить число AMP. Программное обеспечение Teradata Gateway является интерфейсом между Teradata EDW и клиентами, подключенными к сети. Процессы Teradata Gateway обеспечивают коммуникации и управляют ими, а также сообщениями клиентов и шифрованием.
После образования сессий клиент FastLoad посылает пакеты строк в подключенный процесс Gateway, адресуя их в циклическом стиле этим сессиям. Gateway перенаправляет строки в AMP-получатель, ответственный за сессию, которой адресованы эти строки, а затем AMP-получатель вычисляет для каждой строки значение хэш-функции (это значение вычисляется с использованием системной хэш-функции на столбце первичного индекса, задаваемой создателем таблиц или выбираемой автоматически системой баз данных). На основе вычисленных хэш-значений AMP-получатель посылает полученные им строки соответствующим целевым AMP, которые будут хранить эти строки в Teradata EDW. Для каждой строки, посылаемой клиентом FastLoad, AMP-получатель и Gateway могут располагаться в разных узлах.
Целевой AMP и AMP- получатель могут быть разными AMP и также могут выполняться в разных узлах. В действительности, для большинства строк, посылаемых клиентом FastLoad с использованием нескольких сессий, Gateway и AMP-получатель выполняются в разных узлах, и AMP-получатель и целевой AMP также выполняются в разных узлах.
При загрузке в Teradata EDW разделенного файла DFS, сохраняемого в нескольких узлах Hadoop, возникают возможности оптимизации, которые отсутствуют при использовании СУБД, выполняемой в одном SMP-узле, или традиционного подхода FastLoad. Основная идея нашего подхода DirectLoad состоит в устранении двух пересылок данных, присутствующих в существующем подходе FastLoad. Первая пересылка выполняется от процесса Gateway к AMP-получателю, а вторая – от AMP-получателя к целевому AMP. В нашем подходе DirectLoad клиенту разрешается посылать данные в любой AMP-получатель, указываемый клиентом DirectLoad (в отличие от циклического подхода, реализованного в FastLoad). Поэтому мы можем устранить пересылку от Gateway к AMP-получателю за счет использования только AMP-получателей в том же узле, к которому подключен клиент DirectLoad.
Для описания того, как работает подход DirectLoad, мы используем следующий простейший случай. Сначала мы решаем, какую часть файла Hadoop должен получить каждый AMD, а затем образуем столько заданий DirectLoad, сколько AMD имеется в Teradata EDW. Каждое задание DirectLoad подключается к некоторому процессу Gateway, читает назначенную ему часть файла Hadoop с использованием API Hadoop, и пересылает данные подключенному процессу Gateway, который посылает данные Hadoop только одному уникальному AMP в том же узле Teradata. Так можно сделать, потому что каждому заданию DirectLoad известно, к какому процессу Gateway/узлу он подключен, и он может попросить Teradata EDW обнаружить список AMD, поддерживаемых в том же узле.
Поскольку нас более всего интересует быстрая пересылка данных из Hadoop в Teradata EDW, мы делаем каждый AMD-получатель целевым AMD, управляющим полученными им строками.
Таким образом, вычислять значения хэш- функции на строках не требуется, и вторая пересылка в подходе DirectLoad устраняется. Однако при этом мы поступаемся тем, что над загружаемыми данными Hadoop не строится какой-либо индекс. Задания DirectLoad можно сконфигурировать таким образом, чтобы они выполнялись в системе Hadoop или же в системе Teradata EDW. Мы опускаем здесь обсуждение того случая, когда пользователю не угодно запускать столько заданий DirectLoad, сколько имеется AMP.
Наши предварительные эксперименты показывают, что DirectLoad может существенно превзойти FastLoad по производительности. В тестовой системе, которую мы использовали для экспериментов, имелось 8 узлов. В каждом узле имелось 4 процессора Pentium IV 3.6 GHz, 4 гигабайта основной памяти и два устройства с жесткими дисками, выделенных для использования в Teradata. Два других дисковых устройства предназначались для использования операционной системой и системой Hadoop (версия 0.20.1). В одной и той же тестовой системе функционировали и Teradata EDW, и Hadoop. В каждом узле запускались два AMP, чтобы можно было с пользой применять оба дисковых устройства, выделенных для целей Teradata.
Мы выполнили два эксперимента. В обоих экспериментах в одном задании FastLoad для загрузки данных Hadoop в Teradata EDW использовались 16 сессий. В данной системе максимальное число сессий, которое могло бы иметь задание FastLoad, равняется 16, посколько имеется всего 16 AMP. В подходе DirectLoad имелось по два задания DirectLoad на один узел, и в каждом задании DirectLoad использовалась одна сессия для посылки данных в локальный AMD. В обоих экспериментах в подходе DirectLoad одновременно имелось 16 активных сессий. В первом эксперименте мы генерировали DFS-файл с одним миллиардом строк. В каждой строке имелось два столбца. Во втором эксперименте мы генерировали DFS-файл со 150 миллионами строк. В каждой строке имелось 20 столбцов. Все столбцы были целого типа. В обоих экспериментах подход DirectLoad оказался примерно в 2,1 раза быстрее подхода FastLoad.Мы планируем выполнить большее число экспериментов при других конфигурациях системы.
