Создание платформы базы данных Meituantu и деловая практика

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

1. Введение

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

• Графический майнинг:Meituan имеет около 10 графиков знаний в предметной области, включая графики продуктов питания, графики товаров, графики путешествий и графики пользовательских панорам, а объем данных составляет около 100 миллиардов. В процессе итерации и интеллектуального анализа данных необходим компонент для унифицированного управления этими графическими данными.
• Контроль рисков безопасности:Бизнес-отделы нуждаются в контроле рисков контента и надеются выявлять ложные отзывы с помощью многошаговых запросов у продавцов, пользователей и обзоров, проверять контроль финансовых рисков во время оплаты и запрашивать точки риска в режиме реального времени с несколькими переходами.
• Анализ ссылок:Включая анализ кода, управление службами и управление происхождением данных. Например, существует множество заданий ETL на платформе данных компании, и между заданиями и заданиями существуют сильные и слабые зависимости. Эти сильные и слабые зависимости образуют граф, а оптимизация заданий ETL или при устранении неполадок необходимо выполнять анализ запросов в реальном времени на этом графике.
• Организация:Управление организационной структурой компании, управление сплошной цепочкой отчетности, пунктирной цепочкой отчетности, управление виртуальными организациями и управление торговыми сетями. Например, чтобы узнать, какие магазины есть у продавца в разных регионах, можно выполнить многоуровневый поиск взаимосвязей или обратный поиск взаимосвязей.

В общем, Meituan нужен компонент для управления сотнями миллиардов графических данных и решения проблемы хранения графических данных и запросов с несколькими переходами. Эффективное хранение и запрос массивных графовых данных является основной темой исследования графовой базы данных, а реализация проектов в крупномасштабных распределенных сценариях — это проблема, с которой мы сталкиваемся. Традиционные реляционные базы данных и базы данных NoSQL могут использоваться для хранения данных графов, но они не могут очень хорошо обрабатывать высокочастотные операции запросов с несколькими переходами к графам.

Neo4j сравнил производительность запросов традиционной реляционной базы данных MySQL и графовой базы данных Neo4j в социальной среде (см. рисунок 1) [1].В социальной сети, содержащей 1 миллион человек и у каждого человека около 50 друзей, найдите самый большой запрос производительность Друзья друзей с глубиной 5, экспериментальные результаты показывают, что база данных графа имеет очевидные преимущества в запросе с несколькими переходами (см. рис. 2). Однако очень сложно выбрать или самостоятельно разработать графовую базу данных с высокой пропускной способностью, малой задержкой запросов, способную хранить массивные данные и простую в использовании. Далее будут представлены некоторые работы Meituan по выбору базы данных графов и построению платформы.

2 Выбор графической базы данных

При выборе графовой базы данных мы в основном учитывали следующие пять моментов: (А) проект с открытым исходным кодом, и платная графовая база данных пока не рассматривается; (Б) дизайн распределенной архитектуры имеет хорошую масштабируемость; ( C) миллисекундный уровень (D) поддерживает сотни миллиардов точечных и краевых хранилищ; (E) имеет возможность импортировать данные из хранилищ данных пакетами.

Анализируя 30 лучших графовых баз данных на DB-Engine[2], за исключением проектов с закрытым исходным кодом, мы делим оставшиеся графовые базы данных на три категории:

• Первая категория: Neo4j[3], ArangoDB[4], Virtuoso[5], TigerGraph[6], RedisGraph[7].Этот тип базы данных графа доступен только как открытый исходный код в автономной версии, с отличной производительностью, но он не может справиться с ростом масштаба данных в распределенных сценариях, то есть не соответствует требованиям выбора (B) и (Д).
• Вторая категория: JanusGraph[8], HugeGraph[9].Этот тип графовой базы данных добавляет общий уровень семантической интерпретации графа поверх существующей системы хранения.Семантический уровень графа обеспечивает возможность обхода графа, но ограничен уровнем хранения или архитектурой и не поддерживает полное проталкивание вычислений и множественные вычисления. -hop traversal Производительность низкая, и трудно удовлетворить требованиям малой задержки в OLTP-сценариях, то есть не удовлетворяет требованиям выбора (C).
• Третья категория: DGraph[10], NebulaGraph[11].В соответствии с характеристиками данных графа, этот тип базы данных графа имеет новый дизайн модели хранения данных, распределение точек и механизм выполнения, а также глубоко оптимизирован многошаговый обход графа, который в основном соответствует нашему выбору. требования.

