Всем привет! Меня зовут Амир, я Data Engineer в компании «ДЮК Технологии». Расскажу, как мы спроектировали и реализовали на Apache Druid хранилище разрозненных табличных данных.

Тысячи сотрудников заказчика каждый день создают сотни таблиц: отчеты, списки, прогнозы, статистика. К нам заказчик пришел с запросом: создать временное хранилище данных для создания аналитических витрин.

В статье опишу, почему для реализации проекта мы выбрали именно Druid, с какими особенностями реализации столкнулись, как сравнивали методы реализации датасорсов.

Задача

Задача — создать временное хранилище данных (ВХД), чтобы хранить в базах данных загруженные туда JSON/CSV/XLS/XLSX. Затем на основе данных создавать аналитические витрины.

Требуемые характеристики системы:

• Оперативное хранение данные с возможностью загрузки JSON/CSV/XLS/XLSX.

• Поддержка большого числа одновременных сессий.

• Поддержка горизонтального масштабирования.

• Возможность формирования витрин данных

• Возможность доступа к витринам из BI-инструментов и Dremio

• Отказоустойчивость.

Почему Apache Druid?

Инструментом для хранения данных из файлов был выбран Apache Druid — это колоночная база данных реального времени, хорошо подходящая для быстрой обработки больших, редко изменяющихся массивов данных и немедленного предоставления доступа к ним.

Apache Druid имеет уникальную распределенную и эластичную архитектуру, которая предварительно собирает данные из общего слоя данных в практически бесконечный кластер серверов данных. Эта архитектура обеспечивает более высокую производительность и большую масштабируемость по сравнению с такими базами данных, как PostgreSQL и MySQL.

Apache Druid хорошо подходит для создания графических пользовательских интерфейсов (GUI) аналитических приложений. Он также хорошо вписывается в бэк-энд высокопоточных API, которым требуется быстрое агрегирование данных.

Apache Druid поддерживает множество методов и источников для получения и хранения данных и предоставляет большой выбор встроенных API для выполнения тех или иных действий с данными и самой БД, что сильно облегчает взаимодействие с базой данных при помощи внешних инструментов и создания собственного UI с бэк-эндом.

Инструмент Apache Druid используют Airbnb, British Telecom, Paypal, Salesforce, Netflix, Cisco.

Каждая компания использует Apache Druid уникальным образом:

• Например, Netflix использует инструмент для агрегирования множества потоков данных, поглощая до 2 терабайт информации каждый час.

• Cisco использует Druid в работе аналитической платформы реального времени для сбора данных о сетевых потоках.

• Twitch использует Druid, чтобы помогать своим сотрудникам углубляться в высокоуровневые показатели, а не читать сгенерированные отчеты.

Теперь немного об устройстве хранения данных в Druid. Это пригодится для того, чтобы в дальнейшем понимать трудности, с которыми придется столкнуться.

На макро-уровне все данные, хранимые БД Druid, располагаются в Базах данных, которые в свою очередь разбиваются на датасорсы (datasource), которые по смыслу и строению ближе всего к «таблице» из реляционных баз данных, однако способ их записи на диск отличается из-за ориентированности на большие данные и хранение записей поколоночно. Каждый датасорс может иметь свою собственную схему, правила загрузки, ротации и прочее.

Каждая запись в датасорсе обязана иметь метку времени. С помощью неё данные разделяются на временные периоды, называемые временным отрезком (time chunk). Так в дизайн системы закладывается принцип партиционирования. Также, помимо времени, данные можно дополнительно разделять с помощью иных атрибутов, но это не обязательно.

Временные отрезки делятся на сегменты (segment), которые и записываются в постоянное хранилище.

Сегмент — это архив, содержащий несколько специальных файлов, в которых сохранена какая-то часть датасорса (datasource). Данные в нём записываются поколоночно.

При этом каждый сегмент имеет свою схему данных. Она может отличаться от сегмента к сегменту, но любая из них всегда будет являться подмножеством общей схемы датасорса.

Реализация решения

Работали с Apache Druid версии 24.0.1.

Для реализации наших целей мы создали веб-интерфейс, который подключался и отправлял в Apache Druid команды, используя его API.

Для загрузки пользовательских данных в Apache Druid мы использовали встроенный пакетный ввод (Native batch ingestion) — метод, при котором нужно загрузить в Druid так называемую спецификацию задания на загрузку (ingestion task spec, далее its), в которой указываются метаданные о загружаемом файле (местонахождение файла, формат файла, выгружаемые колонки, градация и прочее).

Спецификация позволяет быстро и эффективно загружать данные в Druid, используя заданные параметры и настройки. Большое количество параметров, которые можно настроить, помогает тонко настраивать индексацию данных и получать оптимальную производительность при запросах в Druid.

Бывают простые варианты, когда данные всегда грузятся из одного источника, и при этом оформление данных, количество и названия колонок всегда одинаковое. Но в нашем случае данные в файлах могли быть совершенно разные, и это создавало некоторые неудобства, поскольку нужно было под каждый файл сгенерировать индивидуальный its.

Ниже представлены основные параметры, которые могут использоваться в Ingestion spec:

• - `type`: тип источника данных (например, файл, Kafka, JDBC).

• - `dimensions`: список всех измерений (полей), которые будут индексироваться.

• - `metrics`: список всех метрик, которые будут вычисляться и храниться в индексе.

• - `timestamp`: поле временной метки в данных.

