从数据仓库到数据中台，终于有人说清楚了

作者简介：王春波，《高效使用Greenplum：入门、进阶和数据中台》作者，“数据中台研习社”号主，十年数据开发从业者，资深零售数仓项目实施专家。

以下内容为《高效使用Greenplum：入门、进阶和数据中台》删减内容。欢迎大家关注我的公众号“数据中台研习社”或者购买本书。

数据仓库简史

提到数据中台，我们不得不从它的前辈数据仓库说起。数据仓库的概念可以追溯到20世纪80年代，当时IBM的研究人员提出了商业数据仓库的概念。本质上，数据仓库试图提供一种从操作型系统到决策支持环境的数据流架构模型。数据仓库概念的提出，是为了解决和数据流相关的各种问题，特别是多重数据复制带来的高成本问题。

在没有数据仓库的时代，数据分析人员需要收集、清洗、整合来自多个数据源的数据，并为每个决策支持环境做部分数据复制，过程耗时长并且准确率低。在当时的大型企业里，通常是多个决策支持环境独立运作。一方面，由于系统迭代更新快，数据源通常是已经下线的旧业务系统，为数据分析工作增添了难度。另一方面，尽管每个决策分析系统服务于不同的用户，但这些环境经常需要大量相似或者相同的数据，导致数据清洗过程重复且烦琐。在这个发展背景下，数据仓库应运而生。

数据仓库之父Bill Inmon在1991年出版的Building the Data Warehouse一书中首次提出了数据仓库的概念。Inmon将数据仓库描述为一个面向主题的、集成的、随时间变化的、非易失的数据集合，用于支持管理者的决策过程。这个定义比较复杂并且难以理解，下面我们将它分解开来进行说明。

1. 面向主题

传统的操作型系统是围绕系统的功能性应用进行组织的，而数据仓库是面向主题的。主题是一个抽象概念，简单地说就是与业务相关的数据的类别，每一个主题基本对应一个宏观的分析领域。数据仓库可以辅助人们分析数据，例如一个公司要分析销售数据，就可以建立一个用于销售的数据仓库，使用这个数据仓库，就可以回答类似“去年谁是我们这款产品的最佳用户”这样的问题。这个场景下的销售，就是一个数据主题，而这种通过划分主题定义数据仓库的能力，使得数据仓库是面向主题的。主题域是对某个主题进行分析后确定的主题的边界，如客户、销售、产品。

2. 集成

集成的概念与面向主题是密切相关的。还是用销售的例子，假设公司有多条产品线和多种产品销售渠道，而每个产品线都有独立的销售数据库。此时要想从公司层面整体分析销售数据，必须先将多个分散的数据源统一成一致的、无歧义的数据格式，再放置到数据仓库中。因此数据仓库必须能够解决诸如产品命名冲突、计量单位不一致等问题。当完成了这些数据整合工作后，该数据仓库就可称为是集成的。

3. 随时间变化

为了发现业务变化的趋势、存在的问题、新的机会，需要分析大量的历史数据，这与联机事务处理（On-Line Transaction Processing，OLTP）系统形成鲜明的对比。联机事务处理反应的是当前时间点的数据情况，要求高性能、高并发和极短的响应时间，出于这样的需求考虑，联机事务处理系统中一般将数据依照活跃程度分级，把历史数据迁移到归档数据库中。而数据仓库关注的是数据随时间变化的情况，并且能反映在过去某个时间点的数据是怎样的。换句话说，数据仓库中的数据是反映了某一历史时间点的数据快照，这也是术语“随时间变化”的含义。当然，任何一个存储结构都不可能无限扩展，数据也不可能只入不出地永久停留在数据仓库中，它在数据仓库中也有自己的生命周期。到了一定时候，数据会从数据仓库中移除。移除的方式可能是将细节数据汇总后删除、将旧数据转储到大容量介质后再删除或者直接物理删除等。

4. 非易失

非易失指的是一旦进入数据仓库中，数据就不应该再有改变。操作型环境中的数据一般都会频繁更新，而在数据仓库环境中一般不进行数据更新。当改变的操作型数据进入数据仓库时会产生新的记录，这样就保留了数据变化的历史轨迹。也就是说，数据仓库中的数据基本是静态的。这是一个不难理解的逻辑概念，数据仓库就是要根据曾经发生的事件进行分析，如果数据是可修改的，历史分析就没有意义了。