DGraph — это продукт базы данных графов, выпущенный в 2016 году после того, как бывший сотрудник Google Маниш Рай Джейн ушел в бизнес. Базовая модель данных — RDF[12], написанная на языке Go, механизм хранения основан на преобразовании BadgerDB[13] и использует RAFT для обеспечения чтения данных. Запишите строгую согласованность.

NebulaGraph — это графовая база данных, запущенная в 2019 году после того, как бывший сотрудник Facebook Е Сяомэн ушел, чтобы начать свой бизнес. Базовая модель данных — это граф свойств, написанный на языке C++. Механизм хранения основан на RocksDB[14]. Strong. последовательность.

Основатели этих двух проектов в течение многих лет глубоко вовлечены в область графовых баз данных для интернет-компаний и хорошо понимают болевые точки графовых баз данных, а общий дизайн архитектуры также имеет много общего. При окончательном выборе графовой базы данных мы провели углубленную оценку производительности NebulaGraph, DGraph и HugeGraph на основе набора данных LDBC-SNB [15].Подробности теста см. в статье:Популярная база данных с распределенным графом с открытым исходным кодом, судя по результатам испытаний, NebulaGraph превосходит конкурирующие продукты в импорте данных, записи в реальном времени и производительности многоэтапных запросов. Кроме того, сообщество NebulaGraph является активным, и на вопросы отвечают быстро, поэтому команда, наконец, решила построить платформу графовой базы данных на основе NebulaGraph.

3 Архитектура NebulaGraph

Полный кластер NebulaGraph содержит три типа служб, а именно службу запросов, службу хранения и метаслужбу. У каждого типа службы есть собственный исполняемый двоичный файл, который можно развернуть на одном узле или на разных узлах. Ниже приведены несколько основных моментов архитектуры NebulaGraph (см. рис. 3) [16][17].

• Мета-сервис:Справа на архитектурной диаграмме показан кластер метасервиса, использующий архитектуру ведущий/ведомый. Лидер выбирается всеми узлами Метасервиса в кластере, а затем предоставляет услуги внешнему миру; Последователи находятся в режиме ожидания и копируют обновленные данные с Лидера. Как только узел лидера выйдет из строя, один из последователей будет избран новым лидером. Мета-служба отвечает не только за хранение и предоставление метаинформации графических данных, такой как схема, информация о фрагментации данных и т. д., она также предоставляет механизм диспетчера заданий для управления задачами, отнимающими много времени, и отвечает за направление переноса данных. , изменения лидера, уплотнение данных, реконструкция индекса и другие операции и техническое обслуживание.
• Разделение вычислительных ресурсов хранения:В левой части метасервиса на архитектурной диаграмме это основной сервис NebulaGraph. NebulaGraph использует архитектуру, которая разделяет хранение и вычисления. Над пунктирной линией — вычисления, а под — хранилище. Разделение хранения и вычислений имеет много преимуществ, самое прямое из которых заключается в том, что вычислительный уровень и уровень хранения могут эластично расширяться и сжиматься в соответствии с их собственными условиями. Разделение хранения и вычислений также дает еще одно преимущество: оно обеспечивает горизонтальное масштабирование. Кроме того, разделение хранилища и вычислений позволяет службе хранилища предоставлять услуги для нескольких типов вычислительных уровней или вычислительных механизмов. Текущая служба запросов является высокоприоритетным вычислительным уровнем OLTP, а различные итеративные вычислительные платформы OLAP станут еще одним вычислительным уровнем.
• Уровень вычислений без сохранения состояния:На каждом вычислительном узле работает механизм обработки запросов без сохранения состояния, и узлы не имеют никаких коммуникационных отношений друг с другом. Вычислительные узлы только считывают метаинформацию из службы метаданных и взаимодействуют со службой хранилища. Такой дизайн упрощает управление кластерами вычислительного уровня или их развертывание в облаке с помощью K8s. Каждый механизм расчета запросов может получать запрос клиента, анализировать оператор запроса, генерировать абстрактное синтаксическое дерево (AST) и передавать AST планировщику выполнения и оптимизатору и, наконец, передавать его исполнителю для выполнения.
• Уровень распределенного хранилища без общего доступа:Служба хранилища использует распределенную архитектуру Shared-nothing. Существует три уровня. Нижний уровень — Store Engine, который представляет собой автономную версию Local Store Engine, обеспечивающую операции получения/помещения/сканирования/удаления для локальных данных. Этот уровень определяет интерфейс работы с данными, пользователи могут настраивать и разрабатывать соответствующий плагин локального хранилища в соответствии со своими потребностями. В настоящее время NebulaGraph предоставляет Store Engine на основе реализации RocksDB. Над механизмом локального хранилища находится уровень консенсуса, который реализует Multi Group Raft, и каждый раздел соответствует набору групп Raft. Выше уровня консенсуса находятся интерфейсы хранилища, которые определяют серию API-интерфейсов, связанных с графами. Эти запросы API преобразуются в набор операций KV для соответствующего раздела на этом уровне. Именно наличие этого слоя делает сервис хранения настоящим хранилищем графов. В противном случае Storage Service — это просто хранилище KV. NebulaGraph предлагает KV не только как услугу. Основная причина в том, что в процессе запроса графа задействовано много вычислений. Эти вычисления часто требуют использования схем графа, а слой KV не имеет концепции схем данных. , поэтому дизайн упрощает реализацию вычислений.Pushdown является основной причиной превосходной производительности запросов NebulaGraph.

