火热的数据中台，是否终究一地鸡毛（201024）

在前面我写过关于数据中台，以及数据中台和大数据平台，业务中台区别的一些文章。今天准备再谈下对当下火热的数据中台建设的一些看法。

要把这个问题谈清楚，我准备还是从企业最早的决策支持分析和BI系统入手，再谈BI系统到大数据平台的演进，最后再来谈数据中台建设。通过这个发展演进路线的分析可以方便我们更好的来观察数据中台建设是否真正存在相关的价值和意义。

一个传统的BI技术架构

上图是我们经常会看到的一个BI系统技术架构。其中分为了数据整合层，数据服务层，应用分析层，信息展现层和数据管理层。

数据整合层简单来说核心就是我们常说的ETL，数据采集集成，数据清洗和转换；对于数据服务层重点是将标准数据按照主题进行组织，构建业务应用分析模型。数据服务层中涉及本身又涉及到几个关键的概念，其本身也是按数据抽象程度进行划分。

• ODS库：基本就是采集过来的清洗后的贴源数据库层
• 数据集市：可以理解为面向一个业务域的数据整合和建模
• 数据仓库：面向整个企业的跨域数据建模，更加强调维度和抽象性

而到了应用分析层，则是按照企业各个业务部门的分析需求形成不同粒度的分析数据，然后再通过前端展现层，各种展现报表，驾驶舱，仪表盘等进行信息展现。

当然整个底层是数据管理层，即我们常说的元数据管理，安全管理，数据质量管理等基本的数据管控治理操作，覆盖数据应用的全生命周期。

传统企业为何需要BI系统？

对于企业为何需要BI系统，我还得回到企业IT系统垂直烟囱式的建设模式上面来，并不是说这种模式不好，对于这样分业务域进行的系统建设反而是一种企业分而治之解决问题的方式。

但是由于系统拆分建设，自然带来了系统之间集成和交互的问题，这个也是我前面文章经常谈到的传统企业SOA集成平台出现的背景。对于SOA或ESB总线虽然解决了系统间的数据或业务集成的问题，但是还有一个关键问题没有解决，即：

跨业务域或整个企业层面的业务数据分析和决策。这个事情显然不可能在一个业务系统里面完成，因为需要跨多个业务系统的数据整合才能够进行分析，因此我们就必须考虑采集和整合各个业务系统中的共享数据，形成一个完整的数据中心，然后再对数据进行建模和分析，最终满足我们的数据分析目标。

BI系统建设仍然是企业战略目标和业务目标驱动

在企业进行战略或业务目标规划的时候，我们经常会谈到CSF关键成功要素和平衡记分卡。对于CSF源自于公司战略和核心竞争力，而CSF通过分解对应一套KPI指标体系，同时一个KPI指标可以属于多个 CSF。

因此可以看到一个企业的战略或业务目标，往往可以分解到最下层的业务功能和操作指标，而这些指标往往依赖在我们企业经营的日常关键业务流程中。简单来说我们只要对这些关键指标进行监控和管理，那么我们就可以更好的评估和预测最终的企业战略目标能否达成。

显然这些KPI指标不可能完全通过人工去处理和收集，企业在IT信息化建设到一定程度后你可以看到这些指标中的大部分已经可以通过系统进行自动采集和处理，并基于指标体系建设和维度建模自动进行聚合和关联分析。

因此，企业到了一定程度就需要一套系统来支撑对上述指标的日常监控和分析操作，这些指标分析显然是跨当前业务系统的，需要整合到一个地方进行，即我们常说的BI类分析系统。通过BI系统的关键指标呈现和分析，我们可以更好的来监控，来预测企业经营指标的实现情况和趋势。

我们经常谈业务驱动IT，对于BI系统建设也是一样，如果没有前期的企业战略规划设计，企业的业务流程重组和优化设计，CSF和BSC等工作的推进，往往BI系统就无法落地。

大数据平台建设

对于大数据平台建设出来了很多年，基本常用思路仍然是基于开源Hadoop框架进行定制企业自己的大数据开发和服务能力平台。如果用一个词来总结大数据平台这几年的发展情况，简单来讲就是不不温不火。

大数据平台当前应用的最多的地方仍然是在类似智慧城市大项目建设，集团类而且偏运营服务类行业中，类似电信行业和金融行业。而在传统制造行业等大数据平台建设只能说很一般，包括大点的大数据平台建设项目都少。即使是对于传统的制造企业，往往开始启动大数据平台建设项目，往往也是前几年的从传统信息化到消费互联网的转型，到自建垂直一体化电商平台的时候，伴随进行大数据平台的建设。

