Автор: Free Fish Technology - Qi Wu
Mach — это система выбора и доставки продуктов Xianyu.Большинство продуктов в бизнесе Xianyu — это продукты-сироты, то есть продукты с единичным запасом.Поэтому изменения в продуктах в режиме реального времени должны быть немедленно возвращены в канал выбора и доставки продуктов. Чтобы удовлетворить требования бизнеса, Мах разработал систему.Вначале производительность в реальном времени считалась самой важной технической целью.С расширением данных о работе системы производительность в реальном времени также столкнулась с узкими местами.Эта статья познакомит связанная работа по улучшению производительности Mach в реальном времени в прошлом году.Цель состоит в том, чтобы задержать производительность в реальном времени выбора продукта.Управление в секундах. Если есть студенты, которые не знают Mach, вы можете ознакомиться с соответствующими статьями Mach в общедоступном аккаунте.
ссылка для голосования в прямом эфире
В течение всего выбора продукта и доставки потока данных Mach, показанный ниже, разделен на три части: первый продукт выбирается из доступа к данным, данные просто выбираются продуктами Mach, поток данных в реальном времени всей операционной базы Mach-эффективной . Вторая часть представляет собой продукт, выбранный из правила расчета, правила расчета основного Mach, расчет в реальном времени может гарантировать, что результат выбора продукта Mach синхронизируется с каждым нижестоящим узлом. Третья часть - доставка товаров, товары со стороны пользователя - ближайшее расстояние, обратная связь в режиме реального времени, чтобы дать пользователям лучший опыт.
Оптимизация производительности Mach в реальном времени также начинается с этих трех частей, а процесс оптимизации иглы будет подробно описан ниже.
Оптимизация производительности данных о выборе продуктов в режиме реального времени
Данные таблицы выбора продукта, на которые опирается Mach при выборе продукта, в основном состоят из двух типов данных: один из основных данных о товаре.Основные данные о товаре относятся к информации о товаре, предоставляемой пользователем, в том числе: тип товара, статус товара, цена товара. , описание товара, изображение товара ; Этот тип данных обеспечивает производительность в режиме реального времени благодаря подписке на изменения в базе данных товаров. Другой тип — это статистические и прогнозные данные, полученные из товаров.Этот тип данных обычно рассчитывается в автономном режиме с помощью ODPS (внутренней автономной вычислительной платформы Alibaba).По сравнению с товарными базами время вывода в основном задерживается на дни или часы.Первоначальный доступ план для этого типа данных следующий. Будь то данные о задержке на уровне часа или данные о задержке на уровне дня, они обрабатываются единообразно. Все данные объединяются вместе каждый день и выводятся в автономную таблицу данных, а затем данные подключаются к унифицированному уровню доступа к данным Mach через каналы сообщений BLINK и MetaQ. Преимущество этого решения заключается в том, что все выходные данные в автономном режиме необходимо обрабатывать только один раз для облегчения эксплуатации и обслуживания, а количество данных, возвращаемых для всего процесса один раз в день, можно контролировать. Недостатки также очевидны.Во-первых, время вывода ежедневных агрегированных данных зависит от данных, которые занимают наибольшее время вверх по течению.Если есть задержка данных, это повлияет на времязатратность всего процесса.Во-вторых, это очевидно, что данные, полученные с помощью H+1, должны ждать до момента T+1, и их можно будет использовать, что серьезно влияет на способность к отбору.
Проблема была выяснена, и решение есть решение. Первая проблема, которую необходимо решить, заключается в том, что агрегированные данные зависят от самой длинной восходящей задачи, требующей много времени. Обычное решение состоит в том, чтобы регулярно выводить агрегированные данные. Когда придет время, данные каждого вышестоящего узла были выведены, а затем использованы.Если нет вывода, используются данные последнего вывода, и это решение действительно принимается в исходном решении.Это решение приведет к тому, что некоторые данные будут T + 2, прежде чем он сможет войти в широкую таблицу выбора. Хотя это и не очень хорошее решение, оно простое, и оно также какое-то время использовалось в Mach в качестве переходной схемы. Окончательное решение, использованное Mach для этой проблемы, описано ниже, как показано на следующем рисунке:
Во-первых, классифицируйте данные в соответствии с выходным циклом.Количество данных, произведенных H+1, составляет порядка 10 000, а количество данных, произведенных T+1, составляет порядка 100 миллионов.Для данных H +1, используйте BLINK, чтобы прочитать его напрямую, а затем используйте данные MetaQ. Канал выводится на унифицированный уровень доступа к данным, что гарантирует готовность вывода данных к использованию. Данные T + 1 также напрямую считываются BLINK. Поскольку эта часть данных слишком велика, если QPS выводится напрямую, он достигнет уровня в миллион, а давление на выходе будет слишком большим. Поэтому Mach использует способность агрегации скользящего окна BLINK для размещения идентификатора продукта.Как КЛЮЧ, данные в окне агрегируются, а затем выводятся на уровень унифицированного доступа к данным Mach после агрегации. Чем меньше скользящее окно, тем выше производительность в реальном времени, но больше давление в системе Текущее время скользящего окна Маха составляет 6 часов. Это решение решает проблему доступа в режиме реального времени к товарным алгоритмам и статистическим данным, но при этом трафик всей системы увеличился в 4 раза.Это также компромисс между затратами времени и затратами места, который часто запутывается при проектировании система. В этой оптимизации мы решили использовать Пространство заменено временем, а баланс между ними контролируется контролируемым образом. После оптимизации эффект сокращается с задержки на уровне дня до задержки на уровне часа.
Расчет оптимизации правил выбора в реальном времени
Расчет правила отбора продукта часть состоит из двух частей , выбранных из арифметического оператора при создании правила отбора продукта шириной стола Мах выбор продукта и выбор продукта правила называемога отсутствует исполнительный механизм выводит набор результатов, другие потребности части пересчитать изменение информации о продукте , когда текущий товар , хит выбранные товары правила отбора онлайн продукта называется правило исполнения двигателя. Во-первых представила оптимизированный офф-лайн выбор продукта правила выполнения двигатель первой части, правила эксплуатации избирательных материалов, созданных будет отображаться в SQL для выполнения на Mach широкий продукции Таблица выбора АБР, АБР является полная таблица индексных данных здесь в основном для заменить его на промежутке времени, но существует целый класс задач трудно решить это поле совпадает с текстом, один примером избирательных материалов широкого отображения поля таблица имеет основной товар из таблицы атрибутивных данных, легко видеть , от имени области было выделено в поле расширения дизайна продукта, содержание точки с запятой в виде хранимых кВ, операторы , осуществляющих окончательную карту правил этого поля является SQL - для извлечения данных в более чем десять миллионов в его исполнении можно представить с LIKE на ключевые слова , выбранные продукты Know. Так сделали отображение многозначного для поля класса, который отображается в цифровой кв магазин, хотя программа не является сложным, но когда вы создаете правило решить вычисление количества товаров и товаров анонсировать своевременность проблемы не слишком много говорить, оптимизация товаров уровня рассчитывается из шести минут до 30 секунд, в зависимости от эффекта выглядит следующим образом :
Ниже представлена оптимизация второй части механизма выполнения онлайн-правил. Онлайн-движок реализован в BLINK, а информация об изменении товара используется в качестве источника входных данных. рассчитывается товар, и в результате рассчитывается товар и соответствующий товарный пул. Выход ниже по течению. Первоначальный процесс выглядит следующим образом:
В BLINK ключевые операции MERGE и DIFF Mach в основном завершены.MERGE предназначен для интеграции данных в памяти BLINK с входными данными и получения максимальной временной метки обновления в поле в качестве последних данных для интеграции информации о товаре. Затем запустите интегрированные данные по всем правилам выбора, сравните текущие результаты с предыдущими результатами и отфильтруйте данные с двумя разными результатами в качестве результата.Этот шаг называется DIFF. Преимущество этого заключается в том, что последние данные о товаре хранятся в памяти, IO для чтения уменьшается, а потребление времени уменьшается.В то же время при выводе результата выводится только DIFF, что снижает передачу данных и снова экономит время. Есть у этого решения и очевидные минусы: все данные хранятся в памяти, при возникновении непредвиденного исключения данные в памяти будут потеряны, система ни разу не останавливалась с начала работы до оптимизации, а работа и затраты на техническое обслуживание можно себе представить.В то же время система не может быть обновлена, и возможности BLINK новой версии не могут быть использованы из-за непрерывного простоя. Ниже приведены следующие решения для задачи нон-стоп:
Когда BLINK получает информацию о продукте, он сначала извлекает данные из локальной области. Если это невозможно, он считывает соответствующие данные из базы данных информации о продукте. Когда результат выводится, выводится исходная информация, а выводится информация о продукте и добавляется полный объем попаданий в правила.Информация, как резервное хранилище, удобна для восстановления во время простоя, а для уменьшения места хранения и ввода-вывода данные сжимаются при передаче и хранении. Вся логика окончательного решения не очень сложна.Сложнее то, как плавно перейти от исходного решения к текущему решению, что включает в себя синхронизацию данных, преобразование данных и корректуру данных.Много подводных камней, и это часть не является предметом этой статьи, я не буду вдаваться в подробности. Наконец, версия BLINK была обновлена, чтобы решить проблему отсутствия простоев.После обновления задержка данных была уменьшена с исходных 2 минут до 2 секунд, что сделало весь механизм онлайн-правил более быстрым и плавным.
Оптимизация доставки продукции в режиме реального времени
Доставка товаров — это возможность, которая ближе всего к стороне пользователя.После работы с выбранными продуктами формируется пул продуктов, а затем пул продуктов используется для создания страницы для доставки пользователю.Когда пользователь запрашивает, продукт извлекается из пула продуктов и отображается пользователю Конкретный процесс выглядит следующим образом.
В этом процессе глубокая связь с Mach заключается в части отзыва. В настоящее время Mach поддерживает два метода отзыва: поисковый отзыв и алгоритмический отзыв. При поисковом отзыве изменения товарного пула в реальном времени синхронизируются с поисковой системой для инкрементная итерация, которая, естественно, поддерживает возможность отзыва в реальном времени только для обеспечения стабильности приращений; алгоритм отзыва использует пользовательские атрибуты для отзыва связанных продуктов, а связь между пользователями и продуктами является выходом T + 1, что противоречит в сцене Маха подчеркнут акцент в реальном времени.Для проблемы вызова алгоритма в реальном времени Мах сделал следующее решение:
Сначала мы рассмотрим процесс припоминания: Когда пользователь получает запрос, мы получим две информации ID является ID пользователя и товарное бассейн, первым запросом пользователя с использованием идентификатором пользователя и товарные таблицами персонализированного отзыва, а затем использовать товарный бассейн ID из запроса выбраны пулов продуктов и товарных реляционных таблиц данных универсальности вызова, и, наконец, две частей данных для повторного слияния совместно именуемых здесь как персонализированный вызов, данные РЕГИСТРИРУЙТЕСЬ товарный и товарный бильярдный стол после отзыва, оставив только линии с товаром бассейн ID продуктом упоминаемым здесь , как напоминается в фильтре, если количество элементов в это время , чтобы соответствовать требованиям отзыва возвращается, если не требуется , чтобы вызвать данные замещающего запроса и товарные товары объединять реляционные таблицы данных вспомнить здесь упоминается как запасные отозванный процессом припоминания , а затем через RANK и дополнительную информацию , чтобы поместить данные пользователя. Вышеупомянутая таблиц процесс множественных данных, то таблица выходных данных, как и почему такая конструкция подробно описывается ниже. Впервые представленной BE пользователя логик вывод товаров и реляционных таблиц данных , используемых в личности отзыве, информация , содержащихся в этом разделе данных неудовлетворительных Lai Маэ, просто пользователь в занятых рыбах и других пользовательских предпочтениях Нажмите кнопку Обзор поведения любимых товаров пользователя предсказывал масштаб каждого пользователя, связанных продуктов в 2000 году Т + 1 выход. Затем вводятся В пул избирательных материалов и данных припоминания личности товарных отношений , используемых в этой части данных в соответствии с Laima He выходом отсутствует синхронизация двигателя, выход логик здесь является первым сорт выбранного пула продукта по товарным показателям, зарезервированной отсортировано до того, как 5000 общий отзыв Т + 1 выход, в зависимости от использования этих двух шагов формируют индивидуальный отзыв. Затем вспомнить BE товар и выбор продукта пула реляционных данных фильтрации, эта часть является использование онлайн двигателя синхронизации данных обновляется в режиме реального времени, причина этого шага предназначена для фильтрации отзыва является предотвращение товар личности отзыва T + 1, тем дольше текущий товарный бассейн лото. Поэтому, естественно, будет вспоминать запасной вариант логики, которая является частью синхронизации данных двигателя Мах обеспечения обновления в реальном времени сохраняются в IGRAPH, вы можете вспомнить текущий пул 2000 последний товар с ID товарного пула в качестве запасного варианта. По вышеприведенной логике обеспечения пользователя в режиме реального времени в алгоритме вызова.
Суммировать
В этой статье представлено всестороннее введение от выбора Mach до оптимизации запуска Mach в реальном времени Каждый шаг оптимизации представляет собой окончательное решение Чтобы обеспечить плавный переход системы, при оптимизации было пройдено много ям, но все они приземлились плавно в конце. Оптимизированный Mach Качественно изменилась вся задержка связи в реальном времени от выбора продукта до доставки. Данные выбора продукта изменились с T + 1 на H + 1, процесс выбора продукта изменился с 6 минут до 30 секунд, а процесс доставки изменился с 2 минут до 2 секунд. Система стала более надежной и работает в режиме реального времени. С точки зрения общей функции Mach по-прежнему относится к системе на уровне инструментов, и ей далеко от достижения уровня продукта на уровне системы.
Как показано на рисунке выше, в будущем основное внимание будет уделяться возможностям выбора продукта и общим возможностям эксплуатации и обслуживания, добавлению новых возможностей при оптимизации исходной системы и постепенному превращению Mach в продуктизированную систему.