Распределенное хранилище данных в концепции Data Lake: с чего начать

В мире энтерпрайза наступило пресыщение фронтовыми системами, шинами данных и прочими классическими системами, которые внедряли все кому не лень последние 10-15 лет. Но есть один сегмент, который до недавнего времени был в статусе «все хотят, но никто не знает, что это». И это Big Data. Красиво звучит, продвигается топовыми западными компаниями – как не стать лакомым кусочком?



Но пока большинство только смотрит и приценивается, некоторые компании начали активно внедрять решения на базе этого технологического стека в свой IT ландшафт. Важную роль в этом сыграло появление коммерческих дистрибутивов Apache Hadoop, разработчики которых обеспечивают своим клиентам техническую поддержку. Ощутив необходимость в подобном решении, один из наших клиентов принял решение об организации распределенного хранилища данных в концепции Data Lake на базе Apache Hadoop.

Цели проекта

Во-первых, оптимизировать работу департамента управления рисками. До начала работ расчетом факторов кредитного риска (ФКР) занимался целый отдел, и все расчеты производились вручную. Перерасчет занимал каждый раз около месяца и данные, на основе которых он базировался, успевали устареть. Поэтому в задачи решения входила ежедневная загрузка дельты данных в хранилище, перерасчет ФКР и построение витрин данных в BI-инструменте (для данной задачи оказалось достаточно функционала SpagoBI) для их визуализации.

Во-вторых, обеспечить высокопроизводительные инструменты Data Mining для сотрудников банка, занимающихся Data Science. Данные инструменты, такие как Jupyter и Apache Zeppelin, могут быть установлены локально и с их помощью также можно исследовать данные и производить построение моделей. Но их интеграция с кластером Cloudera позволяет использовать для расчетов аппаратные ресурсы наиболее производительных узлов системы, что ускоряет выполнение задач анализа данных в десятки и даже сотни раз.

В качестве целевого аппаратного решения была выбрана стойка Oracle Big Data Appliance, поэтому за основу был взят дистрибутив Apache Hadoop от компании Cloudera. Стойка ехала довольно долго, и для ускорения процесса под данный проект были выделены сервера в приватном облаке заказчика. Решение разумное, но был и ряд проблем, о которых расскажу ниже по тексту.

В рамках проекта были запланированы следующие задачи:

1. Развернуть Cloudera CDH (Cloudera's Distribution including Apache Hadoop) и дополнительные сервисы, необходимые для работы.
2. Произвести настройку установленного ПО.
3. Настроить непрерывную интеграцию для ускорения процесса разработки (будет освещена в отдельной статье).
4. Установить BI-средства для построения отчетности и инструментов Data Discovery для обеспечения работы датасайентистов (будет освещена в отдельном посте).
5. Разработать приложения для загрузки необходимых данных из конечных систем, а также их регулярной актуализации.
6. Разработать формы построения отчетности для визуализации данных в BI-средстве.

Компания Neoflex не первый год занимается разработкой и внедрением систем на базе Apache Hadoop и даже имеет свой продукт для визуальной разработки ETL-процессов — Neoflex Datagram. Я давно хотел принять участие в одном из проектов этого класса и с радостью занялся администрированием данной системы. Опыт оказался весьма ценным и мотивирующим к дальнейшему изучению темы, поэтому спешу поделиться им с вами. Надеюсь, что будет интересно.

Ресурсы

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

На этапе пилотирования проекта и активной разработки, когда количество пользователей системы было минимально, было достаточно одной основной среды – это позволяло ускоряться за счет сокращения времени загрузки данных из конечных систем (наиболее частая и долгая процедура при разработке хранилищ данных). Сейчас, когда система стабилизировалась, пришли к конфигурации с тремя средами – тест, препрод и прод (основная).

В приватном облаке были выделены сервера для организации 2 сред – основной и тестовой. Характеристики сред приведены в таблице ниже:

Назначение	Количество	vCPU	vRAM, Gb	Диски, Gb
Основная среда, сервисы Cloudera	3	8	64	2 200
Основная среда, HDFS	3	22	288	5000
Основная среда, инструменты Data Discovery	1	16	128	2200
Тестовая среда, сервисы Cloudera	1	8	64	2200
Тестовая среда, HDFS	2	22	256	4000
Основная среда, инструменты Data Discovery	1	16	128	2200
CI	2	6	48	1000

Позднее основная среда мигрировала на Oracle BDA, а сервера были использованы для организации препрод среды.

Решение о миграции было обоснованным – ресурсов выделенных под HDFS серверов объективно не хватало. Узкими местами стали крохотные диски (что такое 5 Tb для Big Data?) и недостаточно мощные процессоры, стабильно загруженные на 95% при штатной работе задач по загрузке данных. С прочими серверами ситуация обратная – практически все время они простаивают без дела и их ресурсы с большей пользой можно было бы задействовать на других проектах.

С софтом дела обстояли непросто – из-за того, что разработка велась в частном облаке без доступа к интернету, все файлы приходилось переносить через службу безопасности и только по согласованию. В связи с этим приходилось заранее выгружать все необходимые дистрибутивы, пакеты и зависимости.

В этой непростой задаче очень помогала настройка keepcache=1 в файлике /etc/yum.conf (в качестве OS использовался RHEL 7.3) – установить нужное ПО на машине с выходом в сеть намного проще, чем руками выкачивать его из репозиториев вместе с зависимостями ;)

