Как не утонуть в озере данных: инструкция от РСХБ
Привет, Хабр! Не так давно мы в РСХБ запустили озеро данных. И подумали, что наш опыт может кому-нибудь пригодиться. В первую очередь тем, кто ещё только думает о создании своего озера, но не знает, с чего начать, с чем предстоит столкнуться, о чём подумать заранее и т. д. Потому что озеро — это, конечно, прекрасно, но как бы не получить вместо него заросшее болото, в котором небезопасно плавать и откуда толком ничего не достать.
Так что мы собрались и небольшой командой специалистов — в лице Алексея Новикова (заместитель директора, ДИТ), Руслана Ибрагимова (исполнительный директор, ДКР), Николая Кудачкина (управляющий директор, ДРК) и Юрия Колошеина (исполнительный директор, ДИТ) — написали своего рода инструкцию по созданию озера данных на собственном примере.
Немного истории
Примерно до 2009 года РСХБ работал в основном с крупными корпоративными клиентами — огромными фермерскими хозяйствами, промышленными предприятиями… А потом решил заняться и розничным сегментом. И вот тут началось.
Сразу понадобилось радикально ускорить процессы рассмотрения и принятия решений —, но так, чтобы не во вред самим себе. Поэтому в 2009 мы начали строить ЦХД (централизованное хранилище данных). Это была наша первая аналитическая система, которая сильно упростила подготовку форм управленческой отчётности, например формы Ф101 (таблица, из которой можно узнать, на каком счёте сколько денег было на определённую дату), Ф6 (отчёт по кредитному портфелю юридических лиц, который до постройки ЦХД приходилось готовить целой армии специалистов), ДК1 (примерно такой же отчёт, только по физическим лицам) и Ф303 (отчёт о том, сколько денег выдали в кредит заводам и фермерским хозяйствам, с которыми всегда находили взаимопонимание). Вдобавок появился источник информации, объединивший данные со всех 79 филиалов из соответствующих АБС (автоматизированных банковских систем «Бисквит» компании ЗАО «БИС»). И всё стало проще, быстрее и удобнее.
Проблемы и новые вызовы
Где-то к 2018 году команда РСХБ пополнилась креативными финансовыми специалистами, требовавшими всё больше и больше данных для своей работы. В результате ЦХД стремительно рос и на нашем пути встали следующие проблемы:
ЦХД обладает общей структурой детального слоя данных, которую нельзя превозмочь, и потому в него не всё можно загрузить.
Объёмы систем хранения данных (СХД) тоже не резиновые, а расширение стоит немалых денег, которые не хочется выделять, не зная, когда ещё эти вложения окупятся.
ETL-процессы загрузки данных в ЦХД работают всё дольше и дольше, перерабатывая терабайты информации — это ведь именно они должны обеспечить консистентность и непротиворечивость данных, которые попадут в детальный слой данных.
Рост объёмов данных замедляет очень важные процессы подготовки нот и партитур, которые так нужны другим музыкантам, не менее хорошим, но играющим немного на других инструментах, и ждать эти музыканты не могут, так как регулярно выступают для Центрального банка, с которым, как известно, шутки плохи.
А с другой стороны, появились новые вызовы:
Необходимо обрабатывать всё больше и больше разнородной информации из совершенно разных источников, зачастую связанных друг с другом лишь на уровне бизнес-сущностей и весьма запутанно.
Всю эту ценную информацию нужно как-то недорого хранить, причём не «летая в облаках», а так, чтобы обеспечить требуемую конфиденциальность информации.
И ещё все эти данные нужно обрабатывать, желательно не очень долго и так, чтобы оркестр всё-таки мог как-то играть в процессе этой обработки.
И тогда мы решили — рядом с ЦХД поставим озеро данных, которое:
защитит ЦХД от лишних данных;
за счёт отсутствия общей структуры детального слоя позволит загрузить всё что угодно;
позволит сэкономить на оборудовании и загружать данные относительно независимо друг от друга, например потаблично из каждой системы-источника (ведь требования консистентности и непротиворечивости данных от batch-пакета снижаются до требования консистентности данных в каждой отдельно взятой таблице или файле, и в случае возникновения сбоя можно догрузить данные во время следующего планового запуска процесса).
Это поможет нам ответить на вызовы и заодно решить возникшие проблемы.
Приступаем к внедрению озера
Мы начали с того, что набросали дорожную карту:
Чётко записываем цели, которых хотим достичь внедрением озера, — на их основе мы сформируем скоуп работ и не дадим озеру превратиться в болото.
Выбираем надёжного партнёра, обладающего техническими компетенциями и опытом (которых у нас на момент начала проекта не было).
Решаем, как будем обеспечивать безопасность хранимых в озере данных, прикинув скоуп угроз и типовых задач, которые будем выполнять.
Подбираем подходящее ПО и оборудование, которое развернём и настроим вместе с партнёром.
Загружаем озеро данными и смотрим, что получилось.
Считаем, в случае чего допиливаем напильником.
На первый взгляд — ничего сложного. А теперь расскажем, как мы это всё воплощали в жизнь.
Ставим цели
У нас их было всего 4:
легко и быстро подключать новые источники данных, хранящие информацию либо в виде таблиц, либо в виде файлов общепринятого формата — CVS, XML, JSON;
просто и безопасно разграничивать доступ к этим данным;
без труда обрабатывать и отображать сырые и рассчитанные данные;
куда-то записывать, что какое поле в табличке означает, чтобы потом не забыть и быстро найти в случае необходимости.
Да, мы не ставили себе целью заливать аудиофайлы телефонных переговоров с клиентом, фотографии или видео из социальных сетей — это пока нам не нужно, но большинство полезной информации мы получим, причём быстро и дёшево.
Реализация
Здесь мы пропустим всякие административно-бюрократические моменты и перейдём сразу к делу. Скажу лишь, что нашим подрядчиком стала компания «Инфосистемы Джет», а вместе с ними мы выбрали:
керберизацию Hadoop-кластера — это, как мы поняли, де-факто отраслевой стандарт;
Cloudera Data Platform — тоже один из отраслевых стандартов, который, в отличие от других, позволяет керберизировать кластер, нажав одну кнопку, версию взяли 7.1 (последнюю стабильную на момент принятия решения);
Informatica Data Engineering Integration (DEI) в качестве ELT-платформы, версию взяли 7.1 (последнюю на тот момент) — мы много работали с Informatica PowerCenter и очень им довольны, и опыт использования DEI показал, что мы выбрали верно;
Tableau — этот BI нам только предстоит узнать, и мы решили:, а почему бы не начать это знакомство с работы с озером (пока только внедрили и начали разбираться с ним)?
Таким образом, все основные направления мы закрыли: данные защищены, грузятся легко и просто, пользователи получают красивые отчёты (по крайней мере, пока всё здесь в порядке) и с администрированием сложностей нет — интуитивно понятный GUI отлично дополнен подробной документацией и обширным сообществом коллег, уже использующих всё это у себя.
Kerberos
Один из вопросов, который мы задавали коллегам из «Джета» и который, возможно, возник и у вас: «А зачем нам этот Kerberos, когда можно обойтись обычной AD-аутентификацией и авторизацией, а Ranger (компонент в CDP) не пустит тех, кто не прошёл процесс аутентификации?».
Ответ оказался простым: Ranger защитит кластер от внешних врагов, но межмашинное взаимодействие внутри кластера останется незащищённым, и только керберизация позволит предотвратить атаки вроде вот этой:
Читаем содержимое каталога под другим пользователем
Поэтому заводим собаку… то есть Kerberos, и настраиваем группы пользователей в AD (Active Directory), на которые при помощи Ranger настроим права доступа к данным озера. Над этим вопросом много народу поломало головы, чтобы было «необходимо и достаточно», но в результате получилось хорошо.
DEI
Пользу DEI трудно переоценить. Он избавил нас от всех прелестей разработки Java-кода c его оркестровкой, а взамен, кроме денег, потребовал очень мало — создать несколько схем в уже существующей БД (у нас ведь уже был IPC), создать несколько сервисов в AdminConsole и немного расширить права пользователей… в итоге административная оснастка выглядит так:
Informatica AdminConsole
А вот так выглядит основной инструмент ELT-разработчика:
Разработанный маппинг в Informatica DeveloperРазработанный процесс (workflow) в Informatica Developer
В ходе выполнения процесса DEI покажет код, который она сгенерила для выполнения на Spark (полагаю, что изначально его вывели в рамках отладки продукта, но потом решили оставить — то ли как оберег, то ли для того, чтобы было что передать в службу поддержки, если что-то «упадёт»):
В качестве движка выбран Spark.
Чтобы подружить DEI и CDP, мы создали технологическую учётную запись, которой в AD и Ranger прописали всё необходимое. Ещё сделали процесс для обновления keytab, который используется всеми процессами загрузки данных (прописывается один раз на уровне платформы DEI) — это удобно и работает как часы.
Сейчас при помощи Informatica DEI мы ежедневно грузим в озеро данные из 20 источников (всего около 2500 таблиц), построенных на основе СУБД Oracle, MS SQL Server и Postgres. Также несколько источников поставляют данные в виде CSV-файлов, как стандартные, так и со спецсимволами, доставшимися от технологического прошлого систем-источников. Мы не считаем такие файлы неструктурированными данными, но стандартных средств DEI для работы с ними нам не хватило, поэтому наш партнёр написал специальный загрузчик на PySpark, который встроили в стандартный mapping, решив нашу задачу и не тратя сил на обвязочный код.
Другой интересной задачей для нас стала реализация оркестровки.
«Играть» нам разрешили только в определённое время, а стандартный DEI Scheduler, хоть и достаточно мощный, но не позволяет «из коробки» настроить вызов процессов согласно графу зависимостей и в разрешённые часы. Поэтому наш партнёр разработал свой scheduler и встроил его в стандартный функционал благодаря открытой структуре репозитория метаданных Informatica DEI, реализовав несколько процедур, генерирующих управляющие сигналы для запуска процессов.
И ещё пару слов про движок, на котором будет работать процесс (кто DEI пользоваться не планирует, можете пропустить абзац). Доступно 3 варианта:
Native
Spark
Blaze
Сравнительные тесты Spark и Blaze не выявили однозначного фаворита — какие-то процессы быстрее работали на Spark, другие — на Blaze. В итоге в качестве движка по умолчанию мы стали использовать Blaze, но, если процесс работает долго, пробуем Spark — бывает, что заметно быстрее, но бывает и медленней. А Native не используем, чтобы не перенести работу с Hadoop на сервер DEI и тем самым его не убить.
Обработка данных
Почти сразу после загрузки первых данных мы стали работать с Hive — нам понравилось, но в окнах загрузки данных запросы работали очень долго, иногда почти на порядок дольше, чем обычно. Нам это не особо мешало на тот момент, но мы подумали, что в будущем это станет нас ограничивать. Поэтому мы, изучив вопрос в интернете, решили попробовать развернуть MPP, в которую вынесли бы обработку потенциально критичных ко времени расчёта витрин. Оставалось выбрать конкретную реализацию.
Мы отдали предпочтение Impala. Она входит в CDP и представляет собой довольно шуструю колоночную MPP-систему. Для хранения данных решение использует HDFS, что экономит время на настройке безопасности — ведь Ranger работает и с Hive, и с Impala через плагин Hadoop SQL.
Метаданные
Вот мы дошли и до нашей последней цели — «куда-то записывать, что какое поле в табличке означает» или, говоря более научно, консолидировать технические метаданные для последующего управления ими (Data Governance). Эту задачу в своё время не смогли решить в ЦХД, но в озере всё получилось.
В состав CDP входит компонент Atlas, который с помощью механизма Ad-hoc-запросов позволяет поддерживать актуальность информации о хранилище метаданных Hive. Это даёт возможность при наличии культуры комментирования полей таблиц получать прототип описания слоя данных в озере, осуществлять поиск по этим данным и даже интегрироваться с внешним бизнес-глоссарием. Пока на основе данных нескольких команд пользователей мы создали прототип базы знаний, который уже помогает говорить на одном языке и разработчикам, и бизнесам.
Как не заехать в болото
Вот такими путями мы и пришли к результату: теперь у нас есть рабочее озеро данных, которое легло в основу программы бизнес-цифровизации наряду с другими нашими структурными проектами. Пока оно совсем небольшое — чуть более 60 ТБ данных, всего из восьми узлов и пользуется им порядка 60 человек, —, но уже решает серьёзные задачи.
Мы смогли достичь наших целей благодаря чёткому пониманию того, что мы хотим, и следованию нашему плану. Это и есть самый простой способ не превратить озеро в болото: делайте, что нужно делать, смело идите вперёд, пользуйтесь тем, что сделали. И всё будет отлично.
А если вы ещё сомневаетесь в чём-то или хотите что-то узнать — задавайте вопросы, комментируйте. Быть может, у нас есть ответы, которые вы ищете.