NebulaGraph реализован на основе C++, архитектурный дизайн поддерживает хранение сотен миллиардов вершин и триллионов ребер и обеспечивает задержку запросов на уровне миллисекунд. Мы проверили работу NebulaGraph, загрузив 1 миллиард данных графика продуктов питания в кластер, созданный тремя физическими машинами 48U192G.

• Задержка запроса TP99 с одним переходом находится в пределах 5 мс, задержка запроса TP99 с двумя переходами — в пределах 20 мс, а общая задержка запроса TP99 с несколькими переходами — в пределах 100 мс.
• Скорость онлайн-записи кластера составляет около 200 000 записей/с.
• Он поддерживает автономное создание базовых SST-файлов RocksDB с помощью задач Spark и напрямую загружает файлы данных в кластер, что аналогично возможностям HBase BulkLoad.
• Предоставляет SQL-подобный язык запросов.Для новых бизнес-требований вам нужно всего лишь создать оператор NebulaGraph SQL, который прост для понимания и может удовлетворить различные сложные требования запросов.
• Предоставляет совместный индекс и индекс GEO, который может запрашивать объекты, отношения через атрибуты объектов или атрибуты отношений или запрашивать объекты в пределах N метров вблизи определенной широты и долготы.
• Несколько пространств (концепция аналогична базе данных MySQL) могут быть созданы в кластере NebulaGraph, а данные в разных пространствах физически изолированы.

4 Создание платформы графической базы данных

Чтобы управлять графовыми данными унифицированным способом и снизить нагрузку на студентов инженерных специальностей в кластерах графовых баз данных, мы создали универсальную платформу самообслуживания графовой базы данных на основе распределенной графовой базы данных с открытым исходным кодом NebulaGraph (см. Рисунок 4) Платформа включает в себя следующий 4-й этаж:

