ES+HBase【案例】仿百度搜索02：项目架构设计

一、项目概览

二、项目整体架构流程

1：项目的数据来源可以是通过爬虫到互联网上采集的数据，也可以是企业数据库中的内部数据
2：根据数据的来源不同，使用不同的程序将数据入库到HBase，实现海量数据存储
3：针对HBase中的数据在ES中建立索引。

注意：并不是把HBase中数据的完整内容全部在ES中建立索引，只需要将检索用到的那些字段在ES中建立索引即可。例如：HBase存储的原始数据有20个字段，在ES可能只需要存储5个字段即可，具体的存储细节在后面会详细分析。

4：在数据展现模块中提供仿百度搜索功能。

三、ES和HBase数据同步的三种方案

针对此项目，有一个核心功能点，如何在ES中同步对HBase中的数据建立索引？
大致有下面这几种方案：

1：方案1

在将原始数据入库HBase的时候，同时在ES中对数据建立索引，此时可以把入库HBase和ES的代码放在一个事务中，保证HBase和ES的数据一致性。

这种方案的优点是操作方便，缺点是入库HBase和ES的代码绑定到一起了，耦合性太高，如果遇到ES出现故障，会导致入库HBase的操作也会失败，或者是ES集群压力过大的时候，会导致数据入库HBase的效率降低。

2、方案二

在将原始数据入库HBase的时候，通过HBase中的协处理器实现数据同步，让协处理器监听HBase中的新增和删除操作，在协处理器内部操作ES，实现对数据建立索引的功能。
HBase中的协处理器其实类似于MySQL中的触发器。

这种方案的优点是通过协处理器可以很方便的获取到HBase中新增和变化的数据，如果入库HBase的程序是之前已经开发好的，此时不需要对之前的代码进行任何改动，影响程度比较低。缺点是过于依赖HBase了，如果后期涉及到HBase集群版本升级，无法保证协处理器功能的可用性。

3、方案3

在将原始数据入库HBase的时候，同时在Redis中使用list数据类型模拟一个队列，存储数据的Rowkey。此时将入库HBase和Redis的操作放在一个事务里面，保证数据的一致性。然后再通过另外一个同步程序，从Redis的list队列中读取Rowkey，根据Rowkey到HBase中获取数据的详细信息，在ES中建立索引，将HBase中数据的Rowkey作为ES中数据的ID。

在这个方案里面是将入库HBase和在ES中建立索引这两个功能解耦了，借助于中间层的Redis实现的。
这种方案的缺点是把入库HBase和Redis的功能耦合在一起了，但是Redis是轻量级的，出现问题的概率是比较低的，对性能损耗也不高，所以是可以接受的。
此时就算ES出现问题，只需要在同步程序内部实现正常的异常处理即可，将建立索引失败数据的Rowkey重新添加到Redis的list列表里面即可，不会导致HBase和ES数据不一致的问题。

其实第2种方案和第3种方案都可以使用，个人推荐使用第3种方案，可控性高一些，在项目中也会使用第3种方案实现。

四、项目整体执行流程

接下来分析一下项目底层细节流程
如下图所示

1：通过入库程序向HBase中入库数据，同时在Redis中存储数据的Rowkey。

2：从Redis中获取数据的Rowkey，根据Rowkey到HBase中查询数据的详细信息，然后在ES中建立索引。
此时我们的海量数据已经存储到HBase中，并且将需要查询的字段在ES中建立索引了。

3：用户向ES发送查询请求。

4：ES返回符合条件的数据的ID，其实就是HBase中数据的Rowkey。在这里也可以根据需求额外再返回一些字段信息都是可以的。

5：当用户想要查看数据完整详细信息的时候，需要根据Rowkey到HBase中查询。

6：HBase会给用户返回Rowkey对应数据的详细信息。