热点新闻网热点新闻网

“数据中台”万字深度思考

导读 : 最新精选区块链汽车创意科技媒体达人电影音乐娱乐休闲生活旅行学习工具历史读书金融理财美食菜谱“数据中台”万字深度思考软件定义世界(SDX)软件定义世界(SDX)2...


  • 最新
  • 精选
  • 区块链
  • 汽车
  • 创意科技
  • 媒体达人
  • 电影音乐
  • 娱乐休闲
  • 生活旅行
  • 学习工具
  • 历史读书
  • 金融理财
  • 美食菜谱

“数据中台”万字深度思考

软件定义世界(SDX) 软件定义世界(SDX) 2020-07-20

热门下载(点击标题即可阅读)

☞【PPT下载】中国数据分析师行业峰会精彩PPT下载(共计21个文件)

【数据中台专栏】(点击蓝色标题即可阅读)

【PPT】八问数据中台:关于数据中台你想知道的都在这里!

PPT】阿里中台(看图不说话)

【10万+】数据中台已成下一风口,它会颠覆数据工程师的工作吗?

比较关于中台,你可能不知道的那些事

【历史】“数据中台”演进的四个阶段

【PPT案例】日均150亿定位滴滴【数据中台】4个历程
【PPT】滴滴大数据研发中台的最佳实践

【案例】Netflix的数据中台
【案例】富国银行的数据中台
案例】民生银行数据中台体系的构建与实践

【挑战】数据中台元年,企业数字化转型面临的三大挑战

【PPT】阿里巴巴数据中台实践分享

【PPT】《2019年中国数字中台行业研究报告》

【辨析】数据中台是真火还是炒作?

【视频】《数据中台建设之道》

本文将总结下数据中台的相关理论知识。Flink平台化需要改进的点等等,参考《数据中台》。

原文地址:https://miaowenting.site/2020/03/24/%E5%85%B3%E4%BA%8E%E6%95%B0%E6%8D%AE%E4%B8%AD%E5%8F%B0%E7%9A%84%E6%80%9D%E8%80%83%E4%B8%8E%E6%80%BB%E7%BB%93/

数据中台


数据汇聚

数据汇聚是数据中台必须提供的核心工具,把各种异构网络、异构数据源的数据方便地采集到数据中台中进行集中存储,为后续的加工建模做准备。数据汇聚方式一般有数据库同步、埋点、网络爬虫、消息队列等;从汇聚的时效性来分,有离线批量汇聚和实时采集。

数据采集工具

Canal、DataX、Sqoop

数据开发

数据开发模块主要面向开发人员、分析人员,提供离线、实时、算法开发工具。

离线开发 作业调度

依赖调度:所有父作业运行完成后,当前作业才能开始运行。图64中的作业B,只有父作业A和C运行完成后,才能开始被调度。时间调度:可指定作业的调度开始时间。图64中的作业B,只有到达05:00后才能开始被调度。

基线控制

在大数据离线作业中,作业执行时间较长,经常遇到急着用数据发现数据还没出来的情况。采用算法对作业完成时间进行智能预测,根据预测,当作业无法正常产出且动态调整无法完成时,调度中心会及时通过监控告警通知运维值班人员提前介入处理,为大数据作业执行留出充裕的时间。

异构存储

企业内部的存储计算引擎呈多元化趋势。离线开发中心针对每种类型的计算引擎会开发不同的组件,例如,针对Oracle开发Oracle插件,针对Hadoop体系分别开发出Hive、Spark、MR等插件。用户在界面新建各种作业类型,在执行时自动根据作业的类型寻找相应的插件来运行作业。

代码校验

对于常见的SQL任务类型,SQL检查器会做好严格的管控,做到事前发现问题。

多环境级联

通过环境级联的方式灵活支持企业的各类环境需求,方便对资源、权限进行控制和隔离。每个环境有独立的Hive数据库、Yarn调度队列,甚至不同的Hadoop集群。常见的环境如下:

单一环境:只有一个生产环境,内部管理简单。经典环境:开发环境中存放脱敏数据、供开发测试使用,上生产环境走发布流程,用于真实数据生产。任务、资源和函数必须在开发环境下进行新建、修改或删除,再经过提交、创建发布包、同意发布三个操作后,才能同步到生产环境。复杂环境:企业有外部人员和内部人员,会给外部人员提供一个脱敏管控的环境,外部人员开发完的数据模型经过测试后发布到内部开发环境。

推荐依赖

随着业务的不断深入,数据开发人员需要开发的作业会不断累加。既能保证准确找到需要定位的上游作业,又能保证不会形成环路。



获取推荐依赖的核心原理在于上下游作业输入和输出的表级血缘依赖图;通过血缘分析当前作业的输入和输出,找到合适的上游作业;对合适的作业进行环路检测,剔除存在闭环的作业;返回合适的节点列表。

数据权限

企业内部计算引擎多样化,数据权限管理面临如下问题:

部分引擎拥有独立的权限管理系统(例如Oracle、HANA、LibrA),导致权限申请需要到每一种引擎上单独操作,让使用变得复杂。同一种计算引擎,不同厂商的权限系统有多种,例如Hadoop自身无数据权限系统,由不同厂商各自去实现,目前主要有两种策略:RBAC(Role-Based Access Control):如Cloudera用的是Sentry,华为的FI也是类似的机制PBAC(Policy-Based Access Control):如Hortonworks用的Ranger数据权限是由大数据集群或数据库运维人员管理的,开发人员无法直接操作或者接触,所有的权限申请都需要运维人员开通,造成运维人员负担过重。在实际开发中,一般需要运维人员把整个库的权限授权给某个开发负责人,然后库里面的表、字段、函数的权限管理由开发负责人负责就行。数据权限管理中心提供界面化操作,数据申请方直接在页面上进行各种权限的申请,数据管理方在界面上审核权限,执行同意或拒绝操作。同时,所有权限的申请、审批都会有记录,便于进行权限审计。在统一数据权限服务中,会对接底层的各种权限管理系统,例如Sentry、Ranger、Oracle,同时对数据权限管理中心提供服务,执行权限的申请、授权、撤销等操作。

实时开发

元数据管理SQL驱动组件化开发

智能运维

任务的管理、代码发布、运维、监控、告警等一系列集成工具,方便使用,提升效率。重跑、重跑下游、补数据。

数据体系

有了数据汇聚、数据开发模块,中台已经具备传统数据仓库(后面简称:数仓)平台的基本能力,可以做数据的汇聚以及各种数据开发,就可以建立企业的数据体系。之前说数据体系是中台的血肉,开发、管理、使用的都是数据。

中台数据体系应具备以下特征:

覆盖全域数据:数据集中建设、覆盖所有业务过程数据,业务中台在数据体系中总能找到需要的数据。结构层次清晰:纵向的数据分层、横向主题域、业务过程划分,让整个层次结构清晰易理解。数据准确一致:定义一致性指标,统一命名、统一业务含义、统一计算口径,并有专业团队负责建模,保证数据的准确一致。性能提升:统一的规划设计,选用合理的数据模型,清晰的定义并统一规范,并且考虑使用场景,使整体性能更好。降低成本:数据体系的建设使得数据能被业务共享,这避免了大量烟囱式的重复建设,节约了计算、存储和人力成本。方便易用:易用的总体原则是越往后越能方便地直接使用数据,把一些复杂的处理尽可能前置,必要时做适当的冗余处理。

不同行业的数据体系建设:

地产行业



证券行业



零售行业



制造行业



传媒行业



检务行业



贴源数据层ODS

对各业务系统数据进行采集、汇聚,尽可能保留原始业务流程数据,与业务系统基本保持一致,仅做简单整合、非结构化数据结构化处理或者增加标识数据日期描述信息,不做深度清洗加工。

