文章转载自：IT叶子兽

人工智能层的：智慧地球、智慧城市、智慧社会
企业层面的：数字互联网，数字经济、数字平台、数字城市、数字政府；
平台层面的：物联网，云计算，大数据，5G，人工智能，机器智能，深度学习，知识图谱
技术层面的：数据仓库、数据集市、大数据平台、数据湖、数据中台、业务中台、技术中台等等

数据中台

数据中台是聚合和治理跨域数据，将数据抽象封装成服务，提供给前台以业务价值的逻辑概念。
数据中台是一套可持续“让企业的数据用起来”的机制，一种战略选择和组织形式，是依据企业特有的业务模式和组织架构，通过有形的产品和实施方法论支撑，构建一套持续不断把数据变成资产并服务于业务的机制。
数据中台连接数据前台和后台，突破数据局限，为企业提供更灵活、高效、低成本的数据分析挖掘服务，避免企业为满足具体某部门某种数据分析需求而投放大量高成本、重复性的数据开发成本。
数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台把数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务。
数据中台，包括平台、工具、数据、组织、流程、规范等一切与企业数据资产如何用起来所相关的。

可以看出，数据中台是解决如何用好数据的问题，目前还缺乏一个标准，而说到数据中台一定会提及大数据，而大数据又是由数据仓库发展起来的。

数据仓库（Data WareHouse）简述

数据仓库，按照传统的定义，数据仓库是一个面向主题的、集成的、非易失的、反映历史变化（随时间变化），用来支持管理人员决策的数据集合。

1，面向主题

操作型数据库的数据组织面向事务处理任务，各个业务系统之间各自分离，而数据仓库中的数据是按照一定的主题域进行组织。
主题是一个抽象的概念，是数据归类的标准，是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。每一个主题基本对应一个宏观的分析领域。
例如，银行的数据仓库的主题：客户
客户数据来源：从银行储蓄数据库、信用卡数据库、贷款数据库等几个数据库中抽取的数据整理而成。这些客户信息有可能是一致的，也可能是不一致的，这些信息需要统一整合才能完整体现客户。

2，集成

面向事务处理的操作型数据库通常与某些特定的应用相关，数据库之间相互独立，并且往往是异构的。而数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。
具体如下：
1：数据进入数据仓库后、使用之前，必须经过加工与集成。
2：对不同的数据来源进行统一数据结构和编码。统一原始数 据中的所有矛盾之处，如字段的同名异义，异名同义，单位不统一，字长不一致等。
3：将原始数据结构做一个从面向应用到面向主题的大转变。

3，非易失即相对稳定的

操作型数据库中的数据通常实时更新，数据根据需要及时发生变化。数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。

数据仓库中包括了大量的历史数据。

数据经集成进入数据仓库后是极少或根本不更新的。

随时间变化即反映历史变化

操作型数据库主要关心当前某一个时间段内的数据，而数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。企业数据仓库的建设，是以现有企业业务系统和大量业务数据的积累为基础。数据仓库不是静态的概念，只有把信息及时交给需要这些信息的使用者，供他们做出改善其业务经营的决策，信息才能发挥作用，信息才有意义。而把信息加以整理归纳和重组，并及时提供给相应的管理决策人员，是数据仓库的根本任务。因此，从产业界的角度看，数据仓库建设是一个工程，是一个过程

数据仓库内的数据时限一般在５-１０年以上，甚至永不删除，这些数据的键码都包含时间项，标明数据的历史时期，方便做时间趋势分析。

数据仓库，并不是数据最终目的地，而是为数据最终的目的地做好准备：清洗、转义、分类、重组、合并、拆分、统计等等

通过对数据仓库中数据的分析，可以帮助企业，改进业务流程、控制、成本、提高产品质量等

主要解决问题：数据报表，数据沉淀，数据计算Join过多，数据查询过慢等问题。

防止烟囱式开发，减少重复开发，开发通用中间层数据，减少重复计算；
将复杂问题简单化，将复杂任务的多个步骤分解到各个层次中，每一层只处理较少的步骤，使单个任务更容易理解；
可进行数据血缘追踪，便于快速定位问题；
整个数据层次清晰，每个层次的数据都有职责定位，便于使用和理解。

