实时数仓技术架构实时数仓方案

转载

技术领航舵手 2023-10-16 15:41:58

文章标签 实时数仓技术架构大数据数据仓库数据离线 文章分类 架构后端开发

随着数字化进程的推进，企业产生的数据越来越多，与此同时企业对数据的需求也变得越来越复杂多样。

如何解决大规模复杂数据的存储和计算，已经成为很多企业必须面对的问题？这值得我们深思。

一、为何需要实时数仓架构

最初企业存储数据都在数仓中存储，但是随着数据量的增大，传统数据的方案在时效性上和数据维护上变得越来越困难。实时数仓架构应运而生。

然而问题并不是这么简单，在具体方案落地上实时数仓有很多方案可以选择，那么面对不同的业务和应用场景我们到底应该选择哪种技术方案呢？这是困扰好多大数据架构师的问题。

实时数仓技术架构实时数仓方案_数据

本文就针对该问题梳理了市场上常见的实时数仓方案和对应的应用场景。以便大家在选择或者使用实时数仓架构时能够有的放矢。

当然，在职业规划中，对应于想要成为大架构师的你而言，通过本文阅读你将会让你了解大数据架构必须掌握的数仓知识。尤其在实时数仓各种方案对比上会让你对数仓的理解更上一层楼。

另外，即便你不是大数据方面的研发人员，这一篇中处理数据的流程和思路，也一样会对你日常的工作有所帮助。

二、数仓如何分层 & 各层用途

在介绍实时数仓前，我们先回顾下离线数仓的分层架构，这将对我们后面理解实时数仓架构设计具有很大帮助。

数仓一般分为：ODS层、DWD层、DWS层和ADS层。这里我会分别展开说一下。这部分内容大家了解数仓中每层数据的特点即可，具体研发中同学们可以根据项目再做深入体会。

实时数仓技术架构实时数仓方案_数据仓库_02

1）ODS层：ODS是数据接入层，所有进入数据的数据首先会接入ODS层。一般来说ODS层的数据是多复杂多样的。从数据粒度上看ODS层是粒度最细的数据层。

2）DWD层：为数据仓库层，数据明细层的数据应是经过ODS清洗，转后的一致的、准确的、干净的数据。DWD层数据粒度通常和ODS的粒度相同，不同的是该层的数据质量更高，字段更全面等。在数据明细层会保存BI系统中所有的历史数据，例如保存近10年来的数据。

3）DWS层：数据集市层，该层数据是面向主题来组织数据的，通常是星形或雪花结构的数据。从数据粒度来说，这层的数据是轻度汇总级的数据，已经不存在明细数据了。

4）ADS层：数据应用层，它是完全为了满足具体的分析需求而构建的数据，也是星形或雪花结构的数据。从数据粒度来说是高度汇总的数据。其汇总的目标主要是按照应用需求进行的。

三、数仓分层的必要性

那么数仓为什么要分层，数仓分层后有哪些好处呢？数仓分层是一个比较麻烦且耗费工作成本的一个事情，只有理解了数仓分层到底有哪些好处，我们才能理解数仓分层的必要性。

数仓分层的总体思路是用空间换时间，其目的是通过数仓分层，使得数仓能够更好地应对需求的变更，和提高数据的稳定性。

1）用空间换时间：通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据。

2）能更好地应对需求的变更：如果不分层的话，如果源业务系统的业务规则发生变化，将会影响整个数据清洗过程，工作量巨大。

3）提高数据处理过程的稳定性：通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，每一层的处理逻辑都相对简单和容易理解。

这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，往往我们只需要局部调整某个步骤即可。

实时数仓技术架构实时数仓方案_数据仓库_03

前面介绍了数仓分层的一些基本理论，这将对我们后面理解实时数仓的各种架构打下一些理论知识基础。下面为大家梳理下市场上常见的实时数仓方案和对应的应用场景。

四、从Lambda架构说起

大部分实时数仓，其实是从Lambda架构演化而来的，因此在介绍实时数仓方案前我们先回顾下Lambda架构。

Lambda架构将数据分为实时数据和离线数据。

针对实时数据使用流式计算引擎进行计算（例如Flink），针对离线数据使用批量计算引擎（例如Spark）计算。然后分别将计算结果存储在不同的存储引擎上对外提供数据服务。