Что потребуется развернуть:

1. Oracle JDK (без Java никуда).
2. База данных для хранения информации, создаваемой и используемой сервисами CDH (например Hive Metastore). В нашем случае был установлен PostgreSQL версии 9.2.18, но может быть использована любая из поддерживаемых сервисами Cloudera (список отличается для разных версий дистрибутива, см. раздел «Requirements and Supported Versions» официального сайта). Здесь надо заметить, что выбор БД оказался не вполне удачным – Oracle BDA поставляется с БД MySQL (один из их продуктов, перешедший к ним вместе с покупкой Sun) и логичнее было использовать аналогичную базу для других сред, что упростило бы процедуру миграции. Рекомендуется выбирать дистрибутив исходя из целевого аппаратного решения.
3. Демон Chrony для синхронизации времени на серверах.
4. Cloudera Manager Server.
5. Демоны Cloudera Manager.

Подготовка к установке

Перед началом установки CDH стоит провести ряд подготовительных работ. Одна их часть пригодится во время установки, другая упростит эксплуатацию.

Установка и настройка ОС

Прежде всего, стоит подготовить виртуальные (можно и реальные) машины, на которых будет располагаться система: установить на каждую из них операционную систему поддерживаемой версии (список отличается для разных версий дистрибутива, см. раздел «Requirements and Supported Versions» официального сайта), присвоить хостам понятные имена (например, <system_name>master1,2,3…, <system_name>slave1,2,3…), а также разметить диски под файловое хранилища и временные файлы, создаваемые в ходе работы системы.

Рекомендации по разметке следующие:

• На серверах с HDFS создать том хотя бы на 500 Gb для файлов, которые создает YARN в ходе работы задач и помещает в директорию /yarn (куда этот том и надо подмонтировать после установки CDH). Небольшой том (порядка 100 Gb) стоит выделить для ОС, сервисов Cloudera, логов и прочего хозяйства. Все свободное место, которое останется после этих манипуляций, стоит объединить в один большой том и примонтировать к директории /dfs до начала загрузки данных в хранилище. HDFS хранит данные в виде достаточно мелких блоков и лучше лишний раз не заниматься их переносом. Также для удобства последующего добавления дисков рекомендуется использовать LVM – проще будет расширять хранилище (особенно когда оно станет действительно BIG).
• На серверах с сервисами Cloudera можно монтировать все доступное место в корневую директорию – проблем с большими объемами файлов быть не должно, особенно если регулярно чистить логи. Единственное исключение составляет сервер с базой данных, которую используют сервисы Cloudera для своих нужд – на данном сервере имеет смысл разметить отдельный том под директорию, в которой хранятся файлы этой БД (будет зависеть от выбранного дистрибутива). Сервисы пишут довольно умеренно и 500 Gb должно хватить с лихвой. Для подстраховки также можно использовать LVM.

