案例与解决方案汇总页：
阿里云实时计算产品案例&解决方案汇总
1.背景介绍
搜索引擎的出现大大降低了人们寻找信息的难度，已经深入到生活与工作的方方面面，简单列举几个应用如下：
- 互联网搜索，如谷歌，百度等；
- 垂直搜索，如淘宝、天猫的商品搜索；
- 站内搜索，各个内容网站提供的站内搜索服务；
- 企业内部搜索，员工查询企业内部信息；
- 广告投放，根据投放上下文检索出对应的广告主和广告内容；
搜索引擎的关键是让用户找到其所需信息，其整体架构如下：
从图示可知，一个搜索引擎从大的方面来看主要包括两部分，一部分是提供在线的搜索服务，一部分要把原始数据已离线的方式建立索引，建立索引是信息可搜索的前提。
注：这里的在线与离线主要指的是是否直接服务于用户，直接服务于用户的部分叫在线系统，服务于在线系统的其他系统叫做离线系统。比如搜索是在线系统，APP是在线系统，那么为搜索建立索引的系统就叫做离线系统，为APP计算某些数据指标的系统叫做离线系统。
今天重点介绍索引系统，我们经常用的谷歌百度等，可能在网页发生变化的几天后才会更新索引，但在某些业务场景下，必须尽可能的缩短索引时间：比如广告投放系统，参考广告场景下的实时计算，如果广告主下线广告后没有及时更新到索引中，那投放系统依然会投放这些已经下线的广告，白白浪费资金；再比如商品搜索系统，商家修改价格后要及时反应到索引中，否则用户会感觉搜索结果跟真实商品不一致；
2.索引：批量索引与实时索引
索引指的是是把原始数据更新到索引中去的过程，很多时候并不是原始数据的直接覆盖，而是要在这个过程中去拼接最后的文档。举个例子，电商的搜索会展示商品信息，商品销量，店铺信息等，而这些信息存在于多个业务数据库，所以需要在索引过程中把这些信息拼接起来：
一般情况下，索引需要持续更新，这时便有两种更新方式：
-
批量更新
- 由一个定时调度程序来循环调度，每次读取全量数据，处理完之后也全量更新索引
- 该方案最大的问题是延迟，如果每次全量脚本需要跑N小时，则索引有N小时的延迟
-
实时更新
- 每次变化后及时更新增量信息
很多情况下这两种方式都会存在：定期全量更新，实时增量更新，但两者的协调会是一个很大的问题，需根据业务情况设计：
- 批量和增量分开，可以批量更新时停掉增量更新，也可以同时跑，但这样需要维护两套逻辑
- 全量更新也复用增量更新的逻辑，统一架构
这有点像之前数仓介绍中的Lambda架构与Kappa架构，参考
3.批量与增量整合的实时索引架构
该系统架构如下：
增量部分不变，但全量部分要做修改，定时调度，每次把全量数据导出，并且逐条按照增量的方式发送到消息队列，这就即可复用增量的逻辑。
4.一种实现
我们接下来介绍一种基于云产品的简单实现方案。
该方案的数据流如上图所示：
- 原始数据存在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。
