Практика UData+StarRocks в JD Logistics | Техническая команда JD Logistics

[Предварительный просмотр прямой трансляции] Как далеко нам нужно зайти, чтобы заменить Oracle?

1. История

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

1.1 Услуги передачи данных

• Модель разработки «дымохода»: для каждого требования разрабатывается служба данных.Сервисы данных не могут использоваться повторно, их сложно создать на платформе и невозможно аккумулировать технологии.
• Обслуживание услуг затруднено: при разработке большого количества сервисов передачи данных последующее обслуживание становится большой проблемой, особенно во время рекламных акций 618 и Double 11, когда один человек обслуживает сотни из них без единого мониторинга, текущего ограничения и планов аварийного восстановления. Службы передачи данных — это очень болезненная вещь, которая также создает большие риски для безопасности.
• Большой спрос со стороны бизнеса: студенты, занимающиеся разработкой данных, часто скованы большим количеством повторяющихся и скучных разработок сервисов данных и тратят много времени на разработку сервисов бизнес-данных.

1.2 Анализ данных

• Сложность поиска данных: пользователям трудно найти то, что они хотят. Даже если они найдут индикаторы или данные со схожими названиями, их нельзя использовать напрямую, поскольку калибр индикатора неясен и непоследователен.
• Сложность использования данных: поскольку данные в настоящее время распределены в различных системах, пользователи не могут использовать одну систему для удовлетворения всех потребностей в данных. В частности, фронтовым операторам приходится экспортировать большие объемы Excel из различных систем для анализа данных, что отнимает много времени и труда, а также создает риски для безопасности данных.
• Медленный запрос: при использовании традиционного механизма Olap пользователям часто требуется несколько минут для запуска SQL для получения результатов, что значительно снижает эффективность аналитиков.
• Механизмы запросов не унифицированы: система может состоять из нескольких механизмов запросов. Каждый механизм запросов имеет свой собственный DSL, что увеличивает стоимость обучения пользователя. В то же время очень неудобно выполнять запросы к нескольким источникам данных. Другая проблема, вызванная гетерогенными механизмами запросов, — это образование островов данных, и данные между различными системами не могут быть связаны друг с другом.
• Обновление данных в режиме реального времени. Традиционный автономный метод обновления данных T+1 больше не может отвечать бизнес-требованиям современных операций в реальном времени, что требует от системы достижения задержки второго уровня.

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

2 Интегрированная практика анализа сервисов данных на базе StarRocks

Основываясь на вышеперечисленных болевых точках бизнеса, команда JD Logistics Operation Data Product разработала интегрированную систему анализа услуг — UData (Universal Data), которая реализована на основе технологии движка StarRocks. UData абстрагирует процесс генерации индикаторов данных и использует конфигурацию для создания сервисов данных с небольшим количеством кода, что значительно снижает сложность и сложность разработки, позволяя студентам, не занимающимся исследованиями и разработками, настраивать и публиковать свои собственные сервисы данных и разработку индикаторов в соответствии со своими потребностями. Время было сокращено с предыдущих одного-двух дней до 30 минут, что значительно высвободило возможности исследований и разработок. Платформенная система управления индикаторами и функции карты данных позволяют пользователям более интуитивно и удобно находить и поддерживать индикаторы, а также делают возможным повторное использование индикаторов.

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

Схема архитектуры потока данных:

Структура до трансформации:

Рис. 1. Схема архитектуры до трансформации

Перед преобразованием данные в реальном времени импортировались во Flink из JDQ (Jingdong Log Message Queue, аналогично Kafka) и JMQ для обработки данных в реальном времени. После обработки данные записывались в Clickhouse и ElasticSearch для предоставления услуг запросов Olap для услуги обработки данных и анализ данных. Автономные данные обрабатываются Spark на уровне хранилища данных, а данные уровня приложения синхронизируются с запросом Mysql или Clickhouse for Olap. В этой архитектуре службы данных и анализ данных представляют собой две отдельные части.Инструментам анализа сложно выполнять анализ данных из нескольких источников данных и разных языков запросов.Службы данных также разрабатываются в стиле дымохода.

