<svg xmlns="http://www.w3.org/2000/svg" style="display: none;"> <path stroke-linecap="round" d="M5,0 0,2.5 5,5z" id="raphael-marker-block" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);"></path> </svg> <p>1.1 什么是中台<br /> · 中台分为业务中台和数据中台,<br /> · 业务中台是中心化的能力复用平台。<br /> · 数据中台可以承担公司所有产品线的数据分析工作,通过数据化的手段为各条产品线赋能。数据中台主要承担以下四个方面的工作,分别是对数据的“采集”“存储”“打通”“使用”,<br /> · “采集”是指采集各条产品线的数据(如业务数据、日志数据、行为数据等),并将这些数<br /> · 据集中处理,存放在数据中心。<br /> · “存储”是用更加科学的方式存储数据。业内一般采用分层建模的方式,让采集上来的数据变成公司的数据资产。<br /> · “打通”分为两方面。一方面要打通用户的行为数据和用户的业务数据,从而构建更加丰富的用户画像;另一方面要打通产品线之间的数据,<br /> · “使用”是用打通后的数据赋能业务人员,帮助领导层进行决策,用数据来反哺业务。<br /> · 美团是一家数据智能的公司。<br /> · 搭建数据中台的最终目标就是帮助企业实现数据智能。<br /> · 业务中台的目的是让一切业务数据化;数据中台的目的是让一切数据业务化。<br /> · 如果公司有多条产品线(至少三条产品线以上),各条产品线之间有很多可以复用的功能,那么该公司就适合搭建中台。<br /> 1.2 双中台实战案例<br /> ·<img src="https://i-blog.csdnimg.cn/blog_migrate/ad6da268b613c57fb0a68c809f.png#pic_center" alt="在这里插入图片描述" /></p>
讯享网
添加图片注释,不超过 140 字(可选)
业务中台的底层是数据存储层,可以根据公司业务量的大小,选择合适的数据库存储。
· 再往上一层就是业务中台的核心部分,其包括多个“中心”,是可以扩展的。

讯享网

添加图片注释,不超过 140 字(可选)
从下往上看,第一层是数据采集层。
· 第二层是数据计算层。
· 海量的数据采用传统的存储方式是不合理的。业界一般采用分层建模的方式来存储海量数据。数据的分层主要包括操作数据层(Operational Data Store,ODS)、维度数据层(Dimension,DIM)、明细数据层(Data Warehouse Detail,DWD)、汇总数据层(Data Warehouse Summary,DWS)和应用数据层(Application Data Store,ADS)等,通过分层建模可以令数据获得更高效、更科学的组织和存储。
· 为了保证数据指标的准确性和无歧义性,企业内部的数据指标需要通过一套严格的数据指标规范来管理,包括指标的定义、指标的业务口径、指标的技术口径、指标的计算周期和计算方
· 式等。
· 第三层是数据服务层。
· 一般以接口的形式对外提供服务,开发人员将计算好的数据根据需求封装成一个个的接口,提供给数据产品和各条产品线调用。
· 第四层是数据应用层。数据产品分为几种:针对内部的数据产品、针对用户的数据产品、针对商家的数据产品。
1.3 数据中台人员构成
· 一个典型的中台组织架构如图1-5所示。中台一般会由公司高层直接主管,高层的下面是中台负责人,其充当部门总监的角色,统一管理公司的业务中台和数据中台。
· 
添加图片注释,不超过 140 字(可选)
一个数据中台的项目需要10种不同角色(包括数据中台负责人在内)共同参与,如图1-6所示。
数据中台的人员构成:

添加图片注释,不超过 140 字(可选)
1.4 数据中台开发流程
· 数据中台完成一个指标的开发需要经历11个步骤,分别是业务口径梳理、技术口径梳理、原型设计和评审、模型设计、数据开发、后端开发、前端开发、联调、测试、上线、迭代。
· (1)业务口径梳理。这个步骤应该由数据中台产品经理来主导。产品经理需要与提出该指标的产品/运营负责人沟通,要问清楚这个指标有什么用、给谁用、业务流程是什么,还要确定指标定义、统计周期、计算方式等。
· (2)技术口径梳理。这个步骤由模型设计师主导。
· 首先,模型设计师需要理解数据指标涉及的业务逻辑,还需要理解指标定义、统计周期、计算方式等。接着,模型设计师需要与产品线的开发人员一起梳理数据指标涉及的表结构和字段,这个工作比较重要,一定要精确到字段级别,
· (3)原型设计和评审。这个步骤还是由产品经理主导的。基于运营的需求设计原型,在原型设计完后,要经过内部评审和外部评审。
· (4)模型设计。这个步骤由数据中台的模型设计师主导。
· (5)数据开发。这个步骤由数据开发工程师主导。首先,数据开发工程师要和模型设计师确定技术口径,明确计算的指标都来自哪些业务系统。接着,数据开发工程师通过数据同步工具将数据同步到ODS层,并一层层地汇总,从ODS层到DWD层,再到DWS层,直到最后把可以直接服务应用的数据填充到ADS层。
· (6)后端开发。这一步骤由后端开发工程师主导。后端开发工程师基于产品经理对功能的定义,输出相应的接口给数据中台的前端开发工程师或产品线的前端开发工程师。
· (7)前端开发。这个步骤由前端开发工程师主导。在原型设计出来后,产品经理会让UI设计师基于产品功能原型设计UI。
· (8)联调。数据开发工程师、前端开发工程师、后端开发工程师都要参与这个步骤。
· (9)测试。这个步骤由测试工程师主导。
· (10)上线。运维工程师会配合数据中台的前端开发工程师、后端开发工程师将最新的版本更新到服务器中。
· (11)迭代。数据指标上线后,随着公司业务的变化,指标的口径可能也会有所变动,所以也要定期盘点已有的指标,如果指标有变化,需要不断迭代,保证指标的准确性。
1.5 数据中台内外合作机制
· 数据中台与其他业务部门的合作主要包括以下几方面。1.业务口径和原型确认
· 2.与各条产品线建立月度沟通机制
· 3.建立日常沟通微信群
· 4.建立规范的取数流程
· “双周迭代计划”的数据中台内部项目管理流程,
· (1)每月制订月度计划,设定月度目标。
· (2)每两周迭代一次,完成月度目标。
2.1 数据采集的分类
· 数据中台要采集的数据分为两种类型,一种是用户行为数据,一种是业务数据。
· 业务数据一般存储在业务数据库或者业务中台中,业务数据库一般存放产品线的个性化的业务数据,业务中台一般存放通用的业务逻辑数据。
2.2 用户行为数据采集
· 用户行为数据的采集有如下三种方式。(1)与第三方移动应用统计公司合作完成数据采集。(2)采用前后端埋点结合的方式完成数据采集。(3)采用可视化埋点与后端埋点结合的方式完成数据采集。
2024/07/18 发表想法
前端埋点主要处理和记录用户与界面交互的行为数据。客户端埋点则涉及在本地客户端(如手机应用内)记录数据。而后端埋点则关注于服务器侧的数据记录,这通常包括用户请求的处理和响应数据。前端埋点重在实时性,后端埋点在数据安全性和整体性上有优势。
原文:前后端埋点
· 第一种方式是与第三方移动应用统计公司合作完成数据埋点。
· 埋点有两方面作用。一方面,针对前文提到的“弄清主路径”问题,需要监控“加购”事件。
· 另一方面,如果我们要看关键按钮的点击次数、关键页面的转化率(如登录页、注册页转化率等),就都需要统计按钮点击事件。
2.3 数据采集流程
· 
添加图片注释,不超过 140 字(可选)
第一步,前端工程师通过异步HTTP接口的形式将埋点数据发送到Ngnix服务器,通过Ngnix做负载均衡将日志文件采集并存储起来。第二步,通过如Flume之类的日志采集工具将埋点日志文件以消息的形式发送到Kafka集群。第三步,数据中台通过订阅Kafka集群的日志消息将日志文件存储在数据中台。
· 

