Основные типы систем данных электронной коммерции

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

1. Реляционная база данных, Большинство интернет-компаний выберут mysql в качестве основного варианта базы данных, которая используется для хранения таких данных, как товары и информация о пользователях. Реляционные базы данных поддерживают очень транзакционные операции OLTP (такие как заказ, расчет и т. д.).
2. экология хаупа, Hadoop является основным носителем хранилища данных. Помимо резервного копирования всех версий реляционной базы данных, он также хранит массивные данные журналов, такие как поведение пользователей, клики, воздействие и взаимодействие. Hadoop имеет более расширенную поддержку OLAP для анализа данных. и интеллектуальный анализ данных, чем реляционные базы данных.Стабильность и устойчивость.
3. поисковый движок, представленный elasticsearch и solr. Поисковые системы являются наиболее эффективным способом получения информации и стали почти стандартными средствами для всех видов веб-сайтов и приложений (по статусу уступают только базам данных).

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

Общие приложения поисковых систем при коммерческом поиске в Интернете обычно сталкиваются со следующими проблемами:

• Интеграция поисковой системы с существующими системами данных компании. MySQL и hadoop являются двумя основными носителями данных электронной коммерции.Поисковые системы должны быть полностью интегрированы с MySQL или hadoop в процессе полной и инкрементной индексации, чтобы в полной мере использовать масштабируемость в реальном времени и горизонтальную масштабируемость (производительность и мощности и пропорционально количеству машин) и другие преимущества.
• Противоречие между узкоспециализированным коммерческим поиском и общей поисковой системой. Проблема коммерческого поиска иногда выходит за рамки самой поисковой системы, например, дедупликация товаров и дедупликация магазинов требует профессиональных навыков поисковой системы, вес товаров и идентификация намерений пользователей требуют поддержки алгоритмов и модели.
• Трудно создать эффективный индекс, не зная опыта поисковых систем. Результатом является иллюзия плохой общей производительности поиска.

Автор — архитектор больших данных Youzan, исходя из собственной поисковой практики, делится актуальной структурой поисковой системы и задачами, которые она решает.

Архитектура поисковой системы

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

1. Техническая архитектура

Поисковая система Youzan основана на распределенном движке elasticsearch (ES) реального времени. ES построен на lucence, самой стабильной и зрелой библиотеке индексов в сообществе с открытым исходным кодом, поддерживает многопользовательскую аренду, высокую доступность и горизонтальное расширение, а также имеет механизмы автоматической отказоустойчивости и автоматического масштабирования. Наши коллеги также реализовали бесшовную интеграцию es с mysql и hadoop; мы самостоятельно разработали модуль расширенного поиска, обеспечивающий гибкую структуру расчета корреляции и другие функции.

2. Создание индекса

Интернет-индексирование характеризуется высокой производительностью в режиме реального времени и большим объемом данных. Своевременность требует, чтобы различное поведение пользователей и клиентов могло войти в индекс в первый раз; большой объем данных требует эффективной распределенной схемы для создания индекса порядка терабайт за постоянное время.

Мы используем очередную архитектуру для индексации в реальном времени: данные сначала записываются в БД (или файл), а затем поток данных записывается в очередь kafka через механизм синхронизации базы данных. Этот механизм синхронизации аналогичен принципу синхронизации master-slave базы данных.Основные продукты с открытым исходным кодом — mypipe и canal, запущенные Ali. es обеспечивает индексацию в реальном времени, подписавшись на соответствующую тему.

Если источником данных является файл, используйте Flume для записи в Kafka в режиме реального времени.

Еще одна проблема индексации — полная индексация. Есть несколько сценариев, когда полная индексация является необходимым процессом:

• Обновления в реальном времени могут привести к потере данных, а каждая небольшая потеря надолго снизит качество поисковых систем. Периодическое полное обновление — самый прямой способ решить эту проблему;
• Даже если можно гарантировать обновления в режиме реального времени, для развития бизнеса может потребоваться повторная индексация (например, добавление полей, изменение атрибутов, изменение алгоритмов сегментации слов и т. д.).
• Многие поисковые системы создаются задолго до начала бизнеса, и для холодного старта необходимо создавать полные индексы.

