Знакомство с OpenMLDB и его преимуществами по сравнению с родным Spark

Фон

Spark быстро стал де-факто стандартом обработки больших данных, и нет необходимости вводить его, но Spark по-прежнему имеет много недостатков в сценариях AI.

  1. хорошо: Native Spark хорошо обрабатывает большие данные в кластере Hadoop
  2. Недостаточно: SparkSQL недостатков постепенно выявляется в области извлечения фич
  3. недостаточно: Koalas, panda API на Apache Spark

Несмотря на то, что проекты SparkSQL и Koalas могут предоставлять некоторые важные функции обработки данных, поддержка функций, необходимая для извлечения функций, все еще очень ограничена. Производительность поддерживаемого вычисления признаков временного ряда неудовлетворительна. Он может поддерживать только автономный анализ, но для производства ИИ также требуются онлайн-вычисления. И поскольку этот процесс должен многократно использовать UDF / UDAF, есть еще много возможностей для улучшения интеграции Spark с открытым исходным кодом и AI.

В настоящее время в отрасли появляется все больше и больше нативных механизмов выполнения, таких как модуль Photon от Databricks, проект Intel OAP, проект Nvidia Spark-rapids и сервис Alibaba EMR. У этих проектов есть свои яркие точки. Их можно сгенерировать с помощью базового нативного кода, полностью использовать характеристики векторизации ЦП и параллельных вычислений с помощью графического процессора, а также значительно улучшить производительность Spark в определенных сценариях. Но все же есть недостатки. Прежде всего, он может поддерживать только офлайн-вычисления и онлайн-вычисления функций, а также услуги онлайн-оценки моделей, необходимые для посадки сцен AI. Во-вторых, отсутствует дополнительная оптимизация для часто используемых функций расчета временных рядов (SQL Over Window), и, наконец, для сценариев AI функция извлечения функций также не поддерживает.

Сравнение нескольких двигателей Spark

Итак, мы выпускаем наш проект OpenMLDB (SparkFE был движком OpenMLDB). Это могло бы компенсировать недостатки вышеупомянутых проектов и обеспечить лучшую производительность в приложениях AI. На основе оптимизации LLVM производительность улучшена более чем в шесть раз по сравнению с исходным Spark.

Преимущества

  • На основе оптимизации LLVM высокопроизводительная производительность улучшена более чем в 6 раз по сравнению с исходным Spark.
  • Для ИИ: расширьте синтаксис SQL, поддержите больше функций FE и вычислений характеристик временных рядов.
  • Онлайн и автономная согласованность, через расчет агрегирования функций окна базы данных временных рядов, SQL одним щелчком мыши онлайн реализуется.
  • Отсутствие затрат на миграцию, совместимость с приложениями SparkSQL, приложениями Scala, Java, Python и R позволяют повысить производительность без изменения кода.
  • Итак, наконец, будь то сценарий вычисления функции временного ряда или конкретный сценарий композиции таблицы для машинного обучения, окончательные результаты теста производительности показывают, что OpenMLDB может добиться повышения производительности от шести до сотен раз без увеличения стоимость оборудования.

Оптимизация производительности по сравнению с родным Spark3.0.

Здесь мы представляем некоторые сценарии применения OpenMLDB, уделяя особое внимание методам оптимизации производительности.

Первая оптимизация - это расчет собственного окна.

Нижний уровень основан на двухстороннем интерфейсе данных очереди C ++, эффективно реализующем стандартные функции окна и подокна. Расширение границы ROWS_RANGE, реализованное с помощью SQL, также может лучше решить проблему последовательности вычислений одних и тех же миллисекундных данных. Нативные оконные вычисления

  • Нативные оконные вычисления
  • ➡Улучшение производительности
  • ➡ ROWS_RANGE граничит
  • ➡ Окно с таблицами объединения
  • ➡ Обработка конфликта микросекунд
select trip_duration, passenger_count,
sum(pickup_latitude) over w as vendor_sum_pl,
max(pickup_latitude) over w as vendor_max_pl,
min(pickup_latitude) over w as vendor_min_pl,
avg(pickup_latitude) over w as vendor_avg_pl,
sum(pickup_latitude) over w2 as pc_sum_pl,
max(pickup_latitude) over w2 as pc_max_pl,
min(pickup_latitude) over w2 as pc_min_pl,
avg(pickup_latitude) over w2 as pc_avg_pl ,
count(vendor_id) over w2 as pc_cnt,
count(vendor_id) over w as vendor_cnt
from t1
window w as (partition by vendor_id order by pickup_datetime ROWS_RANGE BETWEEN 1d PRECEDING AND CURRENT ROW),
w2 as (partition by passenger_count order by pickup_datetime ROWS_RANGE BETWEEN 1d PRECEDING AND CURRENT ROW);

Второй момент оптимизации - это встроенная реализация LastJoin.

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

SELECT t1.name FROM t1 LAST JOIN t2 WHERE t1.id == t1.id

Третий момент оптимизации - это оптимизация многооконных параллельных вычислений.

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

SELECT
 min(age) OVER w1 as w1-min-age,
 min(age) OVER w2 as w2-min-age
FROM t1
WINDOW
 w1 as (PARTITION BY name ORDER by age ROWS BETWEEN 10 PERCEDING AND CURRENT ROW),
 W2 as (PARTITION BY age ORDER by age ROWS BETWEEN 10 PERCEDING AND CURRENT ROW)

Четвертый пункт оптимизации - расчет перекоса данных временного окна.

Подобно оптимизации смещения таблиц, окно дважды разделяет данные смещения, что значительно улучшает параллелизм вычислений задачи и полностью использует ресурсы кластера для снижения общей стоимости владения (TCO).

SparkFE (теперь объединенный с OpenMLDB) имеет множество оптимизаций, которые невозможно повторить. Поскольку он совместим с SparkSQL API, сценарии приложений аналогичны Spark, особенно в расчетах функций временных рядов, связанных с ИИ, и сращивании таблиц данных.

  • Извлечение признаков с временным порядком
  • Параллелизм для нескольких окон
  • Настраиваемое присоединение к таблице
  • Пользовательские функции извлечения функций
  • Оптимизация перекоса
  • Собственные функции агрегирования

Вот архитектура OpenMLDB, добро пожаловать в сообщество.