表名:ODS_系统简称_业务系统表名字段名:与业务系统字段名保持一致,字段类型也尽可能保持一致对于数据量比较大的业务表,采用增量同步的方式,则要同时建立增量表和全量表,增量表命名加后缀:ODS_系统简称_业务系统表名_delta。对于日志、文件等半结构数据,不仅要存储原始数据,还要存储结构化之后的数据。

使用DataX同步数据步骤:

1)确定业务系统源表与贴源数据层目标表

2)配置数据字段映射关系,目标表可能会增加采集日期、分区、原系统标识等必要信息,业务相关内容不做转换

3)如果是增量同步或着有条件的同步部分数据,则配置数据同步条件

4)清理目标表对应数据

5)启动同步任务,往贴源数据层目标表导入数据

6)验证任务是否可以正确运行,并且采集到准确数据

7)发布采集任务,加入生产调度,并配置相关限速、容错、质量监控、告警机制

统一数仓层DW

明细数据层DWD汇总数据层DWS

与传统数据仓库功能基本一致,对全历史业务过程数据进行建模存储。对来源于业务系统的数据进行重新组织。业务系统是按照业务流程方便操作的方式来组织数据的,而统一数仓层从业务易理解的视角来重新组织,定义一致的指标、维度,各业务板块、业务域按照统一规范独立建设,从而形成统一规范的标准业务数据体系。

标签数据层TDM

面向对象建模,对跨业务板块、跨数据域的特定对象数据进行整合,通过IDMapping把各个业务板块、各个业务过程中的同一对象的数据打通,形成对象的全域标签体系,方便深度分析、挖掘、应用。



应用数据层ADS

按照业务的需要从统一数仓层、标签数据层抽取数据,并面向业务的特殊需要加工业务特定数据,以满足业务及性能需求,向特定应用组装应用数据。

数据资产管理

数据资产管理包括对数据资产目录、元数据、数据质量、数据血缘、数据生命周期等进行管理和展示,以一种更直观的方式展现企业的数据资产,提升企业的数据意识。

数据资产对上支持以价值挖掘和业务赋能为导向的数据应用开发,对下依托大数据平台实现数据全生命周期的管理,并对企业数据资产的价值、质量进行评估,促进企业数据资产不断自我完善,持续向业务输出动力。

数据治理

传统的数据治理通常包含数据标准管理、元数据管理、数据质量管理、数据安全管理、数据生命周期管理等内容。

数据服务体系

前面利用数据汇聚、数据开发建设企业的数据资产,利用数据管理展现企业的数据资产,但是并没有发挥数据的价值。数据服务体系就是把数据变为一种服务能力,通过数据服务让数据参与到业务, 快速开发企业的业务中台等。

查询服务

输入特定的查询条件,返回该条件下的数据,以API形式供上层应用调用。

1)支持配置查询标识,底层数据组织一般会对该标识建立索引,以加快查询速度

2)支持配置过滤项

3)支持查询结果配置,包括数据排序规则和分页规则。

分析服务

借助分析组件高效的大数据分析能力,对数据进行关联分析,分析结果通过API形式供上层应用调用。

1)支持多源数据接入:企业的数据经过清洗加工转换成数据资产后,最终通过服务作用于业务系统,基于企业异构存储的现状,要求分析服务能够支持与Hive、ES、Greenplum、MySQL、Oracle、本地文件等多种数据源进行连接。

2)高性能即席查询:随着企业数据爆发式增长,传统的数据分析工具遇到分析能力的瓶颈,也就是对大数据量的分析越来越乏力。因此,这就要求分析服务内置高速计算引擎,以对数据进行高性能的即席计算,实现亿级数据毫秒级(至多秒级)分析和计算,减少用户等待时间。

3)多维数据分析