Настройка http сервера и offline установка пакетов yum и CDH

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

Установка производилась на ОС Red Hat 7.3, поэтому в статье будут приводиться команды, специфичные для нее и других операционных систем на базе CentOS. При установке на других ОС последовательность будет аналогичной, отличаться будут только пакетные менеджеры.
Дабы не писать везде sudo будем считать, что установка происходит из-под рута.

Вот что потребуется сделать:
1. Выбирается машина, на которой будет располагаться HTTP сервер и дистрибутивы.
2. На машине с аналогичной ОС, но подключенной к интернету, выставляем флаг keepcache=1 в файле /etc/yum.conf и устанавливается httpd со всеми зависимостями:

yum install httpd

Если данная команда не работает, то требуется добавить в список репозиториев yum репозиторий, в котором есть данные пакеты, например, этот — centos.excellmedia.net/7/os/x86_64:

echo -e "\n[centos.excellmedia.net]\nname=excellmedia\nbaseurl=http://centos.excellmedia.net/7/os/x86_64/\nenabled=1\ngpgcheck=0" > /etc/yum.repos.d/excell.repo

После этого командой yum repolist проверяем, что репозиторий подтянулся — в списке репозиториев должен появиться добавленный репозиторий (repo id — centos.excellmedia.net; repo name — excellmedia).
Теперь проверяем, что yum увидел нужные нам пакеты:

yum list | grep httpd

Если в выводе присутствуют нужные пакеты, то можно установить их приведенной выше командой.

3. Для создания репозитория yum нам потребуется пакет createrepo. Он также есть в указанном выше репозитории и ставится аналогично:

yum install createrepo

4. Как я уже говорил, для работы сервисов CDH требуется база данных. Установим для этих целей PostgreSQL:

yum install postgresql-server

5. Одним из обязательных условий для корректной работы CDH является синхронизация времени на всех серверах, входящих в кластер. Для этих целей используется пакет chronyd (на тех ОС, где мне приходилось разворачивать CDH, он был установлен по умолчанию). Проверяем его наличие:

chronyd -v

Если он не установлен, то устанавливаем:

yum install chrony

Если же установлен, то просто скачиваем:

yumdownloader --destdir=/var/cache/yum/x86_64/7Server/<repo id>/packages chrony

6. Заодно сразу загрузим пакеты, необходимые для установки CDH. Они доступны на сайте archive.cloudera.com — archive.cloudera.com/cm<мажорная версия CDH>/<название вашей ОС>/<версия вашей ОС>/x86_64/cm/<полная версия CDH>/RPMS/x86_64/. Можно скачать пакеты руками (cloudera-manager-server и cloudera-manager-daemons) либо по аналогии добавить репозиторий и установить их:

yum install cloudera-manager-daemons cloudera-manager-server

7. После установки пакеты и их зависимости закешируются в папке /var/cache/yum/x86_64/7Server/\<repo id\>/packages. Переносим их на машину, выбранную под HTTP сервер и дистрибутивы, и устанавливаем:

rpm -ivh <имя пакета>

8. Запускаем httpd, делаем его видимым с других хостов нашего кластера, а также добавляем его в список сервисов, запускаемых автоматически после загрузки:

systemctl start httpd
systemctl enable httpd
systemctl stop firewalld # Требуется также сделать для остальных хостов
systemctl disable firewalld # Требуется также сделать для остальных хостов
setenforce 0

9. Теперь у нас есть работающий HTTP сервер. Его рабочая директория /var/www/html. Создадим в ней 2 папки — одну для репозитория yum, другую для парселей Cloudera (об этом чуть позже):

cd /var/www/html
mkdir yum_repo parcels

10. Для работы сервисов Cloudera нам потребуется Java. На все машины требуется установить JDK одинаковой версии, Cloudera рекомендует Hot Spot от Oracle. Скачиваем дистрибутив с официального сайта (http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html) и переносим в папку yum_repo.