除了以上4个特性，数据仓库还有一个非常重要的概念就是粒度。粒度问题遍布数据仓库结构的各个部分。粒度是指数据的细节或汇总程度，细节程度越高，粒度级别越低。例如，单个事务是低粒度级别，全部一个月事务的汇总就是高粒度级别。

数据粒度一直是设计数据仓库需要重点思考的问题。在早期的操作型系统中，当细节数据被更新时，总是将其存放在最低粒度级别上。而在数据仓库环境中，通常都不这样做。例如，如果数据被装载进数据仓库的频率是每天一次，那么一天之内的数据更新将被忽略。粒度之所以是设计数据仓库环境的关键问题，是因为它极大地影响了数据仓库的数据量和可以查询的类型。粒度级别越低，数据量越大，查询的细节程度越高，可查询的范围越广泛，反之亦然。

以上4个特性再综合数据粒度的考虑，数据仓库的存储和计算能力就逐步成为了数据仓库的瓶颈。由于传统的数据库设计大部分都是综合OLTP和OLAP（On-Line Analytical Processing）来考虑的，主流的数据库只有Teradata专注于数据仓库的设计，其他数据库（比较常用于数据仓库的有Oracle、DB2、SQL SERVER等）都是综合性数据库，且以满足OLTP需求为优先考虑方向。大数据技术的兴起，正是为了解决这一窘境。

大数据平台

虽然数据仓库技术自诞生之日起的二十多年里一直被用来处理大数据，但“大数据”这个名词却是近年来随着以Hadoop为代表的一系列分布式计算框架的产生发展才流行起来的。

所谓大数据是这样一个数据集合，它的数据量和复杂度是传统的数据处理应用无法应对的。大数据带来的挑战包括数据分析、数据捕获、数据治理、搜索、共享、存储、传输、可视化、查询、更新和信息安全等。“大数据”很少指一个特定大小的数据集，它通常指的是对大规模的数据应用预测分析、用户行为分析或其他数据分析方法，从数据中提炼出有用的信息，使数据产生价值，因此大数据更像是一套处理数据的方法和解决方案。如果非要给出一个定量的标准，大数据的数据量至少是TB级别的，在当前这个信息爆炸的时代，PB级别的数据量已经较为常见了。用于分析的数据量越大，分析得到的结果就越精确，基于分析结果做出的决策也就越有说服力，而更好的决策能够降低成本、规避风险、提高业务运营的效率。

大数据所包含的数据集合的大小通常超越了普通软件工具的处理能力，换句话说，普通软件没办法在一个可以容忍的时间范围内完成大数据的捕获和处理。大数据的数据量一直在飞速增长，2012年的时候，一般要处理的数据集合还只是TB级，而现在PB级甚至更大量级的数据已不新鲜。要管理如此庞大的数据，需要一系列新的技术和方法，它们必须具有新的数据整合形式，从各种各样大量的复杂数据中洞察有价值的信息。

正是在这样的背景之下，以Hadoop为核心的一系列开源技术应运而生。Hadoop最早起源于Doug Cutting等人设计的Nutch项目。Nutch的设计目标是构建一个大型的全网搜索引擎，包括网页抓取、索引、查询等功能，随着抓取网页数量的增加，遇到了严重的可扩展性问题——如何解决数十亿网页的存储和索引问题。2003年～2004年，Google公布了部分GFS和MapReduce思想的细节，受此启发的Doug Cutting等人用两年的业余时间基于Java实现了DFS和MapReduce机制，使Nutch性能飙升。随后Yahoo收购了Doug Gutting及其项目。2005年，Hadoop作为Lucene的子项目Nutch的一部分正式引入Apache基金会。2006年2月被分离出来，成为一套完整且独立的软件，起名为Hadoop。从此Hadoop进入快车道，Hadoop生态快速发展，衍生出一系列开源组件。

2008年1月，Hadoop成为Apache顶级项目。

2010年5月，HBase脱离Hadoop项目，成为Apache顶级项目。

2010年5月，Mahout脱离Hadoop项目，成为Apache顶级项目。

2010年9月，Facebook开源的Hive脱离Hadoop，成为Apache顶级项目。

2010年9月，Pig脱离Hadoop，成为Apache顶级项目。

2010年底，Linkedin将Kafka贡献给了Apache基金会并成为顶级项目。