Обновленная архитектура:

Рис. 2. Преобразованная архитектура

После преобразования мы представили StarRocks на уровне хранения данных. StarRocks обеспечивает чрезвычайно быстрые возможности однотабличных и многотабличных запросов. В то же время мы создали единый механизм запросов на основе StarRocks. Унифицированный механизм запросов добавляет источники данных и агрегирование в соответствии с бизнес-характеристиками JD.com. Функция push-down и другие функции UData унифицируют функции анализа данных и обслуживания данных на основе единого механизма запросов.

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

2.1 Причины чрезвычайно высокой производительности запросов StarRocks

Запрос к одной таблице для чрезвычайно быстрого запроса:

StarRocks многое сделали в плане чрезвычайно быстрых запросов. Здесь мы сосредоточимся на следующих четырех моментах:

1. Векторизованное выполнение: StarRocks реализует комплексное векторизованное выполнение от уровня хранения до уровня запросов, что является основой преимущества SR в скорости. Векторизованное выполнение полностью использует вычислительную мощность ЦП. Полностью векторизованный механизм организует и обрабатывает данные в виде столбцов. Хранение данных StarRocks, организация данных в памяти и вычисление операторов SQL реализованы в виде столбцов. При организации данных на основе столбцов также будет более полно использоваться кэш ЦП. С другой стороны, комплексный механизм векторизации StarRocks в полной мере использует инструкции SIMD, предоставляемые ЦП посредством алгоритмов векторизации. Таким образом, StarRocks может выполнять больше операций с данными с меньшим количеством инструкций. После проверки на стандартном наборе тестов комплексный механизм векторизации StarRocks может улучшить общую производительность выполнения операторов в 3–10 раз.
2. Материализованные представления ускоряют запросы. В реальных сценариях анализа мы часто сталкиваемся с ситуацией анализа десятков миллиардов больших таблиц. Хотя производительность SR превосходна, на скорость запросов по-прежнему влияет большой объем данных. В настоящее время добавление измерений, которые пользователи часто агрегируют. Благодаря материализованному представлению скорость запроса увеличивается более чем в 10 раз без изменения оператора запроса. Интеллектуальное материализованное представление SR позволяет запросу автоматически сопоставлять представление без запроса представления вручную.
3. CBO: Оптимизатор CBO (оптимизатор на основе затрат) использует структуру Cascades, использует различную статистическую информацию для улучшения оценки затрат и дополняет правила логического преобразования (правило преобразования) и физической реализации (правило реализации) и может выполнять планы с десятками тысячи уровней. В пространстве поиска выберите оптимальный план выполнения с наименьшими затратами.
4. Адаптивная оптимизация с низкой мощностью: StarRocks может адаптивно создавать глобальный словарь для столбцов строкового типа с низкой мощностью на основе распределения данных и использовать тип Int для хранения и запросов, что уменьшает накладные расходы памяти и способствует выполнению инструкций SIMD. ускоряется. Соответственно, в Clickhouse тоже есть оптимизация LowCardinality, но ее нужно объявлять при создании таблицы, что усложняет ее использование.

Чрезвычайно быстрая ассоциация нескольких столов:

