关于数据库、数据仓库、数据集市、数据湖、数据中心的 40,000 字 - 5.2 数据中心与数据仓库之间的关系

5.2.1 传统数仓

传统数仓有几个特点：

数据具有历史性

基于文件存储

以表为形态，自带元数据存储（比如Hive）

在数仓的数据是其他原始数据的拷贝或者拷贝的加工 传统数仓需要拷贝数据的重要原因是数据计算和数据存储需要尽可能的近。所以我们需要把MySQL等数据源的数据同步到数仓，才能进行进一步处理。（这里有点疑问，我觉得是因为需要直接对数仓数据进行离线操作，而不是对业务数据库进行繁重的操作，也就是说数据分析不能影响业务）

另外传统数仓更关注的是数据的历史状态，所以导致数据规模庞大。数仓本身也具备计算能力，同时也可以作为存储供其他计算系统使用。

5.2.2 数据中台

数据中台概念，不同于数据平台。数据中台，业务侧包含

• 数据触手(埋点)

• 数据接入(标准化)

• 数据仓库(抽象化)

• 数据治理(可靠性)

• 数据服务(产品化)

整体是一个闭环的解决方案 其中，闭环是最重要的一点。

数据服务接口

数据中台设计立足点本身是数据计算和存储分离的。那就意味着，数据中台本身并没有数据，数据来源是其他地方，比如传统数仓、业务数据库、用户在中台上传的文件（临时使用）、各个业务系统的API(瞬时，我们不关心API之前的数据结果是什么样的)。因为数据中台拥有这些数据源的适配器，所以相当于建立了互联管道。

关于元数据

我们知道数仓的优势是有元数据，通过表的方式很好的规整了数据。数据需要加工，所以一般数仓是有分层的，往上走一层，数据信息损耗就高一些。

数据中台也有一个全局的元数据管理系统，管理也是以表为主，粒度到字段级别。数据中台这个元信息包含了各个子存储的元信息，以数据中台需要的形态进行组织。

数据地图

数据中台的元数据其中承载的一个重要功能是数据地图，虽然在数据中台中，修建了通往所有数据的道路，但是当用户进来的时候无法知道具体某个数据的地址，也就没办法利用这些修好的道路。

数据地图就是解决这个问题 我们需要结合自然语言处理，检索技术，目录分类技术，机器学习以及数据规范化来帮助找到数据地址。数据地址从来都不是面向人类友好的。

通过数据中台的数据地图，以及数据中台到各数据源的建立好的管道，那么我们就可以很好的找到我们要的数据以及对他们进行关联和处理，分析，甚至进一步成为机器学习的素材。

数据地图和传统数仓元数据的区别在于：

它记录了散落在各个孤岛的数据，而不像传统数仓，只是在自己的数据。

数据格式是异构的，不仅仅是文件或表。

他不仅仅存储表以及字段相关信息，同时还让这些信息可检索，可查询，可以更好的面向人而不是机器。

5.2.3 结论

数仓是数据中台的一个重要组成部分，也是元数据的一个重要来源，但是随着技术的发展，数据计算和存储必定是分离的，这就需要一个新的元信息系统（数据地图）来进行承载。

5.3 数据中台建设是数字化转型的支撑

数据中台成为热点，“中台”这个概念，是相对于前台和后台而生，是前台和后台的链接点，将业务共同的工具和技术予以沉淀。数据中台是指数据采集交换、共享融合、组织处理、建模分析、管理治理和服务应用于一体的综合性数据能力平台，在大数据生态中处于承上启下的功能，提供面向数据应用支撑的底座能力。

广义上来给数据中台一个企业级的定义：“聚合和治理跨域数据，将数据抽象封装成服务，提供给前台以业务价值的逻辑概念”。