数据仓库介绍与实时数仓案例

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架构
实时性	实时	实时
计算资源	批和流同时运行，资源开销大	只有流处理，仅针对新需求开发阶段运行两个做业，资源开销小
从新计算时吞吐	批式全量处理，吞吐较高	流式全量处理，吞吐较批处理低
开发、测试	每一个需求都须要两套不一样代码，开发、测试、上线难度较大	只需实现一套代码，开发、测试、上线难度相对较小
运维成本	维护两套系统（引擎），运维成本大	只需维护一套系统（引擎），运维成本小

在真实的场景中，不少时候并非彻底规范的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有隐藏时间语义，在建设中需注意。

最后，从数据保障看，实时数仓由于要保证明时性，因此对数据量的变化较为敏感。在大促等场景下须要提早作好压测和主备保障工做，这是与离线数据的一个较为明显的区别。

原文连接 本文为云栖社区原创内容，未经容许不得转载。