В сценариях анализа данных в реальном времени недостаточно удовлетворить чрезвычайно быстрый запрос одной таблицы.В настоящее время, чтобы ускорить запрос, в отрасли принято преобразовывать несколько таблиц в одну большую широкую таблицу. таблицы работают быстро, проблемы, которые они приносят, следующие: Это чрезвычайно негибко. Уровень обработки данных в реальном времени использует flink для объединения нескольких таблиц в одну таблицу и записи ее в большую таблицу. Когда бизнес-сторона хочет изменить или добавить измерения анализа , цикл разработки данных часто слишком длинный.После завершения обработки данных обнаруживается, что анализ был пропущен.Лучший шанс. Поэтому необходима более гибкая модель данных.Идеальный метод — вернуть модель большой широкой таблицы к модели звезды или модели снежинки. В этом сценарии ключевым моментом становится производительность механизма запросов для запросов корреляции данных из нескольких таблиц. Раньше в Clickhouse в основном использовались большие и широкие таблицы. В случае совместных запросов с несколькими таблицами время ответа на запрос не может быть гарантировано. , и есть даже большая вероятность ООМ. SR очень хорошо решает эту проблему: производительность объединения больших таблиц повышается более чем в 3–5 раз, что делает его мощным инструментом для анализа звездных моделей. CBO (оптимизатор на основе затрат) является ключом к максимальной производительности объединения нескольких таблиц. В то же время StarRocks поддерживает несколько методов соединения, таких как Broadcost Join, Shuffle Join, Bucket Shuffle Join, Colocated Join, Replicationd Join и т. д. CBO может разумно выбирать порядок и метод соединения.

2.2 Преобразование федеративного запроса StarRocks

Трудно достичь действительно унифицированного хранилища на уровне хранения из-за требований, сценариев, истории и других причин.В прошлом разработка службы данных из-за неунифицированного уровня хранения и различного синтаксиса запросов к базе данных, разработка была в основном дымоходом. Мы разработали Индикаторы сложно повторно использовать, а также сложно управлять большим количеством разработанных индикаторов. Федеративный запрос может очень хорошо решить эту проблему. Он использует унифицированный механизм запросов для защиты собственного DSL различных механизмов Olap, что значительно повышает эффективность разработки и затраты на обучение. В то же время он может использовать ОДИН SQL для интеграции индикаторов из разных данных. источников для формирования новых показателей, тем самым улучшая возможность повторного использования показателей. Функция расширения внешнего вида StarRocks обеспечивает основу для реализации федеративных запросов, но у нас есть некоторые собственные бизнес-требования в отношении деталей.

StarRocks поддерживает различные поверхности для федеративных запросов, такие как ES, Mysql, hive, озеро данных и т. д., и уже имеет хорошую основу для федеративных запросов. Однако в реальных требованиях бизнес-сценария некоторым запросам агрегирования необходимо извлекать данные из внешних источников данных, а затем агрегировать их, а производительность агрегирования самих этих источников данных также является хорошей, что фактически увеличивает время запроса. Наша идея состоит в том, чтобы позволить этим механизмам, которые хорошо умеют агрегировать, выполнять агрегацию самостоятельно и передавать операции агрегации внешним механизмам. В настоящее время этому условию оптимизации соответствуют движки: Mysql, ElasticSearch и Clickhouse. В то же время, чтобы обеспечить совместимость с большим количеством источников данных, мы также добавили источник данных JSF (внутренняя служба RPC Jingdong)/HTTP. Вот краткое введение в эти две части:

1.Mysql, агрегатная функция push ElasticSearch.

Текущее решение StarRocks для агрегирования внешних источников данных заключается в извлечении всего объема данных после передачи предиката. Хотя часть данных была отфильтрована после передачи предиката, извлечение данных в StarRocks и последующее агрегирование является тяжелой операцией, приводящей к длительное время агрегации.идеально. Наша идея состоит в том, чтобы сократить операцию агрегации и позволить внешнему обработчику таблиц выполнять агрегацию самостоятельно, что сэкономит время получения данных и сделает локализованную агрегацию более эффективной. Оптимизация агрегирования может повысить производительность более чем в 10 раз в некоторых сценариях.

 

Рис. 3. Диаграмма оптимизации физического плана

На уровне плана физического выполнения мы снова его оптимизировали. При столкновении с агрегацией ES, Mysql и clickhouse мы оптимизируем план выполнения ScanNode+AGGNode в QueryNode. QueryNode — это специальный ScanNode, который отличается от обычного ScanNode. QueryNode напрямую отправит запрос на агрегацию соответствующему внешнему механизму вместо сканирования данных и выполнения агрегации локально. Среди них, для EsQueryNode, мы сгенерируем оператор DSL запроса ES на стороне FE и напрямую отправим его на сторону BE для запроса. В то же время мы реализовали два QueryNodes, EsQueryNode и MysqlQueryNode, на стороне BE.

