了解一下数据仓库

jiezi

5 年前

数据库（DB）是按照 数据结构 来组织、存储和管理 数据的建立在 计算机 存储设备上的仓库
数据库是长期存储在 计算机内、有组织的、可共享的数据集合。数据库中的数据指的是以一定的数据模型组织、描述和储存在一起、具有尽可能小的冗余度、较高的数据独立性和易扩展性的特点并可在一定范围内为多个用户共享

数据仓库是面向主题的，集成的，相对稳定的，反映历史变化的数据集合，用于支持管理决策。

面向主题：在较高层次上将企业信息系统的数据综合归并进行分析利用的抽象的概念。每个主题基本上对应一个相应的分析领域。
集成的：企业级数据，同时数据要保持一致性、完整性、有效性、精确性。
稳定性：从某个时间段来看是保持不变的，没有更新操作、删除操作，以查询分析为主。
变化的：反映历史变化。

功能	数据仓库	数据库
数据范围	存储历史的、完整的、反应历史变化的	当前状态数据
数据变化	可添加、误删除、无变更的、反映历史变化	支持频繁的增、删、改、查操作
应用场景	面向分析、支持战略决策	面向业务交易流程
设计理论	违范式、适当冗余	遵照范式（1NF、2NF、3NF 等范式）、避免冗余
处理量	非频繁、大批量、高吞吐、有延迟	频繁、小批次、高并发、低延迟

面向业务的 数据库 常称作 OLTP，面向分析的 数据仓库 称为 OLAP。

数据仓库概念最早可追溯到 20 世纪 70 年代，希望通过一种架构将业务处理系统和分析处理分为不同的层次。

20 世纪 80 年代，简历 TA2(Technical Architecture2)规范，该明确定义了分析系统的四个组成部分：_数据获取、数据访问、目录、用户服务_。

1988 年，IBM 第一次提出信息仓库的概念：一个结构化的环境，能支持最终用户管理其全部的业务，并支持信息技术部门保证数据质量；抽象出基本组件：_数据抽取、转换、有效性验证、加载、cube 开发等_，基本明确了数据仓库的基本原理、框架结构，以及分析系统的主要原则。

[敲黑板，说重点]:

转换：Sqoop 进行简单的数据转换，更多的转化操作是通过 ETL 来实现的

有效性验证：牵扯到数据质量的问题

那么如何去建设数据仓库呢？

1) 1991 年，Bill Inmon 提出了自上而下（top-down）的方式建设企业数据仓库（Data Warehouse, DW），认为 DW 是一个整体的商业智能系统（BI）的一部分。一家企业只有一个 DW，数据集市（Data Market, DM）的信息来源出自 DW，在 DW 中，信息存储符合 3NF 范式。
2）Ralph Kimball 则主张自下而上 (bottom-up) 的方式建立 DW，极力推崇建立数据集市，认为 DW 是企业内所有 DM 的集合，信息总是被存储在多维模型中。
3）Bill Inmon 提出了新的 BI 架构 CIP（Corporation information factory），把 DM 包含了进来。CIP 的核心是 将 DW 架构划分为不同的层次 以满足不同场景的需求，比如常见的 ODS、DW（e g: DWD, DWS 等）、DM 等，每层根据实际场景采用不同的建设方案，该思路也是目前 DW 建设的架构指南，但到底是以 top-down 还是 bottom-up 方式进行 DW 建设，并未统一。

[敲黑板，说重点]:

很多人说 Hadoop 时代维度建模已经不是必须的了，其实不然，在整个 Hadoop 时代建模依然是有用的，而且是非常有意义的。Hadoop 为整个大数据应用提供了技术的基础，包括 Hive、Spark，只是技术架构。而我们谈及大数据的时候，更多的关注的是大数据的价值，所以在组织梳理数据内容的时候依然会有数据建模的概念。

只不过很多公司做大数据可能是刚起步阶段，更在意与流量方面，所以不需要建模，但是等数据体量达到一定程度后，如果没有数据建模，那么数据质量也就无法保障，数据也就会废掉、烂掉。

数据仓库分层架构图：

核心简述：

将业务 DB 中数据同步到只读 DB 中
使用 Sqoop 将只读 DB 中的数据 Import 到 HDFS 上（ODS）
将 ODS 层 Hive 中的数据通过 HQL 筛选到 DWS 层中（DWS 存储的是中间汇总的结果）
将 DWS 层 Hive 中的数据通过 HQL 结合具体需求筛选到 DM 中（DM 存储的是待计算的指标）
将 DM 层 Hive 中的数据通过 Sqoop，Spark SQL 导入到 RDBMS 之 MySQL 中存储起来（用于数据可视化展示）
通过可视化技术读取 RDBMS 中相应结果数据进行可视化展示（饼状图、柱形图、折线图等）