实时数仓技术架构实时数仓方案_离线_04

这种架构的优点是离线数据和实时数据各自计算，既能保障实时为业务提供服务，又能保障历史数据的快速分析。它分别结合了离线计算引擎与流式计算引擎二者的优势。

但是有一个缺点是离线数据和实时数据的一致性比较难保障，一般在离线数据产生后会使用离线数据清洗实时数据来保障数据的强一致性。

五、Kappa架构解决哪些问题

接下来要讲的这种架构，它是基于Lambda架构上的优化版本，Kappa架构。这种架构将数据源的数据全部转换为流式数据，并将计算统一到流式计算引擎上。

这种方式的特点使架构变得更加简单，但是不足之处是需要保障数据都是实时的数据，如果数据是离线的话也需要转化为流式数据的架构进行数据处理，具体架构可结合这张图来看。

实时数仓技术架构实时数仓方案_离线_05

六、深入实时数仓架构

实时数仓的查询需求

在正式讨论实时数仓前，我们先看下行业对实时数仓的主要需求，这有助于我们理解实时数仓各种方案设计的初衷，了解它是基于哪些需求应运而生的。

这也将帮助我们从更多维度上思考需求、条件、落地难点等等一些关键要素之间如何评估和权衡，最终实现是基于现有条件下的功能如何将其价值最大化。

传统意义上我们通常将数据处理分为离线的和实时的。对于实时处理场景，我们一般又可以分为两类：

一类诸如监控报警类、大屏展示类场景要求秒级甚至毫秒级；另一类诸如大部分实时报表的需求通常没有非常高的时效性要求，一般分钟级别，比如10分钟甚至30分钟以内都可接受。

实时数仓技术架构实时数仓方案_离线_06

基于以上查询需求，业界常见的实时数仓方案有这几种。

实时数仓技术架构实时数仓方案_离线_07

目前老的项目大部分还在使用的标准分层体现+流计算+批量计算的方案。未来大家可能都会迁移到标准分层体系+流计算+数据湖，和基于全场景MPP数据库实现的方案上，我也会重点介绍这两个方案，也希望大家能够多花点时间加以理解。

方案 1：Kappa 架构

首先咱们看下Kappa架构，Kappa架构将多源数据（用户日志，系统日志，BinLog日志）实时地发送到Kafka。

然后通过Flink集群，按照不同的业务构建不同的流式计算任务，对数据进行数据分析和处理，并将计算结果输出到MySQL/ElasticSearch/HBase/Druid/KUDU等对应的数据源中，最终提供应用进行数据查询或者多维分析。

实时数仓技术架构实时数仓方案_数据仓库_08

这种方案的好处有二，方案简单；数据实时。不过有两个缺点：

一个是用户每产生一个新的报表需求，都需要开发一个Flink流式计算任务，数据开发的人力成本和时间成本都较高。

第二个是对于每天需要接入近百亿的数据平台，如果要分析近一个月的数据，则需要的Flink集群规模要求很大，且需要将很多计算的中间数据存储在内存中以便多流Join。

实时数仓技术架构实时数仓方案_实时数仓技术架构_09

方案２：基于标准分层 + 流计算

为了解决方案1中将所有数据放在一个层出现的开发维护成本高等问题，于是出现了基于标准分层+流计算的方案。

接下来咱们看下这种方案，在传统数仓的分层标准上构建实时数仓，将数据分为ODS、DWD、DWS、ADS层。首先将各种来源的数据接入ODS贴源数据层，再对ODS层的数据使用Flink的实时计算进行过滤、清洗、转化、关联等操作，形成针对不同业务主题的DWD数据明细层，并将数据发送到Kafka集群。

之后在DWD基础上，再使用Flink实时计算进行轻度的汇总操作，形成一定程度上方便查询的DWS轻度汇总层。最后再面向业务需求，在DWS层基础上进一步对数据进行组织进入ADS数据应用层，业务在数据应用层的基础上支持用户画像、用户报表等业务场景。

实时数仓技术架构实时数仓方案_数据仓库_10

这种方案的优点是：各层数据职责清晰。缺点是多个Flink集群维护起来复杂，并且过多的数据驻留在Flink集群内也会增大集群的负载，不支持upset操作，同时Schema维护麻烦。