主要价值体现：企业数据模型，这些模型随着前端业务系统的发展变化，不断变革，不断追加，不断丰富和完善，即使系统不再了，也可以在短期内快速重建起来，这也是大数据产品能够快速迭代起来的一个重要原因.

总结：数据仓库，即为企业数据的模型沉淀，为了能更快的发展大数据应用，提供可靠的模型来快速迭代。本文也主要为了讲解数据仓库

数据仓库相关图集

数仓硬件架构图

数仓功能架构

数仓流程架构图1

数仓流程架构图2

实时数仓流程架构图

数据仓库的演进

image.png

数据仓库主要用途

大家应该已经意识到这个问题：既然分析型数据库中的操作都是查询，因此也就不需要严格满足完整性/参照性约束以及范式设计要求，而这些却正是分析型数据库精华所在。这样的情况下再将它归为数据库会很容易引起大家混淆，毕竟在绝大多数人心里数据库是可以关系型数据库画上等号的。

那么为什么不干脆叫"面向分析的存储系统"呢？
这就是关于数据仓库最贴切的定义了。事实上数据仓库不应让传统关系数据库来实现，因为关系数据库最少也要求满足第1范式，而数据仓库里的关系表可以不满足第1范式。也就是说，同样的记录在一个关系表里可以出现N次。但由于大多数数据仓库内的表的统计分析还是用SQL，因此很多人把它和关系数据库搞混了。

支持数据提取

数据提取可以支撑来自企业各业务部门的数据需求。

由之前的不同业务部门给不同业务系统提需求转变为不同业务系统统一给数据仓库提需求，避免烟囱式开发

image.png

支持报表系统

基于企业的数据仓库，向上支撑企业的各部门的统计报表需求，辅助支撑企业日常运营决策。

image.png

支持数据分析

从许多来自不同的企业业务系统的数据中提取出有用的数据并进行清理，以保证数据的正确性，然后经过抽取、转换和装载,即ETL过程，合并到一个企业级的数据仓库里，从而得到企业数据的一个全局视图；

在此基础上利用合适的查询和分析工具、数据挖掘工具、OLAP工具等对其进行分析和处理（这时信息变为辅助决策的知识）；

最后将知识呈现给管理者，为管理者的决策过程提供支持 。

image.png

支持数据挖掘

数据挖掘也称为数据库知识发现（Knowledge Discovery in Databases, KDD），就是将高级智能计算技术应用于大量数据中，让计算机在有人或无人指导的情况下从海量数据中发现潜在的，有用的模式（也叫知识）。

Jiawei Han在《数据挖掘概念与技术》一书中对数据挖掘的定义：数据挖掘是从大量数据中挖掘有趣模式和知识的过程，数据源包括数据库、数据仓库、Web、其他信息存储库或动态地流入系统的数据。

image.png

支持数据应用

物联网基于位置数据的旅游客流分析及人群画像
通信基于位置数据的人流监控和预警
银行基于用户交易数据的金融画像应用
电商根据用户浏览和购买行为的用户标签体系及推荐系统
征信机构根据用户信用记录的信用评估
出行基于位置数据的车流量分析，调度预测

数据集市

数据集市可以理解为是一种"小型数据仓库"，它只包含单个主题，且关注范围也非全局.
数据集市可以分为两种，一种是独立数据集市(independent data mart)，这类数据集市有自己的源数据库和ETL架构；另一种是非独立数据集市(dependent data mart)，这种数据集市没有自己的源系统，它的数据来自数据仓库。当用户或者应用程序不需要/不必要/不允许用到整个数据仓库的数据时，非独立数据集市就可以简单为用户提供一个数据仓库的"子集"。

数据集市：部门级别的数据仓库，能为某个局部范围内的管理人员提供服务。
数据仓库：企业级别的数据仓库，能为企业各个部门的运行提供决策支持。

建模的基本概念

关系建模

image.png

