干货 | 100亿+数据量，每天50W+查询，携程酒店数据智能平台实践

作者简介

 

岳毅，携程高级研发经理，负责酒店数据智能平台研发，大数据技术创新工作。喜欢探索研究大数据的开源技术框架。

背景

随着大数据不断地融入到工作中，如何使大量的数据资产变现，并提供有价值的见解，通过大量的历史数据和实时数据作为业务工作的参考预测未来，驱动业务的发展，需要统一数据平台来满足用户工作的需求。

 

一、为什么要做？

平台建立之前，我们主要依赖各种不同的数据工具来处理团队数据需求。随着业务的发展，数据在工作中作用越来越大，但不同工具各自独立引起的数据问题也越来越严重。酒店数据智能平台的起源，当时主要从以下几个现实痛点出发：

散：数据分散在不同平台，没有地方可以统一查看所有数据；

杂：不同平台逻辑不同，没有统一评判标准；

浅：数据明细不够直观深入，无法清楚地了解趋势及问题；

慢：查询速度慢，临时取数流程漫长；

晚：当时存在的数据报表平台都无法实现实时的数据监控，对于业务在工作中，特别是订单高峰期库存时刻在变化的时候，不能起到很好的指导和推动作用；

 

下图是平台创建之前的工作方式，不同的部门在很多个数据平台获取各种数据：

下图是平台创建之后，每个部门都用同一份数据，整个平台的各种指标逻辑统一：

平台的创建起步数据引擎采用的是多节点SQL服务器为主，ElasticSearch为辅的方式，但同样遇到了大多数数据平台的通病，数据量太大，数据表多，查询性能差，各种问题防不胜防，主要问题集中在以下几点：

1）数据量日积月累越来越大，哪怕sharding也很难实现到查询秒出，并且硬件成本和程序复杂度都很高；

2）数据查询涉及逻辑复杂，单个SQL往往涉及多个表join，以致SQL执行慢，SQL优化难度大；

3）历史数据更新量大，普通的SQL数据库数据导入都会存在io瓶颈；

4）搜索条件多，汇总维度不固定，导致很多数据无法更进一步汇总；

5）同时在线用户量很高，特别是针对业绩数据，实时订单数据和奖金数据等场景是业务非常关心的，所以这些case的并发量非常高；

6）接口性能不稳定，数据更新时接口性能波动大；

 

二、如何做？

2.1 方案选型

针对上述问题，我们需要解决平台的查询性能，高并发以及每天大量的数据更新时用户端应用的高