11. Создадим в папке yum_repo репозиторий yum с помощью утилиты createrepo чтобы пакет с JDK стал доступен для установки с машин кластера:

createrepo -v /var/www/html/yum_repo/

12. После создания нашего локального репозитория на каждом из хостов требуется добавить его описание по аналогии с пунктом 2:

echo -e "\n[yum.local.repo]\nname=yum_repo\nbaseurl=http://<имя хоста с httpd>/yum_repo/\nenabled=1\ngpgcheck=0" > /etc/yum.repos.d/yum_repo.repo

Также можно сделать проверки, аналогичные пункту 2.

13. JDK доступен, устанавливаем:

yum install jdk1.8.0_161.x86_64

Для эксплуатации Java потребуется задать переменную JAVA_HOME. Рекомендую сделать ее экспорт сразу после установки, а также записать ее в файлы /etc/environment и /etc/default/bigtop-utils чтобы она автоматически экспортировалась после перезапуска серверов и ее расположение предоставлялось сервисам CDH:

export JAVA_HOME=/usr/java/jdk1.8.0_161
echo "JAVA_HOME=/usr/java/jdk1.8.0_161" >> /etc/environment
export JAVA_HOME=/usr/java/jdk1.8.0_144 >> /etc/default/bigtop-utils

14. Таким же образом устанавливаем chronyd на всех машинах кластера (если, конечно, он отсутствует):

yum install chrony

15. Выбираем хост, на котором будет работать PostgreSQL, и устанавливаем его:

yum install postgresql-server

16. Аналогично, выбираем хост, на котором будет работать Cloudera Manager, и устанавливаем его:

yum install cloudera-manager-daemons cloudera-manager-server

17. Пакеты установлены, можно приступать к настройке ПО перед установкой.

Дополнение:

В ходе разработки и эксплуатации системы потребуется добавлять пакеты к репозиторий yum для их установки на хостах кластера (например дистрибутив Anaconda). Для этого помимо самого переноса файлов в папку yum_repo требуется выполнить следующие действия:

• на машине с httpd выполнить команду обновления репозитория yum:
  
  

  createrepo -v --update /var/www/html/yum_repo/

• на всех машинах, куда требуется установить пакеты выполнить очистку кешей yum:

• yum clean all

• rm -rf /var/cache/yum

Настройка вспомогательного софта

Настало время сконфигурировать PostgreSQL и создать базы данных для наших будущих сервисов. Данные настройки актуальны для версии CDH 5.12.1, при установке других версий дистрибутива рекомендуется ознакомиться с разделом «Cloudera Manager and Managed Service Datastores» официального сайта.

Для начала произведем инициализации базы данных:

postgresql-setup initdb

Теперь настраиваем сетевое взаимодействие с БД. В файле /var/lib/pgsql/data/pg_hba.conf в секции «IPv4 local connections» меняем метод для адреса 127.0.0.1/32 на метод «md5», добавляем метод «trust» и добавляем подсеть кластера с методом «trust»:

vi /var/lib/pgsql/data/pg_hba.conf
pg_hba.conf:
-----------------------------------------------------------------------
# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
local   all             all                                     peer
# IPv4 local connections:
host    all             all             127.0.0.1/32            md5 
host    all             all             127.0.0.1/32            trust
host    all             all             <cluster_subnet>        trust
-----------------------------------------------------------------------