实时数仓技术架构实时数仓方案_大数据_11

方案 3：标准分层体现+流计算+批量计算

为了解决方案2不支持upset和schema维护复杂等问题。我们在方案2的基础上加入基于HDFS加Spark离线的方案。也就是离线数仓和实时数仓并行流转的方案。

实时数仓技术架构实时数仓方案_大数据_12

这种方案带来的优点是：既支持实时的OLAP查询，也支持离线的大规模数据分析。但是带来了问题这样的几个问题。

数据质量管理复杂：需要构建一套兼容离线数据和实时数据血缘关系的数据管理体系，本身就是一个复杂的工程问题。离线数据和实时数据Schema统一困难。架构不支持upset。

实时数仓技术架构实时数仓方案_大数据_13

方案 4：标准分层体系+流计算+数据湖

随着技术的发展，为了解决数据质量管理和upset 问题。出现了流批一体架构，这种架构基于数据湖三剑客 Delta Lake / Hudi / Iceberg 实现 + Spark 实现。

实时数仓技术架构实时数仓方案_大数据_14

我们以Iceberg为例介绍下这种方案的架构，从下图可以看到这方案和前面的方案2很相似，只是在数据存储层将Kafka换为了Iceberg。

实时数仓技术架构实时数仓方案_数据_15

它有这样的几个特点，其中第2、3点，尤为重要，需要特别关注下，这也是这个方案和其他方案的重要差别。

在编程上将流计算和批计算统一到同一个SQL引擎上，基于同一个Flink SQL既可以进行流计算，也可以进行批计算。
将流计算和批计算的存储进行了统一，也就是统一到Iceberg/HDFS上，这样数据的血缘关系的和数据质量体系的建立也变得简单了。
由于存储层统一，数据的Schema也自然统一起来了，这样相对流批单独两条计算逻辑来说，处理逻辑和元数据管理的逻辑都得到了统一。
数据中间的各层（ODS、DWD、DWS、ADS）数据，都支持OLAP的实时查询。

实时数仓技术架构实时数仓方案_数据_16

那么为什么 Iceberg 能承担起实时数仓的方案呢，主要原因是它解决了长久以来流批统一时的这些难题：

同时支持流式写入和增量拉取。
解决小文件多的问题。数据湖实现了相关合并小文件的接口，Spark / Flink上层引擎可以周期性地调用接口进行小文件合并。
支持批量以及流式的 Upsert(Delete) 功能。批量Upsert / Delete功能主要用于离线数据修正。流式upsert场景前面介绍了，主要是流处理场景下经过窗口时间聚合之后有延迟数据到来的话会有更新的需求。这类需求是需要一个可以支持更新的存储系统的，而离线数仓做更新的话需要全量数据覆盖，这也是离线数仓做不到实时的关键原因之一，数据湖是需要解决掉这个问题的。
同时 Iceberg 还支持比较完整的OLAP生态。比如支持Hive / Spark / Presto / Impala 等 OLAP 查询引擎，提供高效的多维聚合查询性能。

实时数仓技术架构实时数仓方案_实时数仓技术架构_17

Iceberg 实战

上面介绍了基于Iceberg的标准分层体系+流计算+数据湖的架构，下面咱们从实战角度看下Iceberg如何使用。

iceberg写入流式数据代码实现如下：

data.writeStream.format("iceberg") 
 .outputMode("append") 
.trigger(Trigger.ProcessingTime(1, TimeUnit.MINUTES)).option("data_path", tableIdentifier) 
.option("checkpointLocation", checkpointPath) 
.start()

上述代码会将data_path下的数据以流的形式，实时加入到系统中进行计算。

iceberg数据过滤代码实现如下：

Table table = ... Actions.forTable(table).rewriteDataFiles() .filter(Expressions.equal("date", "2022-03-18")) 
.targetSizeInBytes(500 * 1024 * 1024) // 500 MB 
.execute();

上述代码过滤出date为2022-03-18的数据。

方案 5：基于全场景MPP数据库实现

前面的四种方案，是基于数仓方案的优化。方案仍然属于比较复杂的，如果我能提供一个数据库既能满足海量数据的存储，也能实现快速分析，那岂不是很方便。这时候便出现了以StartRocks和ClickHouse为代表的全场景MPP数据库。