实时架构
在某些场景中，数据的价值随着时间的推移而逐渐减少。所以在传统大数据离线数仓的基础上，逐渐对数据的实时性提出了更高的要求。
于是随之诞生了大数据实时数仓，并且衍生出了两种技术架构Lambda和Kappa。
1. Lambda架构
先来看下Lambda架构图：
Lambda架构图
数据从底层的数据源开始，经过Kafka、Flume等数据组件进行收集，然后分成两条线进行计算：
- 一条线是进入流式计算平台（例如 Storm、Flink或者SparkStreaming），去计算实时的一些指标；
- 另一条线进入批量数据处理离线计算平台（例如Mapreduce、Hive，Spark SQL），去计算T+1的相关业务指标，这些指标需要隔日才能看见。
为什么Lambda架构要分成两条线计算？
假如整个系统只有一个批处理层，会导致用户必须等待很久才能获取计算结果，一般有几个小时的延迟。电商数据分析部门只能查看前一天的统计分析结果，无法获取当前的结果，这对于实时决策来说有一个巨大的时间鸿沟，很可能导致管理者错过最佳决策时机。
Lambda架构属于较早的一种架构方式，早期的流处理不如现在这样成熟，在准确性、扩展性和容错性上，流处理层无法直接取代批处理层，只能给用户提供一个近似结果，还不能为用户提供一个一致准确的结果。因此Lambda架构中，出现了批处理和流处理并存的现象。
在 Lambda 架构中，每层都有自己所肩负的任务。
1. 批处理层存储管理主数据集（不可变的数据集）和预先批处理计算好的视图：
批处理层使用可处理大量数据的分布式处理系统预先计算结果。它通过处理所有的已有历史数据来实现数据的准确性。这意味着它是基于完整的数据集来重新计算的，能够修复任何错误，然后更新现有的数据视图。输出通常存储在只读数据库中，更新则完全取代现有的预先计算好的视图。
2. 流处理层会实时处理新来的大数据：
流处理层通过提供最新数据的实时视图来最小化延迟。流处理层所生成的数据视图可能不如批处理层最终生成的视图那样准确或完整，但它们几乎在收到数据后立即可用。而当同样的数据在批处理层处理完成后，在速度层的数据就可以被替代掉了。
那Lambda架构有没有缺点呢？
Lambda架构经历多年的发展，其优点是稳定，对于实时计算部分的计算成本可控，批量处理可以用晚上的时间来整体批量计算，这样把实时计算和离线计算高峰分开，这种架构支撑了数据行业的早期发展，但是它也有一些致命缺点，并在大数据3.0时代越来越不适应数据分析业务的需求。缺点如下：
- 使用两套大数据处理引擎：维护两个复杂的分布式系统，成本非常高。
- 批量计算在计算窗口内无法完成：在IOT时代，数据量级越来越大，经常发现夜间只有4、5个小时的时间窗口，已经无法完成白天20多个小时累计的数据，保证早上上班前准时出数据已成为每个大数据团队头疼的问题。
- 数据源变化都要重新开发，开发周期长：每次数据源的格式变化，业务的逻辑变化都需要针对ETL和Streaming做开发修改，整体开发周期很长，业务反应不够迅速。
导致 Lambda 架构的缺点根本原因是要同时维护两套系统架构：批处理层和速度层。我们已经知道，在架构中加入批处理层是因为从批处理层得到的结果具有高准确性，而加入速度层是因为它在处理大规模数据时具有低延时性。
那我们能不能改进其中某一层的架构，让它具有另外一层架构的特性呢？
例如，改进批处理层的系统让它具有更低的延时性，又或者是改进速度层的系统，让它产生的数据视图更具准确性和更加接近历史数据呢？
另外一种在大规模数据处理中常用的架构——Kappa 架构，便是在这样的思考下诞生的。
2. Kappa架构
Kafka的创始人Jay Kreps认为在很多场景下，维护一套Lambda架构的大数据处理平台耗时耗力，于是提出在某些场景下，没有必要维护一个批处理层，直接使用一个流处理层即可满足需求，即下图所示的Kappa架构：
Kappa架构
这种架构只关注流式计算，数据以流的方式被采集过来，实时计算引擎将计算结果放入数据服务层以供查询。可以认为Kappa架构是Lambda架构的一个简化版本，只是去除掉了Lambda架构中的离线批处理部分；
Kappa架构的兴起主要有两个原因：
- Kafka不仅起到消息队列的作用，也可以保存更长时间的历史数据，以替代Lambda架构中批处理层数据仓库部分。流处理引擎以一个更早的时间作为起点开始消费，起到了批处理的作用。
- Flink流处理引擎解决了事件乱序下计算结果的准确性问题。
Kappa架构相对更简单，实时性更好，所需的计算资源远小于Lambda架构，随着实时处理的需求在不断增长，更多的企业开始使用Kappa架构。但这不意味着kappa架构能够取代Lambda架构。
Lambda和kappa架构都有各自的适用领域；例如流处理与批处理分析流程比较统一，且允许一定的容错，用Kappa比较合适，少量关键指标（例如交易金额、业绩统计等）使用Lambda架构进行批量计算，增加一次校对过程。
还有一些比较复杂的场景，批处理与流处理产生不同的结果（使用不同的机器学习模型，专家系统，或者实时计算难以处理的复杂计算），可能更适合Lambda架构。
四、实时数仓解决方案
实时数仓分层架构为了避免面向需求响应的烟囱式构建，实时数仓也引入了类似于离线数仓的分层理念，主要是为了提高模型的复用率，同时也要考虑易用性、一致性以及计算成本。
当然实时数仓的分层架构在设计上并不会像离线数仓那么复杂，避免数据在流转过程中造成的不必要的延时响应；
实时数仓分层架构图：
实时数仓分层架构
- ODS层：以Kafka为支撑，将所有需要实时处理的相关数据放到Kafka队列中来实现贴源数据层；
- DWD层：实时计算订阅业务数据消息队列，然后通过数据清洗、多数据源join、流式数据与离线维度信息等的组合，将一些相同粒度的业务系统、维表中的维度属性全部关联到一起，增加数据易用性和复用性，得到最终的实时明细数据；
- DIM层：存放用于关联查询的维度信息，可以根据数据现状来选择存储介质，例如使用HBase或者Mysql
- DWS层：轻度汇总层是为了便于面向AdHoc查询或者Olap分析构建的轻度汇总结果集合，适合数据维度、指标信息比较多的情况，为了方便根据自定义条件的快速筛选和指标聚合，推荐使用MPP类型数据库进行存储，此层可视场景情况决定是否构建；
- APP层：面向实时数据场景需求构建的高度汇总层，可以根据不同的数据应用场景决定使用存储介质或者引擎；例如面向业务历史明细、BI支持等Olap分析场景，可以使用Druid、Greenplum，面向实时监控大屏、高并发汇总指标等需求，可以使用KV模式的HBase；数据量较小的时候，也可以使用Mysql来进行存储。
这里要注意下，其实APP层已经脱离了数仓，这里虽然作为了数仓的独立分层，但是实际APP层的数据已经分布存储在各种介质中用于使用。
基于Flink 构建的实时数仓
随着业务场景的丰富，更多的实时需求不断涌现，在追求实时任务高吞吐低延迟的同时，对计算过程中间状态管理，灵活时间窗口支持，以及 exactly once 语义保障的诉求也越来越多。
为什么选择Flink实时计算平台？之所以选择用Flink替代原有Storm、SparkStreaming是基于以下原因考虑的，这也是实时数仓关注的核心问题：
- 高吞吐、低延时；
- 端到端的 Exactly-once，保证了数据的准确性；
- 可容错的状态管理，实时数仓里面会进行很多的聚合计算，这些都需要对于状态进行访问和管理；
- 丰富的API，对Streaming/Table/SQL支持良好，支持UDF、流式join、时间窗口等高级用法；
- 完善的生态体系，实时数仓的构建会涉及多种存储，Flink在这方面的支持也比较完善。
基于Flink的实时数仓数据流转过程:
实时数仓数据流转过程
数据在实时数仓中的流转过程，实际和离线数仓非常相似，只是由Flink替代Hive作为了计算引擎，把存储由HDFS更换成了Kafka，但是模型的构建思路与流转过程并没有发生变化。