Затем внесем некоторые коррективы в файл /var/lib/pgsql/data/postgres.conf (приведу только те строки, которые надо изменить или проверить на соответствие:

vi /var/lib/pgsql/data/postgres.conf
postgres.conf:
-----------------------------------------------------------------------
listen_addresses = '*'
max_connections = 100
shared_buffers = 256MB
checkpoint_segments = 16
checkpoint_completion_target = 0.9
logging_collector = on
log_filename = 'postgresql-%a.log'
log_truncate_on_rotation = on
log_rotation_age = 1d
log_rotation_size = 0
log_timezone = 'W-SU'
datestyle = 'iso, mdy'
timezone = 'W-SU'
lc_messages = 'en_US.UTF-8'
lc_monetary = 'en_US.UTF-8'
lc_numeric = 'en_US.UTF-8'
lc_time = 'en_US.UTF-8'
default_text_search_config = 'pg_catalog.english'
-----------------------------------------------------------------------

После окончания конфигурации требуется создать базы данных (для тех, кому ближе терминология Oracle – схемы) для сервисов, которые будем устанавливать. В нашем случае были установлены следующие сервисы: Cloudera Management Service, HDFS, Hive, Hue, Impala, Oozie, Yarn и ZooKeeper. Из них Hive, Hue и Oozie нуждаются в базах, а также 2 базы потребуются для нужд сервисов Cloudera – одна для сервера Cloudera Manager, другая для менеджера отчетов, входящего в Cloudera Management Service. Запустим и PostgreSQL и добавим его в автозагрузку:

systemctl start postgresql
systemctl enable postgresql

Теперь мы можем подключиться и создать нужные базы:

sudo -u postgres psql
> CREATE ROLE scm LOGIN PASSWORD '<password>';
> CREATE DATABASE scm OWNER scm ENCODING 'UTF8'; # Роль и база Cloudera Manager
> CREATE ROLE rman LOGIN PASSWORD '<password>';
> CREATE DATABASE rman OWNER rman ENCODING 'UTF8'; # Роль и база менеджера отчетов
> CREATE ROLE hive LOGIN PASSWORD '<password>';
> CREATE DATABASE metastore OWNER hive ENCODING 'UTF8'; # Роль и база Hive Metastore
> ALTER DATABASE metastore SET standard_conforming_strings = off; # Рекомендуется для PostgreSQL старше версии 8.2.23
> CREATE ROLE hue_u LOGIN PASSWORD '<password>';
> CREATE DATABASE hue_d OWNER hue_u ENCODING 'UTF8'; # Роль и база Hue
> CREATE ROLE oozie LOGIN ENCRYPTED PASSWORD '<password>' NOSUPERUSER INHERIT CREATEDB NOCREATEROLE;
> CREATE DATABASE "oozie" WITH OWNER = oozie ENCODING = 'UTF8' TABLESPACE = pg_default LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8' CONNECTION LIMIT = -1; # Роль и база Oozie согласно рекомендациям официального сайта:
> \q

Для других сервисов базы данных создаются аналогично.

Не забываем прогнать скрипт для подготовки базы сервера Cloudera Manager, передав ему на вход данные для подключения к созданной для него базе:

. /usr/share/cmf/schema/scm_prepare_database.sh postgresql scm scm <password>

Создание репозитория с файлами CDH

Cloudera предоставляет 2 способа установки CDH – с помощью пакетов (packages) и с помощью парсэлей (parcels). Первый вариант предполагает скачивание набора пакетов с сервисами нужных версий и последующую их установку. Данный способ предоставляет большую гибкость конфигурации кластера, но Cloudera не гарантируют их совместимость. Поэтому более популярен второй вариант установки с использованием парсэлей – заранее сформированных наборов пакетов совместимых версий. Самые свежие версии доступны по следующей ссылке: archive.cloudera.com/cdh5/parcels/latest. Более ранние можно найти уровнем выше. Помимо самого парсэля с CDH требуется скачать manifest.json из той же директории репозитория.

Для эксплуатации разработанного функционала нам также требовался Spark 2.2, не входящий в парсэль CDH (там доступна первая версия данного сервиса). Для его установки требуется загрузить отдельный парсэль с данным сервисом и соответствующий manifest.json, также доступные в архиве Cloudera.

После загрузки парсэлей и manifest.json требуется перенести их в соответствующие папки нашего репозитория. Создаем отдельные папки для файлов CDH и Spark:

cd /var/www/html/parcels
mkdir cdh spark

Переносим в созданные папки парсэли и файлы manifest.json. Чтобы сделать их доступными для установки по сети выдаем папке с парсэлями соответствующие доступы:

chmod -R ugo+rX /var/www/html/parcels

Можно приступать к установке CDH, о чем я расскажу в следующем посте.