• - `granularity`: определяет размер временного окна и частоту, с которой данные будут индексироваться.

• - `inputFormat`: формат данных, используемый в источнике данных.

• - `parser`: параметры, используемые для преобразования данных в формат, который понимает Druid.

• - `tuningConfig`: настройки индексации, такие как размер блока сегмента, параметры сбора мусора и другие.

• - `ioConfig`: определение фактических настроек чтения и записи данных.

• - `firehose`: определяет способ получения потока данных.

Взаимодействие инструментов

В качестве технологий для бэкэнда мы выбрали Python и PostgreSQL. Далее расскажу, почему и для каких целей.

Общая схема взаимодействия инструментов:

Метаданные Apache Druid в PostgreSQL

Apache Druid хранит метаданные необходимые для работы кластера во внешних хранилищах, а внутри себя хранит только фактические данные, загружаемые пользователем. Для хранения метаданных поддерживаются Derby, MySQL и PostgreSQL. Мы выбрали PostgreSQL, так как это стабильное и гибкое open source решение, широко применяемое во многих крупных проектах.

И, так как у нас по задумке осуществлялся собственный веб-интерфейс с отдельной аутентификацией, отображением истории загрузок и прочих действий пользователей, PostgreSQL также стал хранилищем данных нашего веб-интерфейса и обработки данных пользователей.

Python – мост между Apache Druid и нашим веб интерфейсом

Мы использовали Python в качестве инструмента для написания бэк-энд части нашего веб-интерфейса, в частности использовали библиотеку FastAPI для написания микросервисов вызываемых нашим фронт-эндом.

Python хорошо подошел для решения наших задач, так как имеет все готовые библиотеки для взаимодействия с PostgreSQL и для вызова и обработки сторонних API.

Нами были написаны несколько микросервисов, с помощью которых веб-интерфейс мог взаимодействовать с PostgreSQL и Druid, создан функционал загрузки файлов на сервер и последующей их обработкой перед загрузкой в Apache Druid.

Dremio как альтернатива встроенной web консоли Apache Druid

Dremio обладает механизмом виртуализации данных, который подключается к различным источникам данных, включая базы данных, озера данных и облачные платформы хранения. Затем движок создает унифицированное представление данных, к которым можно получить доступ и запросить их с помощью SQL и других стандартных инструментов.

Проблемы реализации и их решения

Первой большой трудностью, которую нам нужно было решить, стала реализация индивидуального its для каждого файла: в разных файлах могло попадаться разное количество столбцов и с разными именами и градациями.

 Необходимо было создать гибкий шаблон its, который можно было подстраивать на уровне бэк-энда в момент загрузки файлов на сервер.

Для этого мы создали таблицу в PostgreSQL, куда сохранили шаблоны its с переменными вместо значений для параметров и написали функцию, которая получала от Python нужные значения для параметров, вычитывая данные из файла и подставляла в шаблон необходимые метаданные.

Следующим сложным шагом было решение проблемы хранения данных в Druid, а именно создание для каждого нового файла отдельный датасорс либо же создание для каждого пользователя отдельный датасорс, в который будут загружаться все его файлы. И мы провели исследование плюсов и минусов обоих этих вариантов, один файл — один датасорс (ОФОД), и один пользователь — один датасорс (ОПОД).

У каждого из двух вариантов были свои недостатки и положительные стороны.

У метода ОПОД были следующие плюсы и минусы:

О плюсах и минусах ОФОД:

По совокупности плюсов и минусов приняли решение для первоначальной реализации использовать метод ОФОД.

Для четкого разделения датасорсов между пользователями решили, что у каждого пользователя название датасорса будет начинаться с префиксом «логин+.+название загруженного файла», и каждый пользователь будет иметь доступ только к своим датасорсам.

Также нам нужно было решить вопрос хранения файлов, загруженных через веб-интерфейс, и дальнейшего их удаления после того, как данные этих файлов будут загружены в Apache Druid.

Было принято решение создать на сервере директорию, в которой эти файлы будут храниться и удаляться ежедневно по расписанию.

Стандартная схема работы Apache Druid:

Витрины без поддержки джойнов

В использованной нами версии Apache Druid не поддерживались DDL команды по типу create table/view, вместо этого можно было создавать модифицированные копии существующих датасетов с помощью конструкций INSERT-SELECT или REPLACE- SELECT. 

Но это можно было делать только при помощи встроенной web-консоли либо с помощью API, по JDBC же такая конструкция не срабатывала. В будущих версиях обещали решить это ограничение, но мы не могли ждать и продумали собственное решение.

Результаты внедрения

В результате внедрения мы получили рабочий продукт: 

• Все таблицы хранятся в едином хранилище.

• Веб-интерфейс c JWT аутентификацией.

• Аутентификация через Госуслуги.

• Разработанный нами коннектор для Dremio ARP, который транслирует запросы от дремио через JDBC. Позволяет в обход встроенной web консоли Apache Druid работать с датасетами.

• История загруженных файлов, которая позволяет загружать данные файлов пользователей в Apache Druid для дальнейшей работы с ними сторонними BI приложениями.

Какие есть планы развития продукта:

• У Apache Druid есть собственный веб-интерфейс. План — разработать минималистичную кастомизированную консоль для работы BI-аналитиков.

• Интерфейсы управления пользователями и логирования. 

• Реализация CI/CD для повышения скорости разработки.

• Мониторинг на базе Grafana.