Мы используем Hadoop-es для создания индексов, используя преимущества распределенного характера Hadoop. hadoop-es делает распределенные индексы прозрачными для пользователей, как и обновление индексов на одной машине. Одна из них представляет собой распределенную платформу данных, а другая — распределенную поисковую систему. Если их объединить, можно реализовать процесс распределенного полного индексирования. Hadoop-es официально является тем инструментом, который нам нужен.

Даем каштан за создание индекса через Hive sql:

1. drop table search.goods_index;
3. CREATE EXTERNAL TABLE search.goods_index (
5. is_virtual int,
7. created_time string,
9. update_time string,
11. title string,
13. tag_ids array
15. ) STORED BY ‘org.elasticsearch.hadoop.hive.EsStorageHandler’ TBLPROPERTIES (
17. ‘es.batch.size.bytes’=’1mb’,
19. ‘es.batch.size.entries’=’0’,
21. ‘es.batch.write.refresh’=’false’,
23. ‘es.batch.write.retry.count’=’3’,
25. ‘es.mapping.id’=’id’,
27. ‘es.write.operation’=’index’,
29. ‘es.nodes’=’192.168.1.10:9200’,
31. ‘es.resource’=’goods/goods’);

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

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

Архитектура полного индекса и добавочного индекса показана на следующем рисунке. Еще один момент заключается в том, что Hadoop также подписывается на Kafka для резервного копирования баз данных и журналов. Лично я рекомендую хранить все БД и файлы компании на хаупе, у которого есть как минимум два преимущества:

1. Хранилище данных, созданное с помощью Hive или Spark в Hadoop, обеспечивает единый рабочий интерфейс для больших данных.
2. Данные Hadoop более стабильны, чем онлайн, и могут использоваться в качестве последней линии защиты для восстановления данных.

Тема хранилищ данных выходит за рамки этой статьи и здесь лишь кратко упоминается.

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

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

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

Еще одна особенность Kakfa заключается в том, что он поддерживает чтение данных из любой точки останова.Например, наш полный индекс читается из HDFS.Мы можем напрямую переключиться на данные, считанные Kafka, в соответствии с отметкой времени последнего фрагмента данных, сохраненного в HDFS.

Расширенный поиск: за пределами возможностей ES

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

AS в основном играет следующие роли в коммерческих поисковых системах:

1. Обратный прокси, который реализует распределенный поиск на основе шардинга (фактически у es есть такая функция); обеспечивает необходимую поддержку аварийного восстановления
2. Предоставляет подключаемый модуль расчета корреляции
3. Предоставляет богатые библиотеки корреляции, такие как библиотека анализа запросов, библиотека перезаписи запросов, библиотека сортировки, библиотека фильтрации и т. д.
4. Управление различными поисковыми операциями

Одной из основных функций AS является представление соответствующего поиска через бизнес-плагин. В простейшем плагине нужно только включить соответствующий API поиска ES, который фактически является элементом конфигурации, указывающим адрес es. Таким образом, AS является чистым прокси. Однако требования коммерческого поиска не поддерживаются самой ЭС, поэтому необходимо писать соответствующие плагины Query rewriter, rerank и другие алгоритмы согласно требованиям. Таким образом, структура и бизнес разделены, а AS обладает высокой масштабируемостью и возможностью повторного использования.

Еще одной функцией AS является предоставление общей библиотеки алгоритмов, фактически она предоставляет только программную среду для каждого алгоритма. Алгоритмы также добавляются в библиотеку алгоритмов через плагины. Этот подход позволяет инженерам-алгоритмам абстрагировать общедоступные библиотеки алгоритмов для использования в бизнесе, не изобретая велосипед. Конкретный бизнес либо использует существующий алгоритм (и модифицирует параметры), либо реализует собственный алгоритм.

