搜索引擎优化的方式哪些( 数据同步平台优化增量搜索数据索引的一系列技术(组图))

　　搜索引擎优化的方式哪些(

数据同步平台优化增量搜索数据索引的一系列技术(组图))

　　

　　Grab 是一家*敏*感*词*在线叫车和外卖平台公司，总部位于新加坡。其业务覆盖*敏*感*词*大部分地区，为8个国家350多个城市的87亿多用户提供服务。Grab 目前提供的服务包括网约车、送餐、酒店预订、网上银行、移动支付和保险。是*敏*感*词*的“美团”。Grab Engineering 分享了他们优化搜索索引的方法和经验，由 InfoQ 中文网站翻译和分享。

　　今天的应用程序通常使用各种数据库引擎，每个引擎都服务于特定的需求。对于 Grab Deliveries，MySQL 数据库用于存储典型的数据格式，而 Elasticsearch 提供高级搜索功能。MySQL 是原创

数据的主要数据存储，而 Elasticsearch 是派生存储。

　　

　　搜索数据流

　　MySQL和Elasticsearch之间的数据同步做了很多工作。本文介绍了一系列优化增量搜索数据索引的技术。

　　背景

　　从主数据存储到衍生数据存储的数据同步由数据同步平台（DSP）食品普贤处理。就搜索服务而言，就是MySQL和Elasticsearch之间的数据同步。

　　当 MySQL 每次实时数据更新触发数据同步过程时，它会将更新后的数据传递给 Kafka。数据同步平台使用Kafka流列表，增量更新Elasticsearch中对应的搜索索引。这个过程也称为增量同步。

　　Kafka到数据同步平台

　　数据同步平台使用Kafka Streams实现增量同步。“Stream”是一个没有边界、不断更新的数据集。它是有序的、可重播的和容错的。

　　

　　使用kafaka的数据同步流程

　　上图描述了使用Kafka进行数据同步的过程。数据生产者在 MySQL 上为每个操作创建一个 Kafka 流，并实时发送给 Kafka。数据同步平台为每个 Kafka 流创建一个流消费者。消费者从各自的 Kafka 流中读取数据更新并将它们同步到 Elasticsearch。

　　MySQL 到 Elasticsearch

　　Elasticsearch 中的索引对应于 MySQL 表。MySQL 数据存储在表中，而 Elasticsearch 数据存储在索引中。多个 MySQL 表连接起来形成一个 Elasticsearch 索引。以下代码片段显示了 MySQL 和 Elasticsearch 中的实体关系映射。实体A和实体B是一对多的关系，实体A在MySQL中有多个相关的表，分别是表A1和A2，它们连接起来形成一个Elasticsearch索引A。

　　

　　MySQL 和 Elasticsearch 中的 ER 映射

　　有时，搜索索引同时收录

实体A和实体B。对于索引的关键字搜索查询，例如“Burger”，搜索响应中将返回实体A和实体B中名称收录

“Burger”的对象。

　　原创

增量同步原创

Kafaka 流

　　在上面显示的 ER 图中，数据生产者为每个 MySQL 表创建一个 Kafaka 流。每当 MySQL 中发生插入、更新或删除操作时，操作后的数据副本将发送到其 Kafka 流。对于每一个 Kafaka 流，数据同步平台都会创建不同的流消费者（Stream Consumer），因为它们具有不同的数据结构。

　　流媒体消费者基础设施

　　流消费者由 3 个组件组成。

　　

　　流媒体消费者基础设施

　　事件缓冲过程

　　事件缓冲区由许多子缓冲区组成，每个子缓冲区都有一个唯一的ID，它是缓冲区中事件的主键。子缓冲区的最大大小为1。这样，事件缓冲区可以重复处理缓冲区中具有相同ID的事件。

　　下图展示了将事件推送到事件缓冲区的过程。当新事件被推送到缓冲区时，共享相同 ID 的旧事件将被替换。因此，将不会处理被替换的事件。

　　

　　将事件推送到事件缓冲区

　　事件处理程序

　　以下流程图显示了由事件处理程序执行的程序。其中包括通用处理程序进程（白色）和对象 B 事件的附加进程（绿色）。当从数据库加载的数据创建一个新的 Elasticsearch 文档时，它会从 Elasticsearch 中获取原创

文档，比较是否有任何更改的字段，并决定是否需要向 Elasticsearch 发送新文档。

　　在处理对象B事件时，也会根据常用的处理器级联更新Elasticsearch索引中的相关对象A。我们将此操作命名为“级联更新”（Cascade Update）。

　　

　　事件处理程序执行的过程

　　原有基础设施的问题

　　Elasticsearch 索引中的数据可以来自多个 MySQL 表，如下所示。

　　

　　Elasticsearch 索引中的数据

　　原有的基础设施存在一些问题。

　　优化 MySQL 二进制日志增量同步

