elasticsearch应用场景总结(持续更新)

搜索引擎有哪些功能

探索海量结构化、非结构化数据，按需创建可视化报表，对监控数据设置报警阈值，甚至通过使用机器学习技术，自动识别异常状况。
被广泛运用在大数据近实时分析领域，包括日志分析、指标监控、信息安全等多个领域
开源搜索引擎 Apache Solr 和 Elastic Search。

搜索引擎应用实例

京东

Elasticsearch 做为一款功能强大的分布式搜索引擎，支持近实时的存储、搜索数据，在京东到家订单系统中发挥着巨大作用，目前订单中心ES集群存储数据量达到10亿个文档，日均查询量达到5亿。

使用分片的方式(类似于数据库的分库分表)来增加查询的吞吐量，然后由搜索引擎来快速查询数据

携程

1. 携程酒店订单Elasticsearch实战
   选择对分片后的数据库建立实时索引，把查询收口到一个独立的 Web Service，在保证性能的前提下，提升业务应用查询时的便捷性。

最终我们选择了 Elasticsearch，看中的是它的轻量级、易用和对分布式更好的支持，整个安装包也只有几十兆。

http://developer.51cto.com/art/201807/579354.htm

2. 携程机票ElasticSearch集群运维驯服记

这个是比较通用的数据的流程，一般会通过Kafka分离产生数据的应用程序和后面的平台，通过ETL落到不同的地方，按照优先级和冷热程度采取不同的存储方式。

一般来说，冷数据存放到HDFS，如果温数据、或者热数据会采用Database以及Cache。一旦数据落地，我们会做两方面的应用

第一个方面的应用是传统BI，比如会产生各种各样的报表，报表的受众是更高的决策层和管理层，他们看了之后，会有相应的业务调整和更高层面的规划或转变。

这个使用路径比较传统的，在数据仓库时代就已经存在了。现在有一种新兴的场景就是利用大数据进行快速决策，数据不是喂给人的，数据分析结果由程序来消费，其实是再次的反馈到数据源头即应用程序中，让他们基于快速分析后的结果，调整已有策略，这样就形成了一个数据使用的循环。

这样我们从它的输入到输出会形成一种闭环，而且这个闭环全部是机器参与的，这也是为什么去研究这种大规模的，或者快速决策的原因所在。

如果数据最终还会给人本身来看的话，就没有必要更新那么快，因为一秒钟刷新一次或者10秒钟刷新一次对人是没有意义的，因为我们脑子不可能一直转那么快，基于数据一直的做调整也是不现实的，但是对机器来讲，就完全没有问题。

http://www.sohu.com/a/199672012_411876

3. 携程：大规模 Elasticsearch 集群管理心得
   目前，我们最大的日志单集群有120个data node，运行于70台物理服务器上。数据规模如下:

单日索引数据条数600亿，新增索引文件25TB (含一个复制片则为50TB)

业务高峰期峰值索引速率维持在百万条/秒

历史数据保留时长根据业务需求制定，从10天 - 90天不等

集群共3441个索引、17000个分片、数据总量约9300亿, 磁盘总消耗1PB

https://www.jianshu.com/p/6470754b8248

去哪儿：

订单中心基于elasticsearch 的解决方案

Elasticsearch分布式搜索储存集群的引入，就是为了解决订单数据的存储与搜索的问题。

https://elasticsearch.cn/article/6197

四、Elasticsearch 在58集团信息安全部的应用

全面介绍 Elastic Stack 在58集团信息安全部的落地，升级，优化以及应用。

包括如下几个方面：接入背景，存储选型，性能挑战，master node以及data node优化，安全实践，高吞吐量以及低延迟搜索优化；kibana 的落地，本地化使其更方便产品、运营使用。

https://elasticsearch.cn/slides/124

五、滴滴Elasticsearch多集群架构实践
滴滴 2016 年初开始构建 Elasticsearch 平台，如今已经发展到超过 3500+ Elasticsearch 实例，超过 5PB 的数据存储，峰值写入 tps 超过了 2000w/s 的超大规模。

Elasticsearch 在滴滴有着非常丰富的使用场景，例如线上核心的打车地图搜索，客服、运营的多维度查询，滴滴日志服务等近千个平台用户。

先看看滴滴 Elasticsearch 单集群的架构：滴滴在单集群架构的时候，写入和查询就已经通过 Sink 服务和 Gateway 服务管控起来。

1. Sink服务
   滴滴几乎所有写入 Elasticsearch 的数据都是经由 kafka 消费入到 Elasticsearch。kafka 的数据包括业务 log 数据、mysql binlog 数据和业务自主上报的数据，Sink 服务将这些数据实时消费入到 Elasticsearch。

最初设计 Sink 服务是想对写入 Elasticsearch 集群进行管控，保护 Elasticsearch 集群，防止海量的数据写入拖垮 Elasticsearch，之后我们也一直沿用了 Sink 服务，并将该服务从 Elasticsearch 平台分离出去，成立滴滴 Sink 数据投递平台，可以从 kafka 或者 MQ 实时同步数据到 Elasticsearch、HDFS、Ceph 等多个存储服务。

有了多集群架构后，Elasticsearch 平台可以消费一份 MQ 数据写入多个 Elasticsearch 集群，做到集群级别的容灾，还能通过 MQ 回溯数据进行故障恢复。

2. Gateway 服务
   所有业务的查询都是经过 Gateway 服务，Gateway 服务实现了 Elasticsearch 的 http restful 和 tcp 协议，业务方可以通过 Elasticsearch 各语言版本的 sdk 直接访问 Gateway 服务

Gateway 服务还实现了 SQL 接口，业务方可以直接使用 SQL 访问 Elasticsearch 平台。

Gateway 服务最初提供了应用权限的管控，访问记录，限流、降级等基本能力，后面随着平台演进，Gateway 服务还提供了索引存储分离、DSL 级别的限流、多集群灾备等能力。

https://mp.weixin.qq.com/s/K44-L0rclaIM40hma55pPQ

六、Elasticsearch实用化订单搜索方案
搜索引擎中，主要考虑到Elasticsearch支持结构化数据查询以及支持实时频繁更新特性，传统订单查询报表的痛点，以及Elasticsearch能够帮助解决的问题。

订单搜索系统架构
整个业务线使用服务化方式，Elasticsearch集群和数据库分库，作为数据源被订单服务系统封装为对外统一接口；各前、后台应用和报表中心，使用服务化的方式获取订单数据。

参考：https://my.oschina.net/u/2485991/blog/533163

搜索引擎应用方向概括

链接: 微信原文链接.