文章转载自：IT叶子兽
人工智能层的：智慧地球、智慧城市、智慧社会
企业层面的：数字互联网，数字经济、数字平台、数字城市、数字政府；
平台层面的：物联网，云计算，大数据，5G，人工智能，机器智能，深度学习，知识图谱
技术层面的：数据仓库、数据集市、大数据平台、数据湖、数据中台、业务中台、技术中台等等
挑重点简介
1.1数据中台
数据中台是聚合和治理跨域数据，将数据抽象封装成服务，提供给前台以业务价值的逻辑概念。
数据中台是一套可持续“让企业的数据用起来”的机制，一种战略选择和组织形式，是依据企业特有的业务模式和组织架构，通过有形的产品和实施方法论支撑，构建一套持续不断把数据变成资产并服务于业务的机制。
数据中台连接数据前台和后台，突破数据局限，为企业提供更灵活、高效、低成本的数据分析挖掘服务，避免企业为满足具体某部门某种数据分析需求而投放大量高成本、重复性的数据开发成本。
数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台把数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务。
数据中台，包括平台、工具、数据、组织、流程、规范等一切与企业数据资产如何用起来所相关的。
可以看出，数据中台是解决如何用好数据的问题，目前还缺乏一个标准，而说到数据中台一定会提及大数据，而大数据又是由数据仓库发展起来的。
1.1.1数据仓库（DataWareHouse）
数据仓库，按照传统的定义，数据仓库是一个面向主题的、集成的、非易失的、反映历史变化（随时间变化），用来支持管理人员决策的数据集合。
为企业所有决策制定过程，提供所有系统数据支持的战略集合面向主题操作型数据库的数据组织面向事务处理任务，各个业务系统之间各自分离，而数据仓库中的数据是按照一定的主题域进行组织。主题是一个抽象的概念，是数据归类的标准，是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。每一个主题基本对应一个宏观的分析领域。例如，银行的数据仓库的主题：客户客户数据来源：从银行储蓄数据库、信用卡数据库、贷款数据库等几个数据库中抽取的数据整理而成。这些客户信息有可能是一致的，也可能是不一致的，这些信息需要统一整合才能完整体现客户。集成面向事务处理的操作型数据库通常与某些特定的应用相关，数据库之间相互独立，并且往往是异构的。而数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。具体如下：1：数据进入数据仓库后、使用之前，必须经过加工与集成。2：对不同的数据来源进行统一数据结构和编码。统一原始数据中的所有矛盾之处，如字段的同名异义，异名同义，单位不统一，字长不一致等。3：将原始数据结构做一个从面向应用到面向主题的大转变。非易失即相对稳定的操作型数据库中的数据通常实时更新，数据根据需要及时发生变化。数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。数据仓库中包括了大量的历史数据。数据经集成进入数据仓库后是极少或根本不更新的。随时间变化即反映历史变化操作型数据库主要关心当前某一个时间段内的数据，而数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。企业数据仓库的建设，是以现有企业业务系统和大量业务数据的积累为基础。数据仓库不是静态的概念，只有把信息及时交给需要这些信息的使用者，供他们做出改善其业务经营的决策，信息才能发挥作用，信息才有意义。而把信息加以整理归纳和重组，并及时提供给相应的管理决策人员，是数据仓库的根本任务。因此，从产业界的角度看，数据仓库建设是一个工程，是一个过程数据仓库内的数据时限一般在５-１０年以上，甚至永不删除，这些数据的键码都包含时间项，标明数据的历史时期，方便做时间趋势分析。
数据仓库，并不是数据最终目的地，而是为数据最终的目的地做好准备：清洗、转义、分类、重组、合并、拆分、统计等等
通过对数据仓库中数据的分析，可以帮助企业，改进业务流程、控制、成本、提高产品质量等
主要解决问题：数据报表，数据沉淀，数据计算Join过多，数据查询过慢等问题。
防止烟囱式开发，减少重复开发，开发通用中间层数据，减少重复计算；将复杂问题简单化，将复杂任务的多个步骤分解到各个层次中，每一层只处理较少的步骤，使单个任务更容易理解；可进行数据血缘追踪，便于快速定位问题；整个数据层次清晰，每个层次的数据都有职责定位，便于使用和理解。
主要价值体现：企业数据模型，这些模型随着前端业务系统的发展变化，不断变革，不断追加，不断丰富和完善，即使系统不再了，也可以在短期内快速重建起来，这也是大数据产品能够快速迭代起来的一个重要原因
总结：数据仓库，即为企业数据的模型沉淀，为了能更快的发展大数据应用，提供可靠的模型来快速迭代。本文也主要为了讲解数据仓库
数仓硬件架构图
数仓功能架构图
数仓流程架构图1
数仓流程架构图2
实时数仓流程架构图
1.1.2大数据平台（DATAPlatform）
大数据平台则是指以处理海量数据存储、计算及流数据实时计算等场景为主的一套基础设施，包括了统一的数据采集中心、数据计算和存储中心、数据治理中心、运维管控中心、开放共享中心和应用中心。
大数据平台的建设出发点是节约投资降低成本，但实际上无论从硬件投资还是从软件开发上都远远超过数据仓库的建设，大量的硬件和各种开源技术的组合，增加了研发的难度、调测部署的周期、运维的复杂度，人力上的投入已是最初的几倍；还有很多技术上的困难也非一朝一夕能够突破。
首先是数据的应用问题，无论是数据仓库还是大数据平台，里面包含了接口层数据、存储层数据、轻度汇总层、重度汇总层、模型层数据、报表层数据等等，各种各样的表有成千上万，这些表有的是中间处理过程，有些是一次性的报表，不同表之间的数据一致性和口径也会不同，而且不同的表不同的字段对数据安全要求级别也不同。
此外还要考虑多租户的资源安全管理，如何让内部开发者快速获取所需的数据资产目录，如何阅读相关数据的来龙去脉，如何快速的实现开发，这些在大数据平台建设初期没有考虑周全。
另外一个问题是对外应用，随着大数据平台的应用建设，每一个对外应用都采用单一的数据库加单一应用建设模式，独立考虑网络安全、数据安全、共享安全，逐渐又走向了烟囱似的开发道路。
总结：大数据平台，即为数据一站式服务，提供可视化的数据展示，提取，计算任务安排，资源管理，数据治理，安全措施，共享应用等等。
平台数据流向图
平台流程架构图
1.1.3数据中台（DataMiddlePlatform）
数据中台要解决什么？数据如何安全的、快速的、最小权限的、且能够溯源的被探测和快速应用的问题。
数据中台不应该被过度的承载平台的计算、存储、加工任务，而是应该放在解决企业逻辑模型的搭建和存储、数据标准的建立、数据目录的梳理、数据安全的界定、数据资产的开放，知识图谱的构建。
通过一系列工具、组织、流程、规范，实现数据前台和后台的连接，突破数据局限，为企业提供更灵活、高效、低成本的数据分析挖掘服务，避免企业为满足具体某部门某种数据分析需求而投放大量高成本、重复性的数据开发成本。
总结：厚平台，大中台，小前台；没有基础厚实笨重的大数据平台，是不可能构建数据能力强大、功能强大的数据中台的；没有大数据中台，要迅速搭建小快灵的小前台也只是理想化的。
中台架构图
阿里数据中台架构图
2数据库的分家
随着关系数据库理论的提出，诞生了一系列经典的RDBMS，如Oracle，MySQL，SQLServer等。这些RDBMS被成功推向市场，并为社会信息化的发展做出的重大贡献。然而随着数据库使用范围的不断扩大，它被逐步划分为两大基本类型：
操作型数据库（OLTP）
主要用于业务支撑。一个公司往往会使用并维护若干个数据库，这些数据库保存着公司的日常操作数据，比如商品购买、酒店预订、打车下单、外卖订购等；
分析型数据库（OLAP）
主要用于历史数据分析。这类数据库作为公司的单独数据存储，负责利用历史数据对公司各主题域进行统计分析；
总结
那么为什么要分家？在一起不合适吗？能不能构建一个同样适用于操作和分析的统一数据库？答案是NO。一个显然的原因是它们会打架......如果操作型任务和分析型任务抢资源怎么办呢？再者，它们有太多不同，以致于早已貌合神离。接下来看看它们到底有哪些不同吧。因为主导功能的不同(面向操作/面向分析)，两类数据库就产生了很多细节上的差异。就好像玩LOL一个中单一个ADC，肯定有很多行为/观念上的不同
2.1OLAP和OLTP简介
数据处理大致可以分成两大类：
联机事务处理OLTP（on-linetransactionprocessing）：是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作。联机分析处理OLAP（On-LineAnalyticalProcessing）：是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。系统则强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。
2.2定义差别
2.3定位差别
2.4组成差别
2.5技术差别
2.6功能差别
2.7OLTP数据库三范式介绍
定义：范式可以理解为设计一张数据表的表结构，符合的标准级别。规范和要求
优点：关系型数据库设计时，遵照一定的规范要求，目的在于降低数据的冗余性。
十几年前，磁盘很贵，为了减少磁盘存储。
以前没有分布式系统，都是单机，只能增加磁盘，磁盘个数也是有限的
一次修改，需要修改多个表，很难保证数据一致性
缺点：范式的缺点是获取数据时，需要通过Join拼接出最后的数据。
目前业界范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。
2.7.1函数依赖
完全函数依赖：
通过AB能推出C，但是AB单独得不到C，那么可以说：C完全依赖于AB（学号，课名）推出分数，但是单独用学号推不出分数，那么可以说：分数完全依赖于（学号，课名）
部分函数依赖：
通过AB能推出C，通过单独的A或者单独的B也能推出C，那么可以说：C部分依赖于AB（学号，课名）推出姓名，而还可以通过学号直接推出姓名，那么可以说：姓名部分依赖于（学号，课名）
传递函数依赖：
通过A得到B，通过B得到C，但是通过C不能得到A，那么可以说：C传递依赖于A通过学号推出系名，系名推出系主任，但是系主任不能推出学号，那么可以说：系主任专递依赖于学号
2.7.2三范式区分
2.7.2.1第一范式：属性不可切割
不符合第一范式表设计
如上表格不符合第一范式，商品列中的数据不是原子数据项，是可以进行分割的。
符合第一范式表设计
1NF是所有关系数据库的最基本要求
2.7.2.2第二范式：不能存在部分函数依赖
不符合第二范式表设计
如上表格不符合第二范式，比如：这张表主键（学号，课名），分数完全依赖于（学号和课名），但是姓名并不完全依赖于（学号和课名）
符合第二范式表设计
2.7.2.3第三范式：不能存在传递函数依赖
不符合第三范式表设计
如上表格不符合第三范式，比如：学号--系名--系主任，但是系主任推不出学号
符合第三范式表设计
2.8OLAP典型架构
OLAP有多种实现方法，根据存储数据的方式不同可以分为ROLAP、MOLAP、HOLAP
ROLAP(RelationalOnlineAnalyticalProcessing)
ROLAP架构并不会生成实际的多维数据集，而是使用雪花模式以及多个关系表对数据立方体进行模拟，它的OLAP引擎就是将用户的OLAP操作，如上钻下钻过滤合并等，转换成SQL语句提交到数据库中执行，并且提供聚集导航功能，根据用户操作的维度和度量将SQL查询定位到最粗粒度的事实表上去这种架构下的查询没有MOLAP快速。因为ROLAP中，所有的查询都是被转换为SQL语句执行的。而这些SQL语句的执行会涉及到多个表之间的JOIN操作，没有MOLAP速度快，往往都是通过内存计算实现。(内存的昂贵大家是知道的)
MOLAP(MultidimensionalOnlineAnalyticalProcessing)
MOLAP架构会生成一个新的多维数据集，也可以说是构建了一个实际数据立方体。事先将汇总数据计算好，存放在自己特定的多维数据库中，用户的OLAP操作可以直接映射到多维数据库的访问，不通过SQL访问。(空间换时间，典型代表Kylin)在该立方体中，每一格对应一个直接地址，且常用的查询已被预先计算好。因此每次的查询都是非常快速的，但是由于立方体的更新比较慢，所以是否使用这种架构得具体问题具体分析。
HOLAP(HybridOnlineAnalyticalProcessing)
这种架构综合参考MOLAP和ROLAP而采用一种混合解决方案，将某些需要特别提速的查询放到MOLAP引擎，其他查询则调用ROLAP引擎。上述MOLAP和ROLAP的结合。它提供了更大的灵活度，MOLAP提供提供了更加快速的响应速度。但是带来的问题是，数据装载的效率非常低，因为其实就是将多维的数据预先填好，但是随着数据量过大维度成本越高，容易引起“数据爆炸”。
2.9OLAP数据立方体(DataCube)
OLAP（onlineanalyticalprocessing）是一种软件技术，它使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。从各方面观察信息，也就是从不同的维度分析数据，因此OLAP也称为多维分析。
很多年前，当我们要手工从一堆数据中提取信息时，我们会分析一堆数据报告。通常这些数据报告采用二维表示，是行与列组成的二维表格。但在真实世界里我们分析数据的角度很可能有多个，数据立方体可以理解为就是维度扩展后的二维表格。下图展示了一个三维数据立方体：
更多时候数据立方体是N维的。它的实现有两种方式。其中星形模式就是其中一种，该模式其实是一种连接关系表与数据立方体的桥梁。但对于大多数纯OLAP使用者来讲，数据分析的对象就是这个逻辑概念上的数据立方体，其具体实现不用深究。对于这些OLAP工具的使用者来讲，基本用法是首先配置好维表、事实表，然后在每次查询的时候告诉OLAP需要展示的维度和事实字段和操作类型即可。最常见的五大操作：切片，切块，旋转，上卷，下钻。
2.9.1切片和切块(SliceandDice)
在数据立方体的某一维度上选定一个维成员的操作叫切片，而对两个或多个维执行选择则叫做切块。下图逻辑上展示了切片和切块操作：
2.9.2旋转(Pivot)
旋转就是指改变报表或页面的展示方向。对于使用者来说，就是个视图操作，而从SQL模拟语句的角度来说，就是改变SELECT后面字段的顺序而已。下图逻辑上展示了旋转操作：
2.9.3上卷和下钻(Rol-upandDrill-down)
上卷可以理解为无视某些维度；下钻则是指将某些维度进行细分。下图逻辑上展示了上卷和下钻操作：
2.9.4Cube和Cuboid
Cube（或DataCube），即数据立方体，是一种常用于数据分析与索引的技术；它可以对原始数据建立多维度索引。通过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种
3数据仓库的演进
4数据仓库主要用途
大家应该已经意识到这个问题：既然分析型数据库中的操作都是查询，因此也就不需要严格满足完整性/参照性约束以及范式设计要求，而这些却正是分析型数据库精华所在。这样的情况下再将它归为数据库会很容易引起大家混淆，毕竟在绝大多数人心里数据库是可以关系型数据库画上等号的。
那么为什么不干脆叫面向分析的存储系统呢？
这就是关于数据仓库最贴切的定义了。事实上数据仓库不应让传统关系数据库来实现，因为关系数据库最少也要求满足第1范式，而数据仓库里的关系表可以不满足第1范式。也就是说，同样的记录在一个关系表里可以出现N次。但由于大多数数据仓库内的表的统计分析还是用SQL，因此很多人把它和关系数据库搞混了。
4.1支持数据提取
数据提取可以支撑来自企业各业务部门的数据需求。由之前的不同业务部门给不同业务系统提需求转变为不同业务系统统一给数据仓库提需求，避免烟囱式开发
4.2支持报表系统
基于企业的数据仓库，向上支撑企业的各部门的统计报表需求，辅助支撑企业日常运营决策。
4.3支持数据分析
从许多来自不同的企业业务系统的数据中提取出有用的数据并进行清理，以保证数据的正确性，然后经过抽取、转换和装载,即ETL过程，合并到一个企业级的数据仓库里，从而得到企业数据的一个全局视图；在此基础上利用合适的查询和分析工具、数据挖掘工具、OLAP工具等对其进行分析和处理（这时信息变为辅助决策的知识）；最后将知识呈现给管理者，为管理者的决策过程提供支持。
4.4支持数据挖掘
数据挖掘也称为数据库知识发现（KnowledgeDiscoveryinDatabases,KDD），就是将高级智能计算技术应用于大量数据中，让计算机在有人或无人指导的情况下从海量数据中发现潜在的，有用的模式（也叫知识）。JiaweiHan在《数据挖掘概念与技术》一书中对数据挖掘的定义：数据挖掘是从大量数据中挖掘有趣模式和知识的过程，数据源包括数据库、数据仓库、Web、其他信息存储库或动态地流入系统的数据。
4.5支持数据应用
物联网基于位置数据的旅游客流分析及人群画像通信基于位置数据的人流监控和预警银行基于用户交易数据的金融画像应用电商根据用户浏览和购买行为的用户标签体系及推荐系统征信机构根据用户信用记录的信用评估出行基于位置数据的车流量分析，调度预测
5数据集市
数据集市可以理解为是一种小型数据仓库，它只包含单个主题，且