数据智能 数据中台 大数据 产品规划 架构设计
2023-10-31 11:07:25 1 举报AI智能生成
数据智能 数据中台 大数据 产品规划 架构设计 大数据架构师必知必会系列 大数据产品经理必知必会系列 1、数据中台是什么？ 2、数据中台如何建设？ 3、数据中台日常干什么？
作者其他创作
大纲/内容
前言
数据中台是什么？
数据中台如何建设？
从产品经理和项目管理角度，数据中台在实际生产中如何运作？
数据中台应该有什么
数据应用
(数据中台给业务的赋能)
(数据中台给业务的赋能)
推荐引擎
埋点系统
画像系统
AB测试系统
业务大屏&报表系统
是什么？
监测核心业务状态的可视化工具
有哪些能力？
监控
集成数据信息，监控商业进程。
领导们监控大趋势，业务部门监控各细化指标，发布业务预警。
分析
各业务团队可通过拖拉拽的方式进行可视化分析，
进行业务复盘，深挖数据细节，分析原因，直击问题点。
进行业务复盘，深挖数据细节，分析原因，直击问题点。
协同
实时同步各部门的协作目标，促进交流与协作，共同解决业务问题。
数据平台
(数据仓库基础架构给数据中台的赋能)
(数据仓库基础架构给数据中台的赋能)
数据开发平台
数据资产管理平
元数据管理平
数据安全合规平台
组织架构
技术架构
各类大数据组件必不可少
当然也不必过分求快
比方说实时计算能力对于一些企业来说并不是必须的
数据中台在做什么
数据中台主要内容
1）业务数据支持
业务的数据需求紧急且重要
2）中台建设统筹
数据中台建设初期，往往由于BI与各业务部门的目标协同不足，被迫投入过多人力支持业务数据需求。
而事实上两者应该是相辅相成的，
平台能力建设是为了业务部门可以更加自助地使用数据资产，
业务数据需求支持可以为中台积累业务认知，更好地洞察业务需求。
平台能力建设是为了业务部门可以更加自助地使用数据资产，
业务数据需求支持可以为中台积累业务认知，更好地洞察业务需求。
举个栗子
以报表为例子
在没有中台的时候，或者中台能力尚不强大时，
数据开发/数据分析的同事需要与业务部门对接，
必然经过多回合的“确认口径-出报表验证-修改口径-定期批跑-导出-分析”，
沟通成本高，节奏拖沓，往往拿到准确的报表已经是几天之后了，
而且后续的每一次调整都需要与数据开发同事沟通确认。
数据开发/数据分析的同事需要与业务部门对接，
必然经过多回合的“确认口径-出报表验证-修改口径-定期批跑-导出-分析”，
沟通成本高，节奏拖沓，往往拿到准确的报表已经是几天之后了，
而且后续的每一次调整都需要与数据开发同事沟通确认。
数据中台建设示例
平台能力建设可以归纳出常见的业务分析场景，将报表需求抽象化、模块化，
赋能业务部门在平台上自行选择统计口径、渠道范围、时间区间、统计频率、汇总粒度等条件，分钟级自动生成报表。
这样的中台建设显著增加了代码和服务的复用，降低了沟通成本，提升了各部门的工作效率。
赋能业务部门在平台上自行选择统计口径、渠道范围、时间区间、统计频率、汇总粒度等条件，分钟级自动生成报表。
这样的中台建设显著增加了代码和服务的复用，降低了沟通成本，提升了各部门的工作效率。
平台能力建设是一个宽泛的概念，应该视业务的需求而定，
准确来说将出现次数越多、消耗中台人力越多的场景，越需要尽早建设为数据中台的能力。
包括报表、合规、AB测试、埋点、推荐等等。
准确来说将出现次数越多、消耗中台人力越多的场景，越需要尽早建设为数据中台的能力。
包括报表、合规、AB测试、埋点、推荐等等。
举个栗子
以报表和合规监管为例
1）报表能力建设
各业务部门需要定期、不定期统计总结日活用户、客单价及各指标变化等数据指标，与画像提报情况相似。
在平台建设完成之后，使用者可以自助选择口径，定期回顾发送邮件，基于图表模块生成可视化图表，或进行异常情况监控。
在平台建设完成之后，使用者可以自助选择口径，定期回顾发送邮件，基于图表模块生成可视化图表，或进行异常情况监控。
2）数据安全合规能力建设
各监管对于用户隐私数据日益重视，需要进行各类加密处理，维护与监管机构的高效沟通。
打个比方，监管机构首次提出整改要求或者要求检查部分数据时，
各公司可能需要一两周的时间来“处理加工”数据（处理加工在这里是中性词，指从海量杂乱的数据中找出监管部门所需要的，并进行分类、归纳）。
后续监管机构再次拜访时，对接部门可以更早拿到数据进行查验，可以更加从容地应对，比友商更及时提交相关资料。
各公司可能需要一两周的时间来“处理加工”数据（处理加工在这里是中性词，指从海量杂乱的数据中找出监管部门所需要的，并进行分类、归纳）。
后续监管机构再次拜访时，对接部门可以更早拿到数据进行查验，可以更加从容地应对，比友商更及时提交相关资料。
数据中台流程与运营实践
前言
这一部分主要介绍数据中台项目管理的重点工作内容
需求管理流程
需求预沟通
业务部门向数据中台中熟识的同事进行预沟通，
与业务部门接触的可能是数据中台的各个岗位的同事，
因此也需要培养数据开发、数据后台工程同事预沟通的习惯。
与业务部门接触的可能是数据中台的各个岗位的同事，
因此也需要培养数据开发、数据后台工程同事预沟通的习惯。
预沟通的目标
预沟通的首要目标是让业务部门的需求进入既定流程，通过数据中台提供的指引完成提单。
预沟通的次要目标是在成本不高的情况下，帮助业务部门明确需求，
如果需求跨越团队较多，预沟通时难以明确，可在需求评审时讨论。
如果需求跨越团队较多，预沟通时难以明确，可在需求评审时讨论。
需求聊不清楚怎么办？
我们经常会遇到业务部门的需求比较模糊的情况，
可能是刚接手的同事只有业务领导的一两句话指示尚不清楚具体情况；
可能是刚接手的同事只有业务领导的一两句话指示尚不清楚具体情况；
可能是发现了一个问题想优化，但没有明确的目标，不清楚要改成什么样；
可能是业务部门想要一份数据，但不清楚有没有这样的数据，或不清楚数据存放在哪里。
提需求单
目标
为了更好地记录、回溯，必须要求业务部门进行提单。
包含的内容
需求单里应该包含的内容，视不同的公司的数据中台所承接的职能不同而有所不同，
较核心的内容包括需求背景、所需的能力支持、相关数据的口径定义、期望完成时间、验收标准，
可能业务部门提单时无法全部写清楚，需要与数据中台各团队在评审会上确认，可以后续对需求单进行补充调整。
较核心的内容包括需求背景、所需的能力支持、相关数据的口径定义、期望完成时间、验收标准，
可能业务部门提单时无法全部写清楚，需要与数据中台各团队在评审会上确认，可以后续对需求单进行补充调整。
Q：如果业务同事太忙了，不愿意写需求单，只写一句话需求单，怎么办？
A：需求单必须由业务部门发起，
业务部门最了解需求背景、验收标准，
业务部门所不太了解的部分（比如数据源、口径、时效等）可以由中台同事进行补充。
业务部门最了解需求背景、验收标准，
业务部门所不太了解的部分（比如数据源、口径、时效等）可以由中台同事进行补充。
提需求单的原则是什么
提单的原则在于“谁需要，谁提单”，
如果需求方不愿意花个把小时把需求梳理清楚并记录下来，如何要求响应方花上几天来实现呢。
如果需求方不愿意花个把小时把需求梳理清楚并记录下来，如何要求响应方花上几天来实现呢。
而且事实上大家会发现，提单时偷懒省的时间，会在后面的需求讨论、数据探查、数据校验、交付调整的时候加倍还回去。
需求分类
前言
通常业务部门提单时，参照中台所提供的指引，大致知道这个需求归属于哪个团队，或者这是一个跨团队的复合型需求。
需求分类的原则
对于归属明晰的需求，由团队直接对接、明确需求owner
对于复合型需求，可以有项目经理组织定期评审，
拉上各团队负责人、业务部门产品&开发对接人，
讨论后明确数据中台侧的需求owner，后续由此owner主导提供解决方案
拉上各团队负责人、业务部门产品&开发对接人，
讨论后明确数据中台侧的需求owner，后续由此owner主导提供解决方案
举个栗子
最初的流程
因而，我们将各需求类型固化出一套分类指引，
业务方只需要回答3-4个 “Yes or No” 的简单问题，
便可自动判断出需求owner，或判断为复合型需求移交PM。
业务方只需要回答3-4个 “Yes or No” 的简单问题，
便可自动判断出需求owner，或判断为复合型需求移交PM。
优化流程
分类指引的原则
由开发主力团队leader担任
由最终交付团队leader担任
分类指引的好处
这一个看起来不大的优化，在实施1个月后，
积压需求减少了70%，
周交付需求数量提升30%，
单个需求交付时间平均减少了约25%。
积压需求减少了70%，
周交付需求数量提升30%，
单个需求交付时间平均减少了约25%。
可行性分析与解决方案
目标
这个环节主要是由需求owner主导完成，
需要明确需求的参与人和职责，
比如数据产品的探查工作，数据开发的编译与调优等，
同时给出排期计划，与各方同步。
需要明确需求的参与人和职责，
比如数据产品的探查工作，数据开发的编译与调优等，
同时给出排期计划，与各方同步。
数据合规安全判断与审批
哪些内容需要合规
需求owner需要判断所提供的数据是否需要数据合规审批，如果需要，则发起数据合规审批
同时也需要把控数据的加密、解密、跨法律主体使用、是否明文处理、传输链路中的风险等细节。
本着谨慎性的原则，数据合规审批一般由中台的同事发起，
这是因为中台是这批数据的提供方，也是可能的责任方，
与此同时也更熟悉数据来源、数据分布、数据主体归属，更了解其中蕴含的风险。
这是因为中台是这批数据的提供方，也是可能的责任方，
与此同时也更熟悉数据来源、数据分布、数据主体归属，更了解其中蕴含的风险。
数据合规安全审批涉及的环节
直面反垄断监管的大体量集团企业
掌握用户较多隐私数据的机构
通信基础设施型企业
承担反赌反诈反洗钱责任的机构
需求交付验收
目标是什么
在开发过程中遇到问题，及时给业务部门反馈，避免交付时才暴露问题，被迫推倒重来。
在交付之后，需求owner和项目经理的一个重要工作是推动需求方尽快验收。
在交付之后，需求owner和项目经理的一个重要工作是推动需求方尽快验收。
尽快验收的原则是什么
我们在需求提单的环节会要求需求方明确“高-中-低”的优先级，
对于高优先级的需求，要求需求方1天内启动验收，2天内完成验收或提出修改；
对于高优先级的需求，要求需求方1天内启动验收，2天内完成验收或提出修改；
对于低优先级的需求，时间要求可适当放开，但也不宜超过一周。
回顾并沉淀能力
目标
这个环节其实与上述几个流程没有强烈的前后因果关系。
核心在于定期回顾业务需求，选择其中高频、高耗时的进行抽象沉淀。
核心在于定期回顾业务需求，选择其中高频、高耗时的进行抽象沉淀。
当然最优解是在业务之前，预测未来一段时间的业务重心，提前建设相关能力。
总结
数据中台的运营与迭代的过程也是各模块相互推进、相互制约从而螺旋式上升的过程，
从来不是一蹴而就的，是一个长期的过程。
从来不是一蹴而就的，是一个长期的过程。
数据中台的发展离不开领导层和leader们清晰的认知，
以及平台开发、数据开发、产品经理、项目管理各个角色的密切配合。
以及平台开发、数据开发、产品经理、项目管理各个角色的密切配合。
收藏
0 条评论
下一页