为什么要对数据仓库进行分层？

用空间换时间，通过大量的预处理来提升系统的用户体验（效率），因此数据仓库会存在大量的数据冗余。
如果不分层的话，源业务系统的业务规则发生变化将会影响整个系统的清洗过程，工作量巨大。
通过数据分层管理可以简化数据清洗的过程，因为原来把一步的工作分了多个步骤去执行，相当于把一个复杂的工作拆分成了多个简单的工作，把一个大的黑盒变成了一个白盒，每一层的处理的逻辑都相对简单和容易理解，这样我们比较容易确定每一个步骤的正确性，当数据发生错误的时候，往往我们需要调整某个步骤即可。

说了这么多，那么数据仓库的建立步骤呢？

1) 收集和分析业务需求
2）建立数据模型和数据仓库的物理设计
3）定义数据源
4）选择数据仓库技术和平台
5）从操作型数据库中抽取，净化和转换数据到数据仓库中
6）选择访问和报表工具
7）选择数据库连接软件
8）选择数据分析和数据展示软件
9）更新数据仓库

1) 特点

鉴于互联网行业的“要么变化，要么去死”的影响，决定了在互联网领域，基于大数据的数据仓库建设是无法按照原有的项目流程、开发模式进行，更多的是需要结合新的技术体系、业务场景进行灵活的调整，以快速响应需求为导向。

2) 广泛的应用场景

传统的数仓	基于大数据的数仓
建设周期长	要求快速响应需求
需求稳定	需求灵活、多变
时效性要求不高	对实时性有不同程度的要求
面向 DSS、CRM、BI 等系统	除了面向 DSS、BI 等传统应用外，还要响应用户画像、个性化推荐（比如你看了一遍文章，再给你推荐十片同类型文章）、及其学习、数据分析等各种复杂的应用场景

阿里系：OneData（公司级别所有数据应用都基于我这一个数据，只有一个数据出口，不论实时还是离线都是统一的唯一出口），OneService（数据服务也是统一的）

很多时候，我们提供到数仓，就会觉得是 离线 的、至少也是 T+1 的，但是这是传统的数据仓库，而基于大数据的数据仓库不应该这么理解，实时也应该归纳到数据仓库中。

3) 技术栈更全面、复杂
- 传统数仓建设：更多是基于成熟的商业数据集成平台，比如 Oracle、Informatica 等，技术体系比较成熟完善，但相对较封闭，对实施者技术面要求也相对专业且单一。
- 基于大数据的数仓建设：一般是基于非商业、开源的技术，且涉及技术较广泛、复杂，没有商业的公司提供服务，需要自己维护更多的技术框架。常见的是基于 Hadoop 的生态建设。

技术栈总图：

4) 数仓模型设计更灵活
- 传统数仓：
  - 有较为稳定的业务场景和相对可靠的数据质量，同时也有较为稳定的需求，对数仓的建设有较为完善的项目流程管控，数仓模型设计有严格的、稳定的建设标准
- 互联网行业：
  - 行业变化快、业务灵活，同时互联网又是个靠速度存活的行业
  - 源数据种类繁多：数据库、Nginx log、用户浏览轨迹等结构化、非结构化、半结构化数据
  - 数据质量相对差，层次不齐

综上，在互联网领域，数仓模型是必须要存在（不一定是维度建模，但是至少需要一个建模），且数仓模型的设计更 关注灵活、快速响应 和应对多变的市场环境，更加以快速 解决业务、运营问题 为导向，快速数据接入、快速业务接入，更不存在一劳永逸。

数仓存在的意义
- 工程治理
基于大数据的数据仓库在互联网行业应用：
- BI
- 消息推送
- 千人千面
- 用户画像
- 反欺诈

1）数据分析、数据挖掘、人工智能、机器学习、风险控制、无人驾驶
2）数据化运营、精准运营
3）广告精准、智能投放

[1] 数据仓库 (三) 之架构篇
[2] 数据仓库学习笔记 — 如何设计数据仓库

了解一下数据仓库

0. 什么是数据库？

1. 什么是数据仓库？

2. 数据仓库的发展历程

3. 基于大数据的数仓构建特点

4. 数据仓库的应用范围与前景

5. 发展方向

Resource Link