实时数仓新选择——Doris构建实时数仓落地方案详解

一、实时数据仓库概述

**首先，**我们从数据仓库说起。

数据仓库的概念可以追溯到20世纪80年代，当时IBM的研究人员提出了商业数据仓库的概念。数据仓库概念的提出，是为了解决和数据流相关的各种问题，特别是多重数据复制带来的高成本问题。

数据仓库之父Bill Inmon在1991年出版的 《Building the Datla Warehouse》一书中首次提出了数据仓库的概念。Inmon将数据仓库描述为一个面向主题的、集成的、随时间变化的、非易失的数据集合，用于支持管理者的决策过程。这个定义一直延续至今，Bill Inmon也被称为数据仓库之父。

大约在2000年前后数据仓库开始进入中国，最开始主要集中在银行业和电信业。银行业建设数据仓库的动力来自于监管要求和1104监管报送系统，电信业的动力主要是推动省市级子公司汇总数据到总公司，构建统一的财务分析报表。两个行业的应用，为数据仓库概念在中国的普及奠定了基础。

在2010年以后，随着大数据技术的发展扩展到其它行业。互联网、零售、制造、医疗行业等各行各业都在推广数据仓库。

然后是数据仓库技术的发展。

在2010年前后，数据仓库系统主要由数据库、ETL平台、BI工具三个商业套件组成。常见的数据库主要是Oracle、DB2、Teradata，对应的ETL平台分别是DataStage、Informatica、ETL Automation，主流的商业BI平台主要是BIEE、Cognos、BO。对于以上这些名词可能今天的听众都很陌生，但是在2010年前后，这些就是数据仓库的代名词。我本人也只是在商业数仓的鼎盛时期入行参与了一些项目，除了今年3月宣布退出中国市场的Teradata没有接触过，但是其它的商业组件我都深入学习和实战过。

与此同时，随着移动互联网的兴起，以BAT为代表的互联网企业高喊着“去IOE”口号，推动数据仓库从商业时代走向了开源时代，也从单体架构走向分布式架构。这里面最具代表性的就是阿里巴巴和腾讯公司分别2009年引入Hadoop集群，并且持续迭代升级并一直使用至今。互联网公司引入Hadoop体系的原因也很简单，因为传统的商业数据库已经无法满足互联网企业的数据存储计算需求了。传统的商业数据库扩展能力有限，硬件价格高昂，并发执行能力不足，Hadoop则刚好可以解决这些痛点，加上HiveQL可以满足大部分数据开发的需求，因此Hive数仓逐步替代了商业数据库。但是前期Hadoop、Hive、sqoop等开源软件并不成熟，需要投入大量的技术研发来完善这些软件，修复其中的bug，优化某些模块的性能或者功能，这个过程也比较缓慢，所以前期大家对Hadoop和Hive的感受都是很难用、不稳定。我本人第一次在项目中接触Hive是在2016年底，当时是腾讯旗下的微众银行，用的是腾讯内部优化过的Hive0.13版本，互联网公司也是在那一年开始引入Kafka。

后面的故事大家基本上都知道了，2016年前后，随着Hive2.3和Hive3.0版本的发布，Hadoop体系逐渐走向成熟稳定，Hortonworks和Cloudera公司分别为Hadoop生态贡献了Tez引擎、Ambari管理平台和Impala引擎，与此同时，内存计算引擎Spark强势崛起，为Hive提高了新的强大动力；Hive母公司Facebook又进一步开源了MPP框架的查询引擎Presto，大幅提升了Hive数仓的查询能力。

站在当前时间点，我们谈论的Hive数仓，一般默认包括HDFS存储系统、Yarn资源管理平台、Hive元数据管理、Spark计算引擎、Presto查询引擎，这些构成了离线数仓的技术栈。

这里简单介绍一下各个技术栈的功能和作用：

