数据存储架构图 示例 数据存储简介

一、背景

在当今世界，大数据时代的来临，带来了信息技术发展的巨大变革，并深刻影响着社会生产和人民生活的方方面面。
如今，随着互联网以及物联网等技术的不断发展，越来越多的数据被生产出来。根据最新的统计，每天大约有超过2.5万亿字节的各种各样数据产生。这些数据需要被存储起来并且能够被方便的分析和利用。

另一方面，大数据技术也在不断更新和迭代，其中数据管理工具得到了飞速的发展，相关概念如雨后春笋一般应运而生，如从最初决策支持系统(DSS)到商业智能(BI)、数据仓库、数据湖、数据中台等，出现了很多新的概念，而且这些概念特别容易混淆，本文次课程的前半段针对这些名词术语及内涵进行简单的介绍，便于大家对数据平台相关的概念有整体的认识。

二、基本概念

1 数据库

本节介绍数据库的基本概念，包括数据库存储方式、数据库技术的发展历史、数据库的存储结构以及数据库在开发中的作用。

1.1什么是数据库

每个人家里都会有冰箱，冰箱是用来干什么的？冰箱是用来存放水果蔬菜等食物的地方。
同样的，数据库是存放数据的地方。正是因为有了数据库后，我们可以直接查找数据。例如你每天使用余额宝查看自己的账户收益，就是从数据库读取数据后给你的。

有人可能会问了：我的数据就存放在自己电脑的excel表里或者其他的本地文件就可以了，为什么还要搞个数据库呢？这是因为数据库比excel有更多的优势。数据库可以存放大量的数据，允许很多人同时使用里面的数据。举个例子你就明白了，excel好比是一个移动硬盘，你使用了这个移动硬盘其他人就用不了了。数据库好比是网盘，很多人可以同时访问里面里的数据。而且网盘比移动硬盘能放更多的数据。

1.2数据库是如何存放数据的？

数据库有很多种类，这里我们重点学习使用最广泛的关系数据库。
关系数据库是由多个表组成的。如果你用过Excel，就会知道Excel是一张一张的二维表。每个表都是由行和列组成的。同样的，关系数据库里存放的也是一张一张的表，只不过各个表之间是有联系的。
所以，简单来说：关系数据库=多张表+各表之间的关系

对应的，学会关系数据库我们只要掌握两点就可以：
1）多张表里面，每一张表的结构
2）各表之间的关系

我们接下来分别来看看这两个知识点。
1） 表的结构表的结构是指要了解关系数据库中每张表长什么样。每个表由一个名字标识。表包含带有列名的列，和记录数据的行。我们举个具体的例子就一目了然了。下面图片里的表名是：学生表，记录了每个学生的信息。

表中每一列都有一个名字来标识出该列，这个表里有4列，列名分别是学号，姓名，出生日期，性别。从列名上你也可以知道这一列对应记录的是什么数据。表的每一行里记录着数据。这里的一行表示该名学生的信息，比如第2行是学号0002学生的信息，他的姓名是猴子，出生日期是1990-12-21，性别是女。

2）各表之间的关系关系数据库是由多张表组成的，图片里是存放在学校数据库里的4张表。你能发现下面这4张表之间有什么关系吗？

什么是关系呢？你是你爸爸的儿子，你是你的儿子的爸爸，这就是生活中的关系。其实，数据之间也是有关系的。关系数据库里各个表之间如何建立起关系呢？我们来看图中“学生表”，“成绩表”这两个表之前的关系。

这两张表通过”学号”关联起来，为了更清楚的看到这两个表的关系，PPT里我用相同颜色代表同一个学生的信息。
例如我想知道学生表里学号“0001” 的成绩是多少？那么我就可以在成绩表里去查找“学号”值是0001的行，最后在成绩表里发现有3行数据的学号都是“0001” ，对应的就找到了该学生的三门课程的成绩。
通过这个例子你应该对表之间的关系有了大概的了解。关系就是数据能够对应的匹配，在关系数据库中正式名称叫联结，对应的英文名称叫做join。

联结是关系型数据库中的核心概念，务必记住这个概念，后面会在多表查询中具体学到。

1.3什么是数据库管理系统？

前面讲的都是关系数据库原理方面的基本理论。理论有了，当然的就的有对应的软件实现才能用起来，不然再强大的理论都是一堆无用的东东。这就好比，建筑师如果只有设计草图是无法盖起楼房的，得有具体的建筑人员才能盖起楼房。

所以，上面讲的关系数据库原理就是“设计草图”，那么对应的“建筑人员”是谁呢？
实现数据库原理的“建筑人员”就是数据库管理系统，用来管理数据库的计算机软件。关系数据库管理系统有很多种，比如MySQL、Oracle、SQL Server等都是实现上面理论的关系数据库。

1.4纯理论

数据库是数据管理的有效技术，是由一批数据构成的有序集合，这些数据被存放在结构化的数据表里。数据表之间相互关联，反映客观事物间的本质联系。数据库能有效地帮助一个组织或企业科学地管理各类信息资源。

数据是数据库中存储的基本对象，是按一定顺序排列组合的物理符号。数据有多种表现形式，可以是数字、文字、图像，甚至是音频或视频，它们都可以经过数字化后存入计算机。

数据库是数据的集合，具有统一的结构形式并存放于统一的存储介质内，是多种应用数据的集成，并可被各个应用程序所共享。

在日常生活中，人们可以直接用中文、英文等自然语言描述客观事物。在计算机中，则要抽象出对这些事物感兴趣的特征，并组成一个记录来描述。

例如，在学生档案中，学生信息是由学号、姓名、性别、年龄、籍贯、联系电话等特征组成的，那么这些具体的特征值所构成的一条记录就是一个学生的信息数据，例如“2016010102，张三，男，26，山西，计算机学院，185********”。

值得注意的是，数据的描述形式还不能完全表达其内容，需要经过解释。例如，对于上面这条学生记录，了解其含义的人会得到这样的信息：张三的学号是 2016010102，今年 26 岁，山西人，就读于计算机学院，他的联系电话是 185********；

而不了解其语义的人则无法理解其含义。所以，数据和对数据的解释是不可分的，数据的解释是指对数据含义的说明，数据的含义也称数据的语义，因此数据与其语义密不可分，没有语义的数据是没有意义和不完整的。

数据存储方式

计算机数据（Data）的存储一般以硬盘为数据存储空间资源，从而保证计算机内的数据能够持续保存。对于数据的处理，一般会采用数据库相关的技术进行处理，从而保证数据处理的高效性。

采用数据库的管理模式不仅提高了数据的存储效率，而且在存储的层面上提高了数据的安全性。通过分类的存储模式让数据管理更加安全便捷，更能实现对数据的调用和对比，并且方便查询等操作的使用。