• Уровень приложения данных.Бизнес-сторона может внедрить граф SDK в бизнес-сервис, а также добавлять, удалять, изменять и проверять данные графа в режиме реального времени.
• Уровень хранения данных.Поддерживаются два типа развертывания кластера графовой базы данных.
  • Первый метод развертывания — это схема CP, а именно непротиворечивость и устойчивость к разделам. Развертывание с одним кластером, количество машин в кластере больше или равно количеству реплик, а количество реплик больше или равно 3 . Пока более половины машин в кластере выживает, весь кластер может нормально предоставлять услуги внешнему миру. Схема CP обеспечивает строгую согласованность чтения и записи данных, но доступность кластера при этом методе развертывания невысока.
  • Второй метод развертывания — это схема AP, а именно доступность и устойчивость к разделам. Разверните несколько кластеров базы данных графа в приложении, каждый кластер имеет 1 копию данных, а несколько кластеров используются для взаимного резервного копирования. Преимущество этого метода развертывания в том, что внешняя доступность всего приложения высока, но непротиворечивость чтения и записи данных плохая.
• Уровень производства данных.Существует два основных источника данных графа.Во-первых, бизнес-сторона преобразует данные в хранилище данных в таблицы точек и ребер Hive через ETL Job, а затем импортирует их в базу данных графа в автономном режиме;второй-это сгенерированные данные в режиме реального времени в бизнес-линии или через данные, генерируемые потоковой обработкой, такой как Spark/Flink, вызов онлайн-интерфейса пакетной записи, чтобы залить их в графовую базу данных в режиме реального времени.
• Платформа поддержки.Он предоставляет такие функции, как управление схемой, управление разрешениями, проверка качества данных, добавление, удаление и изменение данных, расширение и сжатие кластера, графическое изображение, экспорт графических данных, мониторинг сигналов тревоги, визуализация графа и управление пакетами кластера.

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

4.1 Конструкция модуля высокой доступности

Во-первых, представлена ​​конструкция многокластерного модуля высокой доступности с одним приложением (схема AP). Для чего разработана программа AP? Потому что показателем того, что бизнес-сторона, обращающаяся к платформе графовой базы данных, больше беспокоит доступность кластера. Онлайн-сервисы предъявляют очень высокие требования к доступности кластера, самое основное требование — доступная производительность кластера должна достигать 4 9s, то есть время недоступности кластера в году должно быть меньше одного часа. Для онлайн-сервисов доступность сервисов или кластеров является источником жизненной силы всего бизнеса. Если это не может быть гарантировано, даже если возможности, предоставляемые кластером, более богаты, бизнес-сторона не будет рассматривать их использование. Доступность является основой для выбор бизнеса.

Кроме того, компании требуется, чтобы промежуточное ПО обладало возможностями межрегионального аварийного восстановления, то есть имело возможность развертывать несколько кластеров в нескольких регионах. Мы проанализировали бизнес-потребности стороны доступа к платформе, и около 80% сценариев — это полный импорт данных T+1 и доступ только для онлайн-чтения. В этом сценарии требование строгой согласованности данных графа при чтении и записи невелико, поэтому мы разработали схему развертывания с несколькими кластерами для одного приложения.

Способ развертывания решения AP показан на Рисунке 5. Деловая сторона создает приложение на платформе графовой базы данных и развертывает 4 кластера, в том числе 2 в Пекине и 2 в Шанхае. Обычно эти 4 кластера одновременно предоставляют внешние службы. . Если пекинский кластер 1 сейчас не работает, то пекинский кластер 2 может предоставлять услуги. Если, к сожалению, пекинский кластер не работает или внешняя сеть на пекинской стороне недоступна, то шанхайский кластер также может предоставлять услуги. В этом методе развертывания платформа пытается каким-то образом обеспечить доступность всего приложения. Затем попробуйте развернуть машины в одном и том же машинном зале внутри каждого кластера, потому что в кластере графовой базы данных много RPC, и при частых вызовах между машинными залами или регионами внешняя производительность всего кластера будет относительно низкой.

Модуль высокой доступности в основном состоит из следующих четырех частей, как показано на рис. 6 выше:

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

Вторая часть — это платформа базы данных графа, которая в основном управляет кластером и синхронизирует состояние кластера базы данных графа с центром конфигурации.

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

Четвертая часть — центр конфигурации, аналог ZooKeeper, в котором хранится текущее состояние кластера.

4.2 Проектирование модуля импорта данных на десятки миллиардов данных в час