- Apache Hadoop：Apache Hadoop是一个开源的分布式计算框架，提供了可扩展的存储和处理大规模数据的能力。它的核心组件包括Hadoop Distributed File System (HDFS)、MapReduce和Yarn资源管理组件，主要用于离线数仓数据存储和资源调度。

• Apache Hive：Apache Hive是基于Hadoop的数据仓库基础架构，提供了类似SQL的查询语言（HiveQL），使用户可以通过SQL风格的语法进行数据查询和分析。它支持将结构化数据映射到Hadoop集群上的HDFS，并利用MapReduce、Spark、Tez等计算引擎进行查询和数据加工。

• Sqoop：一个短命而重要的Hadoop组件，用于从关系型数据库抽取数据到Hive数仓中或者从Hive数仓中导出数据到关系型数据库。sqoop是一个非常重要的组件，但是不知道出于什么原因，很早就停止了更新，目前国内基本上都是用阿里巴巴开源的DataX替代其功能。

• Apache Spark：Apache Spark是一个快速、通用的大数据处理引擎，可用于构建离线数据仓库和实时数据分析系统。Spark提供了高性能的数据处理和分析能力，并支持多种编程语言，如Scala、Java和Python。

• Apache Kylin：Apache Kylin是一个开源的分布式分析引擎，专门用于构建OLAP（联机分析处理）数据仓库。它支持在Hadoop上构建多维数据模型，提供快速的查询性能和高度可扩展性。这是一款由国人主导和开源的大数据项目，也是一款专注于OLAP查询的Apache顶级开源项目。

• Presto：Presto是一个分布式SQL查询引擎，可用于构建大规模数据仓库和数据查询引擎。它支持在多个数据源上执行高性能的查询，包括Hive、MySQL、PostgreSQL等。

说完数据仓库，就要说说OLAP查询了。在传统的数据仓库架构里，ETL是在数据仓库之外，OLAP在数据仓库之内的。在Hadoop体系引入数据仓库领域以后，大大提升了数据ETL处理的能力、集群的扩展能力、数据存储的稳定性，但是牺牲了数据的查询能力。所以就诞生了OLAP查询这个专业领域。

在离线数仓技术中，除了前面介绍的Kylin、Presto、Impala、Druid都是为了解决OLAP查询而设计的，但是这些基于HDFS设计的OLAP引擎都只是加速了查询速度，还没能达到令人满意或者令人惊艳的速度。于是，ClickHouse和Doris横空出世，一举成为了OLAP领域的王者。

ClickHouse是俄罗斯的 Yandex 于2016年开源的用于在线分析查询的数据管理系统，是一款基于MPP架构的列式存储数据库，能够使用 SQL 查询语句实时生成数据分析结果。ClickHouse的全称是Click Stream，Data WareHouse。ClickHouse 也是第一款实现向量化查询引擎的开源数据库，也是一款专注于OLAP查询的数据库。ClickHouse直接将OLAP查询的耗时压缩到了压秒级。

Apache Doris也是一个MPP架构的、专门用于OLAP查询的数据库产品。Apache Doris不仅可以满足多种数据分析需求，如固定历史报表，实时数据分析，交互式数据分析，探索式数据分析，而且集群扩展能力非常突出，可以支持10PB以上的超大数据集。另外，Apache Doris对实时数据的支持也非常强大，因此是一款综合能力非常强的数据库。由于Apache Doris是本次分享的重点，所以这里只是简单介绍一下，后面再展开。

这里插入一个知识点，也是我在整理PPT的时候看到的一个总结。ClickHouse为什么快？这里总结了几个点，其中最主要的是：C++语言可以利用硬件优势，底层数据选择列存储，支持向量化查询引擎，利用单节点的多核并行处理能力，数据写入时建立一级、二级和稀疏索引。这些特点为新兴的OLAP查询数据库研发指明了方向，这也是Doris的基本特点。

再说说第三个概念，MPP架构。MPP是大规模并行处理框架的简称。MPP是Shared Nothing架构，是将任务并行地分散到多个服务器和节点上，在每个节点上的计算完成后，将各部分的结果汇总在一起得到最终的结果。