上图为web应用中的一个建模片段，遵循三范式建模，可以看出，较为松散、零碎， 物理表数量多，而数据冗余程度低。由于数据分布于众多的表中，这些数据可以更为灵活地 被应用，功能性较强。关系模型主要应用与 OLTP 系统中，为了保证数据的一致性以及避免 冗余，所以大部分业务系统的表都是遵循第三范式的。

维度建模

维度建模(dimensional modeling)是专门用于分析型数据库、数据仓库、数据集市建模的方法

image.png

上图为维度模型建模片段，主要应用于 OLAP 系统中，通常以某一个事实表为中心进行表的 组织，主要面向业务，特征是可能存在数据的冗余，但是能方便的得到数据。

关系模型虽然冗余少，但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这会大大降低执行效率。所以通常我们采用维度模型建模，把相关各种表整理成两种：事实表和维度表两种

维度建模的三种模式

image.png

星形模式(Star Schema)是最常用的维度建模方式
可以看出，星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：
维表只和事实表关联，维表之间没有关联；
每个维表的主码为单列，且该主码放置在事实表中，作为两边连接的逻辑外键；
以事实表为核心，维表围绕核心呈星形分布.

image.png

雪花模式(Snowflake Schema)是对星形模式的扩展，每个维表可继续向外连接多个子维表。(三范式代表作)

星形模式中的维表相对雪花模式来说要大，而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表，满足了规范化设计。然而这种模式在实际应用中很少见，因为这样做会导致开发难度增大，而数据冗余问题在数据仓库里并不严重.

星座模式

星座模式(Fact Constellations Schema)也是星型模式的扩展。

前面两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，星座模式将作为最主要的维度建模。

维度表和事实表

维度表(dimension)
表示对分析主题所属类型的描述。比如"昨天早上张三在京东花费200元购买了一个皮包"。那么以购买为主题进行分析，可从这段信息中提取三个维度：时间维度(昨天早上)，地点维度(京东), 商品维度(皮包)。通常来说维度表信息比较固定，且数据量小。
维度表：一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。例如：用户、商品、日期、地区等。
常用于一个客观世界的维度描述，往往列比较多。
审视数据的角度
维表的特征：
维表的范围很宽（具有多个属性、列比较多）
跟事实表相比，行数相对较小：通常< 10 万条
静态表示的，名词性质的表

事实表(fact table)
表示对分析主题的度量。比如上面那个例子中，200元就是事实信息。事实表包含了与各维度表相关联的逻辑外键，并通过JOIN方式与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表规模迅速增长。
事实表的特征：
非常的大
内容相对的窄：列数较少
经常发生变化，每天会新增加很多
动态表示的，动词性质的表
事务型事实表(每天导入新增)
以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的 一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量 更新
周期型快照事实表(每日全量)
周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，例如每天或者 每月的销售额，或每月的账户余额等

累积型快照事实表(每天导入新增及变化)
累计快照事实表用于跟踪业务事实的变化。例如，数据仓库中可能需要累积或者存储 订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪 订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。
事实维度举例
昨天我去菜市场买了一只蝙蝠，然后我就被隔离了。
事实：订单==>买蝙蝠这个事
维度：
时间==>昨天
用户==>我
商品==>蝙蝠
地理==>菜市场

数据分层####

为什么分层：

简单化：把复杂的任务分解为多层来完成，每层处理各自的任务，方便定位问题。
减少重复开发：规范数据分层，通过中间层数据，能够极大的减少重复计算，增加结果复用性。
隔离数据：不论是数据异常还是数据敏感性，使真实数据和统计数据解耦。

image.png

image.png

image.png

典型的粒度声明如下：

确定维度
维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。
确定事实
此处的“事实”一词，指的是业务中的度量值，例如订单金额、下单次数等。

在 DWD 层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的 明细层事实表。事实表可做适当的宽表化处理。

image.png

DWS层
统计各个主题对象的当天行为，服务于 DWT 层的主题宽表，以及一些业务明细数据， 应对特殊需求（例如，购买行为，统计商品复购率）。

image.png

image.png

大数据平台（DATA Platform)

大数据平台则是指以处理海量数据存储、计算及流数据实时计算等场景为主的一套基础设施，包括了统一的数据采集中心、数据计算和存储中心、数据治理中心、运维管控中心、开放共享中心和应用中心。