2011年1月，ZooKeeper 脱离Hadoop，成为Apache顶级项目。

2011年底，Cloudera 将Flume 贡献给Apache基金会并升级为顶级项目。

2013年，Facebook在Hive的基础上开发的即时查询组件Presto 开源并成为Apache基金会顶级项目。

2014年2月，Spark项目成为Apache基金会顶级项目。

2014年9月，Twitter开源的Storm正式毕业，升级为Apache基金会顶级项目。

 2015 年1月，Flink 正式升级成为Apache基金会顶级项目。

2015年11月，一款由中国人主导的开源MOLAP Cube框架Kylin横空出世，加入Apache基金会顶级项目群。

2016年5月，Zeppelin作为一个支持交互式数据分析的基于Web的网络编辑器，升级为Apache顶级项目。

2016年7月，Cloudera主导开发的数据存储系统Kudu升级为Apache顶级项目。

2017年1月，Google 贡献给Apache 基金会的Beam正式毕业成为顶级项目。

2017年11月，Cloudera开发的基于MPP框架SQL引擎Impala晋升为Apache基金会顶级项目。

2018年8月，中国人主导开发的Apache HAWQ成为Apache顶级项目。

 

随着Hadoop生态系统的不断扩容，各种大数据计算技术如雨后春笋般涌现，开源框架越来越多，海量数据的处理能力和计算速度也在节节攀升。但是总体来说，大数据的框架都在往SQL方向聚焦，朝着使用越来越便捷的方向发展。从早期的NoSQL，到后来的Not Only SQL，现在发展为New SQL的趋势。从早期抛弃SQL，到现在SQL的全面回归。

早期，Hadoop刚诞生的时代，主要是为了处理和存储海量的网页数据、日志数据等传统关系型数据库无法处理的数据结果，于是以MapReduce、HBase、Redis、MongoDB等数据存储系统纷纷涌现，这种定位于存储和分析非结构化数据的工具具有传统数据库无法比拟的处理效率，于是人们纷纷以为数据库将进入一个新的时代。随着NoSQL数据库的普及，人们认识到了NoSQL数据处理的烦琐和高门槛，以Hive和SparkSQL为代表的大数据组件重新加入对SQL的支持，于是人们将“NoSQL”解释为“No noly SQL”。随着数据分析和数据应用的深入发展，业务对数据的时效性提出了更高的要求，以Flink为代表的实时框架重回SQL的怀抱。SQL成为新一代大数据组件的标配，从而诞生了NewSQL的概念。

NewSQL 是一种新方式关系型数据库，意在整合RDBMS所提供的ACID事务特性（即原子性、一致性、隔离性和可持久性），以及NoSQL提供的横向可扩展性。NewSQL系统的提出，满足了整合NoSQL和RDBMS特性的需求。其中，NoSQL提供了可扩展性和高可用性，传统RDBMS提供了关系模型、ACID事务支持和 SQL。用户已不再考虑一招解决所有问题（one-size-fits-all）的方案，逐渐转向针对OLTP等不同工作负载给出特定数据库。大多数NewSQL数据库做了全新的设计，或是主要聚焦于OLTP，或是采用了OLTP/OLAP的混合架构载的全新设计。

 

数据中台兴起

中台概念起源于芬兰的小公司Supercell，这家公司仅有不到200名员工，却推出了一系列爆款游戏，年利润高达15亿美元，这家规模很小的公司，设置了一个强大的中台，用以支持众多小团队进行游戏研发。这样一来，各个团队就可以专心创新，不用担心基础又至关重要的技术支撑问题。

2015年，马云带领了阿里巴巴众多高管拜访了Supercell，让他们惊叹的是，年利润15亿美元的Supercell竟然只有不到200人，他们分散作战，每个团队只需要不超过7名员工。团队可以自行决定开发什么产品，并以最快的速度推出公测版。如果用户不欢迎，则迅速放弃，寻找新的方向。

这一点让阿里巴巴集团感受到了中台的强大，也因此受到了启发。接着，阿里巴巴提出了“大中台、小前台”的战略，将组织架构进行了全面的调整，他们将支持类似的业务工作放在中台，让中台担当支撑的工作，让小前台离一线更近，贴切客户，使得业务更新更加快速。从此，中台的概念在中国开始兴起。

