大数据平台架构与原型实现-学习记录二【聚焦中台】

一、中台简介

中台战略常被简单概况为“大中台，小前台”，即将企业的核心业务能力沉淀和聚集到由业务中心组成的中台层上，前台应用以中台为支撑，向轻量化、敏捷化转变。在强大中台的有力支撑下，前段在进行业务运营和创新时会变得非常高效且灵活，企业可根据最新的市场动态展开各种尝试和调整，一旦发现并验证了新的市场机遇，就可调集中台的强大能力迅速跟进，抢占市场。

二、企业信息系统现状

烟囱式系统架构（每个应用均独立，从基础设施到UI）仅满足自己对接的业务方向上无误，但从企业全局看，在代表业务流程上的壁垒、重叠的功能建设和复杂的系统集成。烟囱式生态具有特征：

• 应用系统都是独立建设和维护的，拥有各自独立的数据库和前后台；
• 系统与系统之间的交互呈现点对点的网状结构，难以梳理和维护；
• 在引入新系统时，需要与所有关联系统集成，开发、协作与沟通成本非常高；
• 系统之间经常会出现功能上的重叠，重复建设的情况比较普遍。

2.1 点对点式的系统集成

烟囱式生态带来一个问题：点对点式的系统集成，每个系统都需要针对对接的系统提供不同的协议和数据接口，当有新系统要融入这个生态时，要和每一个系统商定对接的协议和格斯，集成成本很高。

2.2 重复建设

烟囱式生态带来另外一个问题：重复建设，出现资源浪费、标准不一、同类型业务数据离散分布，既有冗余，又可能出现数据不一致的情况。一般最容易被反复开发的功能有以下三类：

• 业务上处于上下游关系的两个系统在业务边界上的功能；
• 多种渠道商的同类型业务功能；
• 基础设施或公共服务类的功能。

2.3 阻碍业务沉淀与发展

烟囱式的生态环境所带来的问题在于削弱了企业沉淀业务与再发展的能力。

三、曾经的“救赎”——SOA

（1）SOA体系两大核心

对系统提供的对外交互进行提炼、组织和梳理，通过封装、组合与编排，将接口以“服务”形式发布出去；
系统间的交互统一通过中心化的企业服务总线（EBS）完成
（2）SOA中的“服务”在技术上以Web Service为载体，主要由如下三种粒度的服务：

基础服务：最细粒度的服务，最基本、最原子的服务都会在这一层，从服务数量上看，这一层也是很多的；
复合服务：基于多个基础服务组合叠加而成的粗粒度服务，多用于封装并简化有多个基础服务组合实现的共性服务；
业务流程：通过工作流引擎将多个服务编排起来，形成一个完整的业务流程，这是一种粒度更粗的服务，常用于实现一个标准的、可复用的大尺度业务流程。
（3）SOA依靠EBS实现系统集成，EBS是治理点对点式的系统集成的核心手段，它肩负如下重担：

• 实现系统间的连通；

• 数据转换；

• 智能路由；

• 安全控制：

• 可靠性控制：

• 服务管理；

• 监控与日志。
  （4）SOA针对烟囱架构的治理主要依赖于两个方面：

• 立足于每个应用系统，要求系统对提供的“服务”进行提炼和抽象，确保其灵活、可重用，这是让服务满足外部复杂需求的根本保障；

• 通过中心化的交互媒介–EBS来约束系统间的交互，消除点对点集成的负面影响。

四、中台详解

中台打破了应用系统的壁垒，从企业全局梳理和规划业务流程，重构组织架构、业务架构和IT架构。将企业的核心能力随着业务不断发展以数字化形式沉淀到平台，形成以服务为中心，由业务中台和数据中台构建起数据闭环运转的运营体系，供企业更高效地进行业务探索和创新，实现以数字化资产的形态构建企业核心差异化竞争力。中台将带给企业能力和收益：

• 应对未来所需的更快的业务创新和成本更低的业务探索；
• 给企业带来核心竞争力的提升，提质转型、降本增效；
• 给业务快速响应和创新带来的业务价值；
• 给信息中心带来组织职能转变的机会；
• 共享服务架构能提升企业整体效能。

4.1 中台架构

（1）以中台视角看企业整个IT生态，可将其分为前台、中台、后台三部分

• 前台：由直接面向市场和终端用户的业务应用组成，负责支撑企业的前端业务；
• 中台：由按业务领域细分的服务中心组成，负责支撑企业的共享业务；
• 后台：由企业内部业务系统组成，如生产、库存、物流等管理系统。

前台与中台关系：业务中台负责提供企业范围内共享的基础业务服务，前台应用会对这些基础业服务进行组织编排，快速地在前端以产品形式将业务能力展开，以适应日新月异的市场变化。

中台与后台关系：中台架构是为了让企业拥有开放、创新和灵活的市场应变能力而提出的，这对生产、库存、物流等后端系统影响不大，且这些系统需要严谨和规范的组织管管理，因此会保持相对传统的组织架构与生态。

（2）数据中台与业务中台

数据中台侧重于企业数据的统一收集和处理，从技术讲，数据中台完全构建在大数据平台上，数仓是数据中台重要组成部分，还要具备实时的数据处理能力和高级算法分析能力；数据处理完后，中台还提供强大的“数据服务”，能将结果数据通过各种协议以实时或批量的方式提供给业务中台或应用前台。