前文说到的Teradata是业界最早的知名MPP架构的数据库，之后是Greenplum以及和Greenplum架构类似GBase、GaussDB等都是MPP架构。Hadoop体系的Presto、HAWQ、Impala都宣称是MPP架构，还有前面说到的Clickhouse和Doris两个新生物种。由于MPP家族越来越庞大，加上Hadoop生态的跨界“打劫”，所以现在很难定义什么是MPP架构。MPP架构和Hadoop架构在一定层次上走向融合，目前最大的区别就在于计算资源的分配上。Hadoop架构还遵从Yarn分配资源，而MPP架构都是独立使用本地内存和CPU。再就是过程备份和失败重试机制，hadoop都会保留中间计算过程，计算失败的部分节点有自动重试机制，而MPP架构一般是一次性过程，如果执行失败了就会告诉用户执行失败，以此换取更好的查询性能。

最后再来说说实时数仓。传统的数据仓库都是利用夜间的业务低峰期来完成数据的ETL加工处理，并且为白天的日常分析提供数据支撑，所以在这个应用前提下，数据仓库默认都是按天计算和加工数据的，俗称T+1数仓。但是随着业务的发展和技术的成熟，我们不再满足于今天看昨天的数据，而是想要今天就看到今天的数据，于是就有了实时数仓的概念。实时数仓是指数据的实时性更高、延迟性低的数据仓库，一般是统计当天发生的业务数据。实时数仓一般包括按小时执行的小时级、分钟级的延时的准实时和秒级延时纯实时数仓。

从前面的介绍我们可以看出，早期的Hive数仓技术并不完善，连实时OLAP查询都很难做到，所以要做到实时数仓就更加难上加难。所以Kafka诞生这么多年，实时数仓还要等到Flink火爆才流行起来。纯实时数据仓库是指能够以近乎实时的方式处理和分析数据的数据仓库。它的目标是将数据的捕获、处理和分析的速度提高到接近实时的水平，以支持实时决策和洞察。

纯实时数据仓库颠覆了离线数仓的架构，包括数据采集、数据加工、数据查询和分析都需要采用一套新的技术栈。

在数据采集方面，要做到较低延迟的采集数据，常用的方法是读取数据库变更日志（也叫CDC）或者直接接入在线的Kafka数据流。

在数据加工方面，实时数据一般采用Apache Flink或者Spark Streaming来完成数据加工，中间过程数据一般保存在Kafka。

在实时数据查询方面，一般只支持将数据汇总写入MySQL等关系型数据库或者Redis缓存，以便于快速获取结果。为了支持更快的查询，我们也可以将数据写入Clickhouse和Doris进行查询。

这种加工虽然可以做到数据的秒级延迟，但是牺牲了数据的准确性和数据分析维度，高度聚合的数据虽然可以满足一些场景的使用，但是无法进一步分析和深挖数据价值。所以大多数情况下，我们会在实时架构和离线架构之间做一个折中处理，就前半部分实时，后半部分离线，数据接入实时，数据加工采用离线微批处理。如果交易系统无法支持CDC变更日志，我们甚至可以基于数据的创建时间和修改时间，做微批的增量数据抽取。微批处理的好处在于：数据准确度比实时高，技术比较成熟，开发运维成本低。具体的实现方法我们将在第三部分展开。

实时数仓的应用场景也是在逐步丰富的，我在工作中遇到的主要有：

①实时业务监控和预警，避免线上业务中断未能及时发现造成的损失。

②实时大屏，主要用于618或者双十一大促期间监控业绩目标达成情况。

③实时机器人播报，通过实时数据加工，及时向相关同事通报当日业绩进展情况和排名。

④移动端实时数据展现，方便领导、管理人员实时查看业绩完成情况。

⑤实时自助分析，主要是给自助分析补充当日数据。

