内容简介：许鹏，携程高级研发经理，负责机票大数据基础平台的构建和运维。机票业务看起来简单，实际上整个流程的处理链条很长，调用关系也非常复杂，上下游涉及的各类日志种类约60个，每种日志都有独立格式和请求/响应报文，日生产的日志数据量约50-100亿，如果时间范围再扩大到15天，数据量轻松的达到千亿级以上。
作者简介
许鹏，携程高级研发经理，负责机票大数据基础平台的构建和运维。
机票业务看起来简单，实际上整个流程的处理链条很长，调用关系也非常复杂，上下游涉及的各类日志种类约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我们采用更快更好的批量灌入方式等等。
随着大数据技术的不断发展和进步，相信我们的架构也会不断的升级换代，架构的升级必然带来效能的提升，这就是技术的魅力所在。
我们始终相信，架构没有最好，只有更好。
【推荐阅读】
以上所述就是小编给大家介绍的《携程机票日志追踪系统架构演进》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Alone Together
Sherry Turkle / Basic Books / 2011-1-11 / USD 28.95
Consider Facebookit’s human contact, only easier to engage with and easier to avoid. Developing technology promises closeness. Sometimes it delivers, but much of our modern life leaves us less connect......一起来看看 《Alone Together》 这本书的介绍吧!