业务中台的建立对数据中台的建设起到强大促进作用，一方面由于业务梳理和中心化，使才业务数据变得相对简单，业务中心的后台数据库将是数据中台主要的外围数据源；另一方面，业务中台对业务的切分和领域模型将对构建数据中台上的数仓和数据服务有很大指导意义。
（3）中台逻辑架构
前台应用部分变得非常“轻量”，在中台架构下都是调用会员中心上的统一接口完成；与此同时，各业务中心的数据都将通过数据中台上的数据采集组件采集到大数据平台上，然后通过批处理和实时处理机制构建出企业的数仓体系和高级数据分析能力；最后通过构建数据API（web服务）、OLAP及专有的报表数据库等字段，将结果数据以Restful API、JDBC/ODBC或FTP等形式提供给外部使用。

4.2 中台的技术体系

（1）业务中台技术体系

• 微服务
  微服务架构最大的特征是解构了过去的单体应用，按照业务功能对系统进行更细粒度的切分，每一个微服务都是一个可独立部署的单元，微服务内部高内聚、微服务之间低耦合

  与之配套的一系列基础设施服务和支撑技术包括：服务注册与发现、服务配置管理、服务网关、事件/消息总栈、负载均衡、容错与熔断、监控与报警、安全和访问控制、日志收集与处理。

  在业界形成了“微服务+容器技术（Dockers+Kubernetes）+DevOps”三位一体的微服务生态体系。

• 领域驱动设计（DDD）
  在技术上微服务是实现业务中台的最佳技术方案，再借助领域驱动设计，中台的业务中心可构建得足够灵活和强大。

（2）数据中台技术体系

通常人们会用Hadoop、Spark来指代大数据技术，因为两者不单单是技术，更代表着一个技术生态圈，在它们背后有一组相关的配套工具。

在技术上Hadoop、Spark是实现数据中台的主要技术方案，遵循数据仓库理论对数据进行组织和处理，在最上层封装为数据服务形式去支持前台和业务中台对数据需求。

4.3 中台的组织架构

中台架构的提出对企业组织架构产生了巨大的影响，有了与中台相适应的组织架构，企业才能很好地完成中台建设并从中受益。中台架构彻底破除了应用系统边界，从企业的全业务领域着手，切分出业务中心，每一个业务中心所支撑的不是一个孤立的应用系统，而是企业在该领域分全部核心业务，所以每一个业务中心都需要非常专业的团队来负责，团队必须对这部分业务非常了解，而且必须站在企业的全局去支撑和把控这一业务领域。

4.4 中台不是“银弹”

本质上，中台是一种中心化、平台化的企业组织架构和业务形态，当这样的组织和业务架构投射到IT系统上时会自然形成我们今天讨论的IT意义上的“中台”。业务中心化系统都是反传统管理体制，烟囱式的生态系统是企业组织架构在IT上的投影，小到“数据湖”，大到中台，没有能力对等的中心化组织去主导，结果很难预料。

五、数据中台

数据中台是数据平台发展到现在的最新的理论模型和技术架构，它以大数据技术作为支撑，提供数据仓库、实时处理、数据服务和一定的人工智能及机器学习能力。

企业所有的数据需要输送至数据中台，由数据中台统一进行收集、验证、清洗和转换并集中存储，然后经过数据仓库体系的层层治理将数据按业务主体重新组织，为业务系统和数据分析提供高质量的数据集；

具备实时数据处理能力，能在极短时间内完成从数据采集到终端呈现的全链路数据处理，并有能力处理一些基于数据的业务请求，还配备了人工智能与机器学习的相关基础设施，支持高阶的数据洞察与预测；

数据中台通过丰富的接口和协议对外提供完备的数据服务，支撑业务中台与前台应用对数据的全方位需求。

5.1 企业数据资产的现状

• 数据离散分布，信息孤岛问题还没有完全得到解决；
• 依然在大量使用文件进行数据交互，没有实时API，制约了上层业务流程的时效性；
• 企业数据处理平台依然依赖传统技术，符合已经达到上限，无法进行水平伸缩；
• 大量数据离散于业务用户手工维护单额文件中，很难自动化收集并处理
• 同类型数据在多个业务系统中同步，数据冗余严重，一致性差，需要重复采集、核查、去重，成本高；
• 没有实时数据处理能力，无法快速及时地处理并反馈给业务用户；
• 没有健全的数据安全保障机制，面临数据泄露风险；
• 缺乏完善的数据治理机制，数据质量参差不齐。

5.2 数据中台具备的能力

• 平滑自如的水平伸缩能力，从容应对海量数据；
• 对资源拥有细粒度的控制能力，支持多任务、多用户下的作业处理；
• 强大的实时处理能力；
• 参与业务请求处理的能力；
• 具备人工智能及机器学习的数据分析能力；
• 以数据仓库理论管理和组织各类数据；
• 对外提供强大的数据服务，支持多种协议的数据传输与交互；
• 精准的细粒度安全控制。

5.3 数据中台建设策略

分为三个阶段：

（1）起步阶段：搭建基础设施；

• 构建基础设施

• 搭建原型系统

• 启动初试项目进行技术和业务验证

• 探索团队结构和管理模式
  （2）积累阶段：汇集数据，确定数据中台的核心地位

• 大规模集成数据源

• 完善数据仓库体系

• 完善数据服务体系

• 支撑一定的实时处理

• 具备一定的人工智能及机器学习能力

• 开始产出部分业务价值
  （3）发力阶段：基于丰富的数据集和完事的分析模型，产出大量有价值的分析结果，推动业务增长

• 深入挖掘业务需求，多维洞察分析

• 介入业务处理，在线处理业务请求

• 数据功能产品化
  ————————————————
  版权声明：本文为CSDN博主「baidu_38792549」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
  原文链接：https://blog.csdn.net/baidu_38792549/article/details/119805706