讲师介绍
王雪峰，Cloudera资深数仓架构师，加入Cloudera之前曾在Teradata公司担任7年的数仓架构师，在大数据和数据仓库领域十余年工作经验，目前负责大中华区所有合作伙伴及商业客户的技术支持和方案架构设计。
以下内容为雪峰老师分享内容整理而成
首先感谢数澜提供这次机会，也谢谢大家有来参加这样一个分享啊，那先简单介绍一下我自己，我叫王雪峰，是cloudera这边的渠道和用户工程师，主要是负责所有中国的合作伙伴和商业用户，为他们提供一些解决方案和一些技术支持。
今天会议的整个的议程差不多分成这五个部分。
第一部分呢，我会介绍一下实时数仓发展的阶段，他怎么一步步演化过来的；接着我们看一下通用的实时数仓的分析架构是什么样子的；接下来，因为我是在Cloudera这边，所以会给大家看看Cloudera是如何建设实时数仓的，我们去对实时数仓的场景做了一个分类。也会介绍Cloudera的实时数仓的体系架构，以及介绍一些实时数仓架构的组件，通过这些帮助大家对技术产生了解。
01 实时数仓发展结构
数据仓库的概念是于 90 年代由 Bill Inmon 提出, 当时的背景是传统的 OLTP 数据库无法很好的支持长周期分析决策场景，所以数据仓库概念的 4 个核心点，我们要结合着 OLTP 数据库当时的状态来对比理解。
1）面向主题：数据仓库的数据组织方式与 OLTP 面向事务处理不同。因为数据仓库是面向分析决策的，所以数据经常按分析场景或者是分析对象等主题形式来组织。
2）集成：对于数据仓库来说，经常需要去集合多个分散的、异构的数据源，做一些数据清洗等 ETL 处理，整合成一块数据仓库，OLTP 则不需要做类似的集成操作。
3）相对稳定：OLTP 数据库一般都是面向业务的，它主要的作用是把当前的业务状态精准的反映出来，所以 OLTP 数据库需要支持大量的增、删、改的操作。但是对于数据仓库来说，只要是入仓存下来的数据，一般使用场景都是查询，因此数据是相对稳定的。
4）反映历史变化：数据仓库是反映历史变化的数据集合，可以理解成它会将历史的一些数据的快照存下来。而对于 OLTP 数据库来说，只要反映当时的最新的状态就可以了。
以上这 4 个点是数据仓库的一个核心的定义。
由上图可以看出离线数仓有三个核心环节。
第一个环节是数据源部分，一般公司的数据源主要有三类：
1）第1类是通过在客户端埋点上报，收集用户的行为日志，以及一些后端日志的日志类型数据源。对于埋点行为日志来说，一般会经过一个这样的流程，首先数据会上报到 Nginx 然后经过 Flume 收集，然后存储到 Kafka 这样的消息队列，然后再由实时或者离线的一些拉取的任务，拉取到我们的离线数据仓库 HDFS。
2）第2类数据源是业务数据库，而对于业务数据库的话，一般会经过 Canal 收集它的 binlog，然后也是收集到消息队列中，最终再由 Camus 拉取到 HDFS。
3） 第三类其他数据源可以包括外购数据源、爬虫等。
这三部分数据源最终都会落地到 HDFS 中的 ODS 层，也叫贴源数据层，这层数据和原始数据源是保持一致的。
第二个环节是离线数据仓库，是图中蓝色的框展示的部分。可以看到它是一个分层的结构，其中的模型设计是依据维度建模思路。
1）最底层是 ODS 层，这一层将数据保持无信息损失的存放在 HDFS，基本保持原始的日志数据不变。
2） 在 ODS 层之上，一般会进行统一的数据清洗、归一，就得到了 DWD 明细数据层。这一层也包含统一的维度数据。
3）然后基于 DWD 明细数据层，我们会按照一些分析场景、分析实体等去组织我们的数据，组织成一些分主题的汇总数据层 DWS。
4）在 DWS 之上，我们会面向应用场景去做一些更贴近应用的 APP 应用数据层，这些数据应该是高度汇总的，并且能够直接导入到我们的应用服务去使用。
在中间的离线数据仓库的生产环节，一般都是采用一些离线生产的架构引擎，比如说 MapReduce、Hive、Spark 等等，数据一般是存在 HDFS 上。
经过前两个环节后，我们的一些应用层的数据会存储到数据服务里，比如说 HBase 、Redis、Kylin 这样的一些 KV 的存储。并且会针对存在这些数据存储上的一些数据，封装对应的服务接口，对外提供服务。在最外层我们会去产出一些面向业务的报表、面向分析的数据产品，以及会支持线上的一些业务产品等等。这一层的话，称之为更贴近业务端的数据应用部分。
越来越多的客户要求的功能是：
1）分析实时数据、近实时数据和历史数据
2）跨数据域的相关性，即使这些数据域不是传统上存储在一起的（例如：实时客户事件数据与CRM数据一起；网络传感器数据与市场营销活动管理数据一起）
3）“大数据”的极端规模，但具有“小数据”的体验和语义
4） 将以上所有内容集成到一个安全的集成平台中
推动这一趋势的因素包括技术、业务和文化。
l 在技术方面，比以往任何时候都更便宜，更轻松地检测所有内容并通过消息传递系统实时发送数据。
l 在业务方面，公司和政府正在将其尽可能多的业务数字化和自动化，以使决策和资产管理更加有效。
l 在文化方面，人们希望能够立即获得所需的答案，而不必去问别人（感谢Google和Wikipedia）。
描述RTDW的最简单方法是，其外观在感觉上就像是普通的数据仓库，但是所有的一切都会变的更快，即使保持更大规模的数据上。这是数据仓库现代化的一种类型，可让您具有“小数据”语义和“大数据”规模的性能。
1）数据以更快的速度到达仓库–认为每秒数百万个事件的流媒体数据不断到达
2）数据可最佳查询所需的时间更快-到达后立即进行查询，无需进行处理、聚合或压缩
3）查询运行的速度更快–小型选择性查询以10或100毫秒为单位进行衡量；大型、扫描或计算繁重的查询以很高的带宽处理
4） 必要时，数据变化的很快-如果由于某种原因需要校正或更新数据，则无需大量重写即可就地完成。
尽管这听起来似乎很明显，甚至有些琐碎，但数十年来的数据仓库却显示出了其他情况。对于大量快速到达的数据，要保持交互性能非常困难，其中一些数据可能需要更新，并且需要使用大量不同模式的查询。
Cloudera提供了RTDW功能，可以在所有这些框中打勾。因此，许多客户正在构建RTDW应用程序，这是他们使用Cloudera现代化数据仓库实践的总体策略的一部分。
这个架构是 Storm 的作者提出来的，其实 Lambda 架构的主要思路是在原来离线数仓架构的基础上叠加上实时数仓的部分，然后将离线的存量数据与我们 t+0 的实时的数据做一个 merge，就可以产生数据状态实时更新的结果。
l 和上述离线数据仓库架构图比较可以明显的看到，实时数仓增加的部分是上图黄色的这块区域。我们一般会把实时数仓数据放在 Kafka 这样的消息队列上，也会有维度建模的一些分层，但是在汇总数据的部分，我们不会将 APP 层的一些数据放在实时数仓，而是更多的会移到数据服务侧去做一些计算。
l 然后在实时计算的部分，我们经常会使用 Flink、Spark-streaming 和 Storm 这样的计算引擎，时效性上，由原来的天级、小时级可以提升到秒级、分钟级。
大家也可以看到这个架构图中，中间数据仓库环节有两个部分，一个是离线的数据仓库，一个是实时的数据仓库。
我们必须要运维两套（实时计算和离线计算）引擎，并且在代码层面，我们也需要去实现实时和离线的业务代码。
然后在合并的时候，我们需要保证实施和离线的数据一致性，所以但凡我们的代码做变更，我们也需要去做大量的这种实时离线数据的对比和校验。
其实这对于不管是资源还是运维成本来说都是比较高的。这是 Lamda 架构上比较明显和突出的一个问题。因此就产生了 Kappa 结构。
Kappa 架构的一个主要的思路就是在数仓部分移除了离线数仓，数仓的生产全部采用实时数仓。从上图可以看到刚才中间的部分，离线数仓模块已经没有了。
关于Kappa架构，业务变更会导致口径变更，这样就需要重算，甚至重刷历史数据。Kappa 架构的解决思路是：首先要准备好一个能够存储历史数据的消息队列，比如 Kafka，并且这个消息对列是可以支持你从某个历史的节点重新开始消费的。
接着需要新起一个任务，从原来比较早的一个时间节点去消费 Kafka 上的数据，然后当这个新的任务运行的进度已经能够和现在的正在跑的任务齐平的时候，你就可以把现在任务的下游切换到新的任务上面，旧的任务就可以停掉，并且原来产出的结果表也可以被删掉。
随着我们现在实时 OLAP 技术的一些提升，有一个新的实时架构被提了出来，这里暂且称为实时 OLAP 变体。
这个思路是把大量的聚合、分析、计算由实时 OLAP 引擎来承担。在实时数仓计算的部分，我们不需要做的特别重，尤其是聚合相关的一些逻辑，然后这样就可以保障我们在数据应用层能灵活的面对各种业务分析的需求变更，整个架构更加灵活。
这是整体三个关于实时数仓架构的一个对比：
1）从计算引擎角度：Lamda 架构它需要去维护批流两套计算引擎，Kappa 架构和实时 OLAP 变体只需要维护流计算引擎就好了。
2）开发成本：对 Lamda 架构来说，因为它需要维护实时离线两套代码，所以它的开发成本会高一些。Kappa 架构和实时 OLAP 变体只用维护一套代码就可以了。
3） 分析灵活性：实时 OLAP 变体是相对最灵活的。
4）在实时 OLAP 引擎依赖上：实时 OLAP 变体是强依赖实时 OLAP 变体引擎的能力的，前两者则不强依赖。
5）计算资源：Lamda 架构需要批流两套计算资源，Kappa 架构只需要流计算资源，实时 OLAP 变体需要额外的 OLAP 资源。
6）逻辑变更重算：Lamda 架构是通过批处理来重算的，Kappa 架构需要按照前面介绍的方式去重新消费消息队列重算，实时 OLAP 变体也需要重新消费消息队列，并且这个数据还要重新导入到 OLAP 引擎里，去做计算。
然后我们来看一下传统数仓和实时数仓整体的差异。
l 首先从时效性来看：离线数仓是支持小时级和天级的，实时数仓到秒级分钟级，所以实时数仓时效性是非常高的。
l 在数据存储方式来看：离线数仓它需要存在HDFS和RDS上面，实时数仓一般是存在消息队列，还有一些kv存储，像维度数据的话会更多的存在kv存储上。
l 在生产加工过程方面，离线数仓需要依赖离线计算引擎以及离线的调度。但对于实时数仓来说，主要是依赖实时计算引擎。
02 通用的实时数仓分析架构
实时数据处理的本质是在在无界流且未知状态下的一种尽可能快速处理和汇总计算，对于数据处理上主要有逐条处理和窗口汇总两种方式。
多流join最大的问题就是跨窗口问题，会导致晚到的数据无法关联上，而全局join又会导致state存储问题，因此更多是将多流join转换为流与维表之间的join，一般使用left join，将维表放在内存/redis/mysql中。维表数据量大，放在hbase中。如果是广播方式，使用kafka维表。