⑥实时看板。例如，按照五分钟的粒度查看成交指标，并和同期进行对比，便于及时发现业务故障，比实时监控更直观。

⑦实时数据接口。有一些数据对外的场景，需要实时提供最新的数据，便于跨系统对接，不过这种场景大多数在交易系统完成。

⑧实时推荐，例如商品实时销售排行榜等。

实时数仓的实现也有很多难点，我这里总结主要是三个点。

第一，多表关联，也叫多流jion，当其中一方数据延迟时，如果另外一边的流数据不在数据窗口范围中，将无法关联。例如销售订单父表和销售明细子表，如果业务系统出现明细表变更超出窗口范围的数据，双流jion将会丢失数据，导致变更记录丢失。

第二，维度数据变更。当维度数据发生变化时，历史数据和新写入的数据将存在不一致。如果是离线数仓，我们一般用当日凌晨确定时间点的维度状态作为统一维度；如果是纯实时数仓，维度变化前后的数据将出现不一致，而历史数据按照新维度清洗将成为一大难题。

第三，数据失效。数据失效包括数据物理删除和状态变为无效。数据物理删除，是指交易系统直接删除了对应的记录，这个在增量数据处理和实时数据抽取中都是难点，幸运的是CDC日志可以捕获到删除的记录；状态变为无效是指原来有效的数据变为无效数据，例如订单支付后关单。对于数据失效，我们一般的处理方法是生成一条指标为负数的对冲记录，将汇总结果中的指标扣减掉。但是在计算成交人数等指标则无法做到剔除。

以上三种情况在传统方案的实时数仓领域是无解的，但是在Apache Doris时代，我们是可以很轻易的解决这些痛点。

二、Doris核心功能解读

接下来进入第二部分Apache Doris的介绍。
Apache Doris是由百度研发并开源的数据库项目。 Doris2008年开始在百度内部立项，经历了五个大版本的迭代后于2017年开源，2018年进入Apache基金会孵化项目。2022年4月18日正式发布Doris1.0，2022年6月16日正式毕业，成为Apache 软件基金会的顶级项目。截至今日，刚好满一年多一天。

Doris数据库软件主要有BE和FE两个组件构建，BE是后台数据存取组件，是由C++语言编写；FE是前端查询入口和查询解析组件，由Java语言编写。

Doris最大的特点是提供了三大数据模型：

• Duplicate Key模型也叫可重复模型、明细模型，和普通的数据库表用法一样，保留每一条插入的数据，并且支持索引；

• Aggregate Key模型也叫聚合模型、汇总模型，将表的所有字段分为维度列和指标列，按照维度汇总指标数据，大大缩小数据量；

• Unique Key模型也叫去重模型、唯一模型，是按照主键保留最新记录，用于实现数据的删除和修改。

此外，Doris还支持各种外部表，包括ODBC外部表、Hive外部表、ES外部表和Iceberg外部表，分别用于直接使用Doris查询引擎查询关系型数据库、Hive数仓、ES文本检索和Iceberg数据湖的数据，极大的拓宽了Doris数据库的应用边界。
虽然Doris对外部表支持很丰富，但是外部表由于网络的瓶颈和无法支持索引，因此大数据的查询性能低于内部表，这里我们就要用到Doris的数据导入能力。Doris的数据导入具有原子性，也就是说一批数据要么全部导入成功，要么全部失败；也支持容错参数，低于一定比例异常的数据都视为成功。Doris数据导入和数据搬迁工具包括insert into、stream load、broker load、routine load、binlog load、spark load和DataX导入。库内数据处理优先insert into，离线数据导入优选stream load和DataX导入，流式数据接入可以选择routine load和binlog load，hive数据导入选择broker load和spark load。可以看出，Doris支持的数据来源非常丰富，并且对各种大数据生态产品支持都非常友好。