数据库的存储结构

数据库的存储结构是指数据库中的物理数据和逻辑数据的表示形式、物理数据和逻辑数据之间关系映射方式的描述。在数据库技术中，可以使用两种形式描述客观现实的数据：物理数据描述和逻辑数据描述。物理数据和逻辑数据之间的转换通过数据库管理系统实现。

物理数据描述

物理数据描述是指数据在存储设备上的存储方式，物理数据是实际存放在存储设备上的数据，这些数据也称为物理记录。根据物理记录存储的位置，又可以分为有序存储和无序存储。

在物理数据描述中，使用的数据描述术语包括以下各项。

• 位（bit）：二进制的一个单位称为位，位只能取 1 或 0。
• 字节（byte）：8 个位称为一个字节，可以存放对应 ASCII 码的一个字符。
• 字（word）：若干个字节组成一个字。一个字所含的二进制的位数称为字长，许多计算机的字长是不同的，例如计算机的字长可以是 8 位、16 位、24 位、32 位等。
• 块（block）：内存储器和外存储器交换信息的最小单位，又称为物理块或物理记录，每块的大小通常为 256 字节、512 字节、1024 字节等。
• 卷（volume）：一台输入输出设备所能装载的全部有用信息，例如磁带机的一盘磁带即为一卷，磁盘设备的一个盘组也是一卷。
• 无序存储（unordered）：数据记录按照插入的顺序进行存储。

逻辑数据描述

逻辑数据描述是指用户或程序员用于操作的数据形式，逻辑数据是一种抽象的概念，是对客观现实世界的反映和记录，这些数据也可以称为逻辑记录。
逻辑数据包含两个层次，一个层次是对客观现实信息世界的描述，另一个层次是对数据库管理系统中数据的描述。

在对客观现实信息世界的描述中，使用的术语包括以下几项。

• 实体（entity）：客观现实存在的东西使用实体来描述。实体既可以是具体的、有形的对象，也可以是抽象的、无形的对象。例如，一本书是一个有形对象，一次借书过程则是一个无形的对象。
• 实体集（entities）：特性完全相同的同类实体的集合称为实体集。例如，一个图书馆所有的书籍是一个实体集，该图书馆的所有借书过程也是一个实体集。
• 属性（attribute）：实体的特性称为属性。每个属性都有一个值域，这些值域可以是整数类型、浮点数类型、字符类型或日期类型等。例如，实体书的属性包括书名、书号、出版日期、页数、价格以及出版社等，这些属性对应的值域分别为字符类型、字符类型、日期类型、整数类型、浮点数类型和字符类型等。
• 标识符（identifier）：能够唯一地标识每个实体的属性或属性集。例如，书的书号属性是实体书的标识符，借书过程实体的标识符包括借书证号、书号两个属性。

这些逻辑数据最终要通过数据库管理系统来转换成物理数据。在数据库管理系统中，描述逻辑数据的术语包括哪些呢？

下面以关系型数据库管理系统为例进行介绍。

• 数据项（data item）：也称为字段（field），标记实体属性的可以命名的最小信息单位，数据项的命名一般采用属性的描述性名称。这些名称可以是中文、英文或汉语拼音。
• 元组（tuple）：也称为记录（record），数据项的集合称为元组。一个元组表示一个具体的实体。
• 关系（relation）：在关系型数据库系统中，同一类元组所在的集合称为关系。关系适用于描述实体集，它包括一个实体集的所有元组。例如，所有的图书可以组成一个 books 关系。
• 键码（key）：在关系型数据库系统中，能够唯一地标识关系中每个元组的数据项或数据项的组合称为关系的键码。

客观实体经过两层逻辑数据的描述，最后转变成实际存储的物理数据。

数据库在开发中的作用

从数据库系统应用角度来看，数据库系统常见的运行与应用结构有：客户端/服务器结构、浏览器/服务器结构。

在客户端/服务器（Client/Server，C/S）结构中，数据库的使用者（如 DBA、程序设计者）通过命令行客户端、图形化界面管理工具或应用程序等连接到数据库管理系统，可以通过数据库管理系统查询和处理存储在底层数据库中的各种数据。

数据库使用者与命令行客户端、图形化界面管理工具或应用程序等直接交互，而不与数据库管理系统直接联系。

在这种结构中，命令行客户端、图形化界面管理工具或应用程序等称为“客户端”或“前台”，主要完成与数据库使用者的交互任务；而数据库管理系统则称为“服务器”或“后台”，主要负责数据管理。这种结构经常被称为“C/S”结构。

在客户端/服务器模式中，客户端和服务器可以同时工作在同一台计算机上，这种工作方式称为“单机方式”；也可以“网络方式”运行，即服务器被安装和部署在网络中某一台或多台主机上。对于客户端应用程序的开发，目前常用的语言工具主要有 Visual C++、Delphi、.NET 框架、Visual Basic、Python 等。

数据库能有效存储数据，读取数据、查找数据更是方便，其实那些管理软件就是通过软件的界面向内部的数据库进行数据的增、删、改、查操作。

数据库：数据库是面向交易的处理系统（业务系统），它是针对具体业务在数据库联机的日常操作，通常对记录进行查询、修改。

用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段，主要用于操作型处理，也被称为联机事务处理 OLTP（On-Line Transaction Processing）。

2 数据仓库

2.1基本概念

数据仓库，英文名称为Data Warehouse，可简写为DW或DWH。数据仓库顾名思义，是一个很大的数据存储集合，出于企业的分析性报告和决策支持目的而创建，对多样的业务数据进行筛选与整合。它为企业提供一定的BI（商业智能）能力，指导业务流程改进、监视时间、成本、质量以及控制。

数据仓库本身并不“生产”任何数据，同时自身也不需要“消费”任何的数据，数据来源于外部，并且开放给外部应用，这也是为什么叫“仓库”，而不叫“工厂”的原因。

数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理中的决策制定。对于数据仓库的概念我们可以从两个层次予以理解：首先,数据仓库用于支持决策,面向分析型数据处理,它不同于企业现有的操作型数据库; 其次,数据仓库是对多个异构的数据源有效集成,集成后按照主题进行了重组,并包含历史数据,而且存放在数据仓库中的数据一般不再修改。

数据仓库将各个异构的数据源数据库的数据给统一管理起来，并且完成了质量较差的数据的剔除、格式转换，最终按照一种合理的建模方式来完成源数据组织形式的转变，以更好的支持到前端的可视化分析。数据仓库的输入方式是各种各样的数据源，最终的输出用于企业的数据分析、数据挖掘、数据报表等方向。

2.2主要特征

