实时数仓之实际落地如何选型和构建

往期类似文章：

实时数仓之 Kappa 架构与 Lambda 架构_奔跑者-辉的博客-优快云博客

企业级-实时数仓架构图_奔跑者-辉的博客-优快云博客

第一部分：Spark基础篇_奔跑者-辉的博客-优快云博客

第一部分：Flink基础篇_奔跑者-辉的博客-优快云博客

---

目录

一、深入实时数仓架构 

二、具体选型建议

三、大厂方案分享

四、结语 ＆ 延申思考

补充几句话：这篇分享，内容分成了一个个小块知识呈现的，大家可结合文章概览看看对哪部分/哪几部分更为感兴趣，或者哪部分知识点掌握程度有待加深。然后直接找到对应的小模块浏览学习。期待你在留言区里讨论交流。 

一、深入实时数仓架构 

实时数仓的查询需求

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

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

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

一类诸如监控报警类、大屏展示类场景要求秒级甚至毫秒级；

另一类诸如大部分实时报表的需求通常没有非常高的时效性要求，一般分钟级别，比如10分钟甚至30分钟以内都可接受。

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

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

方案 1：Kappa 架构

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

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

这种方案的好处有二，方案简单；数据实时。

不过有两个缺点：

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

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

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

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

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