火热的数据中台,是否终究一地鸡毛( 三 )


数据采集层-》数据存储层-》数据处理层-》数据整合层-》数据分析层-》数据展现层
火热的数据中台,是否终究一地鸡毛文章插图

  • 数据采集:在传统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来分析用的 , 而是这种数据服务能力需要去支撑前台业务场景和业务功能的实现 , 即我们常说的数据反哺业务 。 即这种数据服务能力需要具备一定的数据实时性要求 , 那么我们可能看到对于业务中台本身也会提供数据服务能力 , 比如订单中心也提供订单查询数据服务能力 , 那么两者的区别究竟在哪里?初步分析包括: