实时数仓方案五花八门.docx

《实时数仓方案五花八门.docx》由会员分享，可在线阅读，更多相关《实时数仓方案五花八门.docx（21页珍藏版）》请在第一文库网上搜索。

1、实时数仓方案五花八门，实际落地如何选型和构建01为何需要实时数仓架构最初企业存储数据都在数仓中存储，但是随着数据量的增大，传统数据的方案在时效性上和数据维护上变得越来越困难。实时数仓架构应运而生。然而问题并不是这么简单，在具体方案落地上实时数仓有很多方案可以选择，那么面对不同的业务和应用场景我们到底应该选择哪种技术方案呢?这是困扰好多大数据架构师的问题。It02数仓如何分层&各层用途介绍实时数仓前，我们先回顾下离线数仓的分层架构，这将对我们后面理解实时数仓架构设计具有很大帮助。数仓一般分为：ODS层、DWD层、DWS层和ADS层。这里我会分别展开说一下。这部分内容大家了解数仓中每层数据的特点即

2、可，具体研发中同学们可以根据项目再做深入体会。图21)ODS层：ODS是数据接入层，所有进入数据的数据首先会接入ODS层。一般来说ODS层的数据是多复杂多样的。从数据粒度上看ODS层是粒度最细的数据层。2）DWD层：为数据仓库层，数据明细层的数据应是经过ODS清洗，转后的一致的、准确的、干净的数据。DWD层数据粒度通常和ODS的粒度相同，不同的是该层的数据质量更高，字段更全面等。在数据明细层会保存BI系统中所有的历史数据，例如保存近10年来的数据。3）DWS层：数据集市层，该层数据是面向主题来组织数据的，通常是星形或雪花结构的数据。从数据粒度来说，这层的数据是轻度汇总级的数据，己经不存在明细数

3、据了。4） ADS层：数据应用层，它是完全为了满足具体的分析需求而构建的数据，也是星形或雪花结构的数据。从数据粒度来说是高度汇总的数据。其汇总的FI标主要是按照应用需求进行的。03数仓分层的必要性那么数仓为什么要分层，数仓分层后有哪些好处呢？数仓分层是一个比较麻烦且耗费工作成本的一个事情，只有理解了数仓分层到底有哪些好处，我们才能理解数仓分层的必要性。数仓分层的总体思路是用空间换时间，其目的是通过数仓分层，使得数仓能够更好地应对需求的变更，和提高数据的稳定性。1）用空间换时间：通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据。2）能更好地应对需求的变更：如果不

4、分层的话，如果源业务系统的业务规则发生变化，将会影响整个数据清洗过程，工作量巨大。3）提高数据处理过程的稳定性：通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，每一层的处理逻辑都相对简单和容易理解。这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，往往我们只需要局部调整某个步骤即可。前面介绍了数仓分层的一些基本理论，这将对我们后面理解实时数仓的各种架构打下一些理论知识基础。下面为大家梳理下市场上常见的实时数仓方案和对应的应用场景。04从Lambda架构说起大部分实时数仓，其实是从Lambda架构演化而来的

5、，因此在介绍实时数仓方案前我们先回顾下Lambda架构。Lambda架构将数据分为实时数据和离线数据。针对实时数据使用流式计算引擎进行计算（例如Flink）,针对离线数据使用批量计算引擎这种架构的优点是离线数据和实时数据各自计算，既能保障实时为业务提供服务，又能保障历史数据的快速分析。它分别结合了离线计算引擎与流式计算引擎二者的优势。但是有一个缺点是离线数据和实时数据的一致性比较难保障，一般在离线数据产生后会使用离线数据清洗实时数据来保障数据的强一致性。05Kappa架构解决哪些问题接下来要讲的这种架构，它是基于Lambda架构上的优化版本，Kappa架构。这种架构将数据源的数据全部转换为流式

6、数据，并将计算统一到流式计算引擎上。这种方式的特点使架构变得更加简单，但是不足之处是需要保障数据都是实时的数据，如果06深入实时数仓架构实时数仓的查询需求在正式讨论实时数仓前，我们先看下行业对实时数仓的主要需求，这有助于我们理解实时数仓各种方案设计的初衷，了解它是基于哪些需求应运而生的。这也将帮助我们从更多维度上思考需求、条件、落地难点等等一些关键要素之间如何评估和权衡，最终实现是基于现有条件下的功能如何将其价值最大化。传统意义上我们通常将数据处理分为离线的和实时的。对于实时处理场景，我们一般又可以分为两类:一类诸如监控报警类、大屏展示类场景要求秒级甚至毫秒级；另一类诸如大部分实时报表的需求通

7、常没有非常高的时效性要求，一般分钟级别，比如10分钟甚至30分钟以内都可接受。基于以上查询需求，业界常见的实时数仓方案有这几种。Kappa架构基于标准分层+流计算业界常见的实时数仓方案标准分层体现+流计算+批量计算标准分层体系+流计算+数据湖基于全场景MPP数据库实现目前老的项目大部分还在使用的标准分层体现+流计算+批量计算的方案。未来大家可能都会迁移到标准分层体系+流计算+数据湖，和基于全场景MPP数据库实现的方案上，我也会重点介绍这两个方案，也希望大家能够多花点时间加以理解。方案1： Kappa架构首先咱们看下Kappa架构,Kappa架构将多源数据（用户日志,系统日志，BinLog日志）

