本文主要介绍如何通过 Flink 实时构建搜索引擎的索引，将从背景介绍、索引分类、实时索引架构以及一种简单的实现方法四方面分享。
搜索引擎的出现大大降低了人们寻找信息的难度，已经深入到生活与工作的方方面面，简单列举几个应用如下：
互联网搜索，如谷歌，百度等；
垂直搜索，如淘宝、天猫的商品搜索；
站内搜索，各个内容网站提供的站内搜索服务；
企业内部搜索，员工查询企业内部信息；
广告投放，根据投放上下文检索出对应的广告主和广告内容；
搜索引擎的关键是让用户找到其所需信息，其整体架构如下：
从图示可知，一个搜索引擎从大的方面来看主要包括两部分，一部分是提供在线的搜索服务，一部分要把原始数据已离线的方式建立索引，建立索引是信息可搜索的前提。
说明：这里的在线与离线主要指的是是否直接服务于用户，直接服务于用户的部分叫在线系统，服务于在线系统的其他系统叫做离线系统。比如搜索是在线系统，APP 是在线系统，那么为搜索建立索引的系统就叫做离线系统，为 APP 计算某些数据指标的系统也叫做离线系统。
今天重点介绍索引系统，我们经常用的谷歌百度等，可能在网页发生变化的几天后才会更新索引，但在某些业务场景下，必须尽可能的缩短索引时间：
比如广告投放系统，参考广告场景下的实时计算，如果广告主下线广告后没有及时更新到索引中，那投放系统依然会投放这些已经下线的广告，白白浪费资金；
再比如商品搜索系统，商家修改价格后要及时反应到索引中，否则用户会感觉搜索结果跟真实商品不一致；
索引指的是是把原始数据更新到索引中去的过程，很多时候并不是原始数据的直接覆盖，而是要在这个过程中去拼接最后的文档。举个例子，电商的搜索会展示商品信息，商品销量，店铺信息等，而这些信息存在于多个业务数据库，所以需要在索引过程中把这些信息拼接起来：
一般情况下，索引需要持续更新，这时便有两种更新方式：
2.1 批量更新
由一个定时调度程序来循环调度，每次读取全量数据，处理完之后也全量更新索引。该方案最大的问题是延迟，如果每次全量脚本需要跑 N 小时，则索引有 N 小时的延迟。
2.2 实时更新
每次变化后及时更新增量信息
很多情况下这两种方式都会存在：定期全量更新，实时增量更新，但两者的协调会是一个很大的问题，需根据业务情况设计：
批量和增量分开，可以批量更新时停掉增量更新，也可以同时跑，但这样需要维护两套逻辑；
全量更新也复用增量更新的逻辑，统一架构；
这有点像之前数仓介绍中的 Lambda 架构与 Kappa 架构，参考：如果你也想做实时数仓。
该系统架构如下：
增量部分不变，但全量部分要做修改，定时调度，每次把全量数据导出，并且逐条按照增量的方式发送到消息队列，这就即可复用增量的逻辑。
我们接下来介绍一种基于云产品的简单实现方案。
该方案的数据流如上图所示：
原始数据存在 MySQL 中；
MySQL 开启主备和 binlog；
Logtail 读取 MySQL 的 binlog，并对其中的事件进行解析、过滤、数据解析等（具体方法见下面的描述）；
Logtail 把解析后的数据上传到日志服务（SLS）；
实时计算（Flink）订阅日志服务；
实时计算完成数据的拼接，并把结果推送到 Elasticsearch 之中；
这样就完成了一个实时索引的方案。
说明：Logtail 是日志服务（SLS）的一个日志采集 Agent，详情可参考日志服务产品的官方文档。它采集 Binlog 的原理是：伪装成 MySQL 的 Slave 节点，向 MySQL master 发送 dump 协议；MySQL 的 master 收到 dump 请求后，会将自身的 Binary log 实时推送给 Logtail。
点击阅读原文可了解 Flink Forward Asia 2019 官网，了解大会更多详情。
本文分享自微信公众号 - Flink 中文社区（gh_5efd76d10a8d）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。