Изображение выше является примером. Поиск товаров и поиск дистрибуции реализуют алгоритм повторного ранжирования, и оба вызывают библиотеку алгоритмов rerank1, предоставляемую системой, и добавляют свою собственную уникальную логику.

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

Оптимизация производительности ЭС

В следующих сводках мы описали несколько сценариев оптимизации производительности, с которыми столкнулись.

1. Используйте очереди на уровне приложений для предотвращения лавин

Одна из проблем с ES заключается в том, что он чрезвычайно подвержен сходу лавин в периоды пиковой нагрузки. ES имеет надежную систему пула потоков для обеспечения параллелизма и стабильности. Однако в случае внезапных изменений в трафике (таких как пики Double Eleven) он все равно подвержен параличу, основные причины заключаются в следующем:

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

В AS мы реализуем глобальную очередь, ориентированную на запросы, для обеспечения стабильности. В основном он делает 3 вещи.

1. Разделите запрос на слайды в соответствии с бизнесом, и каждый слайд соответствует очереди. По умолчанию приложение представляет собой слайд, и приложение также может различать разные слайды, что может защитить важные запросы внутри приложения.
2. Для каждой очереди настроена длина очереди, по умолчанию 50.
3. Каждая очередь вычисляет среднее время ответа для этой очереди. Когда среднее время ответа очереди превышает 200 мс, она перестает работать на 1 с.Если запрос переполняется, журнал переполнения будет записан, чтобы сохранить данные для восстановления. Если среднее время отклика очереди превышает 500 мс 10 раз подряд, будет выдан сигнал тревоги, чтобы инженер мог справиться с этим как можно скорее.

2. Автоматический переход на более раннюю версию

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

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

Для слайдов с планом понижения AS напрямую использует запрос на понижение вместо обычного запроса, когда ответ очереди слишком медленный. Этот метод позволил нам успешно пережить резкий рост трафика на Double Eleven без расширения пропускной способности.

3. Эффективно используйте отфильтрованный запрос

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

• Bitsetcache находится в памяти и никогда не исчезает (если только это не LRU).
• Битовые наборы используют битовые операции, изначально поддерживаемые ЦП, которые на несколько порядков быстрее, чем инвертированные индексы.
• Операция И нескольких наборов битов также очень быстрая (64-битный ЦП может одновременно вычислять операцию И 64 DOC)
• Хранение наборов битов в памяти не зависит от запроса и имеет широкие возможности повторного использования.
• Если фрагмент набора битов равен 0, при вычислении эти фрагменты будут автоматически пропущены, что позволит битовым наборам работать лучше, чем инвертированные индексы, в случае разреженных данных.

Например:

1. query:bool:
3. tag:'mac'
5. region:'beijing'
7. title: "apple"

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

Это сценарий использования фильтра, он запоминает только наличие и отсутствие двух состояний. Если мы будем хранить теги и регионы в битсетах, чтобы эти два фильтра всегда можно было кэшировать в памяти, это будет намного быстрее. Кроме того, пересечение между тегами и областями происходит очень быстро, потому что 64-битные машины могут одновременно обрабатывать 64 doc-битных операции за один цикл ЦП.

Золотое правило lucence: используйте фильтр, если можете, если только вы не должны использовать запрос (если и только если вам нужно подсчитывать баллы).

1. query:
3. filtered:
5. query:
7. title: "apple"
9. filter:
11. tag:"mac"
13. region:"beijing"

Отфильтрованный запрос Lucence будет сначала интеллектуально вычислять оператор фильтра, а затем вычислять оператор запроса, максимально сокращая вычислительное пространство перед выполнением сложных алгоритмов инверсии.

4. Другие оптимизации производительности

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

Максимально увеличьте интервал обновления. Чтобы гарантировать, что интервал обновления индекса в реальном времени по умолчанию равен 1 секунде, обновление индекса повлияет на производительность запроса.На основе обеспечения своевременности для бизнеса интервал обновления может быть соответствующим образом увеличен для обеспечения производительности запроса.

