Elasticsearch + Delta Lake: архитектура данных биотех-платформы Polly

архитектура данных дата-инженер примеры курсы обучение, курсы Delta Lake Spark NoSQL, курсы по NoSQL базы данных архитектура данных примеры курсы обучение кейсы, обучение NoSQL, курсы дата-инженер, обучение Big Data для разработчиков, NoSQL Delta Lake для разработчиков и архитекторов обучение курсы, учебный центр Коммерсант Школа Больших Данных, курсы Big Data в Москве

Зачем биотехнологической платформе 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 в Москве:

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Источники

  1. https://medium.com/elucidata/how-to-build-a-scalable-backend-to-query-and-search-billions-of-records-16a532433fda
  2. https://docs.aws.amazon.com/opensearch-service/latest/developerguide/what-is.html
Поиск по сайту