Все организации, имеющие хоть какое-то отношение к данным, рано или поздно сталкиваются с проблемой хранения реляционных и неструктурированных баз данных.
Найти удобный, эффективный и недорогой одновременно подход к этой проблеме непросто.
А также убедитесь, что ученые, работающие с данными, могут успешно работать с моделями машинного обучения на данных.
Нам это удалось – и хотя пришлось повозиться, итоговая прибыль оказалась даже больше, чем ожидалось.
Все подробности мы расскажем ниже.
Со временем любой банк накапливает невероятные объемы корпоративных данных.
Сопоставимый объем хранится только в интернет-компаниях и телекоммуникациях.
Это произошло из-за высоких требований контролирующих органов.
Эти данные не лежат без дела – руководители финансовых учреждений уже давно придумали, как получить на них прибыль.
Для нас все началось с управленческой и финансовой отчетности.
На основе этих данных мы научились принимать бизнес-решения.
Часто возникала необходимость получения данных из нескольких информационных систем банка, для чего мы создавали консолидированные базы данных и системы отчетности.
Из этого постепенно сформировалось то, что сейчас называется хранилищем данных.
Вскоре на базе этого хранилища заработали и другие наши системы:
- аналитическая CRM, позволяющая предлагать клиенту более удобные продукты;
- кредитные конвейеры, которые помогают быстро и точно принимать решения о выдаче кредита;
- системы лояльности, рассчитывающие кэшбэк или бонусные баллы по механикам различной сложности.
Чем больше информации модели смогут взять из хранилища, тем точнее они будут. Их потребность в данных растет в геометрической прогрессии.
Примерно к такой ситуации мы пришли два или три года назад. На тот момент у нас было хранилище на базе СУБД MPP Teradata с использованием ELT-инструмента SAS Data Integration Studio. Это хранилище мы строим с 2011 года совместно с Glowbyte Consulting. В нее были интегрированы более 15 крупных банковских систем и одновременно аккумулированы достаточный объем данных для внедрения и развития аналитических приложений.
Кстати, как раз в это время объем данных в основных слоях хранения начал нелинейно расти из-за множества различных задач, а продвинутая клиентская аналитика стала одним из основных направлений развития банка.
И наши ученые, работающие с данными, стремились поддержать это.
В целом, звезды сошлись правильно для создания Платформы исследования данных.
Планирование решения
Здесь необходимо уточнить: промышленное ПО и серверы стоят дорого даже для крупного банка.Не каждая организация может позволить себе хранить большие объемы данных в топовых СУБД MPP. Всегда приходится делать выбор между ценой и скоростью, надежностью и объемом.
Чтобы максимально использовать имеющиеся возможности, мы решили сделать следующее:
- Оставьте нагрузку ELT и наиболее востребованную часть исторических данных на СУБД Teradata;
- загрузить полную историю в Hadoop, что позволяет хранить информацию гораздо дешевле.
Осталось выбрать дистрибутив.
Вы можете создать свой собственный или использовать Apache Hadoop с открытым исходным кодом.
Но среди корпоративных решений на базе Hadoop лучше себя зарекомендовали готовые дистрибутивы других вендоров — Cloudera и Hortonworks. Поэтому мы тоже решили использовать готовый дистрибутив.
Поскольку нашей основной задачей было хранение структурированных больших данных, в стеке Hadoop нас интересовали решения, максимально приближенные к классическим СУБД SQL. Лидерами здесь являются Импала и Улей.
Cloudera разрабатывает и интегрирует решения Impala, Hortonworks – Hive. Для углубленного изучения мы организовали нагрузочное тестирование обеих СУБД с учетом нагрузки нашего профиля.
Надо сказать, что механизмы обработки данных в Impala и Hive существенно отличаются — Hive вообще представляет несколько разных вариантов.
Однако выбор пал на Импалу — и соответственно дистрибутив от Cloudera.
Почему вам понравилась Импала?
- Высокая скорость выполнения аналитических запросов из-за альтернативного подхода к MapReduce. Промежуточные результаты вычислений не сбрасываются в HDFS, что существенно ускоряет обработку данных.
- Ээффективная работа со столбчатым хранилищем данных в Паркет .
Для аналитических задач часто используются так называемые широкие таблицы с множеством столбцов.
Все столбцы используются редко — возможность поднимать из HDFS только нужные для работы экономит оперативную память и значительно ускоряет запрос.
- Элегантное решение с фильтры времени выполнения , включая фильтрацию цветения.
И Hive, и Impala существенно ограничены в использовании индексов, общих для классических СУБД, из-за особенностей файловой системы хранения HDFS. Следовательно, для оптимизации выполнения SQL-запроса механизм СУБД должен эффективно использовать преимущества доступного секционирования, даже если оно явно не указано в условиях запроса.
Кроме того, ему необходимо попытаться предсказать, какой минимальный объем данных из HDFS необходимо поднять, чтобы обеспечить обработку всех строк.
Это очень хорошо работает в Импале.
- Импала использует LLVM — компилятор на виртуальной машине с RISC-подобными инструкциями — для генерации оптимального кода для выполнения SQL-запроса.
- Поддерживаются интерфейсы ODBC и JDBC. Это позволяет интегрировать данные Impala с аналитическими инструментами и приложениями практически «из коробки».
- Можно использовать Куду — для обхода некоторых ограничений HDFS и, в частности, записи конструкций UPDATE и DELETE в SQL-запросах.
Sqoop и остальная архитектура
Следующим по важности для нас инструментом в стеке Hadoop был Sqoop. Он позволяет передавать данные между реляционными СУБД (нас, конечно, интересовала Teradata) и HDFS в кластере Hadoop в разных форматах, включая Parquet. В тестах Sqoop показал высокую гибкость и производительность, поэтому мы решили использовать его вместо разработки собственных инструментов для захвата данных через ODBC/JDBC и сохранения их в HDFS. Для обучения моделей и связанных с ними задач Data Science, которые удобнее выполнять непосредственно на кластере Hadoop, мы использовали Искра от Апача.Оно стало стандартным решением в своей области – и не зря:
- библиотеки машинного обучения Spark ML;
- поддержка четырех языков программирования (Scala, Java, Python, R);
- интеграция с аналитическими инструментами;
- Обработка данных в памяти обеспечивает превосходную производительность.
Текущая конфигурация содержит 18 таких же узлов с памятью, расширенной до 512 ГБ.
На схеме показана архитектура верхнего уровня платформы исследования данных и связанных с ней систем.
Центральное звено — кластер Hadoop на базе дистрибутива Cloudera (CDH).
Он используется как для получения с помощью Sqoop, так и для хранения данных QCD в HDFS — в столбчатом формате Parquet, позволяющем использовать кодеки сжатия, например, Snappy. Кластер также обрабатывает данные: Impala используется для ELT-подобных преобразований, Spark — для задач Data Science. Sentry используется для разделения доступа к данным.
Impala имеет интерфейсы практически для всех современных инструментов корпоративной аналитики.
Кроме того, в качестве клиентов можно подключать произвольные инструменты, поддерживающие интерфейсы ODBC/JDBC. Для работы с SQL мы считаем Hue и TOAD для Hadoop нашими основными клиентами.
Для управления всеми потоками, которые обозначены на схеме стрелками, спроектирована подсистема ETL, состоящая из инструментов SAS (Сервер метаданных, Data Integration Studio), а также ETL-фреймворка, написанного на основе SAS и скриптов оболочки, использующих базу данных для хранение метаданных ETL-процессов.
Руководствуясь правилами, указанными в метаданных, подсистема ETL запускает процессы обработки данных как на КХД, так и на Платформе исследования данных.
В результате мы имеем комплексную систему мониторинга и управления потоками данных независимо от используемой среды (Teradata, Impala, Spark и т.д., при необходимости).
Через грабли к звездам
Кажется, выгрузить QCD легко.Вход и выход — реляционные СУБД, принимают и передают данные через Sqoop. Судя по описанию выше, у нас все прошло очень гладко, но, конечно, не обошлось и без приключений, и это, пожалуй, самая интересная часть всего проекта.
С нашим объёмом не было никакой надежды передавать все данные целиком каждый день.
Соответственно, необходимо было научиться извлекать достоверный прирост из каждого объекта хранения, что не всегда легко, когда данные в таблице для исторических бизнес-дат могут измениться.
Для решения этой проблемы мы систематизировали объекты в зависимости от способов загрузки и ведения истории.
Затем для каждого типа мы определили правильный предикат для Sqoop и способ его загрузки в приемник.
И наконец, мы написали инструкции для разработчиков новых объектов.
Sqoop — очень качественный инструмент, но он не работает абсолютно надежно во всех случаях и сочетаниях систем.
На наших томах коннектор к Teradata работал не оптимально.
Мы воспользовались открытостью кода Sqoop и внесли изменения в библиотеки коннекторов.
Повышена стабильность соединения при перемещении данных.
По какой-то причине, когда Sqoop вызывает Teradata, предикаты не совсем корректно преобразуются в условия WHERE. Из-за этого Sqoop иногда пытается вытащить огромную таблицу и потом отфильтровать ее.
Пропатчить коннектор здесь не удалось, но мы нашли другой выход: для каждого выгружаемого объекта принудительно создаём временную таблицу с наложенным предикатом и просим Sqoop перезагрузить её.
Все MPP, и в частности Teradata, имеют функцию, связанную с параллельным хранением данных и выполнением инструкций.
Если не учесть эту особенность, то может оказаться, что всю работу возьмет на себя один логический узел кластера, из-за чего выполнение запросов станет значительно медленнее, возможно, в 100-200 раз медленнее.
Мы, конечно, не могли этого допустить, поэтому написали специальный движок, который использует ETL-метаданные QCD-таблиц и выбирает оптимальную степень распараллеливания Sqoop-задач.
Историчность хранения – дело тонкое, особенно если использовать СКД2 , несмотря на то, что Импала не поддерживает ОБНОВЛЕНИЕ и УДАЛЕНИЕ.
Мы, конечно, хотим, чтобы исторические таблицы в Data Research Platform выглядели точно так же, как в Teradata. Этого можно достичь путем комбинирования увеличения с помощью Sqoop, выделения обновленных бизнес-ключей и удаления разделов в Impala. Чтобы каждому разработчику не приходилось писать эту навороченную логику, мы упаковали ее в специальную библиотеку (на нашем ETL-сленге — «загрузчик»).
Наконец, возникает вопрос о типах данных.
Impala достаточно бесплатна в плане преобразования типов, поэтому с некоторыми трудностями мы столкнулись только с типами TIMESTAMP и CHAR/VARCHAR. Что касается даты и времени, мы решили хранить данные в Impala в текстовом формате (STRING) ГГГГ-ММ-ДД ЧЧ:ММ:СС.
Этот подход, как оказалось, позволяет использовать функции преобразования даты и времени.
Для строковых данных заданной длины оказалось, что хранение в формате STRING в Impala им ничем не уступает, поэтому мы тоже использовали его.
Обычно для организации Data Lake исходные данные копируются в полуструктурированных форматах в специальную область этапа Hadoop, после чего с помощью Hive или Impala устанавливается схема десериализации этих данных для использования в SQL-запросах.
Мы пошли по тому же пути.
Важно отметить, что не всегда имеет смысл тащить все в хранилище данных, поскольку разработка процессов копирования файлов и установки схемы обходится гораздо дешевле, чем загрузка бизнес-атрибутов в модель QCD с помощью ETL-процессов.
Когда еще неясно, в каком объеме, за какой период и с какой периодичностью необходимы исходные данные, Data Lake в описанном подходе является простым и дешевым решением.
Теперь мы регулярно загружаем в Data Lake в первую очередь источники, генерирующие пользовательские события: данные анализа приложений, логи и сценарии перехода для автодозвона и автоответчика Avaya, транзакции по картам.
Инструментарий аналитика
Мы не забыли еще об одной цели всего проекта — дать возможность аналитикам использовать все это богатство.Вот основные принципы, которыми мы руководствовались здесь:
- Простота использования и поддержка инструмента
- Применимость в задачах Data Science
- Максимальное использование вычислительных ресурсов кластера Hadoop вместо серверов приложений или компьютера исследователя.
- Питон + Анаконда.
Среда — iPython/Jupyter.
- Р + Блестящий.
Исследователь работает в настольной или веб-версии R Studio, Shiny используется для разработки веб-приложений, предназначенных для использования алгоритмов, разработанных в R.
- Искра.
Для работы с данными используются интерфейсы Python (pyspark) и R, настроенные в средах разработки, указанных в предыдущих пунктах.
Оба интерфейса позволяют использовать библиотеку Spark ML, которая позволяет обучать модели ML в кластере Hadoop/Spark.
- Данные в Impala доступны через Hue, Spark и из сред разработки с использованием стандартного интерфейса ODBC и специальных библиотек, таких как implyr.
В дальнейшем мы планируем улучшить взаимодействие с пользователем, перенести рабочие нагрузки ELT в Impala, увеличить количество источников, загружаемых в Data Lake, и расширить возможности расширенной аналитики.
В заключение хотелось бы дать несколько общих советов коллегам, которые только начинают свой путь в создании крупных хранилищ:
- Используйте лучшие практики.
Если бы у нас не было ETL-подсистемы, метаданных, версионного хранилища и четкой архитектуры, мы бы не смогли выполнить эту задачу.
Лучшие практики окупаются, хотя и не сразу.
- Помните об объемах данных.
Большие данные могут создавать технические проблемы в неожиданных местах.
- Следите за новыми технологиями.
Новые решения появляются часто, не все из них полезны, но иногда встречаются настоящие бриллианты.
- Больше экспериментируйте.
Не доверяйте только маркетинговым описаниям решений – попробуйте сами.
почта .
Теги: #Машинное обучение #Хранилища данных #Хранение данных #Большие данные #озеро данных #vtb
-
Зоология
19 Oct, 24 -
Новая Эра Брендинга
19 Oct, 24 -
Прага
19 Oct, 24 -
Тестер Локальной Сети Для Avr Своими Руками
19 Oct, 24 -
Подкаст Unclesoky - Эпизод №26
19 Oct, 24 -
Системные Таблицы В Базах Данных
19 Oct, 24 -
Простой Алгоритм Метапоиска На Python
19 Oct, 24
