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

  • 业务中台无法支撑上层分析决策类应用 , 而数据中台能力可以
  • 这点理解清楚后 , 我们再回来就容易搞清楚为何数据中台需要提供准实时的数据服务API接口 , 要看到在微服务架构下构建的业务中台各个中心 , 按照标准的微服务架构要求 , 各个中心对应的数据库本身也完全是独立和拆分的 , 订单中心是订单数据库 , 用户中心是用户数据库 , 相互之间完全垂直独立以方便应用的灵活扩展 。 但是这种数据库拆分带来最大的问题就是?
    当业务场景需要底层多个业务数据对象提供关联后聚合后的查询数据集的时候极不方便 。 为了解决这个问题 , 实际上我们有两种做法来进行处理 。
    第一种:构建一个领域服务层组件
    即我们单独构建一个领域服务层组件或微服务模块 , 来提供整合后的领域服务能力 , 这个组件如果需要提供一个关联多个业务对象的数据集合 , 那么就需要调用多个API接口返回多个独立数据集合 , 然后在组件业务逻辑实现中来完成多个数据集的整合工作 。
    虽然对于查询类服务没有分布式事务问题 , 但是这种方式在性能上肯定存在较大损耗 , 优势则在这种方式不用前台访问多次API接口服务 , 同时又保证了数据的实时性 。
    第二种:构建数据中台 , 然后提供开放数据服务能力接口
    这种方式就是构建数据中台 , 在数据中台完成业务中台多个数据库数据的数据采集和整合 , 形成一个完整的跨越的数据模型 , 由于有了完整的数据 , 因此很自然能够提供关联聚合数据对象服务的能力 。
    但是这种方式的问题也比较明显 , 就是如何保证数据本身的实时性和一致性 , 完全的实时往往很难保证 , 那么如何保证数据的准实时性 , 如何保证数据采集过程中出现问题而导致数据不一致也需要考虑 。
    把整个想清楚了 , 也就是想清楚了数据中台的一个关键作用 , 就是提供准实时的聚合数据服务能力API接口并进行开放给前台使用 , 方便前台业务场景和功能的实现 , 而不是简单的提供一个供分析决策的数据库 。 因此对于数据中台的这个关键能力我们可以简单的理解为:
    分布式ODS库+能力开放平台+准实时数据能力提供
    这个就是我们前面谈到的数据中台的一个关键能力提供 , 那么我们谈到数据采集集成技术 , 分布式数据存储 , 实时数据集成 , 数据流处理 , 包括类似Hadoop大数据平台等 , 所有这些都是数据中台在实现过程中为了满足分布式+实时性的技术支撑 。
    先理解清楚为何需要数据中台 , 再来搞清楚数据中台构建需要用到什么技术 , 什么平台 , 整个对中台战略 , 中台构建的思考逻辑才会清楚 。
    数据中台和大数据平台关系首先我们来谈大数据平台是一个技术平台 。 这个技术平台提供了对于大数据的分布式采集 , 存储 , 流处理和计算 , 实时分析等能力 。 在没有大数据平台前也有数据集成和管理的平台 , 这种平台可以实现对结构化数据本身的采集 , 集成和管理 。
    因此我们常说的大数据平台你可以理解为一个纯粹的数据技术能力平台 , 里面本身是空的 。 就像我们理解ESB总线一样 , 本身是一个技术平台 , 一开始没有接口服务注册在上面 , 需要你自己不断的接入新的服务 , 才能够形成服务目录体系 。
    任何一个数据中台 , 底层都需要一个提供数据存储和处理能力支撑的技术平台 。
    这个技术平台如果你有大数据需求 , 构建出来的就是大数据平台 。 但是如果你没有大数据需求 , 那么用传统的数据集成和管理技术平台即可 。
    其次 , 数据中台的范畴包括了如下几个方面
    • 一套底层的数据技术平台(可以是大数据平台 , 也可以是数据集成平台)
    • 一套数据资产(业务层面的内容 , 实际数据 , 数据模型 , 算法装进来了)
    • 一套数据服务能力提供和共享
    • 一套数据管控和治理标准规范体系
    因此可以看到对于数据中台核心重要的反而是数据资产+数据服务能力共享这两点,而这两点在一般的大数据平台并不会包含 。 如果整个数据中台建设有大数据平台 , 那么大数据平台也仅仅是一个底层技术平台和技术实现手段 。 具体两者的差异点我们再通过图来对比下 。
    如下是一个常见的数据中台的架构图:
    火热的数据中台,是否终究一地鸡毛文章插图
    图片来源数澜科技
    在这个图中可以看到中底座的内容+数据汇聚+数据研发内容是常见的大数据平台都会提供的内容 , 具体如下红框里面内容 。