8、实时地发送到Kafka o然后通过Flink集群，按照不同的业务构建不同的流式计算任务，对数据进行数据分析和处理，并将计算结果输出到MySQL/ElasticSearch/HBase/Druid/KUDU等对应的数据源中，最终提供应用进行数据查询或者多维分析。Apache FlinkelastKsearthVMySQL5) druid这种方案的好处有二，方案简单；数据实时。不过有两个缺点：一个是用户每产生一个新的报表需求，都需要开发一个Flink流式计算任务，数据开发的人力成本和时间成本都较高。第二个是对于每天需耍接入近百亿的数据平台，如果要分析近一个月的数据，则需耍的Flink集群规模耍求很

9、大，旦需耍将很多计算的中间数据存储在内存中以便多流Join。方案简单图9方案2 ：基于标准分层+流计算为了解决方案1中将所有数据放在一个层出现的开发维护成本高等问题，于是出现了基于标准分层+流计算的方案。接下来咱们看下这种方案，在传统数仓的分层标准上构建实时数仓，将数据分为ODS、DWD、DWS、ADS层。首先将各种来源的数据接入ODS贴源数据层，再对ODS层的数据使用Flink的实时计算进行过滤、清洗、转化、关联等操作，形成针对不同业务主题的DWD数据明细层,并将数据发送到Kafka集群。之后在DWD基础上，再使用Flink实时计算进行轻度的汇总操作，形成一定程度上方便查询的DWS轻度汇总层

10、。最后再面向业务需求，在DWS层基础上进一步对数据进行组织进入ADS数据应用层，业务在数据应用层的基础上支持用户画像、用户报表等业务场景。图10这种方案的优点是：各层数据职责清晰。缺点是多个Flink集群维护起来更杂，并且过多的数据驻留在Flink集群内也会增大集群的负载，不支持upset操作，同时Schema维护麻烦。图11方案3：标准分层体现+流计算+批量计算为了解决方案2不支持upset和schema维护笑杂等问题。我们在方案2的基础上加入基于HDFS加Spark离线的方案。也就是离线数仓和实时数仓并行流转的方案。ad-hoc直询图12这种方案带来的优点是：既支持实时的OLAP查询，也支

11、持离线的大规模数据分析。但是带来了问题这样的儿个问题。数据质量管理复杂：需要构建一套兼容离线数据和实时数据血缘关系的数据管理体系，本身图13方案4：标准分层体系+流计算+数据湖随着技术的发展，为了解决数据质量管理和upset问题。出现了流批一体架构，这种架构基于数据湖三剑客Delta Lake / Hudi / Iceberg实现+ Spark实现。图14我们以Iceberg为例介绍下这种方案的架构，从下图可以看到这方案和前面的方案2很相似,只是在数据存储层将Kafka换为了 Iceberg。OLAP人eassrstArc*MvSOL图15它有这样的几个特点，其中笫2、3点，尤为重要，需要特别

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

13、持OLAP的实时查询图16那么为什么Iceberg能承担起实时数仓的方案呢，主要原因是它解决了长久以来流批统一时的这些难题:1、同时支持流式写入和增量拉取。2、解决小文件多的问题。数据湖实现了相关合并小文件的接口，Spark / Flink上层引擎可以周期性地调用接口进行小文件合并。3、支持批量以及流式的Upsert (Delete)功能。批量Upsert / Delete功能主要用于离线数据修正。流式upsert场景前面介绍了，主要是流处理场景下经过窗口时间聚合之后有延迟数据到来的话会有更新的需求。这类需求是需耍一个可以支持更新的存储系统的，而离线数仓做更新的话需耍全量数据覆盖，这也是离线数

14、仓做不到实时的关键原因之一，数据湖是需耍解决掉这个问题的。4、同时Iceberg还支持比较完整的OLAP生态。比如支持Hive / Spark / Presto / Impala等OLAP查询引擎，提供高效的多维聚合查询性能。同时支持流式写入和增量扇解决小文件多的问题厂1支持批量以及流式的Upsert(Delete)功能Iceberg 实战上面介绍了基于Iceberg的标准分层体系+流计算+数据湖的架构，下面咱们从实战角度看下Iceberg如何使用。iceberg写入流式数据代码实现如下:data, wri teStream. format (，/iceberg，) . outputMode

15、(append) . trigger (Trigger. ProcessingTimed, TimeUnit. MINUTES). option(data_path，tableldentifier) . option(checkpointLocation, checkpointPath) . start()br上述代码会将data_path下的数据以流的形式，实时加入到系统中进行计算。iceberg数据过滤代码实现如下：Table table =Actions. forTable(table). rewriteDataFiles() . filter(Expressions, equal(date,2022-03T8). targetSizelnBytes(500 * 1024 * 1024) / 500 MB .