案例与解决方案汇总页：

阿里云实时计算产品案例&解决方案汇总

https://yq.aliyun.com/articles/691499

PPT见附件

1.资料仓库简介

资料仓库是一个面向主题的（Subject Oriented）、整合的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的资料集合，用于支援管理决策。

资料仓库是伴随着企业资讯化发展起来的，在企业资讯化的过程中，随着资讯化工具的升级和新工具的应用，资料量变的越来越大，资料格式越来越多，决策要求越来越苛刻，资料仓库技术也在不停的发展。

资料仓库的趋势：

实时资料仓库以满足实时化&自动化决策需求；大资料&资料湖以支援大量&复杂资料型别（文字、影象、视讯、音讯）；

2.资料仓库的发展

资料仓库有两个环节：资料仓库的构建与资料仓库的应用。

早期资料仓库构建主要指的是把企业的业务数据库如ERP、CRM、SCM等资料按照决策分析的要求建模并汇总到资料仓库引擎中，其应用以报表为主，目的是支援管理层和业务人员决策（中长期策略型决策）。

随着业务和环境的发展，这两方面都在发生著剧烈变化。

随着IT技术走向互联网、移动化，资料来源变得越来越丰富，在原来业务数据库的基础上出现了非结构化资料，比如网站log，IoT装置资料，APP埋点资料等，这些资料量比以往结构化的资料大了几个量级，对ETL过程、储存都提出了更高的要求；互联网的线上特性也将业务需求推向了实时化，随时根据当前客户行为而调整策略变得越来越常见，比如大促过程中库存管理，运营管理等（即既有中远期策略型，也有短期操作型）；同时公司业务互联网化之后导致同时服务的客户剧增，有些情况人工难以完全处理，这就需要机器自动决策。比如欺诈检测和使用者稽核。

总结来看，对资料仓库的需求可以抽象成两方面：实时产生结果、处理和储存大量异构资料。

注：这里不讨论资料湖技术。

3.资料仓库建设方法论

1）面向主题

从公司业务出发，是分析的宏观领域，比如供应商主题、商品主题、客户主题和仓库主题

2）为多维资料分析服务

资料报表；资料立方体，上卷、下钻、切片、旋转等分析功能。

3）反正规化资料模型

以事实表和维度表组成的星型资料模型

注：图片来自51CTO

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 资料保障

集团每年都有双十一等大促，大促期间流量与资料量都会暴增。

实时系统要保证实时性，相对离线系统对资料量要更敏感，对稳定性要求更高。

所以为了应对这种场景，还需要在这种场景下做两种准备：

大促前的系统压测；大促中的主备链路保障；