当然，我们还可以通过外部表直接insert into来搬迁数据量较小的外部数据。
然后就是Doris的多表关联功能。Doris支持Shuffle Join、Bucket Shuffle Join、Broadcast Join和Colocate Join四种分布式join策略，可以最大程度减少MPP架构下的数据重分布，提高数据查询效率。Shuffle Join要重分布关联的两个表所有数据；Bucket Shuffle Join只需要重分布两个关联表中一个表的数据；Broadcast Join则是广播关联表的其中一个数据量较小的表的全量数据；Colocate Join则是直接在本地完成数据关联，无需进行任何数据重分布，这是大表数据关联的一种理想状态。四种数据分布策略各有不同的应用场景，我们需要根据不同的数据关联需要进行优化，减少重分布的数据量，可以可以降低网络消耗，提高查询速度。

Doris的核心设计参考了Google Mesa、Apache Impala、OrcFile存储格式。

这里我想重点介绍一下Doris的数据存储。Doris的存储设计结合传统MPP数据库的优点和Hadoop分布式数据的优点，引入了一个叫bucket的概念。我们都知道Hadoop是把一个表的数据按照文件大小切分成多个块，每个块三个副本随机分布到集群的三台服务器上的。而传统的MPP数据（例如Greenplum、Clickhouse），数据要么按照节点平均分布，要么每个节点一份副本的全节点分布，前者对大表友好，后者对小表友好，但是都有缺点，前者并发查询上不去，后者浪费存储，节点数据同步消耗时间多。而Doris则是结合二者的优点又舍弃了其缺点，既支持小表多节点分布数据，有支持大表按照指定节点数分布式，并且Doris的数据副本可以参与计算，分散并发查询压力。针对聚合的热点数据表或者需要多次关联的维度表，我们可以设置3个以上的副本数，提高数据并发查询能力；针对需要关联或者全表扫描的大表，我们设置尽可能多的分桶数，在查询时调用多节点同步进行来提高查询效率；针对ODS层的大表或者实时数据写入的表，我可以只保留一份副本，降低磁盘空间占用。
另外，Doris的数据文件存储格式，也是结合了行存的优点和列存的优点，选择的是基于行列混合的模式，在读写性能上也有非常大的提升。传统的OLTP数据库选择行存储是为了便于数据更新和删除，OLAP数据库选择列存储是为了减少数据查询读取的列数，行列混合存储则结合了二者的优点，又提高了数据存储的灵活性。Doris2.0还提供了对S3对象存储的支持，可以将冷数据自动备份到对象存储中，并且支持在线查询，只是查询速度会降低。
最后是Doris的查询优化功能。Doris在查询方面做了非常多的优化。主要包括一下几个方面：

①索引。其中最重要的是稀疏索引。稀疏索引是首先将入库的数据按照数据块的排序键进行顺序存储，然后每隔1024行数维护一条索引，既大幅降低了索引的空间占用，又可以快速扫描数据，是一个极具突破性的设计。前面介绍Clickhouse快的原因也提到了这个功能。而Doris在前缀稀疏索引之外，还支持了MinMax索引、Bloom Filter索引、Bitmap索引，还支持通过rollup设置多种不同字段组合的索引，功能简直逆天。
②rollup和物化视图。Doris支持通过rollup和物化视图提前预聚合数据，减少查询的数据量，提高响应速度。
③分区。Doris支持多级分区，可以通过分区降低数据的扫描范围，提高查询速度；
④向量化查询引擎。Doris通过支持向量化查询引擎，可以大幅提高CPU数据处理能力，提高查询效率；
⑤查询优化。Doris接收到用户的查询语句以后，会先进行SQL语句改写，尽可能降低查询复杂度，减少数据扫描范围。例如谓词下推、Join Order优化、复杂SQL改写。
然后我们回顾一下实时数仓的三大难点，多表关联、维度数据变更、数据失效。在Doris中，多表关联我们可以通过流数据分别写入主键表的方式，在查询的时候才进行多表关联，这样可以完美的解决窗口不一致导致关联丢失的问题；而维度数据变更也是一样的，我们可以在查询的时候才进行维度关联，舍弃大宽表模型，在不损失查询效率的情况下实现数据的一致性和实时性；关于数据失效问题，Doris主键模型支持按照主键删除和修改数据，失效的数据我们可以直接在明细数据上置为无效或者删除，在查询时过滤掉失效数据。所以我说Doris数据库可以解决实时数仓的三大痛点。