接下来的两年里，阿里对数据中台的探索有了一些成果，并逐渐趋于稳定，他们开始对外推广数据中台机制。参与过阿里中台建设的团队也开始寻找一些新的机遇，2017年以来，随着一些企业数据中台成功案例的发布，国内很多企业开始花大力气探索和建设数据中台，研究建设数据中台的价值所在，以及如何建设数据中台，为企业数字化转型赋能。

那么，什么是数据中台呢？

总的来说，数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台把数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务。

原阿里巴巴资深大数据专家，数澜科技联合创始人付登坡认为：“数据中台是一套可持续‘让企业的数据用起来’的机制，是一种战略选择和组织形式，是依据企业特有的业务模式和组织架构，通过有形的产品和实施方法论支撑，构建的一套持续不断把数据变成资产并服务于业务的机制。”这是站在企业战略层面对数据中台的理解。阿里巴巴数据中台全景图如图1-1所示。

图1-1 阿里巴巴数据中台全景图

从数据中台的进化过程来说，它是数据仓库的下一代产物，也是业务和技术发展成熟的必然要求。一方面，建设数据仓库，解决了企业历史数据的存储问题，但是随着企业的发展和数据的急速膨胀，数据仓库变得臃肿低效，缺乏灵活性。另一方面，大数据技术的发展大大提升了数据处理能力，让高效、敏捷的数据开发变得可能，让数据服务成为可能。同时，随着AI技术的发展和人们理念的升级，传统的BI已经不能满足数据分析的需求，我们需要把数据仓库存储的大量数据盘活、让数据发挥效能，产生价值。

我们可以简单地认为数据中台是由AI驱动，在数据仓库的基础上运用大数据技术实现的敏捷数据服务平台。

 与数据仓库相比，数据中台主要有以下变化。

1.敏捷化

传统的数据仓库倾向于大而全，因此实施成本高、周期长，同时因为架构复杂、层级较多，所以对新业务的适应能力弱。笔者曾长期在银行业从事管理会计数据集市的建设，经历和见证了诸多数据仓库的问题。银行业是数据仓库应用较早，也是最普遍的行业。银行业基于监管要求和业务特殊性，比其他行业更早的认识到了数据的重要性。一般的银行数据仓库的建设周期都在一年以上，数据模型在3到6层，整个批处理链条很长，通常在4到6个小时。一方面，由于数据仓库的数据覆盖面全，导致新上线系统的数据接入变得复杂；另一方面，数据模型层级的增加，也给数据仓库接口的改造造成困扰，因此通常一个数据仓库在其上线之初是最稳定、最合理的架构。后期随着业务的变迁和需求的不断增多，系统变得杂乱无章。

也正是看到了数据仓库的笨重，数据中台开始走向敏捷化。一般的数据中台包括3～4层，且更加聚焦业务应用场景，而不再是大而全的仓库。

2.标准化

建立数据中台的目标是融合整个企业的全部数据，打通数据之间的隔阂，消除数据标准和口径不一致的问题。数据中台通常会对来自多方面的的基础数据进行清洗，按照主题域概念建立多个以事务为主的主题域，比如用户主题域、商品主题域、渠道主题域、门店主题域等。数据中台遵循三个One的原则：One Data、One ID、One Service，即数据中台不仅仅是汇聚企业各种数据，而且让这些数据遵循相同的标准和口径，对事物的标识能统一或者相互关联，并且提供统一的数据服务接口。而传统的数仓主要用来做BI的报表，功能很单一，只抽取和清洗该相关分析报表用到基础数据。要新增一张报表，就要从底层到上层再完整执行一次全套流程。

3.平台化

在数据中台的建设过程中，更加注重平台能力。在数据接入方面，数据接口会更加标准化、配置化，简化数据接入的门槛，提升数据接入的效率。在数据管理方面，更加注重集成平台的建设，包括数据治理、调度管理、元数据管理、数据服务等功能的实现。在数据应用方面，建立在数据中台上的数据应用不仅面向BI报表，更多面向营销推荐、用户画像、AI决策分析、风险评估等，而且这些应用的特点是需求变化快，因此开发必须平台化，便于快速迭代。数据中台能力架构如图1-2所示。

 

图1-2 数据中台能力架构图

 

4.数据来源多样化

数据中台的数据来源期望是全域数据包括业务数据库、日志数据、埋点数据、爬虫数据、外部数据等。数据可以是结构化数据或者非结构化数据，而传统数仓的数据来源主要是业务数据库，数据格式也是以结构化数据为主。

