数据仓库的趋势
数据仓库的建设是“数据智能建设”、“数字化”转型的一个必要且基础的环节；从智能商业的角度来讲，数据的结果代表了用户的反馈，获取结果的及时性就显得尤为重要，快速的获取数据反馈能够帮助公司更快的做出决策，更好的进行产品迭代，实时数仓在这一过程中起到了不 可替代的作用；随着数据时效性在企业运营中的重要性日益凸现，例如，实时推荐、精准营销、实时风控、实时监控大屏、实时BI报表等，数据的实时处理能力成为企业提升竞争力的一大因素。
数仓架构的演变
想要了解实时数仓的架构，就不得不从整个数据仓库的架构演变来进行展开；数据仓库概念是Inmon于1990年提出并给出了完整的建设方法。随着互联网时代来临，数据量暴增，开始使用大数据工具来替代经典数仓中的传统工具。此时仅仅以Hadoop技术体系替代了传统数据 仓库工具，架构上并没有根本的区别，可以把这个架构叫做离线大数据架构。
后来随着业务实时性要求的不断提高，人们开始在离线大数据架构基础上加了一个加速层，使用流处理技术直接完成那些实时性要求较高的指标计算，这便是Lambda架构。再后来，实时的业务越来越多，事件化的数据源也越来越多，实时处理从次要部分变成了主要部分，架构也做了相应调整，出现了以实时事件处理为核心的Kappa架构。
离线大数据架构
数据通过离线批量的方式同步进入到数据仓库中，通过构建数仓分层实现数据的ETL链路，最后通过多样式数据服务完成数据需求的满足，例如推送至业务端MYSQL、HBase，或者是构建独立的数据集市DM等。
离线大数据架构示意图
Lambda架构
随着实时性需求的提出，为了计算一些实时指标，就在原来离线大数据架构的基础上增加了一个实时计算的链路，并对消息队列实现数据源的流式改造，通过订阅消息队列，以流式计算引擎来完成指标增量的计算，推送到下游的数据服务中去，由数据服务层完成离线&实时结果的合并。
Lambda架构示意图
Kappa架构是由Jay Kreps提出。这种架构只关注流式计算，并不是取代Lambda架构，除非完全满足你的使用案例。数据以流的方式被采集过来，实时计算引擎将计算结果放入数据服务层以供查询。可以认为Kappa架构是Lambda架构的一个简化版本，只是去除掉了Lambda架构中的离线批处理部分；
Kappa架构示意图
Lambda和kappa架构都有各自的适用领域；例如流处理与批处理分析流程比较统一，且允许一定的容错，用Kappa比较合适，少量关键指标（例如交易金额、业绩统计等）使用Lambda架构进行批量计算，增加一次校对过程。还有一些比较复杂的场景，批处理与流处理产生不同的结果（使用不同的机器学习模型，专家系统，或者实时计算难以处理的复杂计算），可能更适合Lambda架构。
实时数仓解决方案
实时数仓分层架构
为了避免面向需求响应的烟囱式构建，实时数仓也引入了类似于离线数仓的分层理念，主要是为了提高模型的复用率，同时也要考虑易用性、一致性以及计算成本；当然实时数仓的分层架构在设计上并不会像离线数仓那么复杂，避免数据在流转过程中造成的不必要的延时响应；
实时数仓分层架构示例图
ODS层：
以Kafka为支撑，将所有需以Kafka为支撑，将所有需要实时处理的相关数据放到Kafka队列中来实现贴源数据层；
DWD层：
实时计算订阅业务数据消息队列，然后通过数据清洗、多数据源join、流式数据与离线维度信息等的组合，将一些相同粒度的业务系统、维表中的维度属性全部关联到一起，增加数据易用性和复用性，得到最终的实时明细数据；
DIM层：
存放用于关联查询的维度信息，可以根据数据现状来选择存储介质，例如使用HBase或者Mysql；
DWS层：
轻度汇总层是为了便于面向AdHoc查询或者Olap分析构建的轻度汇总结果集合，适合数据维度、指标信息比较多的情况，为了方便根据自定义条件的快速筛选和指标聚合，推荐使用MPP类型数据库进行存储，此层可视场景情况决定是否构建；
APP层：
面向实时数据场景需求构建的高度汇总层，可以根据不通的数据应用场景决定使用存储介质或者引擎；例如面向业务历史明细、BI支持等Olap分析场景，可以使用Druid、Greenplum，面向实时监控大屏、高并发汇总指标等需求，可以使用KV模式的HBase；数据量较小的时候，也可以使用Mysql来进行存储。
这里要注意下，其实APP层已经脱离了数仓，这里虽然作为了数仓的独立分层，但是实际APP层的数据已经分布存储在各种介质中用于使用。
基于Flink SQL 构建的实时数仓
随着业务场景的丰富，更多的实时需求不断涌现，在追求实时任务高吞吐低延迟的同时，对计算过程中间状态管理，灵活时间窗口支持，以及 exactly once 语义保障的诉求也越来越多。
科杰大数据实时计算平台集成当前最新Flink版本，支持元数据管理，任务调度管理，提供完善监控的能力，支持实时SQL模型以及拥有实时计算场景一系列特性，为客户提供全链路的实时数仓技术解决方案。
为什么选择Flink？
实时计算平台之所以选择用Flink替代原有Storm、SparkStreaming是基于以下原因考虑的，这也是实时数仓关注的核心问题：
1.高吞吐、低延时；
2.端到端的 Exactly-once，保证了数据的准确性；
3.可容错的状态管理，实时数仓里面会进行很多的聚合计算，这些都需要对于状态进行访问和管理；
4.丰富的API，对Streaming/Table/SQL支持良好，支持UDF、流式join、时间窗口等高级用法；
5.完善的生态体系，实时数仓的构建会涉及多种存储，，Flink在这方面的支持也比较完善。
我们在看看FlinkSql有哪些优势呢，我们从四方面去看：第一，支持 ANSI SQL 的标准； 第二，丰富的数据类型与函数支持，包括常见的算术运算与聚合运算； 第三，可自定义 Source/Sink，基于此可以灵活地扩展上下游； 第四，使用SQL进行数据处理，技术门槛要低于Jar的开发，批流SQL可以进行有效的快速转换。
基于Flink的实时数仓数据流转过程
数据在实时数仓中的流转过程，实际和离线数仓非常相似，只是由Flink替代Hive作为了计算引擎，把存储由HDFS更换成了 Kafka，但是模型的构建思路与流转过程并没有发生变化；
数据流转示意图
数据在实时数仓中的流转过程，实际和离线数仓非常相似，只是由Flink替代Hive作为了计算引擎，把存储由HDFS更换成了 Kafka，但是模型的构建思路与流转过程并没有发生变化。
元数据管理
元数据是数仓建设必不可少的基础数据，我们通过元数据来了解数据，但是Kafka本身没有Hive/GP等传统数仓组件的metastore，必须自己维护数据schema。科杰大数据实时计算平台提供了一站式的元数据管理功能支持；我们也提供了元数据的版本维护功能；
Kafka元数据管理
Kafka元数据版本管理
基于WEB的IDE开发
界面化的SQL开发模块，支持FlinkSql关键字自动识别，数据预览、一键引用数据Table等辅助编译功能，支持代码版本的回滚，自定义函数UDF的上传与使用、自动识别代码拓扑图、提供作业单机数据调试功能，极致简化了使用Flink进行数据ETL的过程与难度；
程序设计
任务作业管理
提供一站式全托管的实时任务作业管理能力，可以对实时计算任务进行上下下操作的同时，提供了完善的任务监控支持；
程序管理
可视化集群大屏监控
实时计算平台提供丰富的Kafka集群数据监控，包括集群监控大屏、主题管理、消费者应用、集群监控和告警功能等，帮助管理者监控和管理Kafka的状态，对消费者应用数据积压情况进行及时告警；
监控大屏
寄语
以上是我们依托于科杰实时计算平台以及多年为客户提供专业的实施服务与解决方案的经验总结的实时数仓的建设思路，我们会不断的完善实时计算平台，研究更多行业的实时数据需求场景，为各行业客户持续提供顶级的实时数仓解决方案！ 科杰大数据(www.keendata.com)作为领先的数据中台综合服务商，已先后在金融、通信、新零售、教育、互联网领域进行数据中台的落地与服务，通过赋能企业数字基础设施，帮助客户构建数据资产，加速全线业务智能化的实现。科杰将持续致力于新型基础设施的构建与服务，以软件定义大数据能力，以数据赋能组织与行业发展，通过基础设施的构建与服务助力数字化转型与数字经济建设。