三、Doris 实时数仓设计

前面已经解读实时数仓的背景、技术线路和应用场景，这里具体从实现的角度来介绍实时数仓。
在介绍实时数仓之前，我们先看看离线数仓的标准架构。众所周知，离线数仓一般分为ODS、DW和DM三层架构，这里面的ODS就是数据接口层，目前逐步被数据湖的概念取代，但是其基本原理没有变化，主要是数据同步方法、数据存储方式和增量数据获取等方面有所加强。往上DW层就是数据仓库层，也是我们离线数据处理和模型设计的核心，现在通用的分层都是分为DWD、DIM、DWS三个模块，DIM加工一致性维度；DWD保留业务模型数据并进行数据格式规范化、字段命名标准化；DWS聚焦指标逻辑加工，并适当进行数据汇总，减少数据量。有时候我们还会在DWS层的基础上增加DWT，作为宽表，但是我们也可以将这一层保留在DWS中，作为DWS层的一部分。DM层是数据集市层，在OLAP查询不理想的情况下，DM层是需要大力建设的。现在技术发展了，OLAP查询不再是瓶颈，我们将建设的重心下移到提供一致性对外数据服务的DWS层，DM层的开发工作逐步减少。

以我目前负责的电商业务为例，我会在DWD层构建一张订单表，整合所有接口过来的订单相关信息，包括订单的状态、收发货、业务类型、采购信息、支付信息、交易流程信息等，但是不包括商品的层级、店铺等信息。在DIM层构建以商品为核心的商品信息表，不仅包括商品的属性、业务分类、尺码颜色，还包括商品归属的店铺、价格、采购价等；DIM层还有用户维度信息，包括用户的注册信息、引流信息、历史成交信息和用户画像标签等。在DWS层，基于DWD层的订单信息的基础上计算成交金额、采购成本、订单折扣金额、毛利等指标。这就构成了一个简单的电商数仓最核心的订单业务流程。
从离线数仓过渡到实时数仓，我们的基本数仓分层没有变化，只不过为了数据时效性，有时候会省掉其中一些计算步骤。
实时数仓的设计理念主要由两个思路——Lambda架构和Kappa 架构。
Lambda架构是由Twitter工程师南森·马茨（Nathan Marz）提出的。Lambda架构简单的说就是流式数据作为批处理的补充，流数据之加工当日实时数据，批处理更新当日及之前的数据，在数据应用层将二者加工的结果合并起来。

Kappa架构可以认为是Lambda架构的简化版，即移除lambda架构中的批处理部分。在Kappa架构中，需求变更或历史数据变化都通过上游重放完成，即回溯数据进行重算。

Lambda架构提倡实时数据流程处理当日数据，T+1数据用离线加工来回补和修正，具有很好的灵活性和可扩展性，也对硬件故障和人为失误有很好的容错性。由于有批处理作为后盾，实时数据加工的压力大大减轻；由于有了离线数据加工，数据的准确性也得到了保障。
Kappa架构最大的优点是仅需一套代码，可以同时完成流式数据加工和批量数据加工，最大的问题是批量数据加工的能力会低于离线批处理，因此历时数据的回溯时长存在不确定性。
目前大部分都是采用Lambda架构，也有不少企业在尝试Kappa架构。从设计上说Kappa架构肯定是更优的，一套逻辑处理增量和全量，但是实际上比较难实现，或者说实现代价非常高。
要比较两种方案那种更好，我们需要先思考下面四个问题：