简单总结就是，大数据平台对大部分企业来说都是杀鸡用牛刀，即企业所面临的数据容量，类型复杂度，处理性能要求等都远远不需要采用大数据平台来解决。

采用大数据平台就意味着更高的人力和产品成本投入，往往投入产出性价比极低。

对于大数据技术平台，我原来给出过一个技术架构可参考：

如果从整体分层来说可以包括数据源层，数据整合层和应用分析层，数据管控治理层几大部分。从核心功能来说又包括了数据采集集成，数据存储，数据处理，数据分析，数据能力开放等几个关键的能力。即使你看现在的数据中台架构，你会看到其核心技术平台能力实际上和大数据平台基本是一致的。

大数据平台本身偏技术平台概念

对于大数据平台这个词，本身偏技术平台的概念，即常说的围绕Hadoop开源生态体系构建的一个覆盖数据采集，集成，存储，处理和分析的技术平台。通过这个技术平台来解决我们日常遇到的数据存储，数据分析方面的问题。

但是即使这样大数据平台里面涉及到的技术点仍然相当多，基于Hadoop平台也还需要我们做大量的定制开发，其它开源工具的整合和集成操作。

比如数据采集和集成来说，对于日志类可能会采用Flume来实现，对于网页抓取你得采用开源爬虫工具软件，对于结构化数据集成仍然采用ETL工具，而对于结构化和非结构化之间的集成可以采用类似Sqoop工具来实现。而这些都必须进行整合和定制。

对于数据分析也是同样的道理，从最早经常说的Hive数据分析，到Impala和Spark，本身也需要基于你处理的数据规模，时效性要求等各方面去评估具体采用哪个。比如对于Hive由于基于传统的MapReduce，如果遇到海量数据处理有优势，但是如果对于即席交互式查询就比类似Spark这种内存处理慢很多。而对于类似传统海量结构化数据的处理，往往采用类似MPP架构的Impala往往能够得到更好的效果。

从传统BI到大数据平台

对于传统企业内部，更多的应该是使用了大数据技术的传统BI平台，或者是融合了传统BI+大数据的混合平台，而不能单纯说是大数据平台。因此在谈大数据平台的时候，一味去否定传统BI是不合适的。

在没有和互联网打通的传统企业内部，更多接触的仍然是结构化数据，优先要解决的是围绕企业核心价值链的数据建模和企业战略，各业务域KPI体系的建立，决策支持和分析这些内容。在整个数据建模和分析过程中，还要考虑去解决数据不一致性，重复等问题，建立数据管控和治理体系。

传统BI平台在发展过程中会遇到问题和瓶颈，使用传统的技术架构无法解决，需要我们在传统BI技术架构的构建中引入大数据相关技术和工具，从这意义上更多应该叫使用了大数据技术的传统BI平台。

使用了大数据技术的传统BI平台

在数据存储和查询效率层面，传统BI遇到瓶颈，可以看到在大量的上千万即上亿数据量的结构化数据表中，要进行查询统计分析输出KPI指标性能下降非常明显。为了解决查询效率问题，有两个思路，一个是引入了MPP数据库来解决，一个则是引入Hadoop平台进行存储，虽然是结构化数据但是仍然引入Hadoop平台，重点是解决分布式存储和查询性能问题。

其次，虽然传统企业以结构化数据为主，但是仍然出现对大数据量的非结构化数据的采集和处理，这个时候我们可能引入了Hadoop平台，将数据采集，清理存储后最终还是再导入我们的结构化数据仓库。可以看到在这个过程中大数据技术解决了对非结构化数据的处理和整合问题。

融合传统BI能力的大数据平台

对于原来没有规划建设BI系统的企业，在构建BI系统的时候更多考虑的就是直接构建大数据平台同时完全融合传统BI应该具备的能力。即既保留了传统BI，又实现了远期对大数据平台和应用的扩展能力。

数据采集层-》数据存储层-》数据处理层-》数据整合层-》数据分析层-》数据展现层

• 数据采集：在传统ETL基础上增加了对HDFS，非结构化数据，流数据，互联网数据的支持
• 数据存储：增加了HDFS，HBASE等数据存储方式
• 数据处理：传统BI在ETL过程中可以完成清洗，大数据平台是存采集不处理
• 数据整合：整合了结构化+非结构化数据，提供统一数据开放接口
• 数据分析：HIVE+Impala+Spark，大批量和即席交互查询能力并存
• 数据展现：传统的BI报表功能仍然适用，也可以引入大数据可视化技术

