Elastic Podcast 第二期来啦, 这一次我们来到了位于上海的携程旅行网，携程内部大量运用了 Elasticsearch来进行集中式的运维日志管理和为业务部门提供统一的搜索服务平台， 目前线上总共部署了多达 94 个 Elasticsearch 集群和超过 700 多个 Elasticsearch 节点，每天新增日志 1600 亿条，峰值达到 300 万每秒，存放在 Elasticsearch里面的索引文档达到 2.5 万亿，磁盘存储达到 PB 级。 想知道携程是如何应对这些海量数据下的挑战，以及最佳实践，让我们一起来收听这一期的 Podcast，跟随携程的两位技术负责人吴晓刚和胡航来一探究竟。

音频地址：http://m.ximalaya.com/111156131/sound/89571047

主持人：Elastic 技术布道师，曾勇（Medcl）。 嘉宾： 1、吴晓刚（Wood大叔），携程技术保障部系统研发总监， Elasticsearch 国内早期实践者，中文社区活跃用户。 曾在 eBay, Morgan Stanley, PPTV 等国内外公司从事系统软件研发、系统集成与技术支持工作。对于大规模 IT 系统的运维自动化、可视化、性能优化具有浓厚的兴趣。在技术方面一直抱有知其然知其所以然的态度。

2、胡航，携程旅行网高级技术经理，负责相关搜索实现、SOA服务的开发。曾供职于腾讯、盛大等公司，对新技术持有强烈的好奇心，目前关注于 Elasticsearch 的业务实现、JVM 性能优化等。

1、携程Elasticsearch使用历史

1.1 运维组Wood大叔：

2014年，ES0.9版本。 选型对比：MongoDB——数据量级大了以后，出现性能瓶颈。 调研后，选型：ELK（Elasticsearch、Logstash、Kibana）。 实现效果：实时看效果、查询、聚合。

1.2 胡航业务组：

业务场景：酒店价格。 选型依据：ES分布式、可调试性能好。 版本：ES2.3。 时间：2017年中，逐步转向ES，5.3版本。 效果：显著。专注于后端开发，业务交由业务团队自己去做。

2、携程Elasticsearch规模

2.1 运维组Wood大叔：

集群：94个。最小三个节点，最大：360+节点。 节点：700+。 每日增量：1600亿条。 峰值：300W/s。 总数据量：2.5万亿，PB数量级。 面对挑战： 1）实时写入。 2）业务流程相关，几个月-2年的历史数据。

2.2 胡航业务组：

业务场景：3集群，每集群6个节点。 单个索引：最大1000W-2000W。

关注：ES基础框架，帮业务部分实现写入、查询、DSL调优。 查询：3000-4000/s。

携程ES规模量全国数一数二，有很大挑战。

3、携程Elasticsearch淌过的坑

3.1 运维组Wood大叔：

3.1.1 痛点1：内存溢出。

原因：早期版本，对查询限制做的不充分；数据量上了规模，查询、聚合会非常耗内存。

升级版本后，ES做了很多处理，集群层面做了限制。越来越稳定。

3.1.2 痛点2：集群故障无法恢复。

3.1.3 痛点3：translog做不完。

3.1.4 痛点4：集群的平台化管理。

需要：研究底层工作机制，找到规避方法。 经验丰富后，运维效率提升。

3.2胡航业务组：

3.2.1 痛点1：ES基础不熟悉带来的问题；

3.2.2 痛点2：性能问题——最终排查是ES5.X keyword类型的原因。

4、架构

4.1运维组Wood大叔：

1、早期：ELK+redis（中间缓存）

挑战： 1）redis承受能力差。

2）redis单线程。

改善： 1）redis改为kafka（磁盘级别），数据畅通了。

2）Logstash内存消耗大。——改为：logstash forward，推荐官方Beats。

3）数据规模后，需要很多服务器，Logstash非常耗内存。

优化：用golang开发了一个gohangout (https://github.com/childe/gohangout ) ，

内存比java 版的hangout(https://github.com/childe/hangout) 内存大幅降低。

4.2 胡航搜索业务组：

1）单点集群压力瓶颈。

改为：业务数据导入ES，提供定制客户端。

2）搜索平台，接入更多业务需求。

不方便在kibana做定制开发，自己做了简单网站查询数据、监控，满足业务的贴切需求。

5、ES6.3最新特性（抢先看）

5.1 ES6.3 支持Sql接口

Wood大叔： kibana看DSL，拷贝后修改。新用户不熟悉，会不方便。

BI部分也需要，类似sql的查询。

优点：更简单，发挥更大的作用。

携程BI部门——应用场景：搜索的关键词、 统计热词，目的地等信息。

Kibana满足不了需求，就要写代码。如果有了sql，会非常快的开发。

胡航搜索业务组： 写DSL，还是稍微复杂。借助 NLPChina ElasticsearchSql插件实现。

实际应用发现插件还是有问题，期待ES官方推出Sql查询。

5.2 增加kibana丰富表现力

5.3 更快的索引速度

refresh优化：提升吞吐。

6、ELK Stack最喜欢的特性

Wood大叔： 丰富的扩展能力，用户不必关心底层的实现。通过服务器增加节点，方便大数据量查询。

胡航： ES可视化、可调试特性。 举例： 1）出现问题排查DSL是不是合适？Mapping是不是合适？

2）相信ES的社区，不必关心底层，更多的时间做业务（解放双手）。

3）ES中做好数据模型，实现业务需求。

7、ELK Stack最需要完善的

Wood大叔： 1）集群的保护待更进一步完善 数据丢失后的处理？

节点损毁后的处理？

目的：减轻运维的负担；

2）甄别坏查询，Slow log存在缺陷。 很难判定真正故障是哪个慢查询。

集群发下故障的时候，有API实时分析会更好（比单纯查slow log）。

胡航： 1）ES坑还很多，比较耗费时间。

2）期待社区对常见问题整理。

3）期待官方总结完善的向导，类似：Cookbook。

初级上手的话可以参考借鉴（大家缺乏经验）

8、初学者的建议

1）初学者必读——《Elasticsearch: 权威指南》（英文、中文） WOOD大叔至少看了3遍。

2）不断的实践。

3）带着问题，再去找文档，构建知识体系。

4）多参与社区，尝试理解和解决社区问题，不断学习，以提升自己。 互帮互助，共同成长！

5）中文社区的小建议：问题精华版收集——新手通读，学习前人经验。

9、如何看待Elasticsearch在国内的发展？

1）参与和贡献，国内做的不足；

2）中文分词插件等，如：分词质量要求高，专业语义搜索支持（提高搜索相关性等）、情感标注、NLP等。

3）在中文应用场景应用更加丰富。

4）社区问题比较分散，社区需要意见领袖，加强某领域讨论、深入交流等。

5）medcl：ElasticTips成立，大家都去参与，以图片形式分享。

6) 社区还会做更多的事情，大家多分享、互相交流。

10、小结

非常震惊，wood大叔看了3遍《Elasticsearch: 权威指南》，我们没有理由不努力。

共勉，加油！