目录
数仓架构演变
数据仓库概念是Inmon于1990年提出并给出了一个完整的建设方法，随着互联网时代来临，数据量暴增，开始使 用大数据工具来替代经典数仓中的传统工具。 此时仅仅是工具的取代，架构上并没有根本 的区别，可以把这个架构叫做离线大数据架构。
后来随着业务实时性要求的不断提高，人们 开始在离线大数据架构基础上加了一个加速 层，使用流处理技术直接完成那些实时性要 求较高的指标计算，这便是Lambda架构。
再后来，实时的业务越来越多，事件化的数据 源也越来越多，实时处理从次要部分变成了主 要部分，架构也做了相应调整，出现了以实时 事件处理为核心的Kappa架构。
离线大数据架构
特点：
- 数据源通过离线的方式导入到离线数仓中
- 数据处理采用MapReduce、Hive、SparkSQL等离线计算引擎
数据仓库分层
- ODS(Operation Data Store)层：原始数据层，存放加载原始日志、数据，数据保持原貌不做处理。
- DWD(Data warehouse detail)层：对ODS层数据进行清洗（去除空值，超过极限范围的数据）、维度退化、脱敏等。
- DWS（data warehouse service）层：以DWD为基础，按天进行轻度汇总。
- DWT（data warehouse Topic）层：以DWS为基础，按主题进行汇总。
- ADS（Application Data Store）层：为各种统计报表提供数据。
Lambda架构
随着大数据应用的发展，人们逐渐对 系统的实时性提出了要求，为了计算 一些实时指标，就在原来离线数仓的 基础上增加了一个实时计算的链路， 并对数据源做流式改造（即把数据发 送到消息队列），实时计算去订阅消 息队列，直接完成指标增量的计算， 推送到下游的数据服务中去，由数据服务层完成离线&实时结果的合并。
流处理计算的指标批处理依然计 算，最终以批处理为准，即每次 批处理计算后会覆盖流处理的结 果。（这仅仅是流处理引擎不完 善做的折中）。
实时计算链路内部是否分层，取决 于指标的复杂度，各层之间通过消 息队列交互(多半是不分层的)。
Lambda架构存在的问题
- 同样的需求需要开发两套一样的代码
这是最大的问题，两套代码不仅仅意味着开发困难（同样的需求，一个在批处理引擎上实现，一个在流处理引擎上实现，还要分别构造数据测试保证两者结果一致），后期维护更加困难，比如需求变更后需要分别更改两套代码，独立测试结果，且同时上线。
- 资源占用增多
同样的逻辑计算两次，整体资源占用会增多（多出实时计算这部分）
- 实现链路和离线链路数据差异容易让业务方困惑
例如业务方会发现，次日看到的数据比昨晚看到的要少。原因在于：数据在被放入Result Database 时,走了两条线的计算方式：一条线是ETL按照某个口径“跑”过来，得到更为准确的批量处理结果; 另一条线是通过Streaming“跑”过来，依靠Hadoop Hive或其他算法得出的实时性结果。当然它牺牲 了部分的准确性。可见，这两个来自批量的和实时的数据结果是对不上的。
Kappa架构
Lambda架构虽然满足了实时的 需求，但带来了更多的开发与 运维工作，其架构背景是流处 理引擎还不完善，流处理的结 果只作为临时的、近似的值提 供参考。后来随着Flink等流处 理引擎的出现，流处理技术很 成熟了，这时为了解决两套代 码的问题， Linkedln 的Jay Kreps提出了Kappa架构。
Kappa架构可以认为是Lambda架构的简化版（只要移除lambda架构中的批处理部分即可）
可以直接完成计算，也可以跟离线 数仓一样分层，取决于指标的复杂 度，各层之间通过消息队列交互(多 半是不分层的)
Kappa架构典型案例
Kappa架构来构建数仓是妥妥的实时数仓，每个需求都自己开发流处理代码比较繁琐，一个较好的办法是借助OLAP引 擎，主流的引擎如下(个别的严格意义上来说不是OLAP引擎，但是具备相应功能)：
Kappa架构的重新处理过程
在Kappa架构中，及时流处理引擎在健壮，由于上有数据原因，仍存在数据重新处理的需求，修改数据或历史数据重新处理都通过上游重放完成（从数据源拉取数据重新计算一次）。
Kappa架构最大的问题是：流式重新处理历史数据的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补，重新处理时对Kappa架构最担心的点，但实际上并不会复杂。
1.选择一个具有重放功能的、能够保存历史数据并支持多消费者的消息队列，根据需求设置历史数据保存的 时长，比如Kafka，可以保存全部历史数据。
2.当某个或某些指标有重新处理的需求时，按照新逻辑写一个新作业，然后从上游消息队列的最开始重新消 费，把结果写到一个新的下游表中。
3.当新作业赶上进度后，应用切换数据源，读取2中产生的新结果表。
4.停止老的作业，删除老的结果表。
Lambda架构和Kappa架构的对比
| 对比 | Lambda | Kappa |
| 实时性 | 实时 | 实时 |
| 计算资源 | 批和流同时运行，资源消耗大 | 只有流处理，资源开销小 |
| 重新计算吞吐量 | 批式全量处理，吞吐较高 | 流式全量处理，吞吐较批式全量要低一 些 |
| 开发、测试难度 | 每个需求都需要批处理和流处理两套代 码，开发、测试、上线难度大一些 | 只需实现一套代码，开发、测试、上线 难度相对较小 |
| 运维成本 | 维护两套系统(引擎)，运维成本大 | 维护一套系统(引擎)，运维成本较小 |
实时数仓和离线数仓
- 从架构上，实时数仓与离线数仓有比较明显的区别，实时数仓以Kappa架构为主，而 离线数仓以传统大数据架构为主。Lambda架构可以认为是两者的中间态。目前业界所说的实 时数仓大多是Lambda架构，这是由需求决定的。
- 从建设方法上，实时数仓和离线数仓基本还是沿用传统的数仓主题建模理论，产出 事实宽表。另外实时数仓中实时流数据的join有隐藏时间语义，在建设中需注意。
- 最后，从数据保障看，实时数仓因为要保证实时性，所以对数据量的变化较为敏感。在大 促等场景下需要提前做好压测和主备保障工作，这是与离线数据的一个较为明显的区别。
实际业务中，很多时候并不是完全规范的Lambda架构或者Kapa架构，可以是两者的混合，比如大部分实时指标使用Kappa架构完成计算，少量关键指标（比如金融相 关）使用Lambda架构用批处理重新计算，增加一次校对过程。
离线大数据架构在很多公司仍然比较实用(性价比高)