数据仓库简介、发展、架构演进、实时数仓建设、与离线数仓对比
- - zhisheng的博客数据仓库也是公司数据发展到一定规模后必然会提供的一种基础服务，数据仓库的建设也是“数据智能”中必不可少的一环. 本文将从数据仓库的简介、经历了怎样的发展、如何建设、架构演变、应用案例以及实时数仓与离线数仓的对比六个方面全面分享关于数仓的详细内容. 原地地址： https://ververica.cn/developers/how-to-do-real-time-counting/.
数据仓库简介、发展、架构演进、实时数仓建设、与离线数仓对比
标签：
Flink
大数据
流式计算
| 发表时间：2019-11-23 00:00 | 作者：
出处：http://www.54tianzhisheng.cn/
数据仓库也是公司数据发展到一定规模后必然会提供的一种基础服务，数据仓库的建设也是“数据智能”中必不可少的一环。本文将从数据仓库的简介、经历了怎样的发展、如何建设、架构演变、应用案例以及实时数仓与离线数仓的对比六个方面全面分享关于数仓的详细内容。
本文作者：郭华（付空）
原地地址： https://ververica.cn/developers/how-to-do-real-time-counting/
1. 数据仓库简介
数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策。
数据仓库是伴随着企业信息化发展起来的，在企业信息化的过程中，随着信息化工具的升级和新工具的应用，数据量变的越来越大，数据格式越来越多，决策要求越来越苛刻，数据仓库技术也在不停的发展。
数据仓库的趋势：
-
实时数据仓库以满足实时化&自动化决策需求；
-
大数据&数据湖以支持大量&复杂数据类型（文本、图像、视频、音频）；
2. 数据仓库的发展
数据仓库有两个环节：数据仓库的构建与数据仓库的应用。
早期数据仓库构建主要指的是把企业的业务数据库如 ERP、CRM、SCM 等数据按照决策分析的要求建模并汇总到数据仓库引擎中，其应用以报表为主，目的是支持管理层和业务人员决策（中长期策略型决策）。
随着业务和环境的发展，这两方面都在发生着剧烈变化。
-
随着IT技术走向互联网、移动化，数据源变得越来越丰富，在原来业务数据库的基础上出现了非结构化数据，比如网站 log，IoT 设备数据，APP 埋点数据等，这些数据量比以往结构化的数据大了几个量级，对 ETL 过程、存储都提出了更高的要求；
-
互联网的在线特性也将业务需求推向了实时化，随时根据当前客户行为而调整策略变得越来越常见，比如大促过程中库存管理，运营管理等（即既有中远期策略型，也有短期操作型）；同时公司业务互联网化之后导致同时服务的客户剧增，有些情况人工难以完全处理，这就需要机器自动决策。比如欺诈检测和用户审核。
总结来看，对数据仓库的需求可以抽象成两方面：实时产生结果、处理和保存大量异构数据。
注：这里不讨论数据湖技术。
3. 数据仓库建设方法论
3.1 面向主题
从公司业务出发，是分析的宏观领域，比如供应商主题、商品主题、客户主题和仓库主题
3.2 为多维数据分析服务
数据报表；数据立方体，上卷、下钻、切片、旋转等分析功能。
3.3 反范式数据模型
以事实表和维度表组成的星型数据模型
4. 数据仓库架构的演变
数据仓库概念是 Inmon 于 1990 年提出并给出了完整的建设方法。随着互联网时代来临，数据量暴增，开始使用大数据工具来替代经典数仓中的传统工具。此时仅仅是工具的取代，架构上并没有根本的区别，可以把这个架构叫做 离线大数据架构。
后来随着业务实时性要求的不断提高，人们开始在离线大数据架构基础上加了一个加速层，使用流处理技术直接完成那些实时性要求较高的指标计算，这便是 Lambda 架构。
再后来，实时的业务越来越多，事件化的数据源也越来越多，实时处理从次要部分变成了主要部分，架构也做了相应调整，出现了以实时事件处理为核心的 Kappa 架构。
4.1 离线大数据架构
数据源通过离线的方式导入到离线数仓中。下游应用根据业务需求选择直接读取 DM 或加一层数据服务，比如 MySQL 或 Redis。数据仓库从模型层面分为三层：
ODS，操作数据层，保存原始数据；
-
DWD，数据仓库明细层，根据主题定义好事实与维度表，保存最细粒度的事实数据；
-
DM，数据集市/轻度汇总层，在 DWD 层的基础之上根据不同的业务需求做轻度汇总；
-
典型的数仓存储是 HDFS/Hive，ETL 可以是 MapReduce 脚本或 HiveSQL。
4.2 Lambda 架构
随着大数据应用的发展，人们逐渐对系统的实时性提出了要求，为了计算一些实时指标，就在原来离线数仓的基础上增加了一个实时计算的链路，并对数据源做流式改造（即把数据发送到消息队列），实时计算去订阅消息队列，直接完成指标增量的计算，推送到下游的数据服务中去，由数据服务层完成离线&实时结果的合并。
注：流处理计算的指标批处理依然计算，最终以批处理为准，即每次批处理计算后会覆盖流处理的结果。（这仅仅是流处理引擎不完善做的折中）
Lambda 架构问题：
-
同样的需求需要开发两套一样的代码：这是 Lambda 架构最大的问题，两套代码不仅仅意味着开发困难（同样的需求，一个在批处理引擎上实现，一个在流处理引擎上实现，还要分别构造数据测试保证两者结果一致），后期维护更加困难，比如需求变更后需要分别更改两套代码，独立测试结果，且两个作业需要同步上线。
-
资源占用增多：同样的逻辑计算两次，整体资源占用会增多（多出实时计算这部分
4.3 Kappa 架构
Lambda 架构虽然满足了实时的需求，但带来了更多的开发与运维工作，其架构背景是流处理引擎还不完善，流处理的结果只作为临时的、近似的值提供参考。后来随着 Flink 等流处理引擎的出现，流处理技术很成熟了，这时为了解决两套代码的问题，LickedIn 的 Jay Kreps 提出了 Kappa 架构。
-
Kappa 架构可以认为是 Lambda 架构的简化版（只要移除 lambda 架构中的批处理部分即可）。
-
在 Kappa 架构中，需求修改或历史数据重新处理都通过上游重放完成。
-
Kappa 架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。
Kappa 架构的重新处理过程：
重新处理是人们对 Kappa 架构最担心的点，但实际上并不复杂：
-
选择一个具有重放功能的、能够保存历史数据并支持多消费者的消息队列，根据需求设置历史数据保存的时长，比如 Kafka，可以保存全部历史数据。
-
当某个或某些指标有重新处理的需求时，按照新逻辑写一个新作业，然后从上游消息队列的最开始重新消费，把结果写到一个新的下游表中。
-
当新作业赶上进度后，应用切换数据源，读取 2 中产生的新结果表。
-
停止老的作业，删除老的结果表。
4.4 Lambda 架构与 Kappa 架构的对比
-
在真实的场景中，很多时候并不是完全规范的 Lambda 架构或 Kappa 架构，可以是两者的混合，比如大部分实时指标使用 Kappa 架构完成计算，少量关键指标（比如金额相关）使用 Lambda 架构用批处理重新计算，增加一次校对过程。
-
Kappa 架构并不是中间结果完全不落地，现在很多大数据系统都需要支持机器学习（离线训练），所以实时中间结果需要落地对应的存储引擎供机器学习使用，另外有时候还需要对明细数据查询，这种场景也需要把实时明细层写出到对应的引擎中。参考后面的案例。
-
另外，随着数据多样性的发展，数据仓库这种提前规定 schema 的模式显得越来难以支持灵活的探索&分析需求，这时候便出现了一种数据湖技术，即把原始数据全部缓存到某个大数据存储上，后续分析时再根据需求去解析原始数据。简单的说，数据仓库模式是 schema on write，数据湖模式是 schema on read。
5. 实时数仓案例
菜鸟仓配实时数据仓库本案例参考自菜鸟仓配团队的分享，涉及全局设计、数据模型、数据保障等几个方面。
注：特别感谢缘桥同学的无私分享。
5.1 整体设计
整体设计如下图，基于业务系统的数据，数据模型采用中间层的设计理念，建设仓配实时数仓；计算引擎，选择更易用、性能表现更佳的实时计算作为主要的计算引擎；数据服务，选择天工数据服务中间件，避免直连数据库，且基于天工可以做到主备链路灵活配置秒级切换；数据应用，围绕大促全链路，从活动计划、活动备货、活动直播、活动售后、活动复盘五个维度，建设仓配大促数据体系。
5.2 数据模型
不管是从计算成本，还是从易用性，还是从复用性，还是从一致性等等，我们都必须避免烟囱式的开发模式，而是以中间层的方式建设仓配实时数仓。与离线中间层基本一致，我们将实时中间层分为两层。
第一层 DWD 公共实时明细层
实时计算订阅业务数据消息队列，然后通过数据清洗、多数据源 join、流式数据与离线维度信息等的组合，将一些相同粒度的业务系统、维表中的维度属性全部关联到一起，增加数据易用性和复用性，得到最终的实时明细数据。这部分数据有两个分支，一部分直接落地到 ADS，供实时明细查询使用，一部分再发送到消息队列中，供下层计算使用；
第二层 DWS 公共实时汇总层
以数据域+业务域的理念建设公共汇总层，与离线数仓不同的是，这里汇总层分为轻度汇总层和高度汇总层，并同时产出，轻度汇总层写入 ADS，用于前端产品复杂的 olap 查询场景，满足自助分析和产出报表的需求；高度汇总层写入 Hbase，用于前端比较简单的 kv 查询场景，提升查询性能，比如实时大屏等；
注：
- ADS 是一款提供 OLAP 分析服务的引擎。开源提供类似功能的有，Elastic Search、Kylin、Druid 等；
- 案例中选择把数据写入到 Hbase 供 KV 查询，也可根据情况选择其他引擎，比如数据量不多，查询压力也不大的话，可以用 MySQL；
- 因主题建模与业务关系较大，这里不做描述；
5.3 数据保障
阿里巴巴每年都有双十一等大促，大促期间流量与数据量都会暴增。实时系统要保证实时性，相对离线系统对数据量要更敏感，对稳定性要求更高。所以为了应对这种场景，还需要在这种场景下做两种准备：
大促前的系统压测；
大促中的主备链路保障；
菜鸟双11「仓储配送数据实时化」详情了解： https://yq.aliyun.com/articles/658787
6. 实时数仓与离线数仓的对比
在看过前面的叙述与菜鸟案例之后，我们看一下实时数仓与离线数仓在几方面的对比：
-
首先，从架构上，实时数仓与离线数仓有比较明显的区别，实时数仓以 Kappa 架构为主，而离线数仓以传统大数据架构为主。Lambda 架构可以认为是两者的中间态。
-
其次，从建设方法上，实时数仓和离线数仓基本还是沿用传统的数仓主题建模理论，产出事实宽表。另外实时数仓中实时流数据的 join 有隐藏时间语义，在建设中需注意。
-
最后，从数据保障看，实时数仓因为要保证实时性，所以对数据量的变化较为敏感。在大促等场景下需要提前做好压测和主备保障工作，这是与离线数据的一个较为明显的区别。
关注我
微信公众号： zhisheng
另外我自己整理了些 Flink 的学习资料，目前已经全部放到微信公众号（zhisheng）了，你可以回复关键字： Flink 即可无条件获取到。另外也可以加我微信 你可以加我的微信： yuanblog_tzs，探讨技术！
更多私密资料请加入知识星球！
专栏介绍
扫码下面专栏二维码可以订阅该专栏
首发地址： http://www.54tianzhisheng.cn/2019/11/15/flink-in-action/
专栏地址： https://gitbook.cn/gitchat/column/5dad4a20669f843a1a37cb4f
Github 代码仓库
https://github.com/zhisheng17/flink-learning/
以后这个项目的所有代码都将放在这个仓库里，包含了自己学习 flink 的一些 demo 和博客
博客
1、 Flink 从0到1学习 —— Apache Flink 介绍
2、 Flink 从0到1学习 —— Mac 上搭建 Flink 1.6.0 环境并构建运行简单程序入门
3、 Flink 从0到1学习 —— Flink 配置文件详解
4、 Flink 从0到1学习 —— Data Source 介绍
5、 Flink 从0到1学习 —— 如何自定义 Data Source ？
6、 Flink 从0到1学习 —— Data Sink 介绍
7、 Flink 从0到1学习 —— 如何自定义 Data Sink ？
8、 Flink 从0到1学习 —— Flink Data transformation(转换)
9、 Flink 从0到1学习 —— 介绍 Flink 中的 Stream Windows
10、 Flink 从0到1学习 —— Flink 中的几种 Time 详解
11、 Flink 从0到1学习 —— Flink 读取 Kafka 数据写入到 ElasticSearch
12、 Flink 从0到1学习 —— Flink 项目如何运行？
13、 Flink 从0到1学习 —— Flink 读取 Kafka 数据写入到 Kafka
14、 Flink 从0到1学习 —— Flink JobManager 高可用性配置
15、 Flink 从0到1学习 —— Flink parallelism 和 Slot 介绍
16、 Flink 从0到1学习 —— Flink 读取 Kafka 数据批量写入到 MySQL
17、 Flink 从0到1学习 —— Flink 读取 Kafka 数据写入到 RabbitMQ
18、 Flink 从0到1学习 —— Flink 读取 Kafka 数据写入到 HBase
19、 Flink 从0到1学习 —— Flink 读取 Kafka 数据写入到 HDFS
20、 Flink 从0到1学习 —— Flink 读取 Kafka 数据写入到 Redis
21、 Flink 从0到1学习 —— Flink 读取 Kafka 数据写入到 Cassandra
22、 Flink 从0到1学习 —— Flink 读取 Kafka 数据写入到 Flume
23、 Flink 从0到1学习 —— Flink 读取 Kafka 数据写入到 InfluxDB
24、 Flink 从0到1学习 —— Flink 读取 Kafka 数据写入到 RocketMQ
25、 Flink 从0到1学习 —— 你上传的 jar 包藏到哪里去了
26、 Flink 从0到1学习 —— 你的 Flink job 日志跑到哪里去了
28、 Flink 从0到1学习 —— Flink 中如何管理配置？
29、 Flink 从0到1学习—— Flink 不可以连续 Split(分流)？
30、 Flink 从0到1学习—— 分享四本 Flink 国外的书和二十多篇 Paper 论文
31、 Flink 架构、原理与部署测试
32、 为什么说流处理即未来？
33、 OPPO 数据中台之基石：基于 Flink SQL 构建实时数据仓库
35、 Flink状态管理和容错机制介绍
36、 Apache Flink 结合 Kafka 构建端到端的 Exactly-Once 处理
38、 如何基于Flink+TensorFlow打造实时智能异常检测平台？只看这一篇就够了
40、 Flink 全网最全资源（视频、博客、PPT、入门、原理、实战、性能调优、源码解析、问答等持续更新）
42、 Flink 从0到1学习 —— 如何使用 Side Output 来分流？
源码解析
4、 Flink 源码解析 —— standalone session 模式启动流程
5、 Flink 源码解析 —— Standalone Session Cluster 启动流程深度分析之 Job Manager 启动
6、 Flink 源码解析 —— Standalone Session Cluster 启动流程深度分析之 Task Manager 启动
7、 Flink 源码解析 —— 分析 Batch WordCount 程序的执行过程
8、 Flink 源码解析 —— 分析 Streaming WordCount 程序的执行过程
9、 Flink 源码解析 —— 如何获取 JobGraph？
10、 Flink 源码解析 —— 如何获取 StreamGraph？
11、 Flink 源码解析 —— Flink JobManager 有什么作用？
12、 Flink 源码解析 —— Flink TaskManager 有什么作用？
13、 Flink 源码解析 —— JobManager 处理 SubmitJob 的过程
14、 Flink 源码解析 —— TaskManager 处理 SubmitJob 的过程
15、 Flink 源码解析 —— 深度解析 Flink Checkpoint 机制
16、 Flink 源码解析 —— 深度解析 Flink 序列化机制
17、 Flink 源码解析 —— 深度解析 Flink 是如何管理好内存的？
18、 Flink Metrics 源码解析 —— Flink-metrics-core
19、 Flink Metrics 源码解析 —— Flink-metrics-datadog
20、 Flink Metrics 源码解析 —— Flink-metrics-dropwizard
21、 Flink Metrics 源码解析 —— Flink-metrics-graphite
22、 Flink Metrics 源码解析 —— Flink-metrics-influxdb
23、 Flink Metrics 源码解析 —— Flink-metrics-jmx
24、 Flink Metrics 源码解析 —— Flink-metrics-slf4j
25、 Flink Metrics 源码解析 —— Flink-metrics-statsd
26、 Flink Metrics 源码解析 —— Flink-metrics-prometheus
相关 [数据仓库 简介 发展] 推荐：
从数据仓库系统对比看Hive发展前景
- - 技术改变世界 创新驱动中国 - 《程序员》官网大数据时代的信息爆炸，使得分布式/并行处理变得如此重要. 无论是传统行业，还是新兴行业（特别是互联网行业），日常业务运行所产生的海量用户和服务数据都需要更大的硬件资源来处理. 需要并行处理的应用领域主要为网页搜索、广告投放和机器翻译等. 从单机应用到集群应用的过渡中，诞生了MapReduce这样的分布式框架，简化了并行程序的开发，提供了水平扩展和容错能力.
数据仓库
- Ran - Linux@SOHU翻译：马少兵、曾怀东、朱翊然、林业. 尽管服务器存储、处理能力得到有效的提高，以及服务器价格的降低，让人们能够负担起大量的服务器，但是商业软件应用和监控工具快速的增加，还是使得人们被大量的数据所困扰. 在数据仓库领域中的许多系统管理员、应用开发者，以及初级数据库管理员发现，他们正在处理“海量数据”-不管你准备与否-都会有好多不熟悉的术语，概念或工具.
数据仓库概念
- - 互联网 - ITeye博客数据仓库：是一个数据库环境，它提供用户用于决策支持的当前和历史数据，这些数据在传统的数据库中不方便得到. 特点：面向主题，集成的，相对稳定的，反应历史变化的. 组成：数据仓库的数据库，数据抽取工具，元数据，访问工具，数据集市，数据仓库管理，信息发布系统. 数据挖掘：就是从大量数据中获取有效的，新颖的，潜在有用的，最终可理解的模式的过程.
大数据仓库－kudu
- - 数据库 - ITeye博客数据仓库里面存储引擎是非常重要的，存储引擎的好坏，基本决定了整个数仓的基础. cloudera公司最近发布了一个kudu存储引擎. 按照cloudera的想法，kudu的出现是为了解决，hbase,parquet不能兼顾分析和更新的需求，所以需要一个新的存储引擎可以同时支持高吞吐的分析应用以及少量更新的应用.
数据仓库的设计与开发
- - 数据库 - ITeye博客 数据仓库系统的设计与开发. 1) 收集和分析业务需求. 用户需求，管理人员需求. 2) 建立数据模型和数据仓库的物理设计. 概念模型，逻辑模型，物理模型. 3) 定义数据源. 数据源面向应用，不是面向主题，而且数据源之间存在多个不一致的情况，所以必须在已有的系统中定义记录系统（内容正确，在多个数据源间起决定作用的操作型数据源）.
oracle数据仓库设计指南
- - 数据库 - ITeye博客ODS（Operational Data Store）是数据仓库体系结构中的一个可选部分，ODS具备数据仓库的部分特征和OLTP系统的部分特征，它是“面向主题的、集成的、当前或接近当前的、不断变化的”数据. 一般在带有ODS的系统体系结构中，ODS都设计为如下几个作用：. 1 ） 在业务系统和数据仓库之间形成一个隔离层.
[原]数据仓库元数据管理
- - oycn2010的专栏元数据管理,
简单的做就是EXCEL结合版本管理等传统工具管理,
专业点就用专门的元数据管理工具;. 数据字典-->
数据知识库. 业务元数据，技术元数据，管理元数据. 参照：SAP元数据管理平台：按业务（角色）分类，按技术类型分类（特征，关键值，DSO,InfoCube），数据流程图. 按照传统的定义，元数据（Metadata）是关于数据的数据.
[原]数据仓库构建步骤
- - oycn2010的专栏 即确定数据分析或前端展现的主题(例:某年某月某地区的啤酒销售情况). 主题要体现出某一方面的各分析角度(维度)和统计数值型数据(量度)之间的关系,确定主题时要综合考虑.. 确定主题后，需要考虑分析的技术指标(例:年销售额等等). 它们一般为数据值型数据，其中有些度量值不可以汇总；些可以汇总起来，以便为分析者提供有用的信息.
数据仓库事实表分类
- - 行业应用 - ITeye博客1）在数据仓库领域有一个概念叫Transaction fact table，中文一般翻译为“事务事实表”. 事务事实表是维度建模的数据仓库中三种基本类型事实表中的一种，另外两种分别是周期快照事实表和累积快照事实表. 事务事实表与周期快照事实表、累积快照事实表使用相同的一致性维度，但是它们在描述业务事实方面是有着非常大的差异的.