　　MySQL 二进制日志 (Binlog) 是一组日志文件，其中收录

MySQL 服务器实例的数据修改信息。它收录

更新数据的所有语句。有两种类型的二进制日志。

　　Grab Caspian 团队（Data Tech）基于 MySQL 基于行的二进制日志构建了一个变更数据捕获 (CDC) 系统。它可以捕获所有 MySQL 表的所有数据修改。

　　当前的 Kafaka 流

　　二进制日志流事件定义是一种常见的数据结构，收录

三个主要字段：Operation、PayloadBefore 和 PayloadAfter。Operation 的枚举是 create、delete 和 update。Payload 是 JSON 字符串格式的数据。所有二进制日志流都遵循相同的流事件定义。在二进制日志事件中使用PayloadBefore和PayloadAfter，可以在数据同步平台上优化增量同步。

　　

　　二进制日志流事件的主要字段

　　流消费者优化事件处理器优化优化1

　　请记住，如上所述，Elasticsearch 存在冗余更新问题。Elasticsearch 数据是 MySQL 数据的一个子集。第一个优化是通过检查 PayloadBefore 和 PayloadAfter 之间的不同字段是否在 Elasticsearch 数据子集中来过滤掉不相关的流事件。

　　二进制日志事件中的Payload是一个JSON字符串，因此定义了一个数据结构来解析PayloadBefore和PayloadAfter，其中只收录

Elasticsearch数据中存在的字段。对比解析出来的Payload，我们可以很容易的知道这个变化是否和Elasticsearch有关。

　　下图显示了优化的事件处理程序流程。从蓝色流程可以看出，在处理事件时，首先比较PayloadBefore和PayloadAfter。仅当 PayloadBefore 和 PayloadAfter 之间存在差异时才处理此事件。因为不相关的事件已经被过滤掉了，所以不需要从 Elasticsearch 中获取原创

文件。

　　

　　事件处理器优化 1

　　效力

　　

　　用于优化的 Elasticsearch 事件更新 1

　　优化2

　　事件中的 PayloadAfter 提供更新的数据。因此，我们开始考虑是否需要一个全新的 Elasticsearch 文档来读取多个 MySQL 表。第二个优化是利用二进制日志事件的数据差异改为部分更新。

　　下图显示了更新的事件处理程序流程的一部分。如红色流程所示，它不是为每个事件创建一个新的 Elasticsearch 文档，而是首先检查该文档是否存在。添加的文档存在（大部分时间都存在），那么在这个事件中数据发生变化，只要比较PayloadBefore和PayloadAfter就会更新到现有的Elasticsearch文档中。

　　

　　事件处理器优化2

　　效力

　　

　　事件缓冲区优化

　　将新事件推送到事件缓冲区时，我们不会替换旧事件，而是会将新事件与旧事件合并。

　　事件缓冲区中每个子缓冲区的大小为1。在此优化中，流事件不再被视为通知。我们在事件中使用 Payload 来执行部分更新。替换旧事件的旧过程不再适用于二进制日志流。

　　当事件调度器将新事件推送到事件缓冲区的一个非空子缓冲区时，它会将子缓冲区中的事件A和新事件B合并成一个新的二进制日志事件C，其PayloadBefore来自事件A，PayloadAfter 来自事件 B。

　　

　　合并事件缓冲区的优化操作

　　级联更新优化优化

　　我们使用一个新的流来处理级联更新事件。当生产者向 Kafka 流发送数据时，共享相同 ID 的数据将存储在同一个分区上。每个数据同步平台服务实例只有一个流消费者。当一个消费者消费 Kafaka 流时，一个分区只被一个消费者消费。因此，共享同一 ID 的级联更新事件将由同一 EC2 实例上的一个流消费者使用。通过这种特殊的机制，内存中的事件缓冲区可以重用大部分共享相同 ID 的级联更新事件。

　　以下流程图显示了优化的事件处理程序。绿色显示原创

流程，而紫色显示具有级联更新事件的当前流程。在处理对象B的事件时，事件处理程序不会直接级联更新相关的对象A，而是向新的流发送级联更新事件。这个新流的消费者将处理级联更新事件并将对象 A 的数据同步到 Elasticsearch。

　　

　　具有级联更新的事件处理程序

　　效力

　　

　　级联更新事件

　　总结

　　本文介绍了四种不同的数据同步平台优化方法。切换到Coban团队提供的MySQL二进制日志流并优化流消费者后，数据同步平台节省了约91%的数据库读取和90%的Elasticsearch读取，以及流处理的流流量平均查询次数消费者（Queries Per Second，QPS）从 200 次增加到 800 次。高峰时段平均查询次数最多可达1000次以上。随着平均查询次数的增加，处理数据的时间和从 MySQL 到 Elasticsearch 的数据同步延迟减少。经过优化，数据同步平台的数据同步能力得到了显着提升。