业务对数据实时性的要求越来越高，数据来源也逐步由隔日批量抽取向实时流式计算迈进。实时同步技术把数据的批处理变成了流水线作业，每发生一条业务（或者在一定时间范围内触发）进行一次批处理。实时数据一般由Flink引擎完成数据计算，批处理一般有Hive on Spark完成数据计算。图1-3所示是基于Lambda架构的数据中台架构图。

 

 

图1-3 Lambda架构的数据中台架构图

数据中台应用展望

数据中台的应用场景很多，其中，最成熟的模块有固定报表查询、可视化大屏、移动BI应用、用户画像等，新兴模块有自助分析、场景化智能应用（例如智能推荐、智能营销、智能排班、智能补货等）。

固定报表查询是历史悠久、也是应用最广泛的数据应用。一般由业务人员定义报表的筛选条件、指标展示样式，由技术人员开发实现。固定报表的优点在于，可以随意切换查询条件（必须是事先定义好的），数据按照固定的样式展现，方便进行钻取和切片分析。

固定报表查询一般直接采购商业BI软件来实现，支持固定报表查询是商业BI软件的基本功能。BI软件也分为传统BI和敏捷BI。在传统BI时代，主要是Oracle BIEE、IBM Cognos、SAP BO三分天下，占领了国内外各大数字应用领先企业的市场。随着Tableau倡导的敏捷BI横空出世，传统BI软件日渐式微，以帆软为代表的国产BI软件也趁势崛起。传统BI时代典型的固定查询报表样式如图1-4所示。

 

图1-4 BIEE固定查询报表样式

可视化大屏、移动BI应用和用户画像都是固定报表查询的延伸。很多人认识可视化大屏，是从新闻联播开始的。早期的大屏主要出现在一些大型政府机关、航天企业。伴随着阿里“双十一”盛典和云栖大会的推广，这种蓝色背景、界面简洁、富有科技感的数据展现形式逐渐走入普通企业。

现在各大企业对可视化大屏的需求非常旺盛，可视化大屏直接固定筛选维度，用最直观的方式展现公司最核心的业务指标。相对于固定报表，可视化大屏主要有以下优点。

1）大面积、炫酷动效、丰富色彩，大屏在观感上给人留下震撼的印象，便于营造某些独特氛围、打造仪式感。

2）用可视化大屏展现数据简单明了，展示的都是管理层和大家公认的核心业务指标。

3）可视化大屏一般需要配合实时数据，实现动态刷新的效果。

 

早期的可视化大屏大多都是通过Web应用封装百度开源组件E-Charts来实现的。随着BI工具的迭代升级和产品功能的丰富，越来越多的可视化大屏通过BI应用来开发，大大提高了可视化大屏的开发效率，降低了运维难度和应用门槛。图1-5是某制造企业生产车间运行看板。

图1-5 生产车间运行看板

移动BI应用的诞生比可视化大屏更早，但是推广应用力度不及可视化大屏。主要是因为大部分数据分析师还是需要到固定的工作场所办公，笔记本或者台式机必不可少，所以移动BI只能是锦上添花。移动BI主要定位于管理层查看数据，因此要求指标相对简单，数据时效性要求也较高。

移动BI最早作为BI软件的附属功能，主要供平板电脑使用。随着智能手机的普及和移动互联网的成熟，手机成为移动BI的主要查看工具。移动BI的开发主要还是依赖于BI软件来实现，但是也不乏追求美观的公司采用Hybrid App或者H5进行开发。图1-6是某地产公司的移动BI应用设计截图。

 

图1-6 某地产移动BI应用设计图

 

用户画像是以个体为中心，设计不同的标签对客户进行多维度刻画和全方位描述。俗话说，“物以类聚，人以群分”，用户画像就是为了将用户群体进行分类，来实现精准营销的重要手段。用户画像的基础是标签体系，通过数据中台生产出标签数据，然后通过用户画像进行展现和应用。用户画像既可以是对单个对象的全面刻画，也可以是对一群人的标签统计分析。