2. Добавьте источник данных JSF (внутренняя служба RPC Jingdong)/HTTP.

Службы данных могут включать интеграцию внешних служб данных и повторное использование ранее разработанных индикаторов. Наша идея состоит в том, чтобы абстрагировать JSF (внутренняя служба RPC JD.com)/HTTP во внешнюю таблицу StarRocks. Пользователи могут запрашивать базу данных через SQL. Доступ к службе данных в таким же образом, чтобы вы могли не только повторно использовать старые индикаторы, но и комбинировать данные из других источников данных для создания новых составных индикаторов. Мы добавляем JSF и HTTP ScanNodes как на стороне FE, так и на стороне BE.

2.3 Практика в сценариях реального времени

Подавляющее большинство данных JD Logistics в режиме реального времени относится к сценариям обновления, а данные накладных будут меняться в соответствии с изменениями статуса бизнеса.Вот три наших решения для обновления в реальном времени, находящихся в производстве:

Решение 1. Решение для обновления в реальном времени на основе ES

Принцип следующий:

1. Сначала получите документ внутри компании
2. Обновить старые документы в памяти
3. Отметить старые документы как удаленные
4. Создать новый документ

преимущество:

• Поддерживает обновление данных в реальном времени и может обеспечить частичное обновление.

недостаток:

• Производительность агрегации ES низкая, а время запроса будет очень большим, если появится несколько измерений агрегации.
• Синтаксис DSL ES увеличивает объем работ по разработке.Хотя ES может поддерживать простой SQL, он не может удовлетворить сложные бизнес-сценарии.
• Трудно очистить старые данные.Когда сжатие запускается для физического удаления помеченных документов, будет запущено большое количество операций ввода-вывода.Если объем записи в это время велик, это серьезно повлияет на производительность чтения и записи.

Решение 2. Решение, работающее в квазиреальном времени, на основе кликхауса.

Принцип следующий:

1. Реализовано с помощью ReplacingMergeTree.
2. Распределите данные с одним и тем же первичным ключом в один и тот же раздел данных одного и того же узла данных.
3. Выполняйте объединение при чтении при запросе, объединяйте несколько версий данных для чтения.

преимущество:

• Написание Clickhouse — это, по сути, написание добавления, поэтому производительность письма высокая.

недостаток:

• Из-за слияния версий при чтении производительность запросов и параллелизма снижается.
• Производительность соединения Clickhouse низкая и может вызвать проблемы с островом данных.

Решение 3. Решение для обновления в реальном времени на основе модели первичного ключа StarRocks.

Принцип: когда StarRocks получает операцию обновления строки, она находит местоположение записи по индексу первичного ключа, помечает ее для удаления, а затем вставляет новую запись. Это эквивалентно переписыванию «Обновить» как «Удалить+Вставить». Когда StarRocks получает операцию удаления определенной строки, он находит местоположение записи по индексу первичного ключа и помечает ее для удаления. Таким образом, во время запросов не затрагивается перемещение предикатов и использование индексов, что обеспечивает эффективное выполнение запросов. Скорость запроса в 5-10 раз выше, чем у метода Merge on read.

преимущество:

• Только уникальная версия данных, высокая производительность запросов, обновления в реальном времени.
• Хотя команда «Delete+Insert» немного теряет производительность при записи, в целом она по-прежнему очень эффективна.
• Протокол Mysql, прост в использовании

недостаток:

• Текущая версия имеет некоторые ограничения на удаление данных и не может быть удалена с помощью оператора удаления. Сообщество добавит эту функцию в новую версию.

Вообще говоря, существуют следующие решения для сценариев обновления в реальном времени:

