# 1.数据仓库简介
数据仓库是面向主题的、集成的、非易失的，反映历史变化(时间
Variant)用于支持管理决策。
数据仓库是随着企业信息化的发展而发展起来的。在企业信息化过程中，随着信息工具的升级和新工具的应用，数据量不断增加，数据格式不断增多，决策要求越来越高，数据仓库技术不断发展。
数据仓库的趋势：
*实时数据仓库，满足实时自动决策需求；
*大数据数据湖支持大量复杂数据类型(文本、图像、视频、音频)；
# 2.数据仓库的发展
数据仓库有两个环节：数据仓库的建设和数据仓库的应用。
早期的数据仓库建设主要是指对ERP、CRM、SCM等业务数据库的数据进行建模和汇总。在数据仓库引擎中根据需求进行决策分析。它的应用主要是报表，目的是支持管理和业务人员进行决策(中长期战略决策)。
随着商业和环境的发展，这两个方面正在发生剧烈的变化。
*随着IT技术向互联网和移动化的发展，数据源越来越丰富，而非结构化数据，如网站日志、IoT设备数据、APP埋藏数据等。在原有业务数据库的基础上出现，比过去的结构化数据大几个数量级，对ETL的流程和存储提出了更高的要求；
*互联网的线上特性也将业务需求推向实时，随时根据当前客户行为调整策略变得越来越普遍，如促销过程中的库存管理和运营管理(即兼顾中长期策略型和短期运营型)；同时，公司基于互联网的业务导致同时服务的客户数量急剧增加，有些案件很难完全由人工处理，需要机器自动决策。例如欺诈检测和用户审计。
综上所述，对数据仓库的需求可以抽象为两个方面：实时生成结果、处理和保存大量异构数据。
注：这里不讨论数据湖技术。
# 3.数据仓库建设的方法论
1)主题导向
从公司业务出发，是分析的宏观领域，比如供应商主题、商品主题、客户主题、仓库主题。
2)为多维数据分析服务。
数据报告；数据、分析功能，如向上滚动、向下钻孔、切片和旋转。
# 4.数据仓库体系结构的演变
Inmon在1990年提出了数据仓库的概念，并给出了完整的构建方法。随着互联网时代的到来，数据量急剧增加，大数据工具被用来取代经典数据仓库中的传统工具。此时只是工具的替换，架构上没有根本区别。这种架构可以称为离线大数据架构。
后来随着业务实时性要求的不断提高，人们开始在线下大数据架构的基础上增加加速层，利用流处理技术直接完成实时性要求高的指标的计算，这就是Lambda架构。
后来，实时业务越来越多，基于事件的数据源也越来越多。实时处理从次要部分变为主要部分，架构也相应调整。出现了以实时事件处理为核心的Kappa架构。
4.1离线大数据架构
数据源以离线方式导入离线数据仓库。
下游应用根据业务需求选择直接读取DM或增加一层数据服务，如mysql或redis。
数据仓库从模型层面分为三层：
* ODS，运行数据层，保存原始数据；
*数据仓库的细节层DWD，根据主题定义事实和维度表，保存最细粒度的事实数据；
* DM，数据集市/轻汇总层，在DWD层的基础上根据不同的业务需求进行轻汇总；
典型的仓库存储是HDFS/Hive，ETL可以是MapReduce脚本或HiveSQL。
4.2 Lambda架构
随着大数据应用的发展，人们逐渐对系统的实时性提出了要求。为了计算一些实时指标，在原有离线数据仓库的基础上增加了实时计算环节，精简数据源(即数据发送到消息队列)，进行实时计算订阅消息队列，直接完成指标增量的计算，推送给下游数据服务，数据服务层完成离线实时结果的合并。
注意：流处理
计算的指标批处理依然计算，最终以批处理为准，即每次批处理计算后会覆盖流处理的结果。（这仅仅是流处理引擎不完善做的折中）Lambda架构问题：
* 1.同样的需求需要开发两套一样的代码
* 这是Lambda架构最大的问题，两套代码不仅仅意味着开发困难（同样的需求，一个在批处理引擎上实现，一个在流处理引擎上实现，还要分别构造数据测试保证两者结果一致），后期维护更加困难，比如需求变更后需要分别更改两套代码，独立测试结果，且两个作业需要同步上线。
* 2.资源占用增多：同样的逻辑计算两次，整体资源占用会增多（多出实时计算这部分）
4.3 Kappa架构
Lambda架构虽然满足了实时的需求，但带来了更多的开发与运维工作，其架构背景是流处理引擎还不完善，流处理的结果只作为临时的、近似的值提供参考。后来随着Flink等流处理引擎的出现，流处理技术很成熟了，这时为了解决两套代码的问题，LickedIn
的Jay Kreps提出了Kappa架构
Kappa架构可以认为是Lambda架构的简化版（只要移除lambda架构中的批处理部分即可）。
在Kappa架构中，需求修改或历史数据重新处理都通过上游重放完成。
Kappa架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。
Kappa架构的重新处理过程
重新处理是人们对Kappa架构最担心的点，但实际上并不复杂：
* 1.选择一个具有重放功能的、能够保存历史数据并支持多消费者的消息队别，根据需求设置历史数据保存的时长，比如Kafka，可以保存全部历史数据。
* 2.当某个或某些指标有重新处理的需求时，按照新逻辑写一个新作业，然后从上游消息队列的最开始重新消费，把结果写到一个新的下游表中。
* 3.当新作业赶上进度后，应用切换数据源，读取2中产生的新结果表。
* 4.停止老的作业，删除老的结果表。
4.4 Lambda架构与Kappa架构的对比
在真实的场景中，很多时候并不是完全规范的Lambda架构或Kappa架构，可以是两者的混合，比如大部分实时指标使用Kappa架构完成计算，少量关键指标（比如金额相关）使用Lambda架构用批处理重新计算，增加一次校对过程。（1）
Kappa架构并不是中间结果完全不落地，现在很多大数据系统都需要支持机器学习（离线训练），所以实时中间结果需要落地对应的存储引擎供机器学习使用，另外有时候还需要对明细数据查询，这种场景也需要把实时明细层写出到对应的引擎中。（2）参考后面的案例
另外，随着数据多样性的发展，数据仓库这种提前规定schema的模式显得越来难以支持灵活的探索&分析需求，这时候便出现了一种数据湖技术，即把原始数据全部缓存到某个大数据存储上，后续分析时再根据需求去解析原始数据。简单的说，数据仓库模式是schema
on write，数据湖模式是schema on read。（3）
# 5.实时数仓案例
菜鸟仓配实时数据仓库
5.1 整体设计
整体设计如右图，基于业务系统的数据，数据模型采用中间层的设计理念，建设仓配实时数仓；计算引擎，选择更易用、性能表现更佳的实时计算作为主要的计算引擎；数据服务，选择天工数据服务中间件，避免直连数据库，且基于天工可以做到主备链路灵活配置秒级切换；数据应用，围绕大促全链路，从活动计划、活动备货、活动直播、活动售后、活动复盘五个维度，建设仓配大促数据体系。
5.2 数据模型
不管是从计算成本，还是从易用性，还是从复用性，还是从一致性……，我们都必须避免烟囱式的开发模式，而是以中间层的方式建设仓配实时数仓。与离线中间层基本一致，我们将实时中间层分为两层。
第一层DWD公共实时明细层
实时计算订阅业务数据消息队列，然后通过数据清洗、多数据源join、流式数据与离线维度信息等的组合，将一些相同粒度的业务系统、维表中的维度属性全部关联到一起，增加数据易用性和复用性，得到最终的实时明细数据。这部分数据有两个分支，一部分直接落地到ADS，供实时明细查询使用，一部分再发送到消息队列中，供下层计算使用；
第二层DWS公共实时汇总层
以数据域+业务域的理念建设公共汇总层，与离线数仓不同的是，这里汇总层分为轻度汇总层和高度汇总层，并同时产出，轻度汇总层写入ADS，用于前端产品复杂的olap查询场景，满足自助分析和产出报表的需求；高度汇总层写入Hbase，用于前端比较简单的kv查询场景，提升查询性能，比如实时大屏等；
> 注：
1.ADS是一款提供OLAP分析服务的引擎。开源提供类似功能的有，Elastic Search、Kylin、Druid等；
2.案例中选择把数据写入到Hbase供KV查询，也可根据情况选择其他引擎，比如数据量不多，查询压力也不大的话，可以用mysql
3.因主题建模与业务关系较大，这里不做描述
5.3 数据保障
集团每年都有双十一等大促，大促期间流量与数据量都会暴增。
实时系统要保证实时性，相对离线系统对数据量要更敏感，对稳定性要求更高。
所以为了应对这种场景，还需要在这种场景下做两种准备：
* 大促前的系统压测；
* 大促中的主备链路保障；
# 6\. 实时数仓与离线数仓的对比
在看过前面的叙述与菜鸟案例之后，我们看一下实时数仓与离线数仓在几方面的对比：
首先，从架构上，实时数仓与离线数仓有比较明显的区别，实时数仓以Kappa架构为主，而离线数仓以传统大数据架构为主。Lambda架构可以认为是两者的中间态。
其次，从建设方法上，实时数仓和离线数仓基本还是沿用传统的数仓主题建模理论，产出事实宽表。另外实时数仓中实时流数据的join有隐藏时间语义，在建设中需注意。
最后，从数据保障看，实时数仓因为要保证实时性，所以对数据量的变化较为敏感。在大促等场景下需要提前做好压测和主备保障工作，这是与离线数据的一个较为明显的区别。
> 如果觉得我写的不错，欢迎关注、点赞、收藏、转发，你们的支持就是动力！
