携程机票日志追踪系统架构演进

作者简介

许鹏，携程高级研发经理，负责机票大数据基础平台的构建和运维。

机票业务看起来简单，实际上整个流程的处理链条很长，调用关系也非常复杂，上下游涉及的各类日志种类约60个，每种日志都有独立格式和请求/响应报文，日生产的日志数据量约50-100亿，如果时间范围再扩大到15天，数据量轻松的达到千亿级以上。

如何在海量的数据中提取想要的数据，这不是一件容易的事情。在大多数情况下，我们需要一种稳定而快速的架构，帮助我们 在资源和性能之间获得平衡 ，于是我们开始了探索之旅。

一、初始架构

1.1    ElasticSearch

首先需要解决存储和查询的问题，海量的数据需要存储起来，供查询使用。如何有效的存储和查询这些日志数据，是系统设计时要回答的首要问题。

日志数据存储的特点和要求：

• 支持海量写入，TPS要能够支撑>50K/s

• 支持灵活的schema

• 支持灵活的数据查询，响应时间要尽可能短，时延<5s

• 对于过期的数据，支持海量删除

按照以上指标，我们对市面上的产品进行摸底和预研，选定了三种存储方式来进行对比：Cassandra、HBase、ElasticSearch。

1.1.1   Cassandra

Cassandra支持海量的数据写入，但是查询字段单一，同时对于数据删除不够友好，不支持行级别的TTL。当有大量的cell过期后，很容易出现TombStone的问题，并且在数据定期清理的过程中，很容易出现数据写入超时等现象。

1.1.2  HBase

1）HBase支持海量数据写入，在过期数据处理层面，不容易产生Cassandra才有的TombStone现象。但在查询接口层面，需要调用api才行，使用难度较高，尽管引入apache phoenix可以通过 SQL 来进行查询，但这增强了系统解决方案的复杂度。

2）HBase对于Row Key的查询能够快速返回，如果变更查询条件，响应会下降非常明显。

1.1.3  Elasticsearch

在排除了Cassandra和HBase之后，开始尝试Elasticsearch，通过研究发现，Elasticsearch可以很好的满足我们的需求：

• 支持灵活的数据结构，支持schemaless

• 可以通过水平扩展来支持海量的数据写入

• 查询方式灵活，响应时间短，平均查询响应低于<1s

• 结合别名和每天创建新索引，可以很好的移除过期数据，同时操作过程对用户透明

1.2    Kafka

Kafka作为消息队列，在存储日志数据的同时，隔离开数据产生的应用和数据处理流程。

1.3    ETL

为了把海量日志从Kafka近实时的导入到Elasticsearch，我们采用spark来进行处理，当前数据导入延迟不超过5s。

1.4    全局ID

每一次用户会话请求会被赋予一个单独的全局ID(TransactionID)，这个全局ID会在各个模块之间的消息传递中出现。通过这样一个全局ID，开发人员可以追踪请求在整个链路中的处理情况。

各开发模块将含有全局ID的日志信息存储到Kafka集群中。

二、架构演进

第一代架构采用Elasticsearch解决了日志存储的问题，单日志查询的表现令人满意。

在实际系统使用过程中发现，由于机票日志种类繁多， 同时对50个以上日志并行查询会导致ElasticSearch集群整体状态变黄甚至变红，集群变的不稳定，整体反应速度变得非常缓慢。

硬件扩容Or提升性能，在架构层次需要进行决策，扩容能够解决一些问题，但是对于携程机票而言，后续还会有更多的日志接入，架构层面必须均衡资源和性能的平衡，而不是单纯的硬件扩容，我们决定在架构层面进一步演进来提升性能。

2.1    增加二级索引

通过分析，发现由于Elasticsearch会保存最近15天的日志，如果针对每一个TransactionID，都去查询15天的所有日志，那么查询响应时间会变得缓慢。

实际上每一个TransactionID不可能都存在于60多种日志中，做了很多多余的查询，如果能够精确的查询就好了。

为了增强查询的精确性，我们采用只对存有TransactionID的索引进行查询，我们建立了二级索引，通过二级索引，可以将TransactionID映射到一到多个具体的Elasticseaerch索引，然后对这些索引发起查询请求，获取详情信息。

也就是说，我们建立了索引，在查询前能准确的知道一个TransactionID在哪些日志、哪些日期中存在。

这样可以准确的查询这些日志，去掉不需要查询的日志。

通过二级索引的设置，查询速度获得很大的提升，由原来的20-30秒提升到5秒以内。

2.2    冷热数据分离

二级索引的建立解决了很大一部分问题，随着而来又产生了新的问题。

每天的二级索引数据量高达5亿条，随着时间推移二级索引数据量迅速增长，查询速度出现了抖动甚至大幅度下降，二级索引本身变成了瓶颈。

对二级索引我们再次做出了优化，对冷热数据进行切割，当天的二级索引会存储到 redis 中，因为系统使用中发现，用户一般对于当天的请求处理情况关注的比较多。Redis可以在5ms以内返回二级索引结果。

对于历史的二级索引，会将信息从Redis导入到Elasticsearch中。

三、小结

目前，机票日志追踪系统仍然在不断的、持续的演进中，比如最新的二级索引中冷数据不再存储到ElasticSearch，而是存储在codis集群中，ETL我们采用更快更好的批量灌入方式等等。

随着大数据技术的不断发展和进步，相信我们的架构也会不断的升级换代，架构的升级必然带来效能的提升，这就是技术的魅力所在。

我们始终相信，架构没有最好，只有更好。

【推荐阅读】

• 一文带你了解携程第四代全链路测试系统

• 如何选出最“美”图片展示给你？携程做了基于深度学习的图像美感评分系统

• 知识图谱在旅游领域有哪些应用 ？

• 携程国际BU的SEO重构实践

• 携程机票如何利用大数据提升测试效果