您似乎对数据仓库和大数据平台感兴趣，今天我们来谈谈如何创建实时仓库数量。 实时的数仓可以说是决定性的，能决定什么？ 决定你的报告和BI是否能实时表达数据。
1、数据仓库发展趋势1.1 数据仓库的趋势
我很少介绍数据仓库的概念。
数据仓库是随着企业信息化而发展起来的。 在企业信息化进程中，随着信息化工具的升级和新工具的应用，数据量越来越大，数据格式越来越多，决策要求越来越严格，数据仓库技术也在不断发展。
数据仓库发展趋势：
实时化数据仓库以满足实时自动化决策需求，大数据湖以支持大量复杂的数据类型
1.2 数据仓库的发展
数据仓库包括两个阶段：建立数据仓库和将其应用于数据仓库。
初始数据仓库的建立主要是指根据决策分析的要求对企业的业务数据库，如ERP、CRM、SCM等数据进行建模，并集成到数据仓库引擎中，其应用以报表为主，管理层和业务人员的意愿
随着业务和环境的发展，两者都在急剧变化。
随着IT技术走向互联网、移动化，数据源越来越丰富，在原始业务数据库的基础上出现了非结构化数据，如站点log、IoT设备数据、APP嵌入点数据等，这些数据是传统的结构
互联网的在线特性也迫使业务需求实时化，根据当前的顾客行为调整战略变得越来越普遍。 例如，大促进中的库存管理、运营管理等。 (即既有中长期战略型，也有短期操作型)。 此外，公司业务互联网化后，同时提供服务的客户急剧增加，有时难以人工完全应对，需要欺诈检测和用户审查等机器自动决策。
总之，对数据仓库的需求可以抽象为两个方面：实时生成结果、处理和存储大量异构数据。
2、数据仓库架构的演进从1990年Inmon提出数据仓库的概念到今天，数据架构是第一个传统的数据仓库3354离线数据仓库——离线大数据架构经历了Kappa架构以及Flink火热的流媒体批一体架构，数据架构技术不断演进，本质上是向流媒体批一体的方向发展，让用户能够以最自然、最小的成本实时完成
2.1 传统数仓架构
这是比较传统的方式，结构或半结构化数据通过离线ETL定期加载到离线数据中，然后通过计算引擎获取结果，供前端使用。 这里的脱机数仓计算引擎通常由大型业务数据库(如Oracle、DB2和Teradata )承担。
2.2 离线大数据架构
随着数据规模的增大，传统的数仓方式很难装载大量的数据。 随着大数据技术的普及，大数据技术被采用来承载存储和计算任务。 当然，也可以通过传递传统的数据库集群或MPP架构数据库来实现。 例如Hadoop Hive/Spark、Oracle RAC、GreenPlum等。
2.3 Lambda架构
随着业务的发展随着业务的发展人们对数据的实时性提出了更高的要求此时，出现了将要求实时性的部分分割，添加实时计算链接的Lambda架构。 从源头进行流媒体改造，将数据发送到消息队列，实时计算发动机消耗队列的数据，完成实时数据的增量计算。
同时，批量处理部分依然存在，实时和批量并行执行。 最终，统一数据服务层的集成结果将提供给前端。 一般基于批量处理结果，实时结果主要是高速响应。
2.4 Kappa架构
Lambda体系结构的一个严重问题是需要维护两个逻辑。 一部分由批处理引擎实现，一部分由流引擎实现，维护成本高。 另外，资源的消费量也很大。 之后诞生的Kappa架构是为了解决上述问题。 这能够在需要数据再现处理或数据变更的情况下通过历史数据的再现处理来进行。
方式通过上游播放完成(从数据源中提取数据并重新计算)。 Kappa体系结构的最大问题是流重新处理历史记录的吞吐量低于批处理，但这可以通过增加计算资源来弥补。
2.5混合架构
上述体系结构每个都有一个自适应场景，可能需要综合使用上述体系结构组合来满足实际需要。 当然，这将带来体系结构的复杂性。 用户必须根据自己的需要，进行取舍选择。 通常，大多数场景都可以使用单个体系结构来解决问题。 现在很多产品在流程批量一体、大量、实时性方面也非常优秀，可以考虑用这样的“全能之手”来解决问题。
3、三种大数据仓库体系结构3.1离线大数据体系结构
数据源将脱机导入脱机数据中。 下游APP应用程序根据业务需要选择直接读取DM，还是添加MySQL和Redis等数据服务。 数据仓库从模型级分为三个级别。
ODS，操作数据层，保存原始数据； 根据DWD、数据仓库详细级别、主题定义事实和维度表，保存粒度最细的事实数据；
DM，数据集市/轻度汇总层，在 DWD 层的基础之上根据不同的业务需求做轻度汇总；典型的数仓存储是 HDFS/Hive，ETL 可以是 MapReduce 脚本或 HiveSQL。
3.2 Lambda 架构
Lambda 架构问题：
同样的需求需要开发两套一样的代码：这是 Lambda 架构最大的问题，两套代码不仅仅意味着开发困难（同样的需求，一个在批处理引擎上实现，一个在流处理引擎上实现，还要分别构造数据测试保证两者结果一致），后期维护更加困难，比如需求变更后需要分别更改两套代码，独立测试结果，且两个作业需要同步上线。
资源占用增多：同样的逻辑计算两次，整体资源占用会增多，多出实时计算这部分
3.3 Kappa 架构
Lambda 架构虽然满足了实时的需求，但带来了更多的开发与运维工作，其架构背景是流处理引擎还不完善，流处理的结果只作为临时的、近似的值提供参考。后来随着 Flink 等流处理引擎的出现，流处理技术很成熟了，这时为了解决两套代码的问题，LickedIn 的 Jay Kreps 提出了 Kappa 架构。
Kappa 架构可以认为是 Lambda 架构的简化版（只要移除 lambda 架构中的批处理部分即可）。在 Kappa 架构中，需求修改或历史数据重新处理都通过上游重放完成。Kappa 架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。
Kappa 架构的重新处理过程：
3.4 Lambda 架构与 Kappa 架构的对比
在真实的场景中，很多时候并不是完全规范的 Lambda 架构或 Kappa 架构，可以是两者的混合，比如大部分实时指标使用 Kappa 架构完成计算，少量关键指标（比如金额相关）使用 Lambda 架构用批处理重新计算，增加一次校对过程。
Kappa 架构并不是中间结果完全不落地，现在很多大数据系统都需要支持机器学习（离线训练），所以实时中间结果需要落地对应的存储引擎供机器学习使用，另外有时候还需要对明细数据查询，这种场景也需要把实时明细层写出到对应的引擎中。后面案例会涉及到。
4、实时数仓建设思路
计算框架选型：storm/flink等实时计算框架，强烈推荐flink，其『批量合一』的特性及活跃的开源社区，有逐渐替代spark的趋势。
数据存储选型：首要考虑查询效率，其次是插入、更新等问题，可选择apache druid，不过在数据更新上存在缺陷，选型时注意该问题频繁更新的数据建议不要采用该方案。当然存储这块需要具体问题具体分析，不同场景下hbase、redis等都是可选项。
实时数仓分层：为更好的统一管理数据，实时数仓可采用离线数仓的数据模型进行分层处理，可以分为实时明细层写入druid等查询效率高的存储方便下游使用；轻度汇总层对数据进行汇总分析后供下游使用。
数据流转方案：实时数仓的数据来源可以为kafka消息队列，这样可以做到队列中的数据即可以写入数据湖用于批量分析，也可以实时处理，下游可以写入数据集市供业务使。
5、菜鸟实时数仓案例最后分享菜鸟仓配实时数据仓库的案例本，涉及全局设计、数据模型、数据保障等几个方面。
5.1 整体设计
整体设计如下图，基于业务系统的数据，数据模型采用中间层的设计理念，建设仓配实时数仓；计算引擎，选择更易用、性能表现更佳的实时计算作为主要的计算引擎；数据服务，选择天工数据服务中间件，避免直连数据库，且基于天工可以做到主备链路灵活配置秒级切换；数据应用，围绕大促全链路，从活动计划、活动备货、活动直播、活动售后、活动复盘五个维度，建设仓配大促数据体系。
5.2 数据模型
不管是从计算成本，还是从易用性，还是从复用性，还是从一致性等等，都必须避免烟囱式的开发模式，而是以中间层的方式建设仓配实时数仓。与离线中间层基本一致，将实时中间层分为两层。
第一层 DWD 公共实时明细层。实时计算订阅业务数据消息队列，然后通过数据清洗、多数据源 join、流式数据与离线维度信息等的组合，将一些相同粒度的业务系统、维表中的维度属性全部关联到一起，增加数据易用性和复用性，得到最终的实时明细数据。这部分数据有两个分支，一部分直接落地到 ADS，供实时明细查询使用，一部分再发送到消息队列中，供下层计算使用。
第二层 DWS 公共实时汇总层。以数据域+业务域的理念建设公共汇总层，与离线数仓不同的是，这里汇总层分为轻度汇总层和高度汇总层，并同时产出，轻度汇总层写入 ADS，用于前端产品复杂的 olap 查询场景，满足自助分析和产出报表的需求；高度汇总层写入 Hbase，用于前端比较简单的 kv 查询场景，提升查询性能，比如实时大屏等。
6、美团点评基于Flink的实时数仓平台实践下图所示的是美团点评实时计算平台的架构
最底层是收集层，这一层负责收集用户的实时数据，包括 Binlog、后端服务日志以及 IoT 数据，经过日志收集团队和 DB 收集团队的处理，数据将会被收集到 Kafka 中。这些数据不只是参与实时计算，也会参与离线计算。
收集层之上是存储层，这一层除了使用 Kafka 做消息通道之外，还会基于 HDFS 做状态数据存储以及基于 HBase 做维度数据的存储。
存储层之上是引擎层，包括 Storm 和 Flink。实时计算平台会在引擎层为用户提供一些框架的封装以及公共包和组件的支持。
在引擎层之上就是平台层了，平台层从数据、任务和资源三个视角去管理。
架构的最上层是应用层，包括了实时数仓、机器学习、数据同步以及事件驱动应用等。
从功能角度来看，美团点评的实时计算平台主要包括作业和资源管理两个方面的功能。其中，作业部分包括作业配置、作业发布以及作业状态三个方面的功能。
在作业配置方面，则包括作业设置、运行时设置以及拓扑结构设置；在作业发布方面，则包括版本管理、编译/发布/回滚等；作业状态则包括运行时状态、自定义指标和报警以及命令/运行时日志等。在资源管理方面，则为用户提供了多租户资源隔离以及资源交付和部署的能力。
7、实时数仓与离线数仓的对比在看过前面的案例之后，我们看一下实时数仓与离线数仓在几方面的对比：
首先，从架构上，实时数仓与离线数仓有比较明显的区别，实时数仓以 Kappa 架构为主，而离线数仓以传统大数据架构为主。Lambda 架构可以认为是两者的中间态。
其次，从建设方法上，实时数仓和离线数仓基本还是沿用传统的数仓主题建模理论，产出事实宽表。另外实时数仓中实时流数据的 join 有隐藏时间语义，在建设中需注意。
最后，从数据保障看，实时数仓因为要保证实时性，所以对数据量的变化较为敏感。在大促等场景下需要提前做好压测和主备保障工作，这是与离线数据的一个较为明显的区别。
综上，实时数仓主要解决数据时效性问题，结合机器学习框架可以处理实时推荐、实时获取广告投放效果等智能化业务场景。实时数仓的建设应早日提上日程，未来企业对数据时效性的要求会越来越高，实时数仓会很好的解决该问题。