Второй модуль — модуль импорта данных десятков миллиардов в час.Платформа будет импортировать данные в полном объеме с конца 2019 г. по начало 2020 г., вызывая интерфейс пакетного импорта данных, предоставляемый NebulaGraph.Скорость записи данных этого метода примерно ежечасно. На уровне 1 миллиарда требуется около 10 часов для импорта десятков миллиардов данных, что является большим временем. Кроме того, в процессе импорта данных со скоростью сотни тысяч в секунду ресурсы процессора и ввода-вывода машины будут заняты на длительное время, что, с одной стороны, приведет к потерям машины. с другой стороны, производительность чтения, обеспечиваемая кластером в процессе импорта данных, изменится.

Чтобы решить две вышеупомянутые проблемы, платформа была оптимизирована следующим образом: непосредственно сгенерируйте базовый файл SST File базы данных графа в кластере Spark, а затем используйте функцию массовой загрузки RocksDB для прямой загрузки файла в базу данных графа. .

Основной процесс импорта данных можно посмотреть на рисунке 7. После того, как пользователь выполнит операцию импорта данных, платформа графовой базы данных отправит задачу Spark в кластер Spark компании.В задаче Spark соответствующие точки, ребра и индексы точек в будет создана графическая база данных.Соответствующие файлы SST индексируются и загружаются в облачное хранилище Meituan S3. После создания файлов платформа графовой базы данных уведомит несколько кластеров в приложении о загрузке этих файлов хранилища, затем завершит операции загрузки и сжатия и, наконец, завершит переключение версий данных.

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

4.3 Конструкция модуля синхронизации данных с несколькими кластерами записи в режиме реального времени

Третий модуль — это модуль синхронизации многокластерных данных записи в режиме реального времени.Около 15% сценариев спроса платформы — это запись вновь сгенерированных бизнес-данных в кластер в режиме реального времени при чтении данных в режиме реального времени, а чтение и запись данных является сильным.Требования к согласованности не высоки. Другими словами, данные, записанные бизнес-стороной в графовую базу данных, не нужно считывать немедленно. Для приведенного выше сценария, когда бизнес-сторона использует схему развертывания с одним приложением и несколькими кластерами, данные в нескольких кластерах должны обеспечивать конечную согласованность. В ответ на это требование мы сделали следующую конструкцию.

Первая часть — введение компонента Kafka.Когда бизнес-сторона записывает базу данных графа через SDK в службе, SDK не записывает базу данных графа напрямую, а записывает операцию записи в очередь Kafka, а затем в несколько кластеров под приложение потребляет эту очередь Kafka асинхронно.

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

• SDK анализирует написанный пользователем оператор операции и разбирает пакетные операции точечной операции в одну точечную операцию, то есть перезаписывает оператор записи один раз.
• Когда агент использует Kafka, он гарантирует, что каждый узел и связанные с ним исходящие операции последовательно выполняются в одном потоке (см. рис. 8), что гарантирует согласованность конечного результата каждого кластера после выполнения операции записи.
• Масштабирование параллелизма: отрегулируйте скорость потребления операций в Kafka, изменив количество сегментов Kafka и количество потоков, потребляющих Kafka в агенте. Если графовая база данных будет поддерживать транзакции в будущем, приведенную выше конфигурацию необходимо скорректировать для односегментного и однопоточного потребления, а также необходимо оптимизировать структуру.

Третья часть заключается в том, что в процессе записи данных в режиме реального времени платформа может синхронно генерировать полную версию данных и выполнять плавное переключение (см. рис. 9), чтобы гарантировать, что данные не будут тяжелыми, просочившимися или задержанными.

4.4 Дизайн модуля визуализации графиков

Четвертый модуль — это модуль визуализации графа (см. рис. 10), который в основном используется для решения задачи исследования подграфа. Когда пользователи просматривают данные графа с помощью компонентов визуализации на платформе базы данных графа, они могут сделать все возможное, чтобы избежать всплывающих окон из-за слишком большого количества узлов за счет соответствующего дизайна взаимодействия. В основном включают следующие функции:

• Поиск вершин по ID или индексу.
• Карты, которые могут просматривать вершины и ребра (атрибуты и значения атрибутов точек и ребер отображаются в карточке), и вы можете выбирать вершины путем одиночного выбора, множественного выбора, выбора рамки и по типу.
• Исследование графа: когда пользователь нажимает на вершину, система отображает информацию о соседе с одним переходом, включая исходящие ребра этой вершины? Со сколькими точками оно может быть связано через это ребро? Что можно сказать о входящем ребре этой вершины? Благодаря отображению этой одношаговой информации, когда пользователи изучают подграфы на платформе, они могут быстро узнавать информацию об окружающих соседях и быстрее проводить исследование подграфов. Во время исследования платформа также поддерживает фильтрацию ребер по атрибутам.
• Возможность редактирования графика позволяет пользователям платформы добавлять, удалять или изменять данные точек и ребер, не зная синтаксиса NebulaGraph, и временно вмешиваться в онлайн-данные.

5 деловых практик

5.1 Ассистент

Данные проекта представляют собой график знаний о ресторанном бизнесе и развлечениях, построенный на основе данных продавцов Meituan и отзывов пользователей, охватывающих продукты питания, отели, туризм и другие области, включая 13 типов объектов и 22 типа отношений. В настоящее время количество точек и ребер составляет около 10 миллиардов, а данные T+1 полностью обновлены, что в основном используется для решения задач KBQA (полное название: ответ на вопрос, основанный на знаниях) в поиске или интеллектуальных помощниках. Основной поток обработки заключается в построении SQL-оператора NebulaGraph после идентификации взаимосвязей и сущностей с помощью алгоритма НЛП, а затем в получении данных из базы данных графа.

Типичные сценарии приложений включают торговые центры для поиска магазинов.Например, пользователь хочет знать, есть ли Haidilao в городе Ванцзин Синьхуэй, и система может быстро узнать результаты и сообщить пользователю; другой сценарий — найти магазины по тегам, и пользователь хочет узнать окрестности Wangjing SOHO.Если есть ресторан, подходящий для пар на сегодняшний день, или если вы можете добавить еще несколько тегов сцены, система может помочь это узнать.

5.2 Отзыв поиска

Данные этого проекта представляют собой карту знаний о медицинской красоте, построенную на основе бизнес-информации о медицинской красоте, включающую типы сущностей 9 и типы отношений 13. Количество точек и ребер находится на уровне одного миллиона. Она также полностью обновляется T + 1. Он в основном используется для отзыва в реальном времени в нижней части Dasou. Возвращает информацию о продавце, продукте или враче, связанную с запросом, и решает проблему нескольких результатов или отсутствия результатов для условий поиска медицинской красоты. Например, если пользователь ищет симптомы «пивного живота» или такие бренды, как «Run Baiyan», система может напомнить соответствующие магазины медицинской косметики.

5.3 Причины рекомендаций по графикам

Данные проекта поступают из портретной информации пользователя, информации о характеристиках продавца и поведения пользователя при сборе/покупке в течение полугода.Уровень данных составляет 1 миллиард, и T+1 полностью обновляется. Теперь список рекомендаций продавцов по умолчанию в приложениях Meituan и Dianping создается с помощью модели глубокого обучения, но модель не дает оснований для создания этого списка, которому не хватает интерпретируемости.

На графике, естественно, есть несколько путей подключения между пользователями и продавцами.Проект рассматривает возможность выбора подходящего пути для создания причин рекомендации и отображает причины рекомендации магазина пользователям в интерфейсе приложения. Проект генерирует причины рекомендации на основе алгоритма совместной фильтрации пользователя, находит несколько путей в нескольких комбинированных измерениях, таких как родной город, уровень потребления, предпочтительная категория и предпочтительная кухня, а затем оценивает эти пути и выбирает более высокий балл. генерировать рекомендательные причины по определенному образцу. С помощью вышеперечисленных методов можно получить такие причины, как «соотечественники из Шаньдуна, которым нравится пекинская кухня в Пекине, говорят, что этот ресторан очень хороший», или «соотечественники из Гуанчжоу любят их настоящую пекинскую жареную лапшу с соусом».

5.4 Анализ зависимостей кода

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