可以看到要融合传统BI能力，则数据整合层需要能够整合结构化数据和非结构化数据，同时提供统一的大数据开放能力服务接口。尽量让前端报表通过大数据服务接口获取数据以隔离底层大数据平台的数据源。即数据展现层和数据整合层通过服务层进行解耦和隔离。

如果企业已有传统BI平台，那么底层的BI平台可以共存，即可以将底层BI平台的ODS库或EDW数据导入到大数据平台进行存储和整合。大数据平台存储一定是混合存储模式，即有些通过Hadoop平台处理后的中间结果数据我们仍然导入到结构化数据库进行存储，遵从传统BI数据建模技术构建星型模型，方便后续对数据进行维度分析和上钻下钻。对于self service BI，我们仍然开放Hadoop平台原始数据接口能力。

一开始就构建大数据目标平台

如果企业在构建平台的时候，一开始目标就很明确是大数据类分析和应用，如采集海量的互联网数据进行某行业的客户行为分析，用户画像，同时结合企业内部经营数据进行针对性营销的辅助决策。那么一开始构建就会以Hadoop平台为主，同时兼容能够采集企业已有的结构化数据。

这类平台在构建过程中可以看到不会是传统BI数据建模和分析那套方法，而更多是新的大数据分析和挖掘技术，则完全可能是以Impala+Hive+Hdfs为主线，以Tableau，Qlic View为前端展现，通过R语言或KNIME进行数据挖掘和分析等。即脱离传统BI，大数据整套框架仍然是完整的。但是弱化了传统BI中的数据建模，数据质量管理，数据治理等方面的能力。

对数据中台的基础理解

实际上我们看到阿里最早提出的中台战略的时候，实际上并没有分业务中台和数据中台，在前期的中台概念更多的是偏指业务中台，而后期对中台概念进行了拆分，形成了业务中台和数据中台双中台的概念。我们先看下数据中台定义。

数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台把数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务。这些服务跟企业的业务有较强关联性，是这个企业独有且能复用的。

如果单独看这个定义，那么数据中台很容易被理解为企业里面的BI系统建设，包括了ODS库和数据仓库，同时支持OLTP和OLAP能力。也可以说是构建企业的大数据平台。

而今天想谈下对数据中台这个概念的一些理解。

首先我们要看到数据中台是整个企业中台战略的一部分，是配合企业微服务架构转型和业务中台能力构建不可缺少的部分。如果没有整个中台战略，那么就不存在数据中台，你单独去建设大数据平台或BI平台就可以了。

数据中台不是一个单纯的数据技术平台，而是一个共享数据能力提供平台。对于数据的采集，清洗，存储和加工最终都是为了开放数据服务能力。

如果说业务中台更多的是业务能力的开发，那么数据中台就是聚合后的数据服务能力的开放。

为何要开放数据服务能力？

这个绝对不是简单的给上层做BI来分析用的，而是这种数据服务能力需要去支撑前台业务场景和业务功能的实现，即我们常说的 数据反哺业务 。即这种数据服务能力需要具备一定的数据实时性要求，那么我们可能看到对于业务中台本身也会提供数据服务能力，比如订单中心也提供订单查询数据服务能力，那么两者的区别究竟在哪里？初步分析包括：

• 业务中台数据服务实时性最强，数据中台数据服务准实时
• 业务中台数据服务单一数据对象，而数据中台数据服务提供跨域数据对象整合
• 业务中台无法支撑上层分析决策类应用，而数据中台能力可以

这点理解清楚后，我们再回来就容易搞清楚为何数据中台需要提供准实时的数据服务API接口，要看到在微服务架构下构建的业务中台各个中心，按照标准的微服务架构要求，各个中心对应的数据库本身也完全是独立和拆分的，订单中心是订单数据库，用户中心是用户数据库，相互之间完全垂直独立以方便应用的灵活扩展。但是这种数据库拆分带来最大的问题就是？

当业务场景需要底层多个业务数据对象提供关联后聚合后的查询数据集的时候极不方便。为了解决这个问题，实际上我们有两种做法来进行处理。

第一种：构建一个领域服务层组件

即我们单独构建一个领域服务层组件或微服务模块，来提供整合后的领域服务能力，这个组件如果需要提供一个关联多个业务对象的数据集合，那么就需要调用多个API接口返回多个独立数据集合，然后在组件业务逻辑实现中来完成多个数据集的整合工作。

