0 读取数据_实时报表 T+0 的实现方案

【摘要】

基于数据库系统的 T+0 全量实时查询，在数据量很大时一般只能进行数据库扩容(包括分库手段)，成本高昂；如果采用文件系统和生产数据库混合运算，就可以实现低成本高性能的 T+0 查询，而热导出机制则是这个方案的基础！让我们一起去乾学院看个究竟吧：实时报表 T+0 的实现方案！

一 问题背景

在报表的应用系统中，用户越来越关注数据的实时性，希望最新发生的数据能在报表中体现出来，也就是我们常说的T+0场景, 以此及时辅助决策、驱动运营。

比如交通大数据应用的场景：需要结合实时数据了解车辆通行密度，合理进行道路规划，同时根据历史数据预测线路拥堵情况、事故多发地提醒等等。

但常规的方案：报表+数据仓库+ETL工具很难实现此类实时报表，往往只能看到昨天、上周甚至是上个月的情况，也就是T+1、T+7、T+30等，我们统称为T+n报表。

究其原因，困难大概体现在如下三个方面：

1、如果报表的历史数据和最新数据都从生产系统读取，虽然可以实现T+0报表，但是会对生产数据库造成压力，当数据量越来越大时，产生性能瓶颈，直接影响业务；并且大量的历史数据会占用高昂的数据库成本(存储成本和性能成本)。

2、如果采用数据仓库的方式，那么ETL从生产库中取出数据，需要较长的“窗口时间”，一般是业务人员下班之后，到第二天早上上班之前，所以能看到的最新数据也只能是T+1。

3、虽然理论上可以从历史库中和生产库中同时取数据形成实时报表，但是一般的报表工具都不具备跨库混合计算的能力，其他的跨库计算方案又比较复杂，难以实施，并且性能较低。

二 解决思路

那么，是否有成本更低、实施起来更简单的T+0报表方案呢？下面将要介绍的润乾集算器，就是这样一款利器，利用集算器的混合数据源能力就能实现低成本的T+0实时报表。

实现思路：把不再发生变动的大量历史数据采用数据文件存储，仅从生产库读取少量新数据，在保证报表实时性的同时，降低了历史数据存储的成本，减少了报表系统对生产数据库造成的负载。

下图显示了常规T+n方案和集算器T+0方案的结构对比，应该说，引入集算器后，减少了很多不必要的成本和多余的组件，整个体系架构也变得更加清新与合理了：

上图新处理方式体系结构中的”导出(非实时)”是指在非工作时间(例如晚上)，定时将生产数据库的新增数据同步到存储历史数据的文件中；

关于数据外置方案、设计数据存储组织、定时任务等相关准备和外围工作，具体做法可参考<>的相关章节，这里不再赘述。

三 混合运算场景

下面，我们就通过制作“实时流程工站不良柏拉图”这个例子，来看一下集算器是如何利用历史数据结合当期数据进行混合运算，实现T+0方案的。报表最终的展示效果如下图：

这张报表清楚地显示了电子设备在生产过程中，80%的问题是由20%的原因造成的，对于找出产生大多数问题的关键原因很有优势。

报表中数据的查询过程是：根据选择开始日期、结束日期进行过滤查询；先按照不良代码分组，统计汇总每个分类的不良数量，并按照汇总数量降序，然后计算出不良累计比率(算法为“(不良数量累计汇总/总不良数量汇总)*100”)。报表上部的查询按钮是报表工具提供的“参数模板”功能，具体做法参见教程，这里不再赘述。

3.1编写数据查询脚本

我们假定已经将变化不大的历史数据搬出了数据库，采用集文件(集文件利用集算器提供的压缩格式，具有更好IO性能)存储，命名为MES-pre.btx，同时每天定时执行数据同步脚本，把前一天的数据追加到当前数据文件中；查询涉及的当天少量数据直接从生产数据库(demo)取出，以此保证数据的实时性。集算器SPL脚本如下(也支持仅查历史数据的情况)：

A1：连接预先配置好的生产数据库(demo)

B1：查询字典表，不良代码、不良名称

A2：建立数据库游标，用简单的sql读取数据表的数据。Sql的过滤条件部分会根据逻辑判断进行动态拼接，当结束日期>=当前系统日期时，代表查询当天的实时数据，否则做一次结果为空的查询动作，以适应只查历史数据的业务场景。@x选项是指读完数据库后关闭连接。