数据仓库是面向主题的（Subject-Oriented ）、集成的（Integrated）、稳定的（Non-Volatile）和时变的（Time-Variant ）数据集合，面向数据分析，用以支持管理决策。
1.主题性 不同于传统数据库对应于某一个或多个项目，数据仓库根据使用者实际需求，将不同数据源的数据在一个较高的抽象层次上做整合，所有数据都围绕某一主题来组织。
2.集成性 数据仓库中存储的数据是来源于多个数据源的集成，原始数据来自不同的数据源，存储方式各不相同。要整合成为最终的数据集合，需要从数据源经过一系列抽取、清洗、转换的过程。
3.稳定性 数据仓库中保存的数据是一系列历史快照，不允许被修改。用户只能通过分析工具进行查询和分析。这里说明一点，数据仓库基本上是不许允许用户进行修改，删除操作的。大多数的场景是用来查询分析数据。
4.时变性 数据仓库会定期接收新的集成数据，反应出最新的数据变化。这和稳定特点并不矛盾。另外说明，上面我们已经说了数据仓库中的历史数据是不能修改的，那我们每天修改或新增的数据，从业务数据库中导入数据仓库中，可以以时间戳标记版本来标记最新数据，老旧的数据就可以定期删除，保证数据分析的准确性。

2.3数据仓库与数据库的区别

数据库与数据仓库的区别实际讲的是 OLTP 与 OLAP 的区别。

操作型处理，叫联机事务处理 OLTP（On-Line Transaction Processing，），也可以称面向交易的处理系统，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段，主要用于操作型处理，像Mysql，Oracle等关系型数据库一般属于OLTP。

分析型处理，叫联机分析处理 OLAP（On-Line Analytical Processing）一般针对某些主题的历史数据进行分析，支持管理决策。

首先要明白，数据仓库的出现，并不是要取代数据库。数据库是面向事务的设计，数据仓库是面向主题设计的。数据库一般存储业务数据，数据仓库存储的一般是历史数据。
数据库设计是尽量避免冗余，一般针对某一业务应用进行设计，比如一张简单的User表，记录用户名、密码等简单数据即可，符合业务应用，但是不符合分析。数据仓库在设计是有意引入冗余，依照分析需求，分析维度、分析指标进行设计。数据库是为捕获数据而设计，数据仓库是为分析数据而设计。 以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记账。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。
显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。

数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。

3 数据仓库的分层

3.1数仓分层

数据分层是数据仓库设计中一个十分重要的环节，良好的分层设计能够让整个数据体系更容易被理解和使用。本文介绍的是如何理解数据仓库中各个分层的作用。

图解数据分层

3.2何为数仓DW

Data warehouse（可简写为DW或者DWH）数据仓库，是在数据库已经大量存在的情况下，它是一整套包括了etl、调度、建模在内的完整的理论体系。
数据仓库的方案建设的目的，是为前端查询和分析作为基础，主要应用于OLAP（on-line Analytical Processing），支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。目前行业比较流行的有：AWS Redshift，Greenplum，Hive等。
数据仓库并不是数据的最终目的地，而是为数据最终的目的地做好准备，这些准备包含：清洗、转义、分类、重组、合并、拆分、统计等

3.3为何要分层

数据仓库中涉及到的问题：

为什么要做数据仓库？
为什么要做数据质量管理？
为什么要做元数据管理？
数仓分层中每个层的作用是什么？
……
在实际的工作中，我们都希望自己的数据能够有顺序地流转，设计者和使用者能够清晰地知道数据的整个声明周期，比如下面左图。

但是，实际情况下，我们所面临的数据状况很有可能是复杂性高、且层级混乱的，我们可能会做出一套表依赖结构混乱，且出现循环依赖的数据体系，比如下面的右图。

为了解决我们可能面临的问题，需要一套行之有效的数据组织、管理和处理方法，来让我们的数据体系更加有序，这就是数据分层。数据分层的好处：

• 清晰数据结构：让每个数据层都有自己的作用和职责，在使用和维护的时候能够更方便和理解
• 复杂问题简化：将一个复杂的任务拆解成多个步骤来分步骤完成，每个层只解决特定的问题
• 统一数据口径：通过数据分层，提供统一的数据出口，统一输出口径
• 减少重复开发：规范数据分层，开发通用的中间层，可以极大地减少重复计算的工作

3.4数据分层

每个公司的业务都可以根据自己的业务需求分层不同的层次；目前比较流行的数据分层：数据运营层、数据仓库层、数据服务层。

数据运营层ODS

数据运营层：Operation Data Store 数据准备区，也称为贴源层。数据源中的数据，经过抽取、洗净、传输，也就是ETL过程之后进入本层。该层的主要功能：

• ODS是后面数据仓库层的准备区
• 为DWD层提供原始数据
• 减少对业务系统的影响

为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可
这层的数据是后续数据仓库加工数据的来源。数据来源的方式：
业务库：sqoop定时抽取数据；实时方面考虑使用canal监听mysql的binlog日志，实时接入即可

• 埋点日志：日志一般是以文件的形式保存，可以选择使用flume来
• 定时同步；可以使用spark streaming或者Flink、Kafka来实时接入
• 消息队列：来自ActiveMQ、Kafka的数据等

数据仓库层

数据仓库层从上到下，又可以分为3个层：数据细节层DWD、数据中间层DWM、数据服务层DWS。

• 数据细节层DWD
  数据细节层：data warehouse details，DWD
  该层是业务层和数据仓库的隔离层，保持和ODS层一样的数据颗粒度；主要是对ODS数据层做一些数据的清洗和规范化的操作，比如去除空数据、脏数据、离群值等。
  为了提高数据明细层的易用性，该层通常会才采用一些维度退化方法，将维度退化至事实表中，减少事实表和维表的关联。
• 数据中间层DWM
  数据中间层：Data Warehouse Middle，DWM；
  该层是在DWD层的数据基础上，对数据做一些轻微的聚合操作，生成一些列的中间结果表，提升公共指标的复用性，减少重复加工的工作。

简答来说，对通用的核心维度进行聚合操作，算出相应的统计指标

• 数据服务层DWS
  数据服务层：Data Warehouse Service，DWS；
  该层是基于DWM上的基础数据，整合汇总成分析某一个主题域的数据服务层，一般是宽表，用于提供后续的业务查询，OLAP分析，数据分发等。
  一般来说，该层的数据表会相对较少；一张表会涵盖比较多的业务内容，由于其字段较多，因此一般也会称该层的表为宽表。
• 数据应用层ADS
  数据应用层：Application Data Service，ADS；
  该层主要是提供给数据产品和数据分析使用的数据，一般会存放在ES、Redis、PostgreSql等系统中供线上系统使用；也可能存放在hive或者Druid中，供数据分析和数据挖掘使用，比如常用的数据报表就是存在这里的。
