Elasticsearch大咖说|携程旅行:从日志分析平台到综合性 Elasticsearch 管理平台-阿里云开发者社区

开发者社区> Elasticsearch 技术团队> 正文
登录阅读全文

Elasticsearch大咖说|携程旅行:从日志分析平台到综合性 Elasticsearch 管理平台

简介: Elasticsearch作为一个分布式、高扩展、实时的搜索与数据分析引擎,因其轻量级、稳定、可靠、快速等特性受到越来越多开发者的青睐,在搜索、日志分析、运维监控和安全分析等领域得到广泛应用。阿里云Elasticsearch技术团队,深度采访了来自阿里巴巴、网易、vivo、蚂蚁金服、携程等知名公司的技术专家,推出了Elasticsearch大咖说系列专题,为广大开发者提供技术入门与进阶的经验分享,以及最佳应用实践参考。

如果您想了解更多关于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技术”,随时了解最新资讯;

40cd43a994264b1db3a5dc81dc51a3fb.png

!

往期好文

【最佳实践】这样运用阿里云Elasticsearch,让你的数据库马上拥有强大的数据分析和搜索能力。

从业务需求到能力扩展 | 阿里云Elasticsearch向量检索能力的创变

【技术干货】想要高效采集数据到阿里云Elasticsearch,这些方法你知道吗?

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

Elasticsearch 作为一个分布式、高扩展、实时的搜索与数据分析引擎,因其轻量级、稳定、可靠、快速等特性受到越来越多开发者的青睐,在搜索、日志分析、运维监控和安全分析等领域得到广泛应用。

官方博客
友情链接