Apache Kyuubi [1] — это распределенный многотенантный SQL-шлюз. Его основная функция — принимать SQL-запросы, отправленные пользователями через такие протоколы, как JDBC/REST, и направлять его в управляемый им механизм SQL для выполнения в соответствии с многотенантной изоляцией. политика. В последней версии Kyuubi 1.8 Kyuubi Flink Engine переходит на API Flink SQL Gateway (далее — FSG) и поддерживает режим приложения Flink, что позволяет нам быстро развернуть доступный в рабочей среде распределенный шлюз Flink SQL с помощью Kyuubi.
Зачем тебе Кьюби?
Я полагаю, что первый вопрос, который придет в голову многим читателям, заключается в том, что Flink уже предоставляет SQL Gateway, зачем нам нужно представлять Kyuubi? На самом деле, ключевой ответ кроется в описании Кьюби: один распределенный, а другой мультитенантный, оба дополняют друг друга. Нагрузочную способность шлюза необходимо расширять по горизонтали, поэтому он естественным образом эволюционирует до распределенной; в распределенной среде необходимо обеспечить сходство сеансов, поэтому естественным образом возникает необходимость в мультитенантной маршрутизации; а к мультитенантам предъявляются более высокие требования. для изоляции, так и наоборот. Это также будет способствовать развитию распределенной архитектуры.
Комбинацию SQL Gateway и SQL Client можно использовать сразу после установки, что поможет нам быстро запустить демонстрационную версию. Однако в корпоративной производственной среде один экземпляр часто трудно удовлетворить запросы пользователей. Кроме того, часто разные бизнес-пользователи имеют разные версии Flink, встроенные зависимости и конфигурации ресурсов., что привело к тому, что нам пришлось поддерживать несколько экземпляров SQL Gateway. Что еще более неприятно, так это то, что экземпляр может совместно использоваться несколькими небольшими пользователями или быть эксклюзивным для крупного пользователя.Между пользователями и экземплярами SQL Gateway существует связь «многие ко многим». Кроме того, высокая доступность и балансировка нагрузки также являются сложными проблемами, с которыми приходится сталкиваться. Различные проблемы привели к высоким затратам на управление эксплуатацией и обслуживанием SQL Gateway, и появление Kyuubi в значительной степени решило эту проблему.
Основы Кьюби
Kyuubi в основном имеет три модуля: клиент, сервер и движок.
Рисунок 1. Архитектура Кьюби
- Клиент Kyuubi относительно прост: у него есть клиент, который можно использовать «из коробки» или выбрать открытые инструменты или протоколы, такие как DBeaver или JDBC/REST.
kyuubi-beeline - Сервер Kyuubi является основным модулем, и его основные обязанности:
- Предоставляет интерфейс, включая несколько протоколов для клиента, и принимает соединение.
- Управляйте жизненным циклом Engine и направляйте запросы пользователей в соответствующий Engine.
- Управление статусом сеанса/операции.
- Kyuubi Engine — это модуль, который несет фактическую вычислительную нагрузку. Он отвечает за преобразование запросов сервера Kyuubi в собственные операции движка и поддерживает несколько вычислительных движков, таких как Spark/Flink/Trino.
Многие читатели, возможно, обнаружили, что позиционирование FSG похоже на Flink Engine от Kyuubi (на самом деле, Kyuubi Flink Engine действительно имеет встроенный FSG), а уровень абстракции сервера Kyuubi является ключом к решению распределенных и многопользовательских проблем.
В архитектуре Kyuubi связь между клиентом и сервером, сервером и механизмом включает обнаружение сервисов и балансировку нагрузки, что означает, что различные модули очень слабо связаны. Клиент может подключиться к любому серверу Kyuubi в том же пространстве имен, а сервер Kyuubi также может получить доступ к любому движку в том же пространстве имен. Для коротких соединений с сохранением состояния в пакетном сценарии Kyuubi сохранит соответствующий статус в базе данных и гарантирует, что соединение всегда может попасть на один и тот же сервер посредством пересылки между серверами. Такая конструкция дает Кьюби отличные возможности горизонтального расширения.
Рисунок 2. Маршрутизация сеанса Kyuubi
Как упоминалось выше, маршрутизация мультитенантных запросов является основной функцией сервера Kyuubi. Сервер Kyuubi предоставляет различные уровни общего доступа к движку для удовлетворения потребностей мультитенантов в изоляции и выбирает механизм, соответствующий запросу, на основе уровня общего доступа к движку.
| Уровень доли | описывать | Возможность совместного использования | Изоляция | Подходит для сцены |
|---|---|---|---|---|
| СВЯЗЬ | Каждое соединение имеет эксклюзивный движок | самый низкий | Наибольший | Большой объем данных ETL или специальный запрос или задание в реальном времени |
| ПОЛЬЗОВАТЕЛЬ | Каждый пользователь имеет эксклюзивный движок | середина | середина | Обычный ETL или специальный запрос или задание в реальном времени. |
| ГРУППА | Каждая группа пользователей использует общий движок | высокий | Низкий | Обычный ETL или специальный запрос или задание в реальном времени. |
| СЕРВЕР | Все пользователи используют общий движок | Наибольший | самый низкий | Операции администратора |
Кроме того, жизненный цикл Engine автоматически контролируется Сервером. Если в данный момент нет подходящего Механизма, Сервер запустит Двигатель; а если Двигатель простаивает более определенного периода времени, Механизм автоматически отключается для экономии ресурсов.
дополнительные преимущества
Помимо вышеупомянутых основных преимуществ, Kyuubi имеет и дополнительные преимущества по сравнению с прямым использованием FSG. Существуют краткосрочные различия, вызванные разным прогрессом в разработке, а также долгосрочные различия, которые могут существовать из-за разного позиционирования проектов.
Режим развертывания приложения
Kyuubi поддерживает режим приложения Flink в YARN в последней версии 1.8, а режим приложения FSG все еще находится на стадии обсуждения (см. FLIP-316 [2]). Стоит отметить, что две реализации шаблона приложения в долгосрочной перспективе не одинаковы.
Чтобы понять разницу, сначала кратко рассмотрим основы Flink SQL. Когда мы выполняем Flink SQL, мы проходим следующие этапы:
- Синтаксический анализ: SQL-запрос, отправленный пользователем, сначала будет преобразован в логический план выполнения с помощью Parser.
- Оптимизация: план логического выполнения оптимизируется с помощью Planner Optimizer, и будет создан план физического выполнения.
- Компиляция: план физического выполнения затем используется для генерации кода Java (преобразование потока данных) с помощью кода Planner CodeGen для построения JobGraph.
- Выполнение: отправьте JobGraph в JobManager, который применяет TaskManager для выполнения задания.
Для режима сеанса Flink или режима каждого задания первые три шага выполняются в TableEnvironment клиента Flink, а скомпилированный JobGraph может быть сериализован и содержит всю информацию о задании, поэтому он очень подходит для разделения шлюза SQL и кластера Flink. . Другими словами, после того как шлюз завершит анализ, оптимизацию и компиляцию SQL, он может REST или отправить JobGraph в распределенное хранилище, например HDFS/S3.
Однако шаблон приложения создает новые архитектурные проблемы. Построение JobGraph в режиме приложения должно выполняться на стороне JobManager, а это означает, что компиляцию также необходимо выполнять на стороне JobManager. Для этого нам необходимо сериализовать план физического выполнения, созданный на шаге 2, и загрузить его в JobManager, и этот сериализованный объект — Json Plan [3].
Json Plan был представлен в Flink 1.14. Это сериализованное представление плана физического выполнения Flink ExecNodeGraph. Первоначально он был разработан для кросс-версийных обновлений Flink SQL. Теперь он также очень удобен для связи между FSG и JobManager из коробки. FLIP-316, предложение FSG по поддержке режима приложения, разработано на основе Json Plan.
Рисунок 3. Архитектура режима приложения FSG
Однако Json Plan в настоящее время имеет определенные ограничения. Самое большое ограничение заключается в том, что Json Plan поддерживает только оператор INSERT и оператор STATEMENT SET в потоковом режиме. Это приводит к тому, что режим приложения временно не может поддерживать пакетный режим и SELECT, что ограничивает объем данных. сценарии разведки.
Рисунок 4. Архитектура режима приложения Kyuubi
Напротив, режим приложения Kyuubi Flink Engine использует архитектуру, аналогичную режиму Spark Cluster. Анализ, оптимизация, компиляция и выполнение SQL выполняются непосредственно в среде TableEnvironment на стороне JobManager. Информацию о задании не нужно передавать между процессами. поэтому он не ограничен планом Json. Через Kyuubi мы можем использовать Flink для исследования произвольных данных, как при использовании Spark.
Наблюдаемость
В приложениях корпоративного уровня наблюдаемость, несомненно, является важным базовым требованием. Kyuubi предоставляет богатый набор метрик и отчетов, а также веб-интерфейс, встроенный в сервер Kyuubi, что позволяет нам отслеживать загрузку шлюза в любое время.
Фото 5. Веб-интерфейс Кьюби
С точки зрения метрик Kyuubi Metrics можно разделить на несколько категорий:
- Метрика подключения: отслеживайте количество подключений в разных состояниях.
- Метрика операций: отслеживайте количество операций в разных состояниях и продолжительность их выполнения.
- Метрика пула потоков: отслеживание достаточности пула потоков службы сервера Kyuubi.
- Метрика двигателя: отслеживайте количество двигателей в разных состояниях у разных пользователей.
- Метрика вызовов RPC: отслеживайте частоту и время различных вызовов RPC между сервером Kyuubi и движком.
Что касается отчетов, Kyuubi предоставляет самые популярные Prometheus Reporter и JMX Reporter. Если вам нужны метрики на основе журналов, вы также можете выбрать SLF4J Reporter, JSON Reporter или Console Reporter.
прогноз на будущее
От поддержки Spark до поддержки нескольких механизмов — Kyuubi шаг за шагом движется к цели «стандартного решения для SQL Gateway». Что касается поддержки Flink Engine, Kyuubi в будущем сосредоточится на дополнении K8 и возможностях камуфляжной аутентификации, чтобы улучшить опыт пользователей при использовании Flink SQL в различных средах.
28 октября в 14:00 Исследовательский институт NetEase Ханчжоу и NetEase Shufan проведут технологический салон «Shu Ka Talk · Five Committers Chat about the New Future of Hucang» в парке NetEase Hangzhou Park, пригласив ведущие компании в области технологий передачи данных Databricks и NetEase Shufan , при содействии экспертов-практиков из Fan и Ctrip, в том числе эксперта по технологиям больших данных NetEase Shufan, председателя Apache Kyuubi PMC/комитета Apache Spark Яо Цинь, технического директора группы открытого исходного кода Databricks, члена Apache Spark PMC Фань Вэньчена, NetEase Shufan, технологии больших данных эксперт, коммиттер Apache Spark Ю Сидуо, руководитель автономной вычислительной платформы Ctrip, член PMC Apache Kyuubi Чэнь Шаоюнь, эксперт по технологиям больших данных NetEase, коммиттер Apache Kudu Хэ Лифу и т. д., в общей сложности 5 звездных проектов Apache PMC/Committer собрались вместе, чтобы поговорим о Spark , новых разработках, новых практиках и новых ценностях в популярных технологиях озерных складов, таких как . Узнайте больше: сказал Шука | Топ-5 коммиттеров Apache рассказывают о новом будущем Хукана
ссылка
- Репозиторий Apache Kyuubi на Github
- FLIP-316: Знакомство с драйвером SQL
- FLIP-190: Поддержка обновлений версий для Table API и программ SQL.
об авторе
Линь Сяобо, коммиттер Apache Kyuubi, в настоящее время работает в отделе данных и обслуживания платформ NetEase Games, технологического центра и отвечает за базовые компоненты Flink и платформу вычислений в реальном времени Streamfly.