分析服务除了支持常规的数据分析、上卷下钻、切片切块之外,还应该支持多维的数据分析以及深层次的数据挖掘,发现数据背后的关联关系。

4)灵活对接业务系统

推荐服务

按约定的格式提供历史日志行为数据和实时访问数据,推荐模型就会生成相应的推荐API,从而为上层应用提供推荐服务。

推荐服务即所谓的千人千面,对不同的人对物的行为进行数据挖掘,构建每个人与物之间的关系程度,来推荐人、物以满足用户的兴趣爱好,以提升用户对业务的粘性。每个人打开手机淘宝看到的内容都不一样,这就是一种基于人的兴趣爱好的推荐服务能力。

1)支持不同行业的推荐:不同行业背后的推荐逻辑是有区别的

2)支持不同场景的推荐:以内容资讯为例,在用户冷启动场景下,应该推荐哪些资讯?在用户已有浏览行为的场景下,又该为其推荐哪些资讯?

3)支持推荐效果优化:从导入的原始数据开始,经过推荐组件生成推荐数据,再根据用户的浏览数据不断修正推荐模型,从而使推荐效果不断优化

圈人服务

从全量用户数据中,基于标签组合筛选符合指定特征条件的人群,并通过API形式供上层应用调用。

1)支持人群圈选:通过SQL代码或标签取值组合等多种方式,实现人员查找,帮用户找到对的人群

2)支持人群计量:营销部门或者广告公司使用圈人服务圈选出目标人群后,往往还要考虑人群量是否符合预期,因为预算有限,不可能不计成本的对人群进行营销。

3)支持多渠道对接:将人群名单导出到相应的下游系统。最简单的名单导出方式是先下载文件,再由业务人员导入相应的业务系统中。或者直接对接到短信系统、微信投放接口、营销活动系统等。

离线平台

苏宁离线平台产品功能图:



苏宁调度模块功能图:



苏宁离线平台整体架构图:



跨任务流依赖的实现:

FTP事件机制,即在 FTP 服务器上建立标识文件,一个事件对应一个标识文件地址,当 FTP 服务器上的标识文件生成的时候,我们认为业务系统已经完成作业,需要触发平台任务执行。

“华佗”平台,实施任务诊断:



立即触发的任务,放入DelayQueue的队列头部,周期调度的任务,使用Quartz,依赖触发的任务,使用zk,各个子节点监听自己的父节点,所有父节点执行完毕则可触发执行

实时平台 美团点评



使用了Grafana,可以内嵌到自己的平台。

bilibili

SQL化编程DAG拖拽编程一体化托管运维

实时平台由实时传输和实时计算两部分组成,平台底层统一管理元数据、血缘、权限以及作业运维等。实时传输主要负责将数据传入到大数据体系中。实时计算基于 BSQL 提供各种应用场景支持。

如下图所示,实时传输有 APP 日志、数据库 Binlog、服务端日志或系统日志。bilibili 内部的 Lancer 系统解决数据落地到 Kafka 或 HDFS。计算体系主要围绕 Saber 构建一套 BSQL,底层基于 YARN 进行调度管理。

上层核心基于 Flink 构建运行池。再向上一层满足多种维表场景,包括 MySQL、Redis、HBase。状态(State)部分在 RocksDB 基础上,还扩展了 MapDB、Redis。Flink 需要 IO 密集是很麻烦的问题,因为 Flink 的资源调度体系内有内存和 CPU,但 IO 单位未做统一管理。当某一个作业对 IO 有强烈的需求时,需要分配很多以 CPU 或内存为单位的资源,且未必能够很好的满足 IO 的扩展。所以本质上 bilibili 现阶段是将 IO 密集的资源的 State 转移到 Redis 上做缓解。数据经过 BSQL 计算完成之后传输到实时数仓,如 Kafka、HBase、ES 或 MySQL、TiDB。最终到 AI 或 BI、报表以及日志中心。



场景