在BI的体系中，除了以上成熟的应用之外，自助分析也是正在快速成长的数据应用方向。传统的BI认为，业务人员只需要了解业务的逻辑即可，在一个复杂底层逻辑的基础上，业务人员无法很好地完成报表自定义，因此在这方面功能比较欠缺。然而，利用敏捷BI工具，即时没有任何SQL基础，也能很容易上手，轻轻松松画出漂亮的报表，大大降低了BI的使用门槛。图1-7是Tableau自助分析页面。

图1-7 Tableau自助分析页面

敏捷BI是对传统BI的一次革新。和传统BI相比，敏捷BI主要有以下显著优点。

1）成本更低。传统的BI工具授权费用高，后期运维费用更是大部分企业无法负担的。同时支持的数据库又非常有限，导致必须使用Oracle、DB2、SQL Server等商业授权数据库，进一步提高了项目成本。

2）兼容性强，支持多种数据源。一般的敏捷BI工具都支持连接多种通用数据源，如关系型数据库（MySQL、Oracle、SQL Server等）、文本数据源（Excel、CSV等）、大数据分析引擎 Kylin、Impala、Hive、Presto、Greenplum以及Restful API数据源等。敏捷BI提供直观的可视化界面，简单填写配置参数即可快速连接数据源。 

3）自助式探索式数据分析。自助探索式数据可视化分析，通过主动式的企业数据分析模式，它能够让业务人员直接参与数据分析，无须专业分析团队，业务人员可以直接通过拖曳进行数据可视化分析。自助式探索数据分析已经成为敏捷BI的核心。

4）高级数据可视化。敏捷BI工具一般都提供丰富的可视化图表。以百度Sugar为例，百度Sugar基于E-charts开发，支持70多种图表组件（包括折线、柱图、饼图、拓扑图、地图、3D 散点图等）和10余种过滤组件（单选、多选、日期、输入框、复杂逻辑等），还有非常炫酷的3D地图效果。

5）多终端自适应展现。通过敏捷BI制作的数据分析报告，制作一次就可以在桌面、手机、大屏等多终端上自适应展现，不用针对多个终端进行单独设置。

总之，敏捷BI投入成本更低、更加平民化、更加易于操作，可以让更多的企业客户以较低的投入享受到最专业的数据分析服务。帮助企业用户快速准确地洞悉数据背后隐藏的商业价值，让企业决策更加“有据可依”。

除了上述应用以外，数据中台还有一个最重要的应用方向就是智能场景应用。智能场景应用也就是我们常说的AI。数据智能应用就是基于大数据引擎，通过大规模机器学习和深度学习等技术，对海量数据进行处理、分析和挖掘，提取数据中所包含的有价值的信息和知识，使数据具有“智能”，并通过建立模型寻求现有问题的解决方案或者实现对未来业务的预测。引用董超华《数据中台实战》一书中的一个重要论点——搭建数据中台的最终目标就是帮助企业实现数据智能。数据智能就是指智能应用场景。

智能应用场景=AI算法+数据+业务，三者相辅相成，缺一不可。AI算法提供智能工具，数据中台生产算法需要的数据，然后根据业务视角来评估算法的有效性和应用价值，三者结合起来才能构建有效的智能场景应用。

我们以生活中最常见的百度地图导航为例。在没有地图导航功能之前，我们到一个陌生的地方，只能通过路标和向路人问路来找到目的地。有了地理信息数据和道路交通信息以后，我们开始有了初步的导航功能，通过百度地图来规划线路，这样我们就可以通过手机来寻找目的地。在更多人都开始使用手机导航以后，百度地图可以记录用户的线路、道路的交通情况，综合这些提供更加完善的导航服务。用户借助百度地图导航是在产生数据，同时百度地图综合用户的数据分析出道路状况以后给用户规划新的、更快的线路，则是通过数据智能来实现出行预测，让数据产生了智能，反哺用户。

智能应用的标志就是由机器代替人工决策。在上文的导航案例中，道路的规划没有人工参与，用户数据的汇总也是由机器自动完成，整个导航形成一个数据智能应用的闭环，这就是真正的数据智能应用。

当然，目前能完成数据智能应用闭环的业务场景还很少。在大多数情况下，我们还在寻找和探索数据智能的应用方向，这需要进行大量的试错和验证工作。为了简化数据智能应用的探索过程，很多企业在研发专门的AI平台，以降低AI应用的门槛，促进更多的数据智能应用诞生。AI平台既可以是数据中台功能的延伸，也可以是独立的应用平台。数据智能应用是数据中台未来需要重点开拓的方向。