Зачем биотехнологической платформе Polly от Elucidata понадобился API SQL-запросов в облачном сервисе Elasticsearch и как дата-инженеры реализовали его, развернув Delta Lake с AWS Atnena и S3.
Что не так с SQL-запросами в облачном Elasticsearch на AWS
Ежедневно биотехнологическая платформа Polly от Elucidata обрабатывает гигабайты биомолекулярных данных для биологов по всему миру. Исторически платформа данных Polly использовала документо-ориентированную NoSQL-СУБД Elasticsearch для хранения данных. Это хранилище имеет функцию полнотекстового поиска и работает очень быстро благодаря встроенному механизму индексации документов. Даже большие числовые матрицы, сериализованные в виде документов, хранились в Elasticsearch, развернутой на облачной платформе AWS в полностью управляемом сервисе OpenSearch, который предоставляет подключаемый модуль для SQL-запросов к индексам. Но по мере роста объема обрабатываемых данных платформа Polly на Elasticsearch столкнулась с рядом ограничений этой NoSQL-СУБД.
Типичный набор данных Polly включает в себя следующее:
- Единые метаданные на уровне набора данных;
- Набор из n образцов, каждый из которых имеет свои метаданные;
- Набор из m характеристик, измеренных на выборку, каждая характеристика имеет свои метаданные;
- Матрица данных (n⨯m), в которой хранятся фактические измерения – это самая большая часть набора информации;
- Метаданные каждой сущности представляют собой словарь пар ключ-значение.
Сгруппированные наборы данных в репозитории имеют некоторые общие атрибуты, например, источник происхождения и т.д. Пользователи работают с данными в этих наборах, выполняя поиск по метаданным, полнотекстовый поиск по фичам и запрашивая матрицы данных с помощью SQL-запросов. Поэтому нужен API, который принимает запросы полнотекстового поиска и SQL к огромным наборам данных. Из-за роста объема данных общий размер индексов Elasticsearch очень быстро увеличился в 4 раза, с 1 до 4 ТБ. И, хотя облачное хранилище стоит не очень дорого, в AWS OpenSearch есть ограничение на размер тома EBS, который можно подключить к каждому узлу кластера Elasticsearch. При достижении предела размера следует увеличить количество узлов или обновить их до более мощного и более дорогого класса экземпляров.
Обычно кластер Elasticsearch хорошо масштабируется по мере увеличения объема данных, чтобы беспрепятственно справляться с возрастающей нагрузкой во время поиска. Но в случае платформы Polly объемы данных росли очень быстро, хотя большинство матриц данных никогда не запрашивалось. Поэтому запросы к матрицам данных стали неоптимальными, а весь кластер Elasticsearch не эффективно утилизировал вычислительные ресурсы, будучи не лучшим вариантом реализации SQL-запросов из-за следующих ограничений:
- получение более 10 000 строк для любого нетривиального запроса;
- ограничения при соединениях и агрегациях;
- сложности с запросами вложений в матрице данных с одним документом на строку, где имя каждого образца и измерение в массиве вложенных документов.
Поэтому для поиска с использованием SQL-запросов платформе Polly нужен отдельный инструмент, который имеет встроенную поддержку SQL, хорошо масштабируется с очень большими объемами данных в таблице, отлично работает с огромным количеством таблиц и применяет схему для каждой из них. Далее рассмотрим, что для этого выбрали инженеры Elucidata и почему.
Включение Delta Lake в архитектуру данных
Инженеры Elucidata решили, что использование формата озера данных и сериализация таблиц в распределенной файловой системе помогут с масштабируемостью. В качестве облачного хранилища был выбран AWS S3, поскольку остальная часть платформы Polly уже работает в сервисах Amazon.
Чтобы выбрать формат данных, который будет поддерживать SQL-запросы, а также применять схему, было рассмотрено несколько вариантов: TileDB, Apache Iceberg, Hudi и Delta Lake – уровень хранилища с открытым исходным кодом, обеспечивающий надежность озера данных. Apache Iceberg не подошел для рабочих нагрузок, связанных с частыми обновлениями и удалениями таблиц, в отличие от Delta Lake. Эта платформа от Databricks поддерживает ACID-транзакции и масштабируемую обработку метаданных, объединяя потоковые и пакетные операции с большими данными. Delta Lake работает на базе существующего озера данных (на Apache Hadoop HDFS, AWS S3 или Azure Data Lake Storage) и полностью совместимо со всеми API Apache Spark. Подробнее о том, что такое Delta Lake, мы писали здесь.
Delta Lake отлично подошло для решения проблем платформы Polly с хранением данных, но инженеры Elucidata по-прежнему хотели сохранить поисковый интерфейс на основе Elasticsearch. Поэтому было решено разделить серверные части поиска и запросов, даже за счет дублирования данных между ними, чтобы оптимизировать их по отдельности. Поскольку SQL-запросы выполнялись только к матрицам данных, они сразу сохранялись в Delta Lake в виде отдельных таблиц и не индексировались в Elasticsearch. Это значительно снизило нагрузку к хранилищу кластера Elasticsearch.
Чтобы получать данные через SQL-запросы, нужен соответствующий механизм, поддерживаемый Delta Lake на S3, например, Apache Spark, Presto или AWS Athena. Дата-инженеры Elucidata выбрали движок Athena, который основана на Presto. Он требует, чтобы определение всех внешних запрашиваемых таблиц присутствовало в хранилище метаданных, совместимом с Apache Hive. Это позволяет механизму запросов знать, какие поля доступны для запросов и какие файлы на S3 следует читать, чтобы получить фактические данные.
Вместо настройки и обслуживания экземпляра Apache Hive использовался каталог данных AWS Glue, который поддерживается Delta Lake и Athena, а также имеет объектную модель с оплатой за таблицу.
Таким образом, платформа Polly теперь имеет два разных бэкенда, которые обслуживают API полнотекстового поиска и SQL-запросов, включая контроль доступа на уровне репозитория и сбор показателей. Новая инфраструктура хранения Polly позволяет использовать метаданные объектов как в Elasticsearch, так и в Delta Lake. А постоянное увеличение стоимости хранения составляет всего около $3 за терабайт принимаемых данных. При этом устранены риски, связанные с масштабированием Elasticsearch по вертикали или горизонтали из-за размещения матриц данных непропорционального размера.
Узнайте больше подробностей по проектированию и поддержке современных дата-архитектур в проектах аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Архитектура Данных
- Практическое применение Big Data Аналитики для решения бизнес-задач
- Аналитика больших данных для руководителей
Источники
