如果您想了解更多关于Elasticsearch中国开发者，请点击下载《Elasticsearch 中国开发者调查报告》，探索开发者的现状和未来
第一期分享嘉宾
吴晓刚
携程旅行网 系统研发总监
携程旅行是国内领先的在线旅游网站，主营业务是机票酒店和旅游度假产品的在线预订。目前ES平台，不仅是携程日志分析的集中平台，也应用在很多其他垂直搜索业务中，很好地解决了搜索的数据规模化等问题。自2012年引入ELK技术栈以来，携程的Elasticsearch集群已发展到300多个，并积累了大量的运维经验。
一、ES技术指南
话题1:如何学习ES及相关技术栈的知识？有什么样的学习资源推荐？
初级阶段
对于新手入门最浅显易懂的，还是官方那本Elasticsearch权威指南，而且中文社区的热心网友已经将其翻译成中文版。对于国内的用户来说，这本书基于是ES2.0版本的，但对新手快速了解Elasticsearch的全貌，有非常大的帮助作用。
Elasticsearch是基于Lucene的，所以如果想深入了解底层技术的同学，有必要去学习Lucene的底层运作原理。这方面我推荐的书籍是《Lucene in Action》。
进阶阶段
对ES有一定基础，还需要了解ES内核细节的同学，推荐阅读中文社区大牛张超撰写的《Elasticsearch源码解析与优化实战》。
另外，可以经常关注阿里云同学在知乎上开设Elasticsearch内核技术专栏，里面有不少讨论ES内核技术内容。
最后，需要强调的是，只是阅读书籍和技术文章是远远不够的，因为ES里面有很多非常复杂的理论和知识，所以我们应该在实际工作中通过实践去加深理解。如果你的项目中有ES的应用需求，就应该尽早地在项目中去尝试使用。很显然，你会在初期使用中踩到很多很多的坑，但是好处是，你带着这些问题，再去进行发散性的学习，进步会更快。
话题2:ES开发者除了掌握ELK相关技术栈知识外，还需要了解哪些领域的知识？
我认为这主要取决于ES开发者在哪一种业务场景下工作。
比如ES应用在搜索领域，目前ES对中文分词器支持还不太友好，打分算法也难以满足复杂的业务需求，这就需要ES开发者掌握自然语言处理相关知识，还需要深入学习Lucene和Elasticsearch内部的打分机制。结合具体的业务场景，开发者还需要做一些分词插件或打分插件的开发。
还有一类应用场景，即开发者将ES用在数据分析领域，那么他就需要学习大数据生态下的其他技术，比如传统的Hadoop以及时下流行的Spark和Flink等等。通常情况下，没有一种单一系统能满足所有数据分析场景需求。
在架构方面，我们通常需要综合多种技术，通过一些数据管道上的建设，将数据在不同系统之间打通，结合流式计算、批量计算或者全文索引等组件，构建比较完备的数据平台。
除此之外，玩大数据的同学，还需要掌握机器学习等相关技术，这样可以针对存储在ES中的数据，进行预测分析和异常检测。
另外还有一类ES开发者专注在ES基础平台构建方面，他们通常需要深入了解JVM内部原理、Linux等操作系统工作原理，以及Docker、Kubernetes等平台技术。如果想把ES更好地平台化，就需要对这些云计算相关技术有更好的掌握。
二、ES从业者的职业发展
话题3:对ES开发者技术发展方向的看法
Elasticsearch 在分布式搜索、实时数据分析、监控和安全等领域有非常多的成 功案例。近两年来，国内各大公司基于 Elasticsearch 开发出商业化产品或内部 技术平台数不胜数，也越来越成熟。在未来几年 Elastic Stack 也会像目前流行的 Flink 和 Kubernetes 等技术一样，加速发展，应用范围会越来越广。我已经能感 受到，相关技术的架构、咨询、开发及运维人员在人力资源市场上的需求正变得 越来越旺盛。
三、ES应用实践
话题4:所在团队业务背景介绍
携程旅行是国内领先的在线旅游网站，主营业务是机票酒店和旅游度假产品的在线预订。我主要负责网站工具和内部信息系统研发以及公司IT部门的日常运作。在ES这部分，主要负责工具研发。
在早期的时候，我们公司的网站每天会产生大量监控数据和日志数据，但缺乏很好的收集和分析手段。大约从2012年开始，经过调研，我们发现在国外比较活跃的ELK技术栈能够实现这些功能，因此，我们把他引入到携程。然后经过这么多年的不断发展，目前ES平台，不仅是携程日志分析的集中平台，也有大量的其他业务在使用。比如在搜索方面，可以很好地解决搜索的数据规模化问题，并支持灵活定制，因此在过去几年在携程的垂直搜索业务领域也得到越来越多的应用。目前我们的Elasticsearch集群，已经发展到300多个，运维问题变得至关重要。而我们团队在运维方面拥有较多经验，所以我组建了两到三人的ES运维专家组，负责整个携程ES集群的管理平台开发和所有线上300多个集群的运维和技术咨询工作。
话题5:平台现状以及未来发展方向
我们的ES集群管理平台主要功能还是聚焦在集群的监控、运维元数据管理等方面。但集群本身还是跑在物理机和虚拟机上面，通过Ansible做集中控制，在集群交付速度、扩缩容弹性、规范化治理、问题自动化诊断等方面还有相当的不足。近期ES团队加深了和公司云计算团队的合作，正在基于Docker/K8s开发下一代的ES PAAS平台。
另外一些头部互联网公司已经在尝试基于ES做搜索中台，对上层的业务和数据分析系统的开发者屏蔽掉ES底层的复杂性，让搜索应用的开发进一步简化，我想这也是我们未来要努力的方向。
话题6:ES在安全领域的应用
携程安全团队在安全数据收集和分析时大量应用到ES，比如通过FileBeat收集安全数据，通过MetricBeat收集性能指标，然后写入到ES里面，一方面通过Kibana去做数据可视化，另一方面在ES的API基础上，会做一些数据异常检测的规则。我们基于ELK不同的产品，陆续做了很多小工具。我们看到Elastic官方现在基于ELK推出了SIEM整体方案，这是一个很好的思路，从数据收集、实时索引、到关联分析，以及机器学习等商业化组件，在安全领域系统性提出了解决方案，为安全开发人员降低了开发应用的难度。
话题7:ECS（Elastic Common Schema）和日志规范
ECS这样的日志规范是非常有必要的。不同来源不同类型的日志，需要通过ECS去规范，后续才有可能进行关联分析。前段时间，在参与我们公司新安全产品的开发过程中，我做了关于ECS的布道，希望可以参照ECS的方式，对日志进行schema的规范化定义。
话题8:携程数据采集的现状如何？
因为历史遗留问题，数据采集在携程有自己的特点。基于文件的系统级数据，特别是日志数据采集，目前是由平台方去统一提供的，早期是自行开发的agent，现在已经全面参照Elastic官方的采集组件进行收集，比如Filebeat收集文件日志，Winlogbeat收集Windows日志等等。在应用日志的收集方面，为减轻业务方的改动负担，沿用了原有日志收集SDK，我们增加了数据通道，再转运到ES中。
话题9: 日志平台的数据治理问题
日志平台存在的最大痛点还是数据治理问题。ELK 做为数据平台，是缺乏数据治理 能力的。当上线初期，数据规模还不是很大的时候，数据治理这方面需求还不是很 迫切。随着业务发展，接入的日志类型和数据增量快速增加，数据治理的痛点就会 逐步凸显。通常 Kibana 无法满足用户所有个性化的数据可视化需求，所以我们还 开放了 API 接口给业务方获取数据，去做个性化的分析。API 接口一旦开放，当数 据规模达到一定程度，查询、聚合或写入等操作不当的话，经常会对集群性能和稳 定性造成较大影响。这些问题都需要通过数据治理的方式来解决。所以，我们在日志平台的基础上做一些日志数据治理工作，比如标准化规范化数据获取方式。
四、ES技术前瞻
话题10:对于ES作为NoSQL数据库替代方案的看法
ES现在有一个逐渐兴起的应用方向，作为NoSQL数据库来使用。针对那些关系型数据库跑起来比较费力的复杂条件组合，而且不太需要事务性要求的场景，传统的做法是使用关系型数据库，为了解决海量数据查询慢的问题，往往会分表分库，并配合Redis缓存，整个架构上比较复杂，可靠性也会存在挑战。现在利用Elasticsearch的倒排索引和数值过滤，可以灵活实现复杂的条件组合查询，查询速度也非常快。而且ES内部不同类型的cache效率很高，一定程度上减少了对其他外部cache的依赖。所以，ES未来可能成为一种非常优秀的NoSQL数据库。
但在这之前，ES有三个问题需要去解决：
第一个问题是数据可靠性问题。虽然我知道官方有文档去追踪数据一致性方面的问题，随着ES版本的迭代，以我自己实践经验来看，已经很少出现丢数据的问题。但是从理论上来说依然存在数据一致性问题，它毕竟不像mysql是多年理论和实践验证下来的非常可靠的数据库。ES需要在特别极端的情况下，如某些节点丢失，恢复的过程中，验证它的数据可靠性。
第二个需要解决的问题，作为NoSQL数据库，ES的数据插入性能相对比较弱，这是和它底层实现是基于Lucene这样的搜索引擎有关系，数据写入的时候，要做非常多的索引结构。
第三个问题在于数据更新，与传统NoSQL数据库的数据更新较小的开销相比，ES的更新是先把原始数据读出来，改好后再写回去，对于比较大的文档，ES的开销是非常大的。
这几点都会是阻碍ES成为一款高性能NoSQL数据库的因素，不过随着官方功能迭代，ES在某些场景会成为NoSQL数据库的一种替代选择。
话题11:ES在监控运维领域的发展趋势
我觉得Elasticsearch未来可能成为整个监控运维领域的事实标准。在监控领域，一般包含三类数据的收集和分析：性能数据（Metrics）、日志数据（Logs）、应用调用链数据（Trace）。以往，大家在这三个方面都是使用不同产品去做的。比如性能指标数据，传统行业使用Zabbix比较多，互联网使用新兴的Prometheus、OpenFalon等。而日志方面，又自成一体，大家有不同的方案，比如商业产品Splunk、开源ELK。APM工具更是百花齐放。这三个工具一般情况下割裂开来的，而实际上，我们线上运维通常希望这几个工具是结合起来使用的。
Elastic有个比较好的思路，借助ECS（Elastic Common Schema）等规范化工具，将性能数据（Metrics）、日志数据（Logs）、应用调用链数据（Trace）三类数据标准化，整合到一起，成为一体化的工具。在问题排查的过程中，运维工程师可以非常自然地在不同数据之间进行跳转和关联分析。目前Elastic已经陆续推出了Metrics、APM等方案，但他可能要解决的主要问题还是底层存储的成本问题，对于海量metric和trace数据，存储代价还是很高的。当然Elastic也作出了努力，比如针对metrics推出了rollup功能，类似准实时的流式计算，当数据进来的时候可以通过制定规则，删除实时把数据做聚合后再存储，以减少存储开销。当未来Elastic能够较好地解决数据存储成本问题后，可能成为一款优秀的一体化监控运维产品。另外，Elastic引入了机器学习，对监控数据做智能化的异常检测和预测，顺应了监控报警系统AI化的趋势。
加入我们
钉钉扫码，加入“Elasticsearch技术交流群”，与更多开发者技术交流；
微信关注公众号“Elasticsearch技术”，随时了解最新资讯；
往期好文
【最佳实践】这样运用阿里云Elasticsearch，让你的数据库马上拥有强大的数据分析和搜索能力。