大数据平台的建设出发点是节约投资降低成本，但实际上无论从硬件投资还是从软件开发上都远远超过数据仓库的建设，大量的硬件和各种开源技术的组合，增加了研发的难度、调测部署的周期、运维的复杂度，人力上的投入已是最初的几倍；还有很多技术上的困难也非一朝一夕能够突破。

首先是数据的应用问题，无论是数据仓库还是大数据平台，里面包含了接口层数据、存储层数据、轻度汇总层、重度汇总层、模型层数据、报表层数据等等，各种各样的表有成千上万，这些表有的是中间处理过程，有些是一次性的报表，不同表之间的数据一致性和口径也会不同，而且不同的表不同的字段对数据安全要求级别也不同。

此外还要考虑多租户的资源安全管理，如何让内部开发者快速获取所需的数据资产目录，如何阅读相关数据的来龙去脉，如何快速的实现开发，这些在大数据平台建设初期没有考虑周全。

另外一个问题是对外应用，随着大数据平台的应用建设，每一个对外应用都采用单一的数据库加单一应用建设模式，独立考虑网络安全、数据安全、共享安全，逐渐又走向了烟囱似的开发道路。

总结：大数据平台，即为数据一站式服务，提供可视化的数据展示，提取，计算任务安排，资源管理，数据治理，安全措施，共享应用等等。

大数据平台相关图集

平台数据流向图

平台流程架构图

数据中台（Data Middle Platform）

数据中台要解决什么？数据如何安全的、快速的、最小权限的、且能够溯源的被探测和快速应用的问题。

数据中台不应该被过度的承载平台的计算、存储、加工任务，而是应该放在解决企业逻辑模型的搭建和存储、数据标准的建立、数据目录的梳理、数据安全的界定、数据资产的开放，知识图谱的构建。

通过一系列工具、组织、流程、规范，实现数据前台和后台的连接，突破数据局限，为企业提供更灵活、高效、低成本的数据分析挖掘服务，避免企业为满足具体某部门某种数据分析需求而投放大量高成本、重复性的数据开发成本。

总结：厚平台，大中台，小前台；没有基础厚实笨重的大数据平台，是不可能构建数据能力强大、功能强大的数据中台的；没有大数据中台，要迅速搭建小快灵的小前台也只是理想化的。

中台相关图集

中台架构图

阿里数据中台架构图

数据库的"分家"

随着关系数据库理论的提出，诞生了一系列经典的RDBMS，如Oracle，MySQL，SQL Server等。这些RDBMS被成功推向市场，并为社会信息化的发展做出的重大贡献。然而随着数据库使用范围的不断扩大，它被逐步划分为两大基本类型：

操作型数据库（OLTP）

主要用于业务支撑。一个公司往往会使用并维护若干个数据库，这些数据库保存着公司的日常操作数据，比如商品购买、酒店预订、打车下单、外卖订购等；

分析型数据库（OLAP）

主要用于历史数据分析。这类数据库作为公司的单独数据存储，负责利用历史数据对公司各主题域进行统计分析；

总结：那么为什么要"分家"？在一起不合适吗？能不能构建一个同样适用于操作和分析的统一数据库？
答案是NO。一个显然的原因是它们会"打架"......如果操作型任务和分析型任务抢资源怎么办呢？再者，它们有太多不同，以致于早已"貌合神离"。接下来看看它们到底有哪些不同吧。
因为主导功能的不同(面向操作/面向分析)，两类数据库就产生了很多细节上的差异。就好像玩LOL一个中单一个ADC，肯定有很多行为/观念上的不同

OLAP 和 OLTP简介

数据处理大致可以分成两大类：
联机事务处理OLTP（on-line transaction processing）：是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作。

联机分析处理OLAP（On-Line Analytical Processing）：是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。系统则强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。

OLAP 和 OLTP定义差别

OLAP 和 OLTP定位差别

OLAP 和 OLTP组成差别

OLAP 和 OLTP技术差别

OLAP 和 OLTP功能差别

OLAP典型架构

OLAP有多种实现方法，根据存储数据的方式不同可以分为ROLAP、MOLAP、HOLAP