Типичным сценарием приложения является точное тестирование: когда разработчики завершают выполнение требований и отправляют PR в репозиторий кода компании, изменения могут быть записаны в базу данных графа в режиме реального времени. Таким образом, разработчик может узнать, на какие внешние интерфейсы влияет написанный им код, и просмотреть путь вызова с помощью компонента визуализации графа. Если разработчик изначально хотел изменить поведение интерфейса A и изменил много кода, но он может не знать, что измененный им код также повлияет на внешние интерфейсы B, C и D. В это время вы можете использовать код анализ зависимостей, чтобы сделать проверку, чтобы увеличить полноту теста.

6 Резюме и перспективы

В настоящее время платформа базы данных графов в основном имеет единую функцию самообслуживания для управления графическими данными. Если бизнес-сторона хочет использовать эту возможность базы данных графа, она может создать кластер базы данных графа, создать схему графа, импортировать данные графа, настроить план выполнения для импортированных данных и импортировать SDK, предоставленный платформой, на платформе. , работать и так далее. Сторона платформы в основном отвечает за стабильность каждого кластера базы данных Business Square. В настоящее время на платформе запущено от 30 до 40 предприятий Meituan, что в основном отвечает потребностям различных деловых сторон.

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

7 Информация об авторе

Dengchang, Liang Shuai, Gao Chen, Yang Xin, Zunyuan, Wang Chao и другие — инженеры отдела поиска и НЛП Meituan.

8 Информация о наборе

Если вас интересуют «Хранение графов», «Обучение графам» и «Вычисления графов», отправьте нам свое резюме и электронное письмо:zhaodengchang@meituan.com.

9 ссылок

• [1] Jim Webber, Emil Eifrem, Ian Robinson. Graph Databases(2nd Edition). O'Reilly Media, Inc. 2013: chapter 2.
• [2] Neo4j Database, github.com/neo4j/neo4j.
• [3] ArangoDB, GitHub.com/A Пусть OD B/AR….
• [4] Virtuoso, GitHub.com/открыть ссылку/ви….
• [5] TigerGraph, GitHub.com/тигровый график/….
• [6] RedisGraph, GitHub.com/граф Redis/….
• [7] JanusGraph, GitHub.com/Янус граф/….
• [8] HugeGraph, GitHub.com/Ху Геграф/Также….
• [9] DGraph, GitHub.com/когда граф-IO/….
• [10] NebulaGraph, [GitHub.com/VE soft-Inc/….
• [11] RDF, Woohoo.I 3.org/RDF/] (https….
• [11] RDF, www.w3.org/RDF/).
• [12] BadgerDB, GitHub.com/когда граф-IO/не….
• [13] RocksDB, GitHub.com/Facebook/RO….
• [14] Набор данных LDBC-SNB: набор данных для оценки, предоставленный Комитетом по сравнительному анализу связанных данных, содержащий 2,6 миллиарда вершин и 17,7 миллиарда отношений.
• [15] Архитектура NebulaGraph — с высоты птичьего полета,nebula-graph.IO/posts/ не....
• [16] An Introduction to NebulaGraph's Storage Engine.

Прочтите другие подборки технических статей от технической команды Meituan

внешний интерфейс | алгоритм | задняя часть | данные | Безопасность | Эксплуатация и техническое обслуживание | iOS | Android | контрольная работа

|Ответьте на ключевые слова, такие как [акции 2020 г.], [акции 2019 г.], [акции 2018 г.], [акции 2017 г.] в диалоговом окне строки меню общедоступной учетной записи, и вы сможете просмотреть коллекцию технических статей технической группы Meituan в течение годы.

| Эта статья подготовлена ​​технической командой Meituan, авторские права принадлежат Meituan. Добро пожаловать на перепечатку или использование содержимого этой статьи в некоммерческих целях, таких как обмен и общение, пожалуйста, укажите «Содержимое воспроизводится технической командой Meituan». Эта статья не может быть воспроизведена или использована в коммерческих целях без разрешения. Для любой коммерческой деятельности, пожалуйста, отправьте электронное письмо по адресуtech@meituan.comПодать заявку на авторизацию.