1. Слияние при прочтении: модели агрегации и уникальные модели StarRocks, а также модели ReplacingMergeTree и AggregatingMergeTree от Clickhouse используют это решение. Особенностью этого решения является то, что метод добавления имеет хорошую производительность записи, но необходимость объединять несколько версий данных во время запроса приводит к низкой производительности запроса. Он подходит для сценариев анализа в реальном времени, которые не требуют высокой производительности запросов к данным.
2. Копирование при записи: в настоящее время некоторые системы озер данных, такие как Hudi и Iceberg, имеют решения копирования при записи.Принцип этого решения заключается в том, что при обновлении данных новые и старые данные будут объединены, и новый файл будет перезаписан в заменить старый файл.Нет необходимости выполнять операции слияния при запросе, поэтому производительность запроса очень хорошая. Проблема в том, что операции записи и объединения данных являются трудоемкими, поэтому это решение не подходит для сценариев записи с высокой производительностью в реальном времени.
3. Удаление и вставка. Эта схема представляет собой схему добавления, которая находит обновляемую строку по индексу первичного ключа в памяти, помечает ее для удаления, а затем вставляет ее. При этом жертвуя частью производительности записи, запрос улучшается в несколько раз по сравнению с слиянием при чтении, а также повышается производительность параллелизма.

Обновления в режиме реального времени всегда были технической трудностью в области Olap.Предыдущим решениям было трудно одновременно иметь такие характеристики, как хорошая производительность записи, хорошая производительность чтения и простота использования. Методы удаления и вставки StarRocks на данный момент ближе к идеальному решению. Они имеют отличную производительность при чтении и записи. Они поддерживают протокол Mysql, просты и удобны в использовании. В то же время офлайн-анализ Udata также выполняется с использованием StarRocks, что позволяет нам достичь цели интеграции офлайн-анализа в реальном времени.

3 дальнейших направления

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

Рис. 4. Схема архитектуры последующего планирования

• Единое хранилище данных в реальном времени: в системе по-прежнему существует несколько решений для хранения данных в реальном времени, а затраты на эксплуатацию и обслуживание по-прежнему довольно высоки. В будущем мы постепенно заменим ES и Clickhouse на StarRocks, чтобы добиться унифицированного хранилища данных в реальном времени. слой реального времени. Мы также с нетерпением ждем более поздней функции StarRocks, в которой модель первичного ключа будет поддерживать удаление данных с помощью операторов удаления. Эта функция может упростить текущую проблему очистки данных.
• Поддержка большего количества источников данных. В будущем мы будем поддерживать больше источников данных, таких как Redis, Hbase и другие базы данных Nosql типа kv, чтобы расширить возможности запросов SR.
• Федеративный запрос между кластерами StarRocks: в реальном производстве сложно использовать только один большой кластер, особенно при большом количестве операций записи в реальном времени. Более безопасный подход — разделить несколько небольших кластеров. Когда в одном кластере возникает проблема. не повлияет на другие предприятия. Однако проблема в том, что кластеры могут снова стать островами данных.Даже если StarRocks замаскирован под Mysql для создания таблицы, все равно необходимы инструменты для синхронизации структуры таблицы и другой информации каждого кластера.Управление требует много времени и усилий.Мы Сообщество обсуждает, как реализовать функции федерации между кластерами.

Автор: JD Logistics Чжан Донг Хэ Сиюань

Источник: Сообщество разработчиков JD Cloud Ziyuanqishuo Tech. При перепечатке указывайте источник.

Официально выпущен Spring Boot 3.2.0. Самый серьезный сбой в работе службы в истории Didi. Виновником является базовое программное обеспечение или «снижение затрат и увеличение смеха»? Программисты вмешались в балансы ETC и похитили более 2,6 миллионов юаней в год. Сотрудники Google раскритиковали большого босса после ухода с работы. Они активно участвовали в проекте Flutter и разработали стандарты, связанные с HTML. Microsoft Copilot Web AI будет официально запущен 1 декабря, поддержка китайского PHP 8.3 GA Firefox в 2023 году. Rust Web framework Rocket стал быстрее и выпустил версию v0.5: поддерживает асинхронный режим, SSE, WebSockets и т. д. Официально выпущен настольный процессор Loongson 3A6000, свет отечественного производства! Broadcom объявляет об успешном приобретении VMware

{{o.name}}

{{м.имя}}