ROLAP(Relational Online Analytical Processing)
ROLAP架构并不会生成实际的多维数据集，而是使用雪花模式以及多个关系表对数据立方体进行模拟，它的OLAP引擎就是将用户的OLAP操作，如上钻下钻过滤合并等，转换成SQL语句提交到数据库中执行，并且提供聚集导航功能，根据用户操作的维度和度量将SQL查询定位到最粗粒度的事实表上去

这种架构下的查询没有MOLAP快速。因为ROLAP中，所有的查询都是被转换为SQL语句执行的。而这些SQL语句的执行会涉及到多个表之间的JOIN操作，没有MOLAP速度快，往往都是通过内存计算实现。(内存的昂贵大家是知道的)

ROLAP

在该立方体中，每一格对应一个直接地址，且常用的查询已被预先计算好。因此每次的查询都是非常快速的，但是由于立方体的更新比较慢，所以是否使用这种架构得具体问题具体分析。

MOLAP

HOLAP

OLAP数据立方体(Data Cube)

OLAP（online analytical processing）是一种软件技术，它使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。从各方面观察信息，也就是从不同的维度分析数据，因此OLAP也称为多维分析。
很多年前，当我们要手工从一堆数据中提取信息时，我们会分析一堆数据报告。通常这些数据报告采用二维表示，是行与列组成的二维表格。但在真实世界里我们分析数据的角度很可能有多个，数据立方体可以理解为就是维度扩展后的二维表格。下图展示了一个三维数据立方体：

OLAP

更多时候数据立方体是N维的。它的实现有两种方式。其中星形模式就是其中一种，该模式其实是一种连接关系表与数据立方体的桥梁。但对于大多数纯OLAP使用者来讲，数据分析的对象就是这个逻辑概念上的数据立方体，其具体实现不用深究。对于这些OLAP工具的使用者来讲，基本用法是首先配置好维表、事实表，然后在每次查询的时候告诉OLAP需要展示的维度和事实字段和操作类型即可。

最常见的五大操作：切片，切块，旋转，上卷，下钻

切片和切块(Slice and Dice)

在数据立方体的某一维度上选定一个维成员的操作叫切片，而对两个或多个维执行选择则叫做切块。下图逻辑上展示了切片和切块操作：

切片和切块

旋转(Pivot)

旋转就是指改变报表或页面的展示方向。对于使用者来说，就是个视图操作，而从SQL模拟语句的角度来说，就是改变SELECT后面字段的顺序而已。下图逻辑上展示了旋转操作：

旋转(Pivot)

上卷和下钻(Rol-up and Drill-down)

上卷可以理解为"无视"某些维度；下钻则是指将某些维度进行细分。下图逻辑上展示了上卷和下钻操作：

上卷和下钻

Cube 和 Cuboid

image.png

Cube（或 Data Cube），即数据立方体，是一种常用于数据分析与索引的技术；它可以对原始数据建立多维度索引。通过 Cube 对数据进行分析，可以大大加快数据的查询效率。

Cuboid 特指在某一种维度组合下所计算的数据。给定一个数据模型，我们可以对其上的所有维度进行组合。对于 N 个维度来说，组合的所有可能性共有 2 的 N 次方种。对于每一种维度的组合，将度量做 聚合运算，然后将运算的结果保存为一个物化视图，称为 Cuboid。

所有维度组合的 Cuboid 作为一个整体，被称为 Cube。所以简单来说，一个 Cube 就是许多按维度聚合的物化视图的集合。
下面来列举一个具体的例子：
假定有一个电商的销售数据集，其中维度包括 时间（Time）、商品（Item）、地点（Location）和供应商（Supplier），度量为销售额（GMV）。

那么所有维度的组合就有 2 的 4 次方 =16 种

一维度（1D） 的组合有[Time]、[Item]、[Location]、[Supplier]4 种

二维度（2D）的组合 有[Time，Item]、[Time，Location]、[Time、Supplier]、[Item，Location]、 [Item，Supplier]、[Location，Supplier]6 种

三维度（3D）的组合也有 4 种

零维度（0D）的组合有 1 种

四维度（4D）的组合有 1 种

image.png