• 事实表 Fact Table
  事实表是指存储有事实记录的表，比如系统日志、销售记录等。事实表的记录在不断地增长，比如电商的商品订单表，就是类似的情况，所以事实表的体积通常是远大于其他表。
• 维表层Dimension
  维度表（Dimension Table）或维表，有时也称查找表（Lookup Table），是与事实表相对应的一种表；它保存了维度的属性值，可以跟事实表做关联，相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理。维度表主要是包含两个部分：
• 高基数维度数据：一般是用户资料表、商品资料表类似的资料表，数据量可能是千万级或者上亿级别
• 低基数维度数据：一般是配置表，比如枚举字段对应的中文含义，或者日期维表等；数据量可能就是个位数或者几千几万。
  常见的维度表有：日期表（存储与日期对应的周、月、季度等的属性）、地点表（包含国家、省／州、城市等属性）等。

4 数据湖

4.1基本定义

数据湖是目前比较热的一个概念，许多企业都在构建或者计划构建自己的数据湖。但是在计划构建数据湖之前，搞清楚什么是数据湖，明确一个数据湖项目的基本组成，进而设计数据湖的基本架构，对于数据湖的构建至关重要。关于什么是数据湖，有如下定义

Wikipedia

Wikipedia是这样定义的：
数据湖（Data Lake）是一个存储企业的各种各样原始数据的大型仓库，其中的数据可供存取、处理、分析及传输。数据湖是以其自然格式存储的数据的系统或存储库，通常是对象Blob或文件。数据湖通常是企业所有数据的单一存储，包括源系统数据的原始副本，以及用于报告、可视化、分析和机器学习等任务的转换数据。数据湖可以包括来自关系数据库（行和列）的结构化数据，半结构化数据（CSV，日志，XML，JSON），非结构化数据（电子邮件，文档，PDF）和二进制数据（图像，音频，视频）。

AWS

AWS的定义相对就简洁一点：

数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据（无需先对数据进行结构化处理），并运行不同类型的分析 – 从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策。

微软

微软的定义就更加模糊了，并没有明确给出什么是Data Lake，而是取巧的将数据湖的功能作为定义

Azure的数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力，这些能力使得用户可以存储任意规模、任意类型、任意产生速度的数据，并且可以跨平台、跨语言的做所有类型的分析和处理。数据湖在能帮助用户加速应用数据的同时，消除了数据采集和存储的复杂性，同时也能支持批处理、流式计算、交互式分析等。数据湖能同现有的数据管理和治理的IT投资一起工作，保证数据的一致、可管理和安全。它也能同现有的业务数据库和数据仓库无缝集成，帮助扩展现有的数据应用。Azure数据湖吸取了大量企业级用户的经验，并且在微软一些业务中支持了大规模处理和分析场景，包括Office 365, Xbox Live, Azure, Windows, Bing和Skype。Azure解决了许多效率和可扩展性的挑战，作为一类服务使得用户可以最大化数据资产的价值来满足当前和未来需求。

关于数据湖的定义其实很多，但是基本上都围绕着以下几个特性展开。
1、 数据湖需要提供足够用的数据存储能力，这个存储保存了一个企业/组织中的所有数据。
2、 数据湖可以存储海量的任意类型的数据，包括结构化、半结构化和非结构化数据。
3、 数据湖中的数据是原始数据，是业务数据的完整副本。数据湖中的数据保持了他们在业务系统中原来的样子。
4、 数据湖需要具备完善的数据管理能力（完善的元数据），可以管理各类数据相关的要素，包括数据源、数据格式、连接信息、数据schema、权限管理等。
5、 数据湖需要具备多样化的分析能力，包括但不限于批处理、流式计算、交互式分析以及机器学习；同时，还需要提供一定的任务调度和管理能力。
6、 数据湖需要具备完善的数据生命周期管理能力。不光需要存储原始数据，还需要能够保存各类分析处理的中间结果，并完整的记录数据的分析处理过程，能帮助用户完整详细追溯任意一条数据的产生过程。
7、 数据湖需要具备完善的数据获取和数据发布能力。数据湖需要能支撑各种各样的数据源，并能从相关的数据源中获取全量/增量数据；然后规范存储。数据湖能将数据分析处理的结果推送到合适的存储引擎中，满足不同的应用访问需求。
8、 对于大数据的支持，包括超大规模存储以及可扩展的大规模数据处理能力。

综上，个人认为数据湖应该是一种不断演进中、可扩展的大数据存储、处理、分析的基础设施；以数据为导向，实现任意来源、任意速度、任意规模、任意类型数据的全量获取、全量存储、多模式处理与全生命周期管理；并通过与各类外部异构数据源的交互集成，支持各类企业级应用。

图1. 数据湖基本能力示意
这里需要再特别指出两点：1）可扩展是指规模的可扩展和能力的可扩展，即数据湖不但要能够随着数据量的增大，提供“足够”的存储和计算能力；还需要根据需要不断提供新的数据处理模式，例如可能一开始业务只需要批处理能力，但随着业务的发展，可能需要交互式的即席分析能力；又随着业务的实效性要求不断提升，可能需要支持实时分析和机器学习等丰富的能力。2）以数据为导向，是指数据湖对于用户来说要足够的简单、易用，帮助用户从复杂的IT基础设施运维工作中解脱出来，关注业务、关注模型、关注算法、关注数据。数据湖面向的是数据科学家、分析师。目前来看，云原生应该是构建数据湖的一种比较理想的构建方式，后面在“数据湖基本架构”一节会详细论述这一观点。

4.2数据湖的基本特征

根据要求，典型的组织将需要数据仓库和数据湖，因为它们可满足不同的需求和使用案例。
数据仓库是一个优化的数据库，用于分析来自事务系统和业务线应用程序的关系数据。事先定义数据结构和 Schema 以优化快速 SQL 查询，其中结果通常用于操作报告和分析。数据经过了清理、丰富和转换，因此可以充当用户可信任的“单一信息源”
。数据湖有所不同，因为它存储来自业务线应用程序的关系数据，以及来自移动应用程序、IoT 设备和社交媒体的非关系数据。捕获数据时，未定义数据结构或 Schema。这意味着您可以存储所有数据，而不需要精心设计也无需知道将来您可能需要哪些问题的答案。您可以对数据使用不同类型的分析（如 SQL 查询、大数据分析、全文搜索、实时分析和机器学习）来获得见解。
随着使用数据仓库的组织看到数据湖的优势，他们正在改进其仓库以包括数据湖，并启用各种查询功能、数据科学使用案例和用于发现新信息模型的高级功能。