添加图片注释,不超过 140 字(可选)
(1)业务数据库产生的业务数据一般存储在关系型数据库(如MySQL、Oracle等)中,存储的过程会产生Binlog日志文件。
· (2)Kafka MySQL CDC Connect读取了业务数据的Binlog文件后,通过CDC(Change Data Capture,意为“变动数据捕获”,是增量抽取数据解决方案之一,能够帮助识别从上次提取之后发生变化的数据)的方式将业务库变动数据记录到Kafka等下游来消费。
· (3)可以通过Python语言在Kafka消费基础上做一个调用,将生产者产生的数据消
· 费到Hbase。这样当MySQL中有相应操作时,Hbase便会同步。
3.1 数据指标的定义
· 要想实现数据中台项目,我们要做的第一件事就是梳理公司的数据指标体系。
· 将一个数据
· 指标拆解到不能再继续拆解为止,这样就能够最大限度地保证大家的理解无误。
· (1)业务板块:即面向业务的大的模块,就是公司的产品线,不会经常变。
· (2)数据域:数据所属的领域。
· (3)业务过程:完成某个业务所涉及的全部过程。如电商业务中的下单、支付、退款等环节都属于业务过程。
· (4)时间周期:就是统计的时间范围,
· (5)修饰类型:对修饰词的描述。如电商中的支付方式、终端类型等。
· (6)修饰词:除了维度以外的限定词,
· (7)原子指标:即不可再拆分的指标,
· (8)维度:是指度量单位,用来反映业务的一类属性。常见的维度有地理维度(国家、地区等)、时间维度(年、月、周、日等)、订单的维度等。
· (9)属性:隶属于维度。如地理维度中的国家名称、省份名称等都属于属性。(10)派生指标:一组对应的原子指标、修饰词、时间周期就组成了一个派生指标,
· 数据中台的大部分工作是开发数据指标,并能够识别出哪些指标是虚荣指标,哪些指标是可以促进增长的指标,后者显然比较重要。比如常见的PV、UV、月活(即月活跃用户数)、总用户数、总商品数等指标都是虚荣指标
· 那些和公司的增长无关且从中很难看出公司问题的指标一般都是虚荣指标,
3.2 数据模型设计
· 数据库和数据仓库虽然都是用来存储数据的,但数据库是用来存储业务数据的,而数据仓库是用来存储汇总后的报表数据的。
· 第一层是ODS层和DIM层。
· ODS层的作用是在业务系统和数据仓库之间形成一个隔离层,在数据中台进行计算任务时,可以以ODS层的数据为基础进行计算,从而不给业务数据库增加负担。DIM层存储的是维度数据,如城市、省份、客户端等维度的数据。
· 第二层是DWD层。
· 一般基于ODS层和DIM层的数据做轻度汇总。DWD层存储经过处理后的标准数据,需要对ODS层数据进行再次清洗(如去空/脏数据、去超过极限的数据等操作)。
· 第三层是DWS层。DWS层数据是数据仓库的第三层数据,是以DWD层的数据为基础进行汇总计算的数据。
· 第四层是ADS层。ADS层数据是数据仓库的最后一层数据,以DWS层数据为基础进行数据处理。
· 如果采用分层建模,第一步是将业务数据库的数据同步到ODS层中,将维度数据存储在DIM层中,第二步是通过DWD层丰富统计指标的维度,
· 第三步是在DWD层中汇总各个维度的交易额,第四步是基于现在的需求,计算出产品线A的当月交易额,在ADS层提供要显示的数据。
3.3 数据模型设计实战案例
· 数据模型设计的第一步就是要了解产品功能涉及的业务流程及数据存储情况。
4.2 标签平台快速入门
· 标签平台的建设目标也比较清晰了,具体如下。(1)数据中台的标签平台需要能够为多条产品线、多种角色打标签。(2)一个用户如果在多条产品线中产生了行为数据,都要通过标签记录下来,且标签可以被看到。(3)公司内每条产品线都可以定义自己产品线的个性化标签,但产品线之间互不受影响。(4)标签平台不但能给注册用户打标签,还能给潜客打标签。
基于这四个目标,我们的标签平台规划了以下这四个功能。(1)数据宽表功能。用来存储用户、商品等所有的指标。(2)标签体系功能。将各条产品线共用的标签和非共用的标签,按照统一的层级结构组织起来。(3)标签工厂功能。可以基于规则选择指标生成标签。(4)人群圈选功能。通过不同标签组合形成人群。该功能一般与推送、营销系统对接。
· 搭建标签平台的第一步是制作数据宽表。
· 宽表其实就是单个用户(采购商或供应商)的商品的所有指标以及基础信息的合集。
· 生成标签的步骤如下:
(1)选择平台。
· (2)选择维度。
· (3)选择一级标签和二级标签。
· (4)定义标签。
· (5)设定标签的计算规则。
4.3 用户画像
· 用户画像可以全方位地展示用户的所有信息
· 群体用户画像的作用是通过数据挖掘群体的特征,当知道各条产品线有哪几类的用户时,运营目标才会更加清晰。
· TGI即“目标群体中具有某一特征的群体所占比例/总体中具有相同特征的群体所占比例×100”。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容,请联系我们,一经查实,本站将立刻删除。
如需转载请保留出处:https://51itzy.com/kjqy/159217.html