虽然对于查询类服务没有分布式事务问题，但是这种方式在性能上肯定存在较大损耗，优势则在这种方式不用前台访问多次API接口服务，同时又保证了数据的实时性。

第二种：构建数据中台，然后提供开放数据服务能力接口

这种方式就是构建数据中台，在数据中台完成业务中台多个数据库数据的数据采集和整合，形成一个完整的跨越的数据模型，由于有了完整的数据，因此很自然能够提供关联聚合数据对象服务的能力。

但是这种方式的问题也比较明显，就是如何保证数据本身的实时性和一致性，完全的实时往往很难保证，那么如何保证数据的准实时性，如何保证数据采集过程中出现问题而导致数据不一致也需要考虑。

把整个想清楚了，也就是想清楚了数据中台的一个关键作用，就是提供准实时的聚合数据服务能力API接口并进行开放给前台使用，方便前台业务场景和功能的实现，而不是简单的提供一个供分析决策的数据库。因此对于数据中台的这个关键能力我们可以简单的理解为：

分布式ODS库+能力开放平台+准实时数据能力提供

这个就是我们前面谈到的数据中台的一个关键能力提供，那么我们谈到数据采集集成技术，分布式数据存储，实时数据集成，数据流处理，包括类似Hadoop大数据平台等，所有这些都是数据中台在实现过程中为了满足分布式+实时性的技术支撑。

先理解清楚为何需要数据中台，再来搞清楚数据中台构建需要用到什么技术，什么平台，整个对中台战略，中台构建的思考逻辑才会清楚。

数据中台和大数据平台关系

首先我们来谈大数据平台是一个技术平台。这个技术平台提供了对于大数据的分布式采集，存储，流处理和计算，实时分析等能力。在没有大数据平台前也有数据集成和管理的平台，这种平台可以实现对结构化数据本身的采集，集成和管理。

因此我们常说的大数据平台你可以理解为一个纯粹的数据技术能力平台，里面本身是空的。就像我们理解ESB总线一样，本身是一个技术平台，一开始没有接口服务注册在上面，需要你自己不断的接入新的服务，才能够形成服务目录体系。

任何一个数据中台，底层都需要一个提供数据存储和处理能力支撑的技术平台。

这个技术平台如果你有大数据需求，构建出来的就是大数据平台。但是如果你没有大数据需求，那么用传统的数据集成和管理技术平台即可。

其次，数据中台的范畴包括了如下几个方面

• 一套底层的数据技术平台（可以是大数据平台，也可以是数据集成平台）
• 一套数据资产（业务层面的内容，实际数据，数据模型，算法装进来了）
• 一套数据服务能力提供和共享
• 一套数据管控和治理标准规范体系

因此可以看到对于数据中台核心重要的反而是数据资产+数据服务能力共享这两点,而这两点在一般的大数据平台并不会包含。如果整个数据中台建设有大数据平台，那么大数据平台也仅仅是一个底层技术平台和技术实现手段。具体两者的差异点我们再通过图来对比下。

如下是一个常见的数据中台的架构图：

在这个图中可以看到中底座的内容+数据汇聚+数据研发内容是常见的大数据平台都会提供的内容，具体如下红框里面内容。

其次，我刚才在接受如果企业数据量根本没有到要上类似Hadoop等大数据平台的程度，那么基于类似Oracle， Mysql等结构化数据库+ETL等数据集成调度工具同样可以构建数据中台需要的传统数据技术平台。如下：

数据中台-新瓶装旧酒

前面基本分析了从最早的BI系统，到大数据平台，再到现在炒的火热的数据中台。对于数据中台由于打着阿里和互联网，企业数字化转型，消费互联和产业互联的必经之路等各种标签，导致很多企业信息化基础水平都没达到的企业就在搞数字化营销，数据中台等。

因此对于数据中台，即使当前在风口上被大家所推崇，也有不少推数据中台的软件企业和服务商真正站在风口上飞上天，但是对于数据中台我仍然坚持我的看法，即：

对于当前的数据中台并没有对传统的BI系统和大数据平台带来大的业务和技术两方面的变革，属于典型的新瓶装旧酒，对于大部分传统企业IT建设成熟度偏低，当前都不需要规划和建设数据中台，一个是本身成本投入大，一个是短期并不可能带来实质性的价值贡献。

数据中台-新瓶装旧酒

首先对于中台我们在前面就谈到过中台属于一个业务层面的概念，即 共性业务能力的下沉，通过数据业务化为业务类应用进一步赋能。 那么对于数据中台来说就是共性数据能力的下沉并开放，这才是数据中台的核心。