通过对比数据湖与传统数仓的区别，可以从数据和计算两个层面进一步分析数据湖应该具备哪些特征。在数据方面：
1）“保真性”。数据湖中对于业务系统中的数据都会存储一份“一模一样”的完整拷贝。与数据仓库不同的地方在于，数据湖中必须要保存一份原始数据，无论是数据格式、数据模式、数据内容都不应该被修改。在这方面，数据湖强调的是对于业务数据“原汁原味”的保存。同时，数据湖应该能够存储任意类型/格式的数据。

2）“灵活性”： 上表一个点是 “写入型schema” v.s.“读取型schema”，其实本质上来讲是数据schema的设计发生在哪个阶段的问题。对于任何数据应用来说，其实schema的设计都是必不可少的，即使是mongoDB等一些强调“无模式”的数据库，其最佳实践里依然建议记录尽量采用相同/相似的结构。“写入型schema”背后隐含的逻辑是数据在写入之前，就需要根据业务的访问方式确定数据的schema，然后按照既定schema，完成数据导入，带来的好处是数据与业务的良好适配；但是这也意味着数仓的前期拥有成本会比较高，特别是当业务模式不清晰、业务还处于探索阶段时，数仓的灵活性不够。
数据湖强调的“读取型schema”，背后的潜在逻辑则是认为业务的不确定性是常态：我们无法预期业务的变化，那么我们就保持一定的灵活性，将设计去延后，让整个基础设施具备使数据“按需”贴合业务的能力。因此，个人认为“保真性”和“灵活性”是一脉相承的：既然没办法预估业务的变化，那么索性保持数据最为原始的状态，一旦需要时，可以根据需求对数据进行加工处理。因此，数据湖更加适合创新型企业、业务高速变化发展的企业。同时，数据湖的用户也相应的要求更高，数据科学家、业务分析师（配合一定的可视化工具）是数据湖的目标客户。

3）“可管理”：数据湖应该提供完善的数据管理能力。既然数据要求“保真性”和“灵活性”，那么至少数据湖中会存在两类数据：原始数据和处理后的数据。数据湖中的数据会不断的积累、演化。因此，对于数据管理能力也会要求很高，至少应该包含以下数据管理能力：数据源、数据连接、数据格式、数据schema（库/表/列/行）。同时，数据湖是单个企业/组织中统一的数据存放场所，因此，还需要具有一定的权限管理能力。

4）“可追溯”：数据湖是一个组织/企业中全量数据的存储场所，需要对数据的全生命周期进行管理，包括数据的定义、接入、存储、处理、分析、应用的全过程。一个强大的数据湖实现，需要能做到对其间的任意一条数据的接入、存储、处理、消费过程是可追溯的，能够清楚的重现数据完整的产生过程和流动过程。
在计算方面，个人认为数据湖对于计算能力要求其实非常广泛，完全取决于业务对于计算的要求。

5）丰富的计算引擎。从批处理、流式计算、交互式分析到机器学习，各类计算引擎都属于数据湖应该囊括的范畴。一般情况下，数据的加载、转换、处理会使用批处理计算引擎；需要实时计算的部分，会使用流式计算引擎；对于一些探索式的分析场景，可能又需要引入交互式分析引擎。随着大数据技术与人工智能技术的结合越来越紧密，各类机器学习/深度学习算法也被不断引入，例如TensorFlow/PyTorch框架已经支持从HDFS/S3/OSS上读取样本数据进行训练。因此，对于一个合格的数据湖项目而言，计算引擎的可扩展/可插拔，应该是一类基础能力

6）多模态的存储引擎。理论上，数据湖本身应该内置多模态的存储引擎，以满足不同的应用对于数据访问需求（综合考虑响应时间/并发/访问频次/成本等因素）。但是，在实际的使用过程中，数据湖中的数据通常并不会被高频次的访问，而且相关的应用也多在进行探索式的数据应用，为了达到可接受的性价比，数据湖建设通常会选择相对便宜的存储引擎（如S3/OSS/HDFS/OBS），并且在需要时与外置存储引擎协同工作，满足多样化的应用需求。

5 数据中台

5.1背景

伴随着云计算、大数据、人工智能等技术的迅速发展，以及这些技术与传统行业的快速融合，企业数字化、智能化转型的步伐逐渐加快。
到2021年，全球至少50%的GDP将被数字化，而每个行业的增长都会受到数字产品与服务、数据化运营的驱动。
数字化转型成功的企业，其内部和外部的交互均以数据为基础。业务的变化快速反馈在数据上，企业能够迅速感知并做出反应，而其决策与考核基于客观数据。同时，数据是活的，是流动的，越用越多，越用越有价值。随着数据与业务场景的不断交融，业务场景将逐步实现通过数据自动运转和自动优化，进而推动企业进入数字化和智能化的阶段。
传统IT建设方式下，企业的各种信息系统大多是独立采购或者独立建设的，无法做到信息的互联互通，导致企业内部形成多个数据孤岛。

传统烟囱式IT建设方式:在一个有一定规模的企业中，通常都会存在各种各样的应用系统，它们分别由企业的各个不同部门、在各种不同历史时期、为满足各种不同业务目的而开发。由于数据格式没有统一规范，相互之间没有联通、数据更没有整合，像一个个烟囱，因此称其为“烟囱式应用”

互联网、移动互联网的发展带来很多新的业务模式，很多企业尝试通过服务号、小程序、O2O平台等新模式触达客户、服务客户，新模式是通过新的平台支撑的，产生的数据与传统模式下的数据也无法互通，这进一步加剧了数据孤岛问题。分散在各个孤岛的数据无法很好地支撑企业的经营决策，也无法很好地应对快速变化的前端业务。因此需要一套机制，通过这套机制融合新老模式，整合分散在各个孤岛上的数据，快速形成数据服务能力，为企业经营决策、精细化运营提供支撑，这套机制就是数据中台，如下图所示。

5.2定义

与许多新概念诞生之初的境遇一样，数据中台目前正处于“定义混乱期”。
有人认为数据中台是云平台的一部分，同时包括业务中台和技术中台；有人认为数据中台是数据的共享、整合和深度分析；还有人认为数据中台是“计算平台+算法模型+智能硬件”，不仅有云端，还需要智能设备帮企业在终端收集线下数据……从服务方到客户方，对数据中台的理解并不相同，如同一千个观众心中就有一千个哈姆雷特。

数据中台是一套可持续“让企业的数据用起来”的机制，是一种战略选择和组织形式，是依据企业特有的业务模式和组织架构，通过有形的产品和实施方法论支撑，构建的一套持续不断把数据变成资产并服务于业务的机制。 数据来自于业务，并反哺业务，不断循环迭代，实现数据可见、可用、可运营

5.3数据中台必备的4个核心能力

数据中台需要具备数据汇聚整合、数据提纯加工、数据服务可视化、数据价值变现4个核心能力，让企业员工、客户、伙伴能够方便地应用数据

