Недавно на DataFunSummit: Smart Finance Online Summit архитектор платформы 4Paradigm Чен Дихао сосредоточился на применении базы данных машинного обучения с открытым исходным кодом 4Paradigm OpenMLDB в финансовой сфере с темой «Оптимизация расчетов базы данных управления рисками OpenMLDB», а также базовая временная последовательность.Обработка функций, детали оптимизации расчетов окон и т. д. позволяют пользователям понять техническую архитектуру базы данных управления рисками, понять основные точки оптимизации производительности вычислений на основе окон и детали реализации оптимизации производительности.
1. Характерный дизайн сцены контроля рисков
База данных интеллектуального управления рисками, основанная на машинном обучении, постепенно заменила ручную проверку и экспертные правила и стала более точной и надежной системой управления рисками.Будет представлен дизайн интеллектуальной платформы управления рисками в сценарии управления рисками и ее дизайн функций. позже. .
Во-первых, это эволюция системы управления рисками.Все уже поняли, что с самого раннего ручного обзора были достигнуты определенные результаты, но цена высока, а эффективность низка. Вступая в 21 век, промышленность начала использовать сочетание возможностей компьютерной автоматизации и экспертных правил для решения проблем низкой эффективности и плохой автоматизации, однако она склонна к непредумышленным убийствам и имеет плохой пользовательский опыт. В последние годы системы управления рисками крупных финансовых институтов и интернет-финансовых предприятий стали внедряться на основе машинного обучения.
Во-первых, применение моделей машинного обучения, обученных на массивных данных, таких как традиционные LR-модели и более сложные DNN, может обеспечить более высокую точность, а также может обеспечить модельные прогнозы тысяч людей в соответствии с различными сценариями применения. Характеристики машинного обучения — более сильное сокрытие, более высокая точность и более высокая скорость итерации, и постепенно оно стало незаменимой технической поддержкой для интеллектуальных систем управления рисками.
С точки зрения эффекта, в сценарии предотвращения и контроля мошенничества с неличными транзакциями в Интернете государственного банка после запуска OpenMLDB точность прогнозирования увеличилась на 316% с коэффициентом отзыва около 0,5; в транзакции Сценарий обнаружения мошенничества. По сравнению с обнаружением мошенничества в процессе с использованием экспертных правил, когда доля ложных срабатываний составляет около 54% для отзыва, общий уровень ложных срабатываний снижается на 33%.
Интеллектуальная система управления рисками представляет собой платформу, реализованную путем объединения некоторых прошлых экспертных правил и новейших моделей машинного обучения. Синяя часть - это существующая бизнес-система в банке, есть черный и белый списки, а некоторые внешние данные, такие как данные временных рядов, могут быть импортированы в нашу платформу для принятия решений через хранилище данных. Он не полностью зависит от модели. , но сочетает в себе экспертные правила и правила. Механизм и служба оценки модели работают вместе, чтобы принять окончательное решение.
\
Модельная часть представляет собой традиционный процесс машинного обучения, такой как автономная часть данных, которая реализует такие функции, как импорт данных и предварительная обработка данных, извлечение признаков, обучение модели и последующая онлайн-модель, самообучение модели и обновление модели.
Это полный набор интеллектуальной системы управления рисками.То, что мы представляем сегодня, - это автономное управление данными нижнего уровня и служба онлайн-запросов функций OpenMLDB в этой системе.
l Разработка сложных функций в сценариях управления рисками
Давайте посмотрим на характеристики сцены управления рисками.Во-первых, информация о транзакции пользователя и атрибуты пользователя очень важны. Функции временных рядов также особенно важны в сценариях управления рисками. Пользователи находятся в разных окнах, таких как предыдущий день, предыдущие семь дней, предыдущий месяц и предыдущие три месяца. Эти окна содержат очень важные информационные функции. количество транзакций и сумма транзакций в разных исторических окнах, необходимо рассчитывать разные характеристики.
Существуют также максимальное и минимальное значение суммы транзакции, информация о местоположении транзакции и т. д., каждая из которых содержит некоторые непрерывные характеристики поведения. Поэтому, когда мы строим модель машинного обучения в сценарии управления рисками, проектирование функций является относительно сложным, и нам необходимо учитывать расчет, связанный со сроками функций.Самая большая трудность заключается в том, что после того, как эти функции разработаны учеными, им нужно для повторного внедрения в онлайн-систему.
Традиционным способом автономной реализации является использование системы OLAP или MPP, Spark, Flink и т. д. сами по себе поддерживают скользящее окно стандарта SQL. Но онлайн трудно достичь, каждую офлайн-функцию нужно переводить в онлайн. Если наша схема моделирования изменена или добавлены некоторые новые функции, необходимо также разработать новые функции в режиме онлайн. Новая онлайн-разработка функций и автономная система на основе MPP представляют собой два набора вычислительной логики и механизмов выполнения, и оптимизация выражений также отличается, требуя много ручной проверки согласованности функций в автономном и онлайн-режиме.
l OpenMLDB обеспечивает лучшую поддержку расчета признаков
OpenMLDB может решить эту проблему.Он оптимизирует функции для сценариев ИИ.Он не только реализует оптимизацию расчета функций автономного хранилища, но также реализует запросы онлайн-бизнеса в режиме реального времени на миллисекундном уровне.
Во-первых, OpenMLDB — это механизм вычислений функций для сценариев ИИ, который может обеспечить правильную и эффективную подачу данных для приложений машинного обучения.Будь то автономные данные или онлайн-данные, нижний уровень имеет последовательную синхронизацию, которая чем-то похожа на HTAP. упомянутый выше. Но наши онлайн-данные — это высокопроизводительный интерфейс последовательного доступа к памяти, который может обеспечить последовательную подачу данных на миллисекундном уровне. Для достижения согласованности расчета функций в режиме онлайн и в автономном режиме и согласованности хранения это достигается с помощью унифицированного механизма выполнения.Унифицированный оптимизатор SQL на основе (LLVM JIT) реализует один и тот же механизм выполнения в автономном режиме и в режиме онлайн.Функции рассчитываются без ручной проверки и перевода, и он также поддерживает специальные пакетные операции с таблицами для сценариев машинного обучения, а также функции извлечения специальных функций.
Во-вторых, OpenMLDB также является высокопроизводительным исполнением OLTP и MPP, который поддерживает чтение, запись и восстановление высокопроизводительных онлайн-данных серии Wime. Его производительность чтения и записи очень высока, и она оптимизирована для данных о временных рядах. В настоящее время ни OLTP, ни TSDB в отрасли не могут достичь производительности миллисекундного уровня. С точки зрения оптимизации и поддержки оборудования, OpenMLDB может использоваться на носителях памяти и PMEM. PMEM - это новая среда хранения, предоставляемая Intel. Его стоимость ниже, чем в памяти, и это новая постоянная среда хранения. Мы это Также оптимизирован для PMEM, а скорость восстановления данных составляет более десяти раз, чем у оригинала. Кроме того, производительность автономной пакетной обработки OpenMLDB составляет более чем в 6 раз выше, чем у основных систем MPP MPP в отрасли. Мы все знаем, что распределенные системы, такие как Spark и Presto, имеют очень хорошую оптимизацию производительности и имеют хороший исполнительный двигатель, но они не специально оптимизированы для сценариев AI. Следующий рисунок - это диаграмма производительности нашей фактической проверки сцены. Ордана - это время работы. OpenMLDB - более десяти раз лучше, чем последняя версия, которую мы проверены.
2. Оптимизация параллельных вычислений
Как OpenMLDB выполняет вычислительную оптимизацию для этих функций управления рисками? Начнем с введения оптимизации параллельных вычислений. Когда вы используете OpenMLDB для крупномасштабного извлечения признаков, производительность повышается в несколько раз по сравнению с основными системами MPP в отрасли благодаря оптимизации базовых вычислений.
В крупномасштабных системах обработки данных Hadoop начал появляться в 2000 году, а Spark, Presto, Flink и т. д. стали популярны после 2010 года. Можно использовать память для перетасовки, чтобы избежать отбрасывания диска, а его вычислительная производительность в разы, а то и десятки раз по сравнению с Hadoop Повышение производительности. Сегодня четвертая нормальная форма OpenMLDB будет иметь больше улучшений производительности, чем Spark и Presto, при некоторой крупномасштабной обработке данных.Ниже мы подробно расскажем об основных деталях оптимизации.
\
Слева от OpenMLDB находятся некоторые периферийные системы, поддерживающие импорт данных. Его внешние пользователи имеют программные интерфейсы, такие как JDBC или Pytho SDK. Нижний уровень — это самостоятельно разработанный синтаксический анализатор SQL и некоторые пользовательские оптимизаторы. Серверная часть реализует на основе LLVM Механизм выполнения, который может быть оптимизирован для различного оборудования, такого как X86, архитектура ARM и т. д., также может в будущем обеспечивать аппаратное ускорение графического процессора на основе бэкэнда LLVM PTX.
Нижний уровень включает в себя два исполнительных механизма, один из которых является исполнительным механизмом в реальном времени, который, как и традиционная система OLTP, может обеспечивать сверхвысокопроизводительные функции чтения и записи функций синхронизации. Вторая часть — Massive parallel executor, которая похожа на традиционную систему MPP и поддерживает сценарии обработки больших данных OLAP. Нижний уровень представляет собой унифицированный механизм хранения, который использует OpenMLDB для извлечения признаков, а также поддерживает экспорт форматов данных машинного обучения с открытым исходным кодом.Например, Tensorflow и LightGBM могут напрямую использовать данные OpenMLDB для обучения модели. Благодаря таким функциям, как согласованность в автономном и онлайн-режиме, каждая функция не требует дополнительной онлайн-разработки перевода и может быть запущена напрямую.
l Многооконная параллельная оптимизация
Почему пакетный режим OpenMLDB в несколько раз быстрее, чем последний Spark 3.1? Первый пункт оптимизации — многооконная параллельная оптимизация.
\
Выше приведен простой оператор SELECT. Расчет агрегации окон выполняется в соответствии с W1 и W2. Определения этих двух окон различны. Если они совпадают, сгенерированный логический план будет объединен и оптимизирован. Но поскольку его ключ раздела отличается, логический план, транслируемый этим SELECT, совпадает с планом слева. Во-первых, данные из таблицы Т1, а по ней идут последовательные вычисления двух окон, так реализованы практически все фреймворки распределенной обработки данных с открытым исходным кодом. Сложность этой реализации относительно невелика, и она также вычисляется последовательно при встрече с несколькими окнами.Достаточно отфильтровать результаты W2 и столбцы, требуемые T1, а затем выполнить W1.
Однако здесь будет пустая трата ресурсов, так что места для оптимизации еще много. Сами по себе расчеты в двух окнах могут не использовать все вычислительные ресурсы.Теоретически параллельные вычисления должны быть возможны для достижения более высокой производительности.Если возникает проблема перекоса данных в одном окне, второе окно может быть выполнено в ближайшее время.Его тоже нужно подождать чтобы первое окно завершилось до того, как оно запустится. Следовательно, его общее вычислительное время напрямую накапливается, сколько времени нужно W1 и сколько времени нужно W2, что в сумме составляет его общее время работы.
\
Реализация многооконной параллельной оптимизации OpenMLDB позволит распараллелить последовательную структуру. Левая и правая стороны узла DataProvider представляют собой два узла WindowAgg. Эти два узла не зависят друг от друга. Пока ресурсов достаточно, параллельные вычисления могут выполняться во время выполнения. Конечно, параллельные вычисления реализуются сразу, и их результат после оптимизации согласуется с результатом последовательного выполнения.
Как достигается этот параллелизм? Предыдущий пользователь может получить оптимизированный логический план после компиляции с помощью нашего анализатора SQL. Нижний уровень — это узел DataProvider, представляющий собой параллельную структуру после оптимизации. При выполнении сначала вынимаем нужные данные, а потом делаем второй WindowAgg.Они не зависят друг от друга, и данные не нужно читать дважды, а все зависит от узла DATA PROVIDER. Чтобы реализовать слияние данных параллельного окна, необходимо добавить узел JOIN. Предыдущий простой узел фильтрации столбцов не имеет потребления производительности, а только указывает, какие столбцы мне нужно вводить при расчете в логическом плане, в реальном расчете ему не нужно кодировать, декодировать и передавать всю строку данных.
После того, как данные поступят, мы выполним параллельные вычисления данных двух узлов. После расчета мы соединим их вместе с помощью операции написания таблицы. Наконец, мы ПРОЕКТИРУЕМ необходимые столбцы. В дополнение к окну у нас есть также добавлена операция написания таблицы, но оптимизировано выполнение нескольких окон. Если есть непрерывное окно, мы можем сделать всю его непрерывную параллельную оптимизацию.
Хотя логика реализации кажется относительно простой, она просто распараллеливает последовательную структуру, но сейчас не все реализуют ее таким образом.Основная причина в том, что детали реализации этой оптимизации все еще относительно сложны. Мы знаем, что, как и в первом окне, при выполнении агрегации окон W1 столбцы имени и возраста окна должны быть зарезервированы в первую очередь.Только эти два столбца можно использовать для сортировки разделов, а возраст необходимо агрегировать.
Требования W1 и W2 различаются.Недостаточно хранить только столбец age, рассчитанный для каждого окна.По сути, это последовательное выполнение.Когда T1 заканчивает окно W2, он не только сохраняет столбцы, рассчитанные W2 ., также сохраните столбец W1, и даже все необходимые столбцы, вы можете сделать W1 только после вывода W2. При выполнении параллелизма каждое окно должно выводить только свой собственный столбец, но ключ раздела окна отличается, и данные в каждом разделе в распределенных данных также различаются, поэтому простое объединение не может быть выполнено напрямую в том же порядке. , поэтому у нас есть некоторые операции по добавлению новых столбцов, и ему будет присвоен индексный столбец для всех данных.
Реализация кода занимает восемь шагов, каждый шаг относительно сложен. Вот краткое введение, вы можете увидеть конкретную реализацию из открытого исходного кода OpenMLDB (адрес открытого исходного кода OpenMLDB:GitHub.com/4paradigm/О…).
Первый - получить логический план, и мы должны его проанализировать. Нам нужно знать, какие узлы Window нужно оптимизировать параллельно, и количество столбцов параллельных оптимизированных узлов разное. При обработке этого узла метод реализации такое же, как и у обычных узлов, окно тоже другое.
-
Пройдите через узел LastJoin1 и найдите все узлы ConcatJoin.Есть только узел ConcatJoin3, который хранится в списке.
-
Начните с узла ConcatJoin3, выполните предварительный обход, затем начните маркировку, создайте уникальное имя столбца индекса и установите его на карту метки.
-
Проходя через дочерние узлы ConcatJoin3, каждый узел устанавливает карту флага, где ключ — это идентификатор узла, а значение — имя столбца индекса, сгенерированное ранее.
-
В процессе обхода дочерних узлов также необходимо проверить, чтобы найти следующий общий дочерний узел ConcatJoin3, которым здесь является SimpleProject6, и установить для него флаг Map.
-
При фактическом запуске узла он выполняется обходом логического плана в обратном порядке.Для узла SimpleProject6 при запуске логики слева необходимо заранее добавить столбец индекса по флагу Map.При этом время результат не может быть закеширован, потому что он не может быть возвращен при вычислении правой части DataFrame столбцов индекса.
-
Промежуточные узлы, такие как WindowProject4 и WindowProject5, согласно информации флага Map, знают, что столбец индекса был добавлен, и столбец индекса необходимо удалить при выполнении вычисления окна и кодировании и декодировании.
-
При вычислении узла ConcatJoin3 вы можете использовать последнее соединение или левое соединение, и вам нужно удалить столбец индекса в соответствии с флагом Карта.
-
Другие узлы, такие как LastJoin1, SimpleProject2, DataProvider7 и SimpleProject8, ведут себя правильно со старой логикой.
Обратите внимание, что шестой шаг — это вывод всех проиндексированных столбцов. Если есть другие узлы, которым требуется вывод без столбца индекса, этот узел будет иметь два выхода. Два узла, WindowProject4 и WindowProject5, были помечены и знают, что это за узлы, и столбец индекса необходимо удалить при расчете. Поскольку до того, как сам этот узел не будет оптимизирован, его расчет состоит в том, чтобы обработать столько столбцов, сколько он вводит, но после параллельной оптимизации ему необходимо удалить столбец индекса при выполнении функции C, но ему необходимо удалить столбец индекса, когда Добавлены индексные столбцы.
В приведенном выше примере SQL W1 и W2 выполняют только одно вычисление признаков и выводят только соответствующий столбец результатов и один индексный столбец. После получения этих двух выходных таблиц нам нужно выполнить операцию написания таблицы, потому что все они имеют уникальный идентификатор индекса, и индекс останется неизменным даже после выполнения расчета окна. На основе предыдущего столбца индекса мы можем создать таблицу правописания, которая может быть реализована с помощью последнего соединения или левого соединения.Эти два узла не затрагиваются оптимизацией, и логика выполнения такая же, как и раньше.Будь то ввод или вывод , итоговая таблица такая же, как и предыдущая, оптимизация такая же.
Давайте посмотрим на эффект многооконной параллельной оптимизации. Во-первых, логически видно, что если у вас есть два окна и вычислительных ресурсов достаточно, два окна вычисляются параллельно, и время его расчета должно быть в состоянии уменьшить окно с более коротким временем выполнения, которое будет короче после параллельной оптимизации.Время, занимаемое окном, игнорируется. Как и в случае с баррелем, узкое место, отнимающее много времени у всего пользователя, находится в самом длинном окне. В сочетании с оптимизацией логики расчета окна LLVM наше окончательное оптимизированное время может быть сокращено до очень низкого уровня.
Производительность параллельной оптимизации показана на рисунке.Здесь перечислены три сценария тестирования производительности.По сравнению с последней системой MPP производительность OpenMLDB и системы MPP с открытым исходным кодом, основанной на параллельной оптимизации окна, может быть в 5,3 раза выше, чем у исходной, по сравнению к производительности самой OpenMLDB примерно в 2 раза.
3. Оптимизация наклона окна
OpenMLDB также имеет большое количество оптимизированных реализаций для перекоса данных окна. Во-первых, давайте представим основы перекоса данных и перекоса данных окна.Перекос данных — обычное явление в сценариях обработки больших данных.Объем данных определенного раздела или ключа очень велик, что непропорционально объему данных других разделов. . Например, когда пользователь собирает информацию о таких пользователях игры, если производится разделение на мужчин и женщин, пользователей игры, это, вероятно, будет перекошено.Например, пользователей мужского пола будет больше, и эти данные делятся по половому признаку.Типов будет не много, и количество перегородок будет небольшим. Это также приводит к очень небольшому параллелизму, когда мы выполняем агрегацию разделов.
Перекос данных приведет к большому разрыву между результатами вычислений раздела данных и других разделов.Другими словами, вычислительная задача раздела данных с перекосом серьезно не соответствует ресурсам его процессора. В итоге будет ситуация ожидания на один больше одного.После завершения расчета нескольких разделов с малым объемом данных ждут наклонного раздела с большим объемом данных.Только после расчета наклонного раздел завершен, результат можно вывести. Это огромная катастрофа для эффективности. Например, 64 ядра, каждый раздел обрабатывается одним, каждая задача — 20 ядер, и время относительно велико. После завершения нескольких небольших разделов данных необходимо дождаться различения больших данных.Результат может быть выведен только после завершения расчета наклонного раздела, а производительность ограничена.
Существует несколько сценариев искажения данных. Например, сделать один (уменьшить) для каждого раздела. Между разделами нет никакой связи. Я делю данные на 128 разделов, чтобы можно было использовать все ресурсы ЦП. После того, как каждый раздел израсходован, можно выполнить агрегацию для получить результат.
При расчете функций машинного обучения перекос данных возникает при расчете окна, и в определенном разделе слишком много данных.Когда возникает проблема перекоса, традиционная схема оптимизации перекоса данных, о которой мы только что упоминали, не может быть использована. Мы добавляем префикс к данным, а префикс может отделять больше разделов, почему мы не можем этого сделать? Поскольку расчет окна зависит от данных до и после, он основан на данных до и после определенных данных для агрегирования. Если мы принудительно разделим данные на десять разделов для пользователей мужского пола, расчет первого раздела может быть правильным, но второй раздел зависит от данных предыдущего раздела, поэтому в традиционной реализации, будь то SparkSQL, FlinkSQL и т. д. , Ни один из этих данных не оптимизирован.
OpenMLDB предлагает схему оптимизации перекоса данных окна на основе Spark, которая расширяет данные.Если прямой раздел не расширен, окна различных расчетов данных будут неточными, а результаты будут противоречивыми. После того, как мы завершим расширение данных, мы создадим новые разделы в соответствии с новым ключом раздела и временным интервалом, и параллелизм будет выше.
Это типичный сценарий с наклонным окном, и в наших обучающих данных есть только два пола, мужской и женский. В этом сценарии, если мы создадим функцию окна для мужчин и женщин, ключ раздела будет иметь только два значения, и на самом деле будет только два раздела. То есть в этом сценарии SQL мы агрегируем на основе ключа раздела.В реализации всего два раздела.Независимо от того, имеет ли ваш кластер Hadoop 100 или 1000 ЦП, задача Spark может быть разделена только на две задачи для обработки. Задача трудоемкая находится на наклонной перегородке.
Схема оптимизации перекоса данных окна, обычно выполняется тяжелое разбиение. Здесь аналогичный принцип, если разделить на четыре партиции, то степень параллелизма будет выше. Наш общий подход заключается в префиксе, скажем, для всех мужчин мы добавляем разные префиксы 1 и 2. После добавления префикса мы разбиваем префиксный ключ, и параллельный сценарий из параллельного 1 может стать 2. Это традиционное решение, но оно не может решить расчет окна, то есть не может справиться с перекосом времени вычисление характеристик серии проблема.
Предполагая, что это функция временного ряда, ввод и вывод представляют собой четыре строки, и каждая строка предполагает, что ее окно является первыми двумя данными пользователя, а для ее собственных данных данные ее окна сначала разделены. Перед первыми данными нет данных, и расчет правильный. Второй фрагмент данных имеет только один фрагмент данных, и эти данные можно найти в этом разделе.Первые два результата непротиворечивы, а третий несогласован в начале. В исходной таблице все они мужского пола, а впереди два данных, которые следует включить в расчет агрегации. Но после повторного разбиения данных перед этим разделом нет, а вычисление окна вычисляет только один кусок, и результаты вывода несовместимы до и после оптимизации.
Решение OpenMLDB реализовано в четыре этапа. Из конечного результата оптимизации видно, что степень параллелизма до оптимизации равна 2, а степень параллелизма после оптимизации равна 4, что можно увеличить как минимум вдвое.
\
Первый шаг — это оценка данных. Во-первых, мы подсчитаем, искажены ли данные. Предполагая, что есть данные, которые необходимо переразбить, мы повторно разделим все данные на несколько частей. В этом примере мы сначала подсчитаем 20% и 50% из четырех частей., Что составляет 70% данных, а затем данные могут быть равномерно разделены на несколько блоков, и объем данных в каждом блоке близок. Для расчета 25% каждого блока требуется полная статистика данных.Здесь можно сделать приблизительный запрос, чтобы найти значение 25% позиции ключа сортировки каждого данных.Приблизительная производительность расчета также лучше, чем полная статистика , гораздо лучше.
\
Второй шаг - маркировка данных.После получения таблицы распределения данных данные могут быть помечены.Используемое здесь соединение представляет собой операцию написания таблицы. Добавьте его, чтобы проанализировать каждые данные на свой ПРОЦЕНТИЛЬ. Например, данные мужчин и женщин делятся на четыре части поровну, и каждая строка сравнивается с несколькими процентными значениями, первая часть делится на первый блок, а вторые данные делятся на второй, третий и четвертый блоки. соответственно. С новым добавленным столбцом я знаю блок каждой строки данных и могу расширить каждый блок данных.
Третий шаг - делать расширение данных. Когда второй раздел используется для расчета окна, вполне вероятно, будет использовать данные первого раздела. При расширении данных первого раздела мы добавляем условие фильтрации, что идентификатор меньше Чем 2. Условный столбец выбран, и флаг устанавливается кстати. Исходные данные остаются неизменными, и выполняется UNICN. После последнего количества UNICN сумма данных в таблице увеличится. Это было изначально десять Ряды, и он расширяется до двадцати рядов.
Четвертый шаг — переразметить данные, которые сильно отличаются от оригинала.Получается, что у нас всего два раздела, мужской и женский. Возьмем мужской раздел в качестве примера.Предполагая, что параллелизм здесь равен 4, совокупный расчет окна, выполняемый каждым разделом, будет иметь достаточно данных и не приведет к утечке данных. По сравнению с исходной таблицей самец можно разделить только на один раздел, а после оптимизации — на четыре.
Пятый шаг — выполнить расчет скользящего окна после переразбиения. Первоначально в каждом разделе было несколько фрагментов данных. Например, если были введены два фрагмента данных, два фрагмента данных должны быть выведены. Здесь, если несколько фрагментов данных выводятся напрямую, окончательный результат вывода будет несовместим с исходным. оптимизация. Поэтому мы сделали оптимизацию расчета окна, после расширения данных мы не даем ему выводить результат, оно участвует только в расчете скользящего окна, а нижний слой будет добавлен в очередь данных окна. Первые два данных существуют только для расчета третьего, и их не нужно выводить. В итоге при выполнении первые два данных будут помещены в окно, но не выведены, а при использовании третьих данных для расчета окна может быть получен предыдущий результат и может быть выведен правильный результат. Таким образом, выходные данные результата могут быть гарантированы.Например, здесь пять мужских разделов, что так же, как и до оптимизации.
\
После оптимизации наклона окна OpenMLDB сравнил последнюю версию SparkSQL, и сама OpenMLDB показала в четыре раза более высокую производительность по сравнению со Spark. После добавления оптимизации наклона множители Spark улучшаются больше, и улучшение также более очевидно, чем без оптимизации наклона. Кроме того, чем более склонны ресурсы оптимизации, тем очевиднее будет повышение производительности.
4. Резюме вычислительной оптимизации
В последней части представлены другие детали оптимизации и кратко изложена схема оптимизации расчетов в сценарии управления рисками. Первый — это реализация нативной склейки таблиц, допустим, таблицы Т1 и Т2 подлежат склейке, но есть надежда, что объем данных основной таблицы после склейки останется неизменным, а размер выборки тех или иных данных не изменится. увеличение после таблицы сплайсинга.Это требует специального правописания. Мы можем реализовать его на основе Spark, но его производительность будет относительно низкой. OpenMLDB может добиться повышения производительности почти в 100 раз. Нижний уровень — это новая собственная реализация проверки правописания таблиц, поддерживаемая модификацией исходного кода Spark.
Во-вторых, оптимизация ZeroCopy памяти.Основной механизм выполнения OpenMLDB реализован на C++.Все вычисления функций не реализованы в JAVA, но сам объект JAVA не может получать данные через указатели.
Мы сделали относительно экстремальную стыковку с форматом Spark UnsafeRow.Хотя Spark реализован на основе JAVA/Scala, в нем есть механизм управления памятью, и мы добились совместимости с расположением памяти объектов строки Spak. Слева — схема памяти Spark UnsafeRow, а значения каждого столбца хранятся в определенном формате. Мы создали интерфейс, совместимый с памятью, который может напрямую читать и записывать в память UnsafeRow, и каждый столбец может получать значение столбца посредством вычисления смещения указателя. После реализации этой функции нам не нужно кодировать и декодировать Spark-строки, и улучшение производительности также очевидно. В случае тысячи колонок Columns время выполнения можно сократить примерно вдвое.
Наконец, приветствую всех, кто продолжает обращать внимание на четвертую парадигму OpenMLDB:
Адрес открытого исходного кода OpenMLDB:GitHub.com/4paradigm/О…