Разве что нужно убрать поле all. По умолчанию, помимо индексации каждого поля, создается дополнительное поле all для сохранения всего текста. Удаление этого поля может уменьшить размер индекса на 50%.

При создании индекса постарайтесь физически отделить медленный индекс от быстрого, насколько это возможно.

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

Алгоритмическая архитектура

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

1. Процесс индексации

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

Процесс создания индекса выглядит следующим образом:

шаг 1, вычислить статическую оценку каждого документа;

шаг 2, вычислить сходство между двумя документами;

Шаг 3: Разделите данные по базам данных по сходству и другой информации;

Шаг 4, установите индекс ES.

2. Процесс поиска

Процесс поиска — это процесс, в котором поисковая система получает запрос пользователя для серии обработок и возвращает релевантные результаты. Коммерческие поисковые системы должны учитывать 2 фактора в процессе поиска: 1) релевантность, 2) важность.

Релевантность относится к тому, связан ли возвращаемый результат с входным запросом, что является одной из основных проблем поисковых систем.В настоящее время обычно используются алгоритмы BM25 и пространственно-векторная модель. Оба этих алгоритма поддерживаются ElasticSearch, а обычные коммерческие поисковые системы используют алгоритм BM25. Алгоритм BM25 рассчитает показатель релевантности каждого документа и запроса, для представления которого мы используем Dscore.

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

Окончательный рейтинг поисковых систем основан на:

Score = Dscore * Tscore

То есть, всесторонне рассматривая статическую оценку и динамическую оценку, чтобы предоставить пользователям релевантные и важные продукты.

Процесс поиска грубо абстрагируется от следующих шагов.

Шаг 1, выполните анализ исходного запроса;

шаг 2, перепишите запрос в соответствии с результатами анализа запроса как;

шаг 3, используйте переписанный запрос для получения es в as;

Шаг 4, в процессе запроса es всесторонняя сортировка в соответствии со статической оценкой и динамической оценкой;

шаг 5, переставьте результаты, возвращаемые es, в as;

Шаг 6, вернуть результат.

Технология расчета статической оценки товара

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

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

Будем считать, что на статическую оценку товара влияют 3 решающих фактора: 1 — количество заказов, 2 — выгодный курс, 3 — скорость доставки.

Мы используем Tsocre для выражения статической оценки, а Tscore можно записать в следующей форме:

Tscore = a * f (количество заказов) + b * g (хороший показатель) + c * h (скорость доставки)

a, b, c – весовые параметры, которые используются для уравновешивания степени влияния каждого показателя. f, g, h — репрезентативные функции, используемые для преобразования исходных метрик в разумные метрики.

Во-первых, нам нужно найти разумную репрезентативную функцию.

1. Во-первых, зарегистрируйте каждый индикатор. Производная log представляет собой убывающую функцию, а это означает, что для получения лучшего результата требуется все больше и больше денег.
2. стандартизация. Цель нормализации состоит в том, чтобы обеспечить возможность сравнения каждой меры в пределах одного и того же интервала. Например, значение номера заказа составляет 0~10000, а значение благоприятного рейтинга составляет 0~1. Эта ситуация повлияет на результаты и удобство анализа данных.Чтобы устранить влияние размеров между показателями, требуется обработка стандартизации данных для решения сопоставимости между показателями данных. Наиболее часто используемым методом нормализации является метод нормализации z-оценки.

метод нормализации z-оценки

«Теория вероятностей» говорит нам, что для данных, которые удовлетворяют нормальному распределению, диапазон 3 z-показателей до и после среднего может охватывать 99% данных. Эмпирически мы устанавливаем баллы >5 zscore или меньше -5 zscore на 5*zscore или -5zscore. В частности, мы не рекомендуем использовать метод нормализации минимум-максимум. Этот метод, также известный как стандартизация дисперсии, представляет собой линейное преобразование исходных данных, так что результирующее значение отображается между [0-1].Функция преобразования выглядит следующим образом:

Этот метод очень нестабилен.Если предположить, что особая точка в 1000 раз больше второго по величине значения, большинство значений будет сосредоточено в диапазоне 0 ~ 0,01, что также теряет цель нормализации.

На рисунке 1 приведено нормированное по min-max распределение данных. Очевидно, что большая часть данных «сжата» в небольшой диапазон. На рисунке 2 используется логарифмическое нормированное распределение данных. Поскольку логарифм уменьшает скорость роста, это может быть видно, что уже есть хороший результат, рисунок 3 представляет собой нормализацию z-показателя на основе журнала.Видно, что z-оценка делает данные очень гладкими.

(Рисунок 1: минимальная нормализация)

(Рисунок 2: нормализация журнала)

(Рисунок 3: нормализация log-zscore)

Наконец, после выбора соответствующего веса и нормализации log-zscore мы в основном объясняем репрезентативные функции f, g и h. Tscore = af (количество заказов) + bg (хороший курс) + c*h (скорость доставки), следующим шагом является определение параметров a, b и c. Обычно есть два метода:

1. Экспертное право. Динамически настраивать параметры веса в соответствии с нашим повседневным опытом;
2. Экспериментальный метод. Сначала задайте начальное значение с помощью экспертов, а затем измените метод одной переменной, чтобы динамически настроить параметры в соответствии с результатами abtest.

Дедупликация названия продукта

Снятие акцента с названия продукта играет важную роль в поиске электронной коммерции: согласно данным, 80% пользователей покупают товары через страницу поиска и выбирают первые 4 страницы поиска. Повторение названий продуктов приведет к тому, что важные страницы не будут иметь золотого содержания, что значительно снизит количество покупок в поиске.

Например:

Title1: Вкусно/банан/бесплатная доставка/Гуандун/Гаочжоу/банан/банан//нет/созревающий агент/

Title2: Delicious/Banana/Guangdong/Gaozhou/Banana//Non/Fan Banana/Бесплатная доставка/

Здесь используется техника «мешка слов», в качестве размерности пространственного вектора используется словарный запас, а в качестве значения этого признака используется частотность каждого термина заглавия. Возьмите этот пример. Размеры этого словаря: вкусный (0), банан (1), бесплатная доставка (2), Гуандун (3), Гаочжоу (4), банан (5), нет (6), созревающий агент (7), не - (8), Розовый банан (9) Позиция: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9

Заголовок1: 1, 2, 1, 1, 1, 1, 1, 1, 0, 0

Название2: 1, 2, 1, 1, 1, 0, 0, 0, 1, 1

Каждый заголовок представлен вектором фиксированной длины.

Снова вычисляем попарное сходство.

Сходство обычно достигается путем вычисления расстояния между двумя векторами без потери общности, здесь мы используем 1-косинус (x, y) для представления расстояния между двумя векторами. Это проблема «сходства всех пар», то есть требуется попарное сравнение, а сложность составляет O (n ^ 2). Одной машине сложно справиться с огромным объемом товаров. Мы даем два метода для достижения «сходства всех пар».

Способ 1: матричная операция искры.

rddRows = sc.parallelize(["1 0 2 0 0 1", "0 0 4 2 0 0"])

rddRows.map(lambda x: Vectors.dense([float(each) для каждого в str(x).split(" ")]))

mat = RowMatrix(rddRows)

simsPerfect = mat.columnSimilarities()

Метод 2: линейный метод уменьшения карты.

Этот метод относится к статье «Попарное сходство документов в больших коллекциях с помощью MapReduce». Можно достичь почти линейной временной сложности. По сравнению с матричными операциями имеет преимущества в крупномасштабных (более 1 миллиарда) парных операциях подобия. Этот метод кратко описывается следующим образом: сначала вычисляется отображение каждого термина в doc в соответствии с методом вычисления инвертированного индекса. Например 3 документ:

doc1 = Я люблю Пекин

doc2 = I Пекинская площадь

