Сегодня корпоративные хранилища строятся на базе как классических реляционных СУБД (Oracle DB, PostgreSQL) и NoSQL-решений (MongoDB, Cassandra), так и сложных распределенных систем (Apache Hadoop, Apache Ignite, Hazelcast, Oracle Coherence). Для обработки данных обычно используются специализированные подходы и системы решения конкретных бизнес-задач, в частности, на основе методов машинного обучения, позволяющего автоматизировать работу с огромными объемами распределенных между различными хранилищами данных.
Допустим, имеется система хранения и система обработки данных, а для выполнения прогноза — например, на основе исторических данных, обрабатываемых с помощью технологий машинного обучения, — требуется как минимум передать данные между двумя системами: выгрузить данные из хранилища, преобразовать, а затем загрузить в специализированную систему, использующую, например, технологии машинного обучения. Наиболее популярным подходом является ETL (Extract Transform Load), реализуемый как с помощью самописных bash-скриптов, так и средствами мощных коммерческих интеграционных продуктов от таких компаний, как Informatica или SAP.
Рис. 1. Узкое горло традиционных систем |
Однако у этого подхода имеются недостатки (рис. 1). Например, данные, выгружаемые из хранилища, обычно передают по сети, и если их действительно много, то передача займет больше времени, чем обучение нейронной сети, используемой в модели анализа исторических данных. К тому же выгрузка больших объемов данных может существенно снизить производительность корпоративных сетей компании, добавить проблем с доступом к данным из других внешних и внутренних систем. Все это означает необходимость развертывания значительных вычислительных и сетевых ресурсов, большие затраты на инфраструктуру, персонал и, как следствие, сдерживает рост бизнеса — информационная система оказывается не готова как к резкому увеличению объемов данных (например, в случае наплыва клиентов), так и к развертыванию и испытанию новых бизнес-моделей.
Хранение данных отдельно от системы машинного обучения, где они обрабатываются и где выполняется обучение модели, может свести на нет усилия по ускорению процесса обучения нейронной сети, особенно когда данных так много, что они не умещаются на одной машине. Задачу можно решить, если сосредоточиться на проблеме долгого ETL и тренировать модель глубинного обучения на кластере, обеспечив не параллельную, а распределенную систему обучения.
Рис. 2. Вычисления на месте хранения данных |
В распределенных системах не данные доставляются к вычислителям, а, наоборот, анализ данных выполняется по месту их хранения (рис. 2).
Такую распределенную систему хранения и обработки можно построить на базе решения с открытым кодом Apache Ignite [1], которое обеспечивает горизонтальное масштабирование, поддерживает распределенное, предусматривающее обработку в памяти (in-memory) хранилище «ключ-значение» с соблюдением требований ACID, персистентности и ANSI SQL, а также имеет встроенные средства поддержки таких методов машинного обучения, как линейная и логистическая регрессия, алгоритмы кластеризации, деревья решений, случайный лес, градиентный бустинг деревьев и ряд других. Кроме того, в Apache Ignite предусмотрена поддержка TensorFlow — одной из популярных платформ для решения задач методами глубинного обучения.
Apache Ignite разворачивается либо на кластере из нескольких серверов категории bare metal (сервер, управляемый гипервизором, загружаемым перед ОС), либо в контейнерах, а все данные хранятся и обрабатываются в оперативной памяти, что существенно быстрее, чем у традиционных решений, использующих жесткие диски. Такая архитектура предъявляет особые требования к масштабируемости и отказоустойчивости — для любых распределенных решений изменение топологии кластера «на лету» является штатной ситуацией. Иначе говоря, система должна быть готова как к вводу новых узлов, на которые необходимо перенести часть нагрузки, так и к выводу, в том числе и нештатному, из кластера узлов, на которых хранились данные или выполнялись вычисления. Все эти же требования справедливы и для распределенных платформ поддержки систем на безе технологий машинного обучения.
В распределенной системе хранения и обработки не требуется переносить огромные объемы данных во внешнюю систему — в Apache Ignite есть встроенные механизмы для анализа и обработки данных как традиционными методами, так и средствами машинного обучения. Отпадает необходимость расходов на дополнительные системы и серверные мощности. Также в распределенной системе имеется возможность немедленно начать обучение предсказательных моделей, не дожидаясь выгрузки данных в отдельные системы. Режим continuous learning означает, что можно при необходимости корректировать поведение модели буквально «на лету» — появляется возможность быстрой адаптации модели к изменению данных и их объемов.
***
Для поддержки работы с большими данными методами глубинного обучения все чаще применяются горизонтально масштабируемые архитектуры: стоимость вертикального масштабирования растет экспоненциально, а горизонтального — почти линейно. Кроме того, существуют физические ограничения на вертикальный рост, а это означает, что традиционные системы хранения не могут расширяться бесконечно или хотя бы достаточно быстро. Это особенно критично для задач глубинного обучения в случае, когда данных больше, чем может поместиться на одной машине. Появились принципиально новые системы HTAP (Hybrid transaction/analytical processing), сочетающие в себе функциональность хранения и обработки данных. И со временем такие решения придут на смену монолитным вертикально масштабируемым архитектурам.
Литература
- Никита Иванов. Универсальная платформа для работы в оперативной памяти // Открытые системы. СУБД. — 2018. — № 2. — С. 12–13. URL: https: www.osp.ru/os/2018/2/13054147/ (дата обращения: 25.11.2018).
Юрий Бабак (ybabak@gridgain.com) — руководитель отдела исследований и разработок в области машинного обучения, компания GridGain Systems. Статья подготовлена на основе материалов выступления на конференции «Технологии управления данными — 2018».