“月上柳梢头，人约黄昏后”，诗人对于爱情的表达多么婉约含蓄啊！想必很多人都钟爱古诗词，从先贤的言语中读懂很多思想情怀。倘若让你此时来接一句带“月”字的诗词，你会想到哪些？

这让我忽地想起，近些年春节期间央视热播的《中国诗词大会》的飞花令环节。我们绞尽脑汁在瞬间能飞出来带“月”的诗词极其有限，但静下心来仔细梳理一下，受教育这么多年，脑海里储存的相关的诗词还真不少。

“窗前明月光，疑是地上霜”

“人有悲欢离合，月有阴晴圆缺”

“明月松间照，清泉石上流”

“举杯邀明月，对影成三人”

这里就不再过多列举，有兴趣的话，大家可以在评论区飞花传令。那为什么学了那么多，却突然间想不起来呢，这其实与人脑储存、搜索知识的方式是有关系的。那么，接下来本文的作者将从名为“洞天”的数据产品的开发实践为切入点，带你了解分布式搜索分析引擎-Elastic search，是如何实现快速飞花的！

1、 背景介绍

在银行金融机构的对公作业中，公司客户经理长期面临着获客困难，难以挖掘高意向度的营销目标的问题。基于充分的同业研究，结合目前互联网营销的常用策略，在充分保护客户信息安全的前提下，可结合适当的数据分析获客的同时，进而为客户提供更精准、更深度的服务。

基于此种情况，我们重点考虑通过对存量客户的转账数据进行分析，这样可以在存量客户的交易对手中，对未与公司发生业务关系的进行营销;亦可以对存在以下行为的存量客户进行营销，如：存量客户将账户余额大量转入同名的非我公司账户中，存量客户的主结算账户非我公司账户等。

借助已有的客情关系，结合客户的实际经营，通过合理的方式方法对客户进行适度营销，在提升公司业务规模的同时，也起到了深入服务客户的作用，增加了与客户之间的粘性;

但要执行以上营销策略，需要专业的会计人员对数据进行整理，然后进行汇总，排序，每次至少半个小时，这个过程存在以下痛点：

• 整理时间太长

• 整理出的结果无法支持多维聚合

• 无法对交易对手再次进行多维筛选

• 深入下钻查看比较麻烦

为此，我们项目组成员决定在对公业务支持平台“洞天”上，利用行内交易流水数据做一个新的分析场景——转账分析。

经过初步的需求挖掘分析与调研，发现在近亿条数据中实现筛选、排序是比较困难的。而数据不经过聚合使用效率将会大大降低，我们决定一定要实现多维聚合，结合多维筛选与多维排序，在聚合的同时实现数据下钻，考虑需求场景化的同时增加平台的通用性。在此基础上，还要有足够快的速度，我们希望能够在2秒内展示最终结果，给用户更好的使用体验。

以上过程的实现，要求平台拥有出色的数据搜索与分析能力，团队人员经过技术预研与选型后，最终决定使用分布式可扩展的实施搜索和分析引擎Elastic search。

2、 选型与使用

项目启动伊始，项目组就遇到了数据分析类产品常见的困难：超大数据量支持多种实时检索，兼顾高并发，高可用、响应迅速。若使用传统数据库对大数据量进行检索和汇总排序，会面临响应速度慢，查询方式少等问题，且随着数据量增加，性能、稳定性急剧下降。

为此，项目组决定深度使用Elastic search，来支持客户、转账等数据的实时检索分析。因为其十分适合进行复杂条件查询，是业界主流的复杂条件查询场景解决方案，广泛应用于订单和日志查询等场景。

确定技术选型后，我们申请使用了公司数据平台组维护的Elastic search集群，申请到的资源有3台服务器，提供了可视化管理页面与监控页面。由于客户信息数量高达几百万，转账数据高达上千万，从传统数据库导入Elastic search是一个关键问题。项目组考察了多种导入方式，包括：官方提供的客户端、国内厂家的bboss同步工具、logstash增量查询导入等。

通过在测试环境，对建立的500万条数据进行测试，经过一周时间，多次对比验证测试，bboss相比其他两种方式，更高效、安全、可靠。为了保证数据的实时性，采用定时器每天轮询增量导入数据。

使用Elastic search后，用户可以在洞天首页，对客户实时模糊搜索并高亮显示搜索内容，并对高达千万级转账数据，实现秒级汇总排序。经过半年投产使用，ES完全可以对洞天日益增长的数据进行支撑。

3、Elastic search原理

相比传统数据库，es为何会有这样的表现呢?接下来一起来看下Elastic search的基础介绍及其原理。

为了便于理解，我们先将 ElasticSearch 中的概念和传统关系型数据库中的概念大致地进行对应。