1.汇聚整合

随着业务的多元化发展，企业内部往往有多个信息部门和数据中心，大量系统、功能和应用重复建设，存在巨大的数据资源、计算资源和人力资源的浪费，同时组织壁垒也导致数据孤岛的出现，使得内外部数据难以全局规划。
数据中台需要对数据进行整合和完善，提供适用、适配、成熟、完善的一站式大数据平台工具，在简便有效的基础上，实现数据采集、交换等任务配置以及监控管理。
数据中台必须具备数据集成与运营方面的能力，能够接入、转换、写入或缓存企业内外部多种来源的数据，协助不同部门和团队的数据使用者更好地定位数据、理解数据。同时数据安全、灵活可用也是绝大多数企业看重的，他们期望数据中台能协助企业提升数据可用性和易用性，且在系统部署上能支持多种模式。

2.提纯加工

数据就像石油，需要经过提纯加工才能使用，这个过程就是数据资产化。
企业需要完整的数据资产体系，围绕着能给业务带来价值的数据资产进行建设，推动业务数据向数据资产的转化。
传统的数字化建设往往局限在单个业务流程，忽视了多业务的关联数据，缺乏对数据的深度理解。数据中台必须连通全域数据，通过统一的数据标准和质量体系，建设提纯加工后的标准数据资产体系，以满足企业业务对数据的需求。

3.服务可视化

为了尽快让数据用起来，数据中台必须提供便捷、快速的数据服务能力，让相关人员能够迅速开发数据应用，支持数据资产场景化能力的快速输出，以响应客户的动态需求。
多数企业还期待数据中台可以提供数据化运营平台，帮助企业快速实现数据资产的可视化分析，提供包括实时流数据分析、预测分析、机器学习等更为高级的服务，为企业数据化运营赋能。
此外，伴随着人工智能技术的飞速发展，AI的能力也被多数企业期待能应用到数据中台上，实现自然语言处理等方面的服务。数据洞察来源于分析，数据中台必须提供丰富的分析功能，数据资产必须服务于业务分析才能解决企业在数据洞察方面的短板，实现与业务的紧密结合

4.价值变现

数据中台通过打通企业数据，提供以前单个部门或者单个业务单元无法提供的数据服务能力，以实现数据的更大价值变现。

