实时离线一体化在资产租赁saas服务中使用 (2)

                                 （网络图）

查询引擎—实现秒级响应—Presto

不依赖hive元数据服务，部署简单。在sql语法方面，虽然存在小部分与标准相违背(如：分页需要 ORDER BY、时间比较需要用TIMESTAMP先转换等)，但整体支持标准sql度极高。这对于当前业务系统改动成本小。业务接入时，除了部分sql在性能上需要做优化外，只需要配置多个JDBC数据源即可。这只是理想状态，由于整个业务系统使用的是msyql数据库，所以慢长的开发过程中，难免会用到mysql特有的语法，这就造成更麻烦的sql兼容问题。在这方面，我们选择对官方提供的presto-jdbc做二开，使其尽可能多的支持mysql语法，如group by、时间大小比较等。

扩大业务覆盖率

由最初的帐单明细查询，发展成整个平台通用的即时查询系统。所有涉及OLAP查询，TB级以上的数据都接入了即时查询系统。服务部署也由原来的十几个节点，发展到了三十多个节点。

部署配置  
服务名称   节点数   配置  
Confluent Platform   7   32核64g  
Kudu   11   32核64g  
Presto   15   32核64g  
Zeppelin   1   6核32g  
大数据需求

需求第二期：

在资产租赁管理服务中，除了要了解客户投诉情况、满意度调查、水电使用情况、设备故障等统计分析之外，还需要帮客户做租赁业务的精准营销，网络爬取提供竞品分析数据，指导客户业务决策。

实时离线一体化系统之技术架构

 

实时离线一体化系统之数据流

实时离线一体化接入

大数据的来源主要分为三个：

第一个来源是内部系统的Mysql数据库(业务分析)

第二个来源是应用App(用户轨迹)

第三个来源是外部系统网络采集(同行数据,用于竞品分析,行业分析)

日志文件(业务访问、打印在日志文件上的业务数据)

有些实时数据，只需简单的清洗就可以产出，比如：异构数据同步、上面讲到的即时查询系统等这类数据是不需要进入ODS层的。为了能跟即时查询系统的接入统一化。所有来源数据统一由集成服务实时接入ODS层(hdfs)或APP层(Kudu)。

数据仓库分层规范化

数据分层大家都流行以四层划分(关于数仓分层，不了解的同学需要自己去找文章补脑)，这里也不例外，只是我们每层的存储和访问需要解决整合问题，原因跟我们用的技术架构有关系。接下来我们讲下每种数据流进来以后和经过层层分析后怎么存储。先上个直观图：

对于要求实时的数据，进入到kafka后，经过ETL直接输出应用数据到Kudu或Mysql，提供给应用使用。相当于在先前的即时查询系统中加入了ETL功能，不再是之前简单的kafka Connector了。需要做离线分析、定制查询或实时性要求不高的数据分析，通过数据集成通道后通过Hive进入到ODS。然后再由已开发好的程序经过预计算出的结果往数据上层上放(DW和APP层)，我们的原则是：越往上层的数据，越往实时仓Kudu上放。对于离线计算，可以固化的查询，如果随着数据量和计算复杂度的增长，即使我们用了上面的即时查询系统，在响应时间上也不能得到保证(就算可以增加计算节点，如果查询树无法再拆分的情况下），所以我们选择预计算方案

预计算方案