而我们现在谈数据中台的时候，可以看到实际上最多的是谈两个方面的内容，第一就是传统的大数据技术平台的内容，而这个内容本身划分到数据中台里面并不合适。

其二就是谈数据建模方面的内容，而这本身又属于传统的BI系统，大数据里面的标签系统建设等方面的已有内容，并不是数据中台所独有。

即使对于前面谈到的数据能力服务化开放，在我们最早规划的大数据平台整体架构里面就已经谈到过了数据服务能力开放平台，因此数据服务化开放也不是新鲜的东西。

业务中台和数据中台

我们可以简单来说，就是在中台概念出来后，我们在构建业务中台的时候进行了大量的微服务化拆分，包括数据库的拆分，你会发现要实现跨域共享数据的提供更加困难，这是其一；另外就是我们在进行业务运营的时候，发现对融合后数据分析能力的实时性要求更加迫切，特别是对于类似电商，营销或运营类toC端客户的应用，这是其二。

正是在以上两个关键需求下出现了数据中台，解决数据跨域融合问题，解决实时分析类API接口的提供问题。那么我们来看下传统企业信息化是否寻找上面两个问题。

对于跨域数据提供： 对于传统企业信息化，由于本身没有进行微服务化拆分，往往单个业务系统就能够提供微服务跨库的数据服务能力。因此这点需求对于传统企业本身还没有进行微服务架构改造的时候并不突出。

对于实时分析API接口： 对于这点，往往对于传统企业开始面向C端运营类业务的时候往往才比较明显，即需要更加实时的分析辅助API能力，比如我们常说的电商类应用的推荐引擎API能力等。而这个在传统企业同样需求并不突出，很多企业连内部信息化都很薄弱，更难以谈得上马上进入到产业互联或消费互联阶段。

数据中台-共性数据能力下沉

再回到数据中台的本质上面来，即我们谈的数据共性能力下沉，这个是数据中台建设最大的业务价值体现。但是要注意的就是，对于不同的行业，不同的产品形态来说，实际上共性数据能力都存在千差万别。

我们最早在建设BI系统的时候可以看到，对于基本的ETL，BI报表工具等往往并不是重点，真正一个BI系统的价值是垂直细分行业，多个大项目积累形成的可复用指标库或指标模型。

因此，要真正形成普遍适用的共性数据能力模型往往并不现实，即这个共性数据能力并没有我们想象的容易抽象化。那么数据中台本身就变成了如下： 大数据技术平台+个性化数据建模实施项目。 在这种情况下，数据中台本身又回到了传统BI建设模式，难点在实施，而且投入巨大。

包括对于当前大力推数据中台的厂商，我们也看到，虽然有些也提出一些数据中台建设方法论，数据建模方法论，但是这些和传统BI的数据仓库建模来说，仍然显得相当单薄而不成体系。包括连最简单的数据维度建模往往都不系统，这样很难说给企业能够带来一个有价值的数据类分析应用。

太去强调数据分析的实时性，反而忽视了数据模型的完整性，那么自然是本末倒置。

也正是这个原因，对于大部分传统企业来说，基于企业自身的信息化建设程度，IT治理管控水平，该建设BI系统或数据集市的还是老老实实的实施BI系统应用，往往才是投入产出比最佳的方式。要明白一个关键道理，即： 任何IT平台或系统建设没有最先进性，只有最实用性。

盲目的去追求技术和架构的先进性，一个是过去超前反而无法应用，一个是投入巨大。同时当前你看起来时髦的东西，过几年也会变成陈旧的技术。

最后，再次强调对于数据中台建设往往对数据平台的技术架构要求，数据建模要求，数据服务的开放，数据治理和管控等各方面都提出更高的要求，一个企业盲目实施数据中台，不仅仅是无法体现业务价值，更加重要的是实施完成的数据中台自己甲方团队可能根本服务自我承接和运维，那么这个成本投入将变成持久化的不断成本投入，变为手里的烫手山芋。

类似我们看到不少的企业盲目去实施大数据平台，建设完成后应用效果差，治理管控跟不上，同时大数据技术平台无法运维而废弃也是一个道理。

互联网推出的业务中台和数据中台概念，对于互联网电商，营销等应用有价值，并不代表对传统企业就有价值。其中不仅仅包括数据中台，也包括了业务中台和微服务架构改造。包括我在前面也写过企业在自身IT治理和成熟度能力不足够的时候要谨慎对待微服务架构一样。因此企业对待数据中台同样需要从自身业务目标和真实的业务需求出发来考虑和评估。