企业期待数据中台能提升跨部门的普适性业务价值能力，更好地管理数据应用，将数据洞察变成直接驱动业务行动的核心动能，跨业务场景推进数据实践。同时，企业对于如何评估业务行动的效果也十分关注，因为没有效果评估就难以得到有效反馈，从而难以迭代更新数据应用，难以持续为客户带来价值，如图2-6所示。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JeaFmN3M-1658833684981)(en-resource://database/1460:1)]

如前所述，数据中台是一套持续地让企业的数据用起来的机制，要想把数据用起来，四个核心能力都需要不断迭代和提升。从战略上来看，汇聚整合、提纯加工、服务可视化和价值变现的能力是数据中台最核心的竞争力， 是企业真正将数据转化为生产力、实现数字化转型和商业创新、永葆竞争力的保障

5.4数据中台的价值

业务价值

业务价值：从洞察走向赋能业务创新，形成核心壁垒
在以客户为中心的时代，数据中台对数字化转型具有重要作用，以数据中台为基础的数据系统将位于企业应用的核心，通过数据从企业降本增效、精细化经营等方面为企业带来巨大收益。具体来说，笔者们认为包含以下三个层面：

1.以客户为中心，用洞察驱动企业稳健行动
在以客户为中心的时代，客户的观念和行为正在从根本上改变企业的经营方式以及企业与客户的互动方式。
数据中台建设的核心目标就是以客户为中心的持续规模化创新，而数据中台的出现，将会极大提升数据的应用能力，将海量数据转化为高质量数据资产，为企业提供更深层的客户洞察，从而为客户提供更具个性化和智能化的产品和服务。
譬如，数据中台能够汇聚全渠道的数据，在标签管理、营销圈人、效果分析等应用上实现全域的闭环，优化对客户全生命周期的理解。此外，以数据中台为基础，通过数据化运营提升客户留存、复购和忠诚度，也得到诸多企业的认可。

2.以数据为基础，支持大规模商业模式创新
只有依托数据和算法，将由海量数据提炼的洞察转化为行动，才能推动大规模的商业创新。数据中台在通过算法将洞察直接转化为行动、实现大规模商业创新方面的能力，令人瞩目。
另一方面，数据无法被业务用起来的一个原因是数据没办法变得可阅读、易理解。信息技术人员不够懂业务，而业务人员不够懂数据，导致数据应用到业务变得很困难，数据中台需要考虑将信息技术人员与业务人员之间的障碍打破，信息技术人员将数据变成业务人员可阅读、易理解的内容，业务人员看到内容后能够很快结合到业务中去，这样才能更好地支撑商业模式的创新
。此外，数据中台提供标准的数据访问能力，简化集成复杂性、促进互操作性等特性也非常受企业CIO们的青睐。同时，在快速构建服务能力、加快商业创新、提升业务适配等方面，数据中台也将会发挥重要的作用。

3.盘活全量数据，构筑坚实壁垒以持续领先
在以客户为中心的时代，只有赢得客户的企业才能在竞争中保持优势。企业能否真正做到“客户至上”，并不断提高对客户的快速响应力来满足客户的需求，甚至引领市场潮流，持续推进规模化创新，终将决定企业能否在充满挑战和机遇的市场上发展壮大，长久保持生命力与竞争力。
面对纷繁复杂而又分散割裂的海量数据，数据中台的突出优势在于，能充分利用内外部数据，打破数据孤岛的现状，打造持续增值的数据资产，在此基础上，能够降低使用数据服务的门槛，繁荣数据服务的生态，实现数据“越用越多”的价值闭环，牢牢抓住客户，确保竞争优势。

技术价值

技术价值：能力多、成本低、应用广

数字化转型的需求必将催生多元化的数据场景，而多元化的数据场景将会带来以下技术需求，企业数据中台建设势在必行。

1.应对多数据处理的需求
针对不同的数据应用场景，需要能够快速应对多数据处理需求，比如：
要保持原来的报表需求，仍需要保持批量离线计算的能力（Hadoop、Oracle RAC）；
针对准实时的指标统计和实时推荐，需要实时流式计算的能力（Storm、Spark Streaming、Flink）；
针对决策类业务如海量人群的圈人需求和ad-hoc需求，需要即席计算能力（Greenplum、Elasticsearch、Impala）；
针对高并发业务场景（如用户画像），需要在线计算能力（MySQL、Redis、Oracle）。
因此，企业需要一个统一的数据中台来满足离线／实时计算需求、各种查询需求（实时查询和ad hoc），同时在将来新数据引擎（更快的计算框架，更快的查询响应）出现时，又不需要重构目前的大数据体系。

2.丰富标签数据，降低管理成本
根据全国信标委大数据标准工作组发布的《数据管理能力成熟度模型》（DCMM），针对数据标准提到的数据分类主要有主数据、参考数据和指标数据，但根据目前真实的数据建设情况来看，需要对一类数据进行定义和分类，譬如标签名为“消费特征”，标签值为“促销敏感”“货比三家”“犹豫不决”。数据中台能对这类标签进行快速定义和有效管理。

3.数据的价值能体现业务系统效果而不仅是准确度
过去的数据应用场景主要为报表需求，注重数据的准确性，但在更多数据场景下，特别是对于标签数据的应用，越来越多的数据是需要不断“优化”的，数据本身没有准不准确之分，比如某个会员是属于促销敏感人群，这个数据其实更多的说的是概率。

4.支持跨主题域访问数据
企业早期建设的应用数据层ADS（传统数据仓库ODS/DW/ADS）更多是为某个主题域所服务的，如营销域、人力资源域、风控域，而企业在数据应用的时候往往需要打破各个业务主题，会从业务对象主体出发来考虑数据应用，如人（会员、供应商、渠道、员工）和物（商品、仓库、合同），从全域角度设计完整的面向对象的数据标签体系。

5.数据可以快速复用而不仅是复制

传统的架构中，要将数据应用到业务中，通用的做法都是通过数据同步能力，把计算的结果同步给业务系统，由业务系统自行处理，这会带来一个数据管理问题，即无法获取数据在应用场景中的具体价值和热度，整个数据血缘链路也是割裂的。这种方式笔者们认为是复制数据，而不是复用数据。如何快速复用数据，正是可以在数据中台中解决的问题。
数字化浪潮席卷全球，企业正面临着前所未有的挑战和机遇，必须不断加速数字化转型才能生存和保持领先。数据中台能够帮助企业聚合内外部数据，支撑高效的数据服务，最终提升企业决策水平和业务表现。企业期待通过数据中台把原始数据转化为数据资产，快速构建数据服务，使企业可以持续、充分地利用数据，实现数据可见、可用、可运营的目标，以数据来驱动决策和运营，不断深化数字化转型。总结一句话：数据中台是把数据这种生产资料转变为数据生产力的过程。

else

通过数据中台把数据变为一种服务能力，既能提升管理、决策水平，又能直接支撑企业业务。数据中台不仅仅是技术，也不仅仅是产品，而是一套完整的让数据用起来的机制。既然是“机制”，就需要从企业战略、组织、人才等方面来全方位地规划和配合，而不能仅仅停留在工具和产品层面。

数据中台通过对企业内外部多源异构的数据采集、治理、建模、分析和应用，使数据对内优化管理提高业务价值，对外进行数据合作让业务价值得到释放，使之成为企业数据资产管理中枢。数据中台建立后，会形成数据API服务，为企业和客户提供高效各种数据服务。数据中台对一个企业的数字化转型和可持续发展起着至关重要的作用。数据中台为解耦而生，企业建设数据中台的最大意义就是应用与数据之间的解藕，这样企业就可以不受限制地按需构建满足业务需求的数据应用。

• 构建了开放、灵活、可扩展的企业级统一数据管理和分析平台， 将企业内、外部数据随需关联，打破了数据的系统界限。
• 利用大数据智能分析、数据可视化等技术，实现了数据共享、日常报表自动生成、快速和智能分析，满足企业各级部门之间的数据分析应用需求。
• 深度挖掘数据价值，助力企业数字化转型落地。实现了数据的目录、模型、标准、认责、安全、可视化、共享等管理，实现数据集中存储、处理、分类与管理，建立大数据分析工具库、算法服务库，实现报表生成自动化、数据分析敏捷化、数据挖掘可视化，实现数据质量评估、落地管理流程。

6 数据平台

数据平台是在大数据基础上出现的融合了结构化和非结构化数据的数据基础平台，为业务提供服务的方式主要是直接提供数据集。数据平台的出现是为了解决数据仓库不能处理非结构化数据和报表开发周期长的问题，所以先撇开业务需求、把企业所有的数据都抽取出来放到一起，成为一个大的数据集，其中有结构化数据、非结构化数据等。当业务方有需求的时候，再把他们需要的若干个小数据集单独提取出来，以数据集的形式提供给数据应用。大数据时代，数据平台一般被称之为大数据平台。狭义上的大数据平台和传统数据平台的功能一致，只是技术架构和数据容量方面的不同，但广义的大数据平台通常被赋予更多的使命，它不仅存储多样化的数据类型，还具有报表分析等数据仓库的功能，以及其他数据分析挖掘方面的高级功能。

数据仓库 VS 数据湖

相较而言，数据湖是较新的技术，拥有不断演变的架构。数据湖存储任何形式（包括结构化和非结构化）和任何格式（包括文本、音频、视频和图像）的原始数据。根据定义，数据湖不会接受数据治理，但专家们一致认为良好的数据管理对预防数据湖转变为数据沼泽不可或缺。数据湖在数据读取期间创建模式。与数据仓库相比，数据湖缺乏结构性，而且更灵活，并且提供了更高的敏捷性。值得一提的是，数据湖非常适合使用机器学习和深度学习来执行各种任务，比如数据挖掘和数据分析，以及提取非结构化数据等。

数据仓库 VS 数据平台

由于数据仓库具有历史性的特性，其中存储的数据大多是结构化数据；而数据平台的出现解决了数据仓库不能处理非结构化数据和报表开发周期长的问题。

数据仓库 VS 数据中台

数据仓库和传统的数据平台，其出发点为一个支撑性的技术系统，即一定要先考虑我具有什么数据，然后我才能干什么，因此特别强调数据质量和元数据管理；而数据中台的第一出发点不是数据而是业务，一开始不用看你系统里面有什么数据，而是去解决你的业务问题需要什么样的数据服务。

在具体的技术处理环节，二者也有明显不同，数据的预处理流程正在从传统的ETL结构向ELT结构转变。传统的数据仓库集成处理架构是ETL结构，这是构建数据仓库的重要一环，即用户从数据源抽取出所需的数据，经过数据清洗，将数据加载到数据仓库中去。而大数据背景下的架构体系是ELT结构，其根据上层的应用需求，随时从数据中台中抽取想要的原始数据进行建模分析。

7 总结

根据以上数据平台、数据仓库、数据湖和数据中台的概念论述和对比，我们进行如下总结：

• 数据中台、数据仓库和数据湖没有直接的关系；
• 数据中台、数据平台、数据仓库和数据湖在某个维度上为业务产生价值的形式有不同的侧重；
• 数据中台是企业级的逻辑概念，体现企业数据向业务价值转化的能力，为业务提供服务的主要方式是数据 API；
• 数据仓库是一个相对具体的功能概念，是存储和管理一个或多个主题数据的集合，为业务提供服务的方式主要是分析报表；
• 数据平台是在大数据基础上出现的融合了结构化和非结构化数据的数据基础平台，为业务提供服务的方式主要是直接提供数据集；
• 数据中台距离业务更近，能够更快速的响应业务和应用开发需求，从而为业务提供速度更快的服务；
• 数据仓库是为了支持管理决策分析，而数据中台则是将数据服务化之后提供给业务系统，不仅限于分析型场景，也适用于交易型场景；
• 数据中台可以建立在数据仓库和数据平台之上，是加速企业从数据到业务价值的过程的中间层。

8 API

API（Application Programming Interface,应用程序编程接口）是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。

举个常见的例子，在京东上下单付款之后，商家选用顺丰发货，然后你就可以在京东上实时查看当前的物流信息。京东和顺丰作为两家独立的公司，为什么会在京东上实时看到顺丰的快递信息，这就要用到API，当查看自己的快递信息时，京东利用顺丰提供的API接口，可以实时调取信息呈现在自己的网站上。除此，你也可以在快递100上输入订单号查取到快递信息。只要有合作，或是有允许，别的公司都可以通过顺丰提供的API接口调取到快递信息。既然有多方调用，那提供一个统一的调用规范会方便很多。

9 云原生

“云原生”，很多人会对这个新名词感到困惑，到底什么是云原生，云原生又能给我们带来什么呢？其实云原生的概念最早是由来自Pivotal的MattStine于2013年首次提出，这是他根据自身多年的架构和咨询经验总结出来的一个思想集合，得到了开源社区的不断完善，并被一直延续使用至今。

9.1定义

那么到底什么是“云原生”呢？我们试图先从字面意思理解“云（Cloud）”和“原生（Native）”。

• “云（Cloud）”这个字面意识不难理解简单的看就是天空中漂浮的一朵云，那么这个“云”放在科技环境下由从指代网络、互联网的标识到现在的云计算，所以可以说“云”在现在我们默认指代云计算。
• “原生(Native)”字面的意识理解为本地人，那么同样的放到现今的科技大环境下就是指"应用所处的环境"。
  所以"云原生"可以简单的理解为：“一个应用系统借助云计算相关的周边技术进行设计研发，从而使该应用能完美的适配云上环境”。
  云原生计算基金会总经理Priyanka Sharma对云原生的解释为：“云原生技术是指工程师和软件人员利用云计算构建更快、更有弹性的技术，这样做是为了快速满足客户的需求”。

而官网（CNCF）上则将云原生的定义概况为：服务网格、声明式API、不可变基础设施、微服务、容器这五大特征，这也成了很多人对云原生的基础印象。

总结来说，云原生就是一个快速构建应用的理念，一种快速交付应用的技术集合。 云原生还有一个非常重要的知识点，那就是云原生基金会，毕竟云原生这个理念需要落地推行的话还是需要靠众人来拾材，CNCF(云原生计算基金会)致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术，可以说CNCF的主要目的是培育云原生工具市场。

9.2云原生的代表技术

上文提到过云原生是一种理念，一个技术栈的集合。那么相对应的技术栈主要有：容器、服务网格、微服务、不可变基础设施和声明式API。

• 容器：容器是与系统其他部分隔开的一系列进程。运行这些进程所需的所有文件都由一个镜像提供，这意味着从开发到测试再到生产的整个过程中，容器都具有可移植性和一致性。简单的说容器就是存放应用和应用相关依赖的“独立集装箱”，根据运送的货物的不同特性可以制定多种集装箱类型（即容器镜像）
• 服务网格：服务网格简单的说可以看做是我们平时用的代理软件，但这个代理软件又更加的智能。Service Mesh可以看做是传统代理的升级版，用来解决现在微服务框架中出现的问题，可以把 Service Mesh看做是分布式的微服务代理。
• 微服务：将应用程序构造为一组松散耦合的服务。在微服务体系结构中，服务是细粒度的，协议是轻量级的。简单的说就是其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。
• 不可变基础设施：这里基础设施可以理解为一个应用运行所需要的基本需求，不可变性最基本的就是指运行服务的服务器在完成部署后，就不在进行更改。这里指代容器镜像。
• 声明式API：描述最终运行环境的状态，而由系统来决定如何来创建这个环境。例如，你的描述就变成“创建一个有三个Nginx的集群”，而不是把创建Nginx的命令运行三次组成一个集群。这样的好处是当运行环境与描述不符合时，系统能检测到差异，并自动修复，这样系统就有了自动容错的功能。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

9.3云原生能带来什么

在去年IDC（互联网数据中心）对企业的调研中，有将近70%已经将云策略落地，却只有3%能带来明显的获利突破，差异就在技术面的“云实践成熟度”也就是云原生化。
MSP团队（基础设施平台服务商）在面对一个云化项目时大致的流程，首先需要做相关的业务系统的调研，然后选择相对应的云平台，然后给出相关的云化方案，最后根据方案对业务系统进行迁移或者云化的改造。但是面对混合云或多云环境的下云特色存在差异性，导致了在云实践上的差异性。
而云原生化的云服务平台，不仅能够显着的降低基础建设与管理成本、提高布署灵活性与可扩充性，而且还有较高的安全性。

• 在微服务化方面：云原生将应用程序代码解耦成独立模块化单元，降低微服务的部属时间与互依性，提高应用的扩展性等。
• 在容器化包装方面：过去程序开发者可能需要创建多个虚拟机好让不同的应用程序运作，但程序容器化让多个应用程序得以存在同一操作环境中，开发人员将代码、微服务放置在可复制、搬移的容器中，轻松地复制、发布到任意云平台，多个容器间不会互相干扰（沙盒机制），不仅减少管理工作还能更有效地利用硬件资源，实现更快的持续集成、交付与发布。
• 在动态管理方面：通过集中的编排调度系统进行动态管理和调度，达到高速、低风险、迅速扩展和部署的方式，进行应用或服务的构建、测试、部署。

借助以上优势以及相对一致的实践方式，云原生能快速的打通各家云环境的壁垒，企业可以对市场变化做出最快的反应，使得新创云原生企业拥有能不断颠覆传统企业的威力。

9.4云原生的挑战

根据CNCF的统计自2016年以来，生产中使用容器的数量增加了300％。根据这个规模来看若是在大型应用云化部署后（这里假设都是以容器实例在运行），那么这个应用数以百计或者千计的容器该如何做好全生命周期的管理，如：监控日志的采集告警、调度、以及应用模块与模块之间链路调用追踪等将会是我们即将面临的最大的挑战之一。