用户查询是在index上完成的，每个index由若干个shard组成，以此来达到分布式可扩展的能力。比如下图是一个由10个shard组成的index。

Elasticsearch 使用 Lucene 作为其全文搜索引擎，用于处理纯文本的数据，一个shard就对应了一个lucene的library。Lucene 提供建立索引、执行搜索等接口，而ES提供分布式服务。ES采用分布式集群，将索引拆分成多个分片，每个分片有多个副本，ES会把查询发送给每个相关分片，将结果组合进行一系列运算;

面对多个分片，Elasticsearch 会通过固定算法决定数据存入哪个分片：这也是为什么我们要在创建索引的时候就确定好主分片的数量，因为如果数量变化了，那么所有之前路由的值都会无效。当然，重建索引可以帮助你解决大部分的索引变更问题。每个节点都知道集群中任一文档位置，所以可以直接将请求转发到需要的节点上，一开始进来访问任意一个节点，这个节点知道位置后，会作为协调节点转发请求到对应的节点上。分布式服务保证了ES的高容错性与快速扩展。

ES通过建立倒排索引，进而实现快速的全文搜索。一个倒排索引由文档中所有不重复词的列表构成，对于其中每个词，有一个包含它的文档列表。为了创建倒排索引，我们首先将每个文档的指定filed拆分成单独的词，创建一个包含所有不重复词条的排序列表，然后列出每个词条出现在哪个文档。例如：

Doc1.The quick brown fox jumped over the lazy dog

Doc2.Quick brown foxes leap over lazy dogs in summer

建议的倒排索引如下：

接下来，如果我们想搜索 quick brown ，我们只需要查找倒排索引即可快速定位：

基于以上各种特性，ES的能力得以发挥，但它也不是事事全能：在事务处理方面，传统数据库依然优势明显，所以两类数据库在交易及分析领域各自发挥重要作用。

4、ES使用心得

使用好ES，也需要注意一些技巧。在关系型数据库中，经常有一些复杂的关联查询。但在es 里面，复杂的关联查询尽量别用，一旦用了性能一般都不太好。最好是先在 Java 系统里就完成关联，将关联好的数据直接写入 ES 中。document 模型设计是非常重要的，在模型设计的时候，应将查询用到的字段全量写入。另外对于一些太复杂的操作，比如 join/nested/parent-child 搜索都要尽量避免，免得出现性能问题。

当然，存入所有字段，有优点也有缺点。优点是一次查询所有信息，不需要再查询别的数据源。缺点是存入的大量字段是不用来搜索的，结果会占据 ES 机器上的 filesystem cache 的空间，单条数据的数据量越大，就会导致 filesystem cahce 能缓存的数据就越少。而ES 的搜索引擎严重依赖于底层的 filesystem cache，如果给 filesystem cache 更多的内存，尽量让内存可以容纳所有的索引数据文件，那么搜索的时候就基本都是走内存的，性能会非常高。事实上，ES 中仅仅写入要用来检索的少数几个字段就可以了，可以把其他的字段数据存在关系型数据库或hbase里，这样虽然会增加访问数据源次数，但可以完全发挥ES的性能优势，在数据量达到几十上百亿时有明显的效果。

另外在分页问题上，ES集群的分页查询支持from和size参数，查询的时候，每个分片必须构造一个长度为from+size的优先队列，然后回传到网关节点，网关节点再对这些优先队列进行排序找到正确的size个文档。由此可见，当from足够大的时候，就算不发生OOM，也会影响到CPU和带宽等，从而影响到整个集群的性能。所以应该避免深分页查询，尽量不去使用。

通过对ES的学习与使用，对ES的特点与应用可以概括如下：

• 倒排索引，是根据文章内容中的关键字建立索引

• 搜索引擎原理就是建立倒排索引

• Elasticsearch 在 Lucene 的基础上进行封装，实现了分布式搜索引擎

• Elasticsearch 中的索引、类型和文档的概念比较重要，类似于 MySQL 中的数据库、表和行

• Elasticsearch 也是 Master-slave 架构，也实现了数据的分片和备份

• Elasticsearch 典型应用场景是：ELK 日志分析系统、数据聚合分析、业务内搜索

5、未来展望

在很多业务场景中都有对现有数据进行聚合、筛选、排序的，从海量数据中找到自己需要的精准的那部分。传统的关系型数据库在处理大量数据的时候就会容易遇到响应速度慢的问题，而ES给我们提供了一种新的可能。

洞天对ES的使用尚处在初级阶段，未来势必会在数据预热、document模型设计、分页性能优化上下更多功夫。如此才能基于更大的数据量，服务好对公业务，为数字化转型贡献力量。

最后给大家一个小福利：公众号“数据社”后台回复“资料”，即可直接下载！

欢迎大家加我微信好友，交个朋友，有需要的可以拉你进大数据交流群!

历史好文推荐