doc3 = Моя площадь

Преобразованный в инвертированный формат, для этого требуется сокращение карты.

я -> документ1, документ2, документ3

любовь -> документ1

Пекин -> документ1, документ2

Тяньаньмэнь -> doc2, doc3

Затем отфильтровывается только один элемент для Value, две или две комбинации, превышающие 2 DOC:

doc1, doc2 doc1, doc2, doc3

doc1,doc3 doc1, doc2, doc3

doc2, doc3 doc1, doc2, doc3

doc1,doc2 doc1, doc2

doc2, doc3 doc2, doc3

Наконец, для выходной агрегации значение представляет собой отношение количества повторений к квадратному корню из произведения двух документов.

doc1,doc2 -> 2/(len(doc1)*len(doc2))^1/2 = 0.7

doc1,doc3 -> 1/(len(doc1)*len(doc3))^1/2 = 0.3

doc2,doc3 -> 2/(len(doc2)*len(doc3))^1/2 = 0.3

Для двух title1 и title2, если X(title1, title2) > 0.7, считается, что title1 и title2 похожи, для двух похожих документов статически большой документ определяется как основной, а статически маленький — как вторичный док. Основной документ и вспомогательный документ строятся отдельно.

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

магазин для тяжелого

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

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

A и B представляют разные магазины.

При поиске бананов можно контролировать количество результатов магазина А, но при поиске «груши» неверно, что груши магазина Б ранжируются первыми (при условии, что А: груши имеют более высокий статический балл, чем Б: груши).

На самом деле, если вы хотите добиться эффекта дедупликации в магазине, очень легко сделать поиск по корзинам. Мы предполагаем, что на страницу приходится 20 результатов поиска, мы делим библиотеку индексов на 4 корзины, и каждый элемент модулирует количество корзин, чтобы получить номер корзины, в которой он находится. Это может гарантировать, что товары одного и того же магазина будут только в одном ведре. В процессе поиска каждая корзина поровну делится на 25% поисковой задачи, а результаты объединяются в одну страницу согласно статической оценке. Таким образом, относительный порядок одних и тех же гарантированных результатов достигает цели дедупликации в хранилище.

Как показано на рисунке выше, выполните поиск «банан», хотя есть 10 результатов, соответствующих потребностям магазина А, но на каждой странице поиска может отображаться только 5 результатов.

Анализ запросов и технология перезаписи запросов

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

Расширение синонима обычно получается путем анализа журналов сеансов пользователей. Если пользователь вводит «iphone» и не получает желаемого результата, он вводит «iphone», и мы создаем связь перехода между «iphone» и «iphone». На основе статистики мы можем создать взаимосвязанную карту весов пользовательских запросов.

Пользователь вводит запрос «Apple phone», согласно анализу запроса, «Apple phone» имеет два синонима: «iphone» 0,8 и «iphone 6» 0,5. 0,8 и 0,5 указывают на степень синонимии соответственно. Мы хотим одновременно ввести три запроса «iphone», «iphone» и «iphone 6» и присвоить разным запросам разные веса в зависимости от степени синонимии. BoostingQuery, предоставляемый ElasticSearch, может удовлетворить это требование.

Исходный запрос:

1. {
2. “query”{
3. “match”: {
4. “query”: ”苹果手机”
5. }
6. }
7. }

Оптимизированный запрос:

1. {
2. "query": {
3. "should": [
4. {
5. "match": {
6. "content": {
7. "query": "苹果手机",
8. "boost": 10
9. }
10. }
11. },
12. {
13. "match": {
14. "content": {
15. "query": "iphone",
16. "boost": 8
17. }
18. }
19. },
20. {
21. "match": {
22. "content": {
23. "query": "iphone6",
24. "boost": 5
25. }
26. }
27. }
28. ]
29. }
30. }

Другие методы, такие как распознавание основных слов и исправление неоднозначных слов, аналогичны, и в этой статье мы не будем их подробно описывать.

резюме

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

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