详解数据中台的底层架构逻辑
发布时间：2021-09-29 作者： admin
数据中台到底是什么，几年过去了，也一直众说纷纭。
笔者认为数据中台不应该是一个单纯的系统或者是一个软件工具，而应该是一套架构、一套数据流转模式。
数据中台需要采集数据作为原材料进行数据加工、数据建模，然后分门别类地储存，再根据实际的业 务场景,打造各类数据服务（含数据应用平台）从而实现对业务的赋能加速。
但以上流程的实现，需要有对应的系统与产品作为支撑，那么基础的数据中台到底应该由哪些系统或者产品组成？
这里我们可以先来看一下几个企业的数据中台架构。
可以看出，虽然每个企业由于自身业务的不同，衍生出来的数据中台体系都有所不同，但大的架构方面是基本统一的，都需要通过一个“数据采集接入”-“加工存储”-“统一管理”-“服务应用”的阶段。
这里笔者认为《数据中台产品经理：从数据体系到数据平台实战》一书中总结的数据中台架构是比较具有普适性的， 不论是互联网行业、还是传统行业，都可以在该架构上进行改造，设计建设自己的中台架构。
总体来说数据中台的功能架构由大数据平台、数据资产管理平台与数据服务平台三大部分组成，其中在数据服务平台中自助分析平台与标签管理系统的应用场景最为广泛。
1、大数据平台
大数据平台是数据中台的基座，我们也可以把大数据平台称为大数据开发平台，它需要具备与大数据相关的开发能力，提供数据存储、数据清洗/计算、数据查询展示及权限管理等功能。那么，应该如何建设上述功能与服务？是不是拥有了上述能力就等同于成功打造大数据平台了呢？
其实我们可以发现各公司的大数据平台系统架构其实大同小异，各类架构都包含了数据采集组件、数据存储组件、数据计算引擎、数据权限与安全组件，以及集群管理与监控组件等。 除了少数像阿里这样倾力打造自研“飞天”系统的企业，其他企业在底层组件选用上，还是以 Hadoop 生态构建的技术体系为主，依托各类开源组件进行优化改进与二次开发。例如，数据存储组件可以选择HBase、Hive等组件，数据计算引擎可以选择Spark、Flink等分布式计算引擎。 既然大家选用的组件相同或者相似，那为什么最终各企业大数据平台的服务能力还是存在差距呢？这有些类似于购买零件组装台式电脑，零件不需要选最贵的，而是要根据实际需求来选择最适合的。 好用的大数据平台需要拥有为用户解决问题的能力。因此，数据中台的大数据平台建设不是比拼引用了多少新技术、覆盖了多少技术组件，而是要看它能否解决数据中台建设中所面临的复杂数据现状，能否成为数据中台打破数据壁垒的技术保障，能否提供简洁有效的数据处理工具，如提供自助配置式的数据采集与数据清洗工具等，以及能否提供更多的附加价值。 数据中台的大数据平台建设，可以避免各事业部技术团队各自搭建大数据集群所带来的资源浪费。统一的、成熟的大数据平台对企业来说，不能一蹴而就，需要循序渐进、分步实施，在持续迭代中构建企业的大数据平台生态。
2、数据资产管理平台
数据资产管理平台主要解决数据资源的管理, 数据资产遍布在各个大数据组件中, 有 hive 的表, 有 hbase 的表, 有 druid 的 datasource, 有 kafka 中的流, 各个组件的管控系统很难互相打通, 所以需要一个统一的数据资产管理服务, 来统筹大数据资源的管理。
随着大数据平台的建设，构建数据中台的数据体系成为可能，通过对各业务线数据的归类整合，我们可以构建出各个数据主题域，完成数据的规范存储，形成数据资产，进而完成数据资产管理。 在数据中台体系中，数据资产管理平台主要由元数据管理与数据模型管理组成，下面让我们分别了解一下。
-
元数据管理
这里举一个最通俗的例子。当我们去图书馆借书时，直接面对数以万计的图书，自然难以寻找，但是你通过在图书馆查询系统中输入这本的书名、作者、出版社等信息，获取就能准确的图书位置。那么这些书名、作者等信息，就可以理解为元数据，而图书的存放位置、借阅历史记录等，则是我们系统中的普通数据。 在数据库中，每一张数据表的表名、创建信息（创建人、创建时间、所属部门）、修改信息、表字段（字段名、字段类型、字段长度等），以及该表与其他表之间的关系等信息都属于这张数据表的元数据。 其实，元数据有多种分类方式，笔者更倾向于按照元数据的用途来区分，总共分为三类：业务元数据、技术元数据和管理元数据。 ►业务元数据：描述数据的业务含义、业务规则等，包括业务规则、数据字典以及安全标准等多项内容。通过明确业务元数据，让人们产生统一的数据认知，消除数据歧义，让不懂数据库的业务方读懂数据表的内容。 ►技术元数据：描述数据源信息、数据流转信息及数据结构化信息，主要服务于数据开发人员，让开发人员明晰数据表结构与所依赖的上下游任务，主要包括库表字段（存储位置、数据库表、字段长度和类型）、数据模型、ETL脚本（调度信息）与SQL脚本等。 ►管理元数据：描述数据的管理归属信息，包括业务归属、系统归属、运维归属以及数据权限归属等信息，是数据安全管理的基础。 所以有人说，元数据记录了数据从无到有的全过程，就像一本有关数据的“字典”，让我们可以查询到每一个字段的含义与出处，同时它又像是一张“地图”，让我们可以追溯数据产生的路径。 通过对数据体系的建设，数据中台的元数据汇聚了企业各业务线与各系统的数据信息，让数据中台具备了提供全域数据资产视图的能力，实现了统一数据资产查询与获取入口的目标。 元数据管理包括对元数据增删与编辑管理、版本管理、元数据统计分析与元模型管理。通过上述功能模块，有计划地进行数据体系的落地实施，实现数据中台元数据的结构化与模型化，这样既可以避免元数据出现杂乱与冗余的现象，也便于用户查询与定位数据。
-
数据模型管理
3、数据服务平台
自助分析平台
自助分析平台，也就是商业智能平台（BI平台）。BI平台目前已经是很多企业的标配，目前BI商用市场的行业竞争日趋激烈，进场者可以分为如下3类： ►国内BI厂商，典型代表为连续多年国内市场占有率第一的帆软►国外BI厂商，如Tableau►互联网大厂内部孵化
BI 平台是数据中台服务能力的主要输出方，要想让数据中台发挥出应有价值，那么BI平台的建设必不可少，所以需要将BI 平台建设划分在数据中台体系下。综合来看，BI平台应该具备如下能力。
（1）数据接入
除了数据中台的自有数据源，BI平台还需要支持外部数据源的接入。其接入方式，主要有如下3种。
►文件型：支持Excel等文件数据的上传。►数据连接型：支持Mysql、Oracle等数据库，以及Hadoop、Spark等大数据平台（数据中台的大数据平台也在此列）。►API读取：支持通过API获取第三方系统数据。
图例：帆软BI平台支持的数据源
（2）数据处理
BI 平台需要能为用户提供数据建模工具，帮助用户创建目标数据（数据集），其提供的功能包括拖拽表字段、自动识别维度/指标、自定义视图语句、预览数据、设置虚拟字段、函数计算、设置参数等基本操作，以及多源异构的 JOIN/UNION等数据处理功能。
FineBI自助数据集数据处理界面
（3）数据分析与可视化
在数据处理的基础上，BI 平台还需要为用户提供丰富的图表制作和联机分析处理（OLAP）操作，让用户在前端页面完成数据分析与数据可视化等工作。 其操作流程如下：用户选择处理后的数据集，对维度与指标进行筛选过滤，然后通过上卷下钻、图表联动、报表跳转等操作，完成业务需求的分析，同时BI平台会为用户提供可视化图形组件，使其最终完成可视化内容的设计。
（4）内容分发与基础服务
BI平台需要具备分发可视化内容，并进行查看权限与数据权限控制的能力。主要的分发方式包括BI平台、移动BI（App）、数据大屏、邮件、链接访问，以及第三方嵌入等方式。 同时BI平台还需要具备基础的运营管理、角色管理、帮助中心与消息推送等功能。 只有满足以上功能、具备了多维分析、数据可视化与数据大屏等服务能力的BI平台，才可以最大限度的发挥在数据中台体系中的价值，有效地帮助分析师与运营团队提升工作效率。
-
标签管理系统
（1）用户唯一性识别
很多企业内各业务线都有自己的独立用户识别体系，如在 58 集团内就有 58设备指纹、安居客唯一用户、招聘自然人、金融自然人等多种用户识别方式，但是这些识别方式大部分是服务于单一业务线的，各业务线内的标签也是面向本业务的独立用户标识进行研发的。 数据中台的标签管理体系，可以提供统一的用户识别服务，将各业务线的独立用户标识进行关联和统一，从而打通面向整个企业的独立用户识别和标签交互转换方案。
（2）标签体系管理
标签体系管理的主要工作是制订标签数据和信息交互方案，打通用户画像研发和服务中的信息及数据壁垒，提供标签接入、可视化标签信息展现、可视化标签权限控制、可视化用户标签分析、可视化人群定向提取与可视化相似人群扩展（Lookalike）等功能。
（3）标签数据服务
标签管理系统，需要提供用户画像研发和应用过程中涉及的标签提取与查询等服务，以标准化服务接口（API）的方式将相关解决方案提供给各业务方，支持业务方基于数据中台的能力，打造业务线的个性化服务。 除了商业智能BI和标签管理外，各企业还需根据自身所处行业的特性去进行数据应用价值的最大化挖掘。
（如有侵权，请联系删除。）
