2023-02-08 02:05 浏览量:419
关于数据中台的几点思考
1:什么是数据中台?数据中台的特点?
数据中台是指通过数据技术,对海量数据进行采集、计算、存储、加工,同时统一标准和口径。数据中台把数据统一之后,会形成标准数据,再进行存储,形成大数据资产层,进而为客户提供高效服务。
数据中台是一套可持续“让企业的数据用起来”的机制,通过有形的产品和实施方法论,构建一套持续不断把数据变成资产并服务于业务的机制,数据来自于业务,并反哺业务,不断循环迭代,实现数据数据可见、可用、可运营,通过数据中台把数据变成一种服务能力,其目标是提供普惠的数据服务。
数据中台的4个核心能力(最核心的竞争力):汇聚整合、提纯加工、服务可视化、价值变现
数据中台的功能与定位:
1)数据中台具备数据汇聚整合、数据提纯加工、数据服务可视化、数据价值变现核心能力。
2)数据中台的核心就是实现公共计算逻辑下沉,实现数据复用,提供给接口使用。
3)数据中台不是某一个单一的产品或者某个技术。本质上讲数据中台就是从数据中发现价值,赋能业务数据管理机制。
4)数据中台最核心的理念就是"OneData,OneEntity,OneService"
Onedata致力于统一数据标准,让数据成为资产而非成本
Oneentity致力于统一实体,让数据融通,而非孤岛
Onservice致力于统一数据服务,让数据复用而非复制
2: 标准数据中台架构?
3: 数据中台包含哪些内容?
数据采集
数据集成
数据存储
数据模型管理
数据仓库/数据湖
数据计算/ETL
主数据管理
元数据管理
数据血缘
数据质量
指标管理
数据生命周期管理
数据安全管理
数据标准管理
自助分析平台
olap查询
BI可视化
统一数据服务
调度平台
3: oneData ?
One Data就是指所有数据只加工一次。
有以下五点需要保障:
分主题域管理
命名规范定义
指标一致
数据模型复用
数据完善
oneData包含以下模块:数据同步/采集,数据目录,数据资产,数据模型,数据质量检查,元数据管理,数据治理,数据存储,数据计算,etl...
4: oneEntity ?
oneEntity旨在连接数据孤岛,实现数据融通。其中包括:IDMapping,OneEntity统一实体,GProfile全域标签萃取,GBehavior全域行为。(用户画像标签平台,oneModle(多业务模型融合)
5: oneService ?
One Service即数据即服务,强调数据中台中的数据应该是通过API 接口的方式被访问。
有以下四点:
屏蔽异构数据源
把控数据网关
提供面向用户的逻辑模型
保证性能和稳定性
OneService体系方法论至少包括:主题式数据服务、统一但多样化的数据服务、跨源数据服务3个方面。
(1)主题式数据服务。举一个例子,假设用户想要看的是“会员”这个主题下的数裾.,至于“会员”主题背后有1000张物理表还是2000张物理表,他都不关心。而主题式数据服务要做的是,从方便用户的视角出发,从逻辑层面屛蔽这1000张甚至是2000张物理表,以逻辑模型的方式构建而非物理表方式。
(2)统一但多样化的数据服务。例如,双十一当天上百亿次的调用服务是统一的,但获取形式可以是多样化的,可以通过API提供自主的SQL查洵数据服务,也可以通过API提供在线直接调用数椐服务。
(3)跨源数据服务。不管数裾服务的源头在哪里,从数据服务的角度出发,都不应该将这些复杂的情况暴露给用户,而是尽可能地屏蔽多种异构数据源。
oneService包含内容:统一查询API接口,集群性能监控,全链路监控,调度平台,网关服务,鉴权,安全认证,高可用建设,容器化...
OneService平台的第一个关键技术是API矩阵。API矩阵是指,平台面向不同的数据服务业务场景,而沉淀下来的API创建模板或者API类型。API类型非常多,我们将API类型从两个维度来划分,一是查询灵活度,二是查询速度,每个象限中都有API分布。用户在平台创建API时,可根据自己的需求,从对应象限中寻找符合自己场景的API。此外,针对单类API,面向不同的业务使用场景时,还可做到定制化,如设置数据压缩、热点数据加速等特性,从而更好满足业务需求。
本文选取三类典型的API类型介绍:
KV API:KV API 底层基于KV 引擎,如Redis、Hbaes、Pika 等,因此取数很快,且可支撑百万QPS。KV API消息是基于Protobuf,传输效率也非常高。用户在使用时,拿到的结果对象也是基于PB(结果集是自动ORM),因此在编码时也很方便。典型使用场景包括用户标签查询、IP查询等点查类场景。
SQL API:SQL API底层基于OLAP引擎,如Clickhouse、Druid 等,其支持的查询速度相对慢一些,不过能够支持更加灵活自由的查询条件。SQL API提供了Fluent API风格的接口,调用者可在select中自行传入要查询的字段信息,也可在where方法中自由构造多种嵌套的过滤查询条件。SQL API典型使用场景是支持数据BI看板。
Template API:Template API 和 SQL API 类似,底层也是基于Clickhouse、Druid等,不过有个较大区别点是用户在使用Template API时,查询模板是预定义在服务端,然后在客户端动态传入参数变量,后台将模板和变量组合成完整语句查询。其典型场景和SQL API类似。
OneService平台的第二个关键技术是「配置即开发」的设计理念。早期快手建设数据服务依赖于手工开发,而「配置即开发」意味着,用户只需要配置好一个API,就相当于开发一个API接口。基于这个设计理念,用户通过平台创建API,主要包含三个阶段:
配置 API:配置创建API的必要信息,包括数据底表来源、接口本身形态(RPC or HTTP)、是否需要批量访问数据、访问QPS范围、测试链路独立数据源等等。
自动生产接口:OneService平台根据前面的 API 配置信息,自动化生成客户端接口以及自动部署服务端。在不需要用户参与的情况下,后台自动化去做好数据加速、数据服务接口生成、接口验证、测试环境配置、接口上线和上架等操作。
使用接口:待 OneService 平台自动化创建 API 接口之后,调用者只需要在平台上申请接口权限,即可在测试环境和正式环境访问数据。
上述三个阶段中,对用户提效最大的是第二阶段,即自动生产接口。这也是「配置即开发」的核心落脚点。OneService 平台自动化生产包括三个主要步骤:
基于Code Generation的客户端自动化生成:用户提交的 KV API 创建申请,后端根据其配置详情信息,来生成 Java 代码,并且自动发布 SDK。该 Java 接口针对每个业务是定制化的,使用体验更好。除了 KV API 之外,针对 SQL API创建申请,后端无需再次创建定制化的Java 接口,用户是使用统一的固定的预先开发好的 Java 接口来访问 SQL API数据。未来趋势是,OneService 平台提供一个统一的接口,来应对所有类型的场景。
热部署轻量虚拟服务:KV API / SQL API 客户端的请求打到后端,会有对应的虚拟服务处理。虚拟服务保留了API粒度的处理逻辑,如数据存储地址、读取方式、解析逻辑等,由于其非常轻量,因此也可以动态迁移到其他物理集群上,来动态平衡流量和服务压力。
数据加速:由于数据资产主要存储于离线存储体系,读取速度较慢,因此需要进行数据加速,将数据以一次性或者周期性的方式加速到高速存储引擎,包括 KV 引擎或者 OLAP 引擎中。虚拟服务可直接从高速引擎中取数。
6: 统一存储
统一存储不仅仅在于架构简单,更主要是避免了跨源连接,复用性增强,统一管理起来,消除了数据孤岛,而且避免了多组件之间的兼容性和效率影响。也为后续湖仓一体提供了存储基石。
7: 统一计算引擎
统一数据计算引擎,降低传统实时计算与批处理技术不一致的问题,降低系统的管理成本。
后续可以采用批流一体,避免了维护两套代码,也简化了技术架构。