• 1.我们真的需要一个完全实时的数据仓库吗？很多业务，例如银行的日结、存款利息计算、财务报表统计等都是以日终或者月末作为时点计算的，所以并不需要实时。
• 2.在数据准确性和实时性之间，那个更重要？我们都知道不管是Lambda架构的实时部分还是Kappa 架构架构，我们都无法做到100%准确的实时。
• 3.实时计算的中间过程数据保存在Kafka中，数据出现了异常，我们要怎么找原因？
• 4.Kappa架构虽然给我们规划了一个非常美好的蓝图，但是真的可以实现吗？
  基于对以上四个问题的思考，我提出了基于Doris的全新实时数仓方案，也就是流+批组合模式。按照流数据加工的层级和批数据加工层级不同，分为了五种具体方案。
  

方案一是流数据写入ODS，往上数据加工逐层进行微批处理，在保证数据准确的情况下，提高微批的频率；

方案二是用FlinkSQL完成DWD层数据清洗和表关联，将数据写入DWD层，往上逐层进行微批处理。

方案三是Flink完成ODS到DWD、DWD到DWS的数据加工，并将数据同步写入Kafka和Doris，Doris只做数据查询，不进行数据加工。

方案四是将方案一中的数据微批处理改成视图，流批用同一个程序，T+1数据写入实体表，实时数据写入ODS后通过视图获取，对外提高实体表union all视图的数据给查询使用。
方案五是将方案二的微批处理改成视图，实时数据写入DWD，往上利用视图查询当日数据，T+1数据每日刷新写入实体表。

这种五种方案简单实用，虽然无法构建完整的流批一体数仓，但是可以满足大部分实时数仓的需求。之所以提供五个方案，主打一个灵活。
听到这里，可能很多朋友会说，切，你这太简单了吧？这里我会说，简单不好吗？Flink搞得那么复杂，数据准确性和运维便捷性 能超过这五个方案吗？做数仓开发，我从来都崇尚“大道至简”，逻辑非常简单都可能会出现bug，搞得太过复杂bug不是更多吗？
最后我们再对比一下这五个方案：这五个方案各有优点，也各有缺点，不能简单的说那个好，那个不好。

各有不同的应用场景：

方案一和方案四的应用场景类似，适合没有大表关联的场景或者三个以上的多表关联场景，在查询性能达不到要求的情况下改用方案一微批加工数据；
方案二和方案五的应用场景类似，适合两个表（例如头行结构的父子表）关联场景，推荐使用FinkSQL双流Join完成数据的初步关联，降低查询资源消耗。在后续的查询性能达不到要求情况下采用方案二进行微批加工数据。
方案三适合日志数据加工或者对数据准确性要求不高，但是对实时性要求非常高的业务场景。或者每日增量数据特别大，查询太慢、微批处理占用系统资源过多的情况。
以上五个方案都可以实现实时数据和离线数据加工共用一套代码逻辑，降低维度成本，实现了某种程度上的“流批一体”。
最后，我们再回到前面介绍的八种实时数据的应用场景，根据业务场景的不同，对数据时效性和准确性的要求也不同。

监控预警准确性和时效性要求都很高，但是查询要求不高，所以方案四和方案五均可。
实时大屏的时效性和查询性能要求高，但是准确性可以低一点，因此优选方案三和方案五。
机器人播报则是准确性要求最高，查询性能和时效性要求都不高，因此才有方案一和方案二的跑批模式。
移动看板、实时看板的查询性能要求高，数据时效性也要求很高，准确性可以略低一点，因此推荐方案三和方案五。
自助分析的数据粒度比较细，不需要太过于汇总，查询性能要求高，一般采用方案二和方案五。
实时接口的数据时效性要求高，查询一般是点查，所以一般采用方案四和方案五。
实时推荐的数据时效性要求不高，但是查询性能和数据准确性要求高，一般采用方案一和方案二。

转自：https://mp.weixin.qq.com/s/LtTx_Pj96VzeoDmh-b87Lg