大数据团队规范准则
2021-07-08 14:25:30 1 举报AI智能生成
登录查看完整内容
大数据团队规范准则，包括管理理念，开发规范，数据设计规范，报表开发规范，常用指标梳理等
作者其他创作
大纲/内容
不要怕麻烦
可以慢，但不能漏
不急不噪一步一步最省事
目的：使人人都熟悉业务
大数据团队规范准则
公共规范
git使用规范
常用命令
git add
git commit -m \"\"
git pull
git push
git branch
git status
git diff
git reset
git tag
git checkout
常用分支
master
dev
release
使用原则
master永远是稳定的上线代码分支
dev是能稳定运行的，包含所有最新功能的代码分支
每人开发功能时都要从dev，checkout一份分支，并对这个新分支根据tb的story命名，开发完毕且验证无误后合并至dev
当整个项目开发完毕后从dev合并至release进行整体验证
如果验证有问题，责任人再从dev分支checkout下代码修复
当release验证完毕后合并至master分支
此时基于master分支打tag标记相关版本然后依据此tag上线
打点规范
埋点流程
需求确认
埋点规划
埋点确认
前端埋点及自测
自测通过
大数据验证
问题点位提醒各端修正
自动备份
字段拆解
page页面的命名
英文以下划线_分割
尽量短，但不要简写缩写
如果是活动要以act_开头
event页面的命名
通用按钮以button_click命名
APP版本打点param公共参数
uid
tz
app_version
活动打点param公共参数
code
platform
cms_id
activity_id
规划点的时间，2081221_活动英文
page_share
resource
param里的type类型取值书写规则: key1=value1;key2=value2
数据流向
子主题
敏捷开发
什么是完成
完成
是指可上线状态。编码完成，测试完成都不能算是完成，只有经过验收，达到可上线状态才算完成
谁来整理任务
自己（包括团队）的任务自己来整理，根据工作进展改变状态，不是靠leader，如果自己搞不定，主动找人帮忙。
关于说“是”
说“是”意味着承诺，口头上说，心里认真，付诸行动。言必行，行必果。
承诺意味着按时交付高质量的产品，不能打任何折扣，不能省略任何工作环节，比如：Code Review等。
如果开发过程中，有特殊情况使得承诺不能兑现，尽快通知到相关同学，越快越好。
我们的底线
遵守编码规范
做Code Review
做单元测试（视项目紧急程度决定是否执行）
做接口测试
做压力测试
做模块测试
做集成测试（测试环境、gamma环境、生产环境）
做回归测试
数据验证
产品验收
Sprint流程
Sprint流程为：待处理—开发中—模块测试—集成测试—待发布—云测—灰度测试—完成。“云测”和“灰度测试”是可选项，根据实际情况来定。
各阶段定义：
待处理：还没开发的story。
开发中：正在开发的story
模块测试: 模块测试是由开发工程师交付给测试工程师后进行，模块测试之前，开发工程师要完成自测，要将代码从feature分支经过Code Review，进入dev分支。模块测试由测试工程师进行。
集成测试：完成“模块测试”（针对Story或任务的测试），等待“集成测试”的Story。
待发布：完成接口测试、性能测试，测试环境和gamma环境测试的测试，等待上线的story。
云测：云测在生产环境进行，包括：兼容测试、探索测试，云测不是必选，每个版本根据实际情况可选择进行那种测试。
灰度测试：灰度发布测试。
完成：完成上线工作。
Story/任务
每个story是完整的最小可独立开发、测试、运行的单元
Product Backlog(需求池)里大的story（epic），在sprint开发时可以拆分成几个小的story。如：凯叔任务集成到APP，是一个大的story（epic）， 在Sprint开发时，分解成3个story
StoryID：Story都有自己的ID，如：“APP_60”
Branch：每个Story 都有自己的branch。
测试用例：Story的测试用例，要增加StoryID的标记，根据测试用例能查到本用例是关于哪个Story的。
Bug：Jira提交bug时，Story相关的，标题要以StoryID为前缀，如：“APP_60:xxx”。
Story子任务：
Story的功能，各端以子任务的方式列在story里，主要有三种：开发，测试，数据，验收。
开发：各端为独立的子任务，“Android”，“iOS”，“H5”，“后端”单独列自己的子任务，子 任 务 名 称 以 各 端 的 简 写+“：”为前缀，比如：“Android：”，“ 后 端 ：”。
测试：测试用例编写，功能测试（测试环境、gamma环境、生产环境的测试）、接口测试、压力测试，测试子任务名称以“测试：”为前缀。
数据：对于数据需求的验证，对数据结构（表结构）变更的确认。
验收：产品参与，要review测试用例执行情况。
执行人，开始时间& 结束时间
对进行中的每个Story、任务、子任务都需要填写执行人，“开始时间”和“结束时间”。Story的结束时间，完成所有子任务的时间。
开发子任务
技术评审
每个开发子任务需要经过技术评审，技术评审需要团队Manager、架构师参加，完成后由manager或架构师进行勾选完成。技术评审根据实际情况，可以在迭代开发之前统一做，也可以每个story单独来做。技术评审阶段，要对工作量进行评估。
单元测试
Code Review
故事点（StoryPoints）
工作量估算：敏捷估算不是以时间为单位，而是以故事点为单位，是个数字，没有单位。现阶段：1个故事点=团队1天的工作量来定义。
计算：StoryPoints：Story Points的计算包括Story内从任务开始到完成“模块测试”所需要的点数。
迭代：每个迭代所有story的story point加起来就是每个迭代的总故事点。
故事点写在Teambition的任务卡片上的“Story Points”
谁来写？Story的团队成员一起商量来写，Master统筹
团队速度：固定时间完成的故事点数
每日站会
为什么要开站立会
个体交互重于过程和工具
面对面的沟通：微信邮件不如当面沟通。
过程透明：了解真实情况，然后进行检查和调整。
三个问题
我完成了什么？
我打算做什么？
我遇到的障碍或者困难是什么？如果没有障碍可以说改进和提升的方法。
规则
站着开：精力集中，不懒散。
时间不超过15分钟
同一时间，同一地点。
只管挖坑不管埋：master记录问题，会后组织相关同学专题讨论解决。
不是汇报工作：面向团队成员发言。
回顾会
团队在迭代结束后，开回顾会。
总结经验教训，不断完善提高
环境定义
开发dev环境：用来进行开发、自测、联调，完成后交付给测试。
测试test环境：测试同学用来做模块测试和集成测试，
Gamma环境：上线前的最终验证，不做测试，由运维操作。
生产环境: 线上运行
谁来负责质量
质量是由开发工程师来负责的，开发工程师是第一责任人，不是测试工程师，也不是运维，开发工程师可以调动/协调测试、运维工程师等资源来保证代码质量
开发工程师要加强“测试用例review”环节，在测试工程师的协助下，保证测试用例的覆盖率。
工程师为自己代码质量负责，开发小组的master为本小组的任务质量负责。
开发工程师要加强自测，在交付测试之前，要按照测试用例完成自测，不能等着测试工程师提bug，再解bug，开发工程师最了解代码，要站在排除bug的第一线。
所有的开发任务需要在Teambition里创建Story或任务
所有开发任务需要有story，有了story，测试才会跟进，测试用例才会覆盖到，否则会被漏测。
不能在一个story里修改和story不相干的代码，因为测试用例有可能覆盖不到，会导致漏测的情况。如果需要修改其他模块的代码，需要另建story。
分析常用指标
PV
UV
DAU
MAU
留存
转化率
ROI
ARPU
ARPPU
渠道评估方法
预测方法和模型
用户流失率
用户生命周期
用户使用时长
付费计算方法
新用户定义
算法与挖掘
报表开发
仪表盘开发规范
仪表盘每个指标都要有备注内容
制作人
制作时间
适用场景，比如指标只适用于活跃用户大于>30天的
各个指标的算子说明，用户数: count(distinct uid)
答疑：即使描述清楚了也有人有各种疑问，把问题记录在此。
工作表
命名
表性质_实际业务需求_开发者
表性质
长期需求：ks
临时需求：tmp
默认两周，两周后删除
测试表：test
实际业务需求： 业务_限制条件_指标
业务
播放
会员
活跃
转化
地域
画像
限制条件
最近N天活跃
仅会员
付费在N元内
参与过某活动
打开过某页面
购买过某商品
指标
最大值
最小值
平均值
付费金额
N日留存
周留存
月留存
日活
周活
月活
明细
完听率
复听率
工作表制作流程
报表制作
报表验证
需求方验证数据
发布仪表盘
内容增加备注
需求提出人，需求目的，需求内容
制作人，制作日期
修改时标记，修改日期，修改人，修改内容
高级设置
更新设置原则
不建议设置自动更新
老板看的表或者新功能和活动__重要程度: 高__时间3~5点
常规功能点__重要程度: 中__时间7点~13点
过时的活动或者临时表或者关注度没那么高的表__重要程度: 低__一般设置在14点后，或者暂停更新
关联策略
依赖更新的表如果有多个尽量设置成一个
增加知识
数据开发
数据开发流程
需求调研
需求评审
接口文档
设计表结构
程序开发
java开发规范
数据仓库
上线流程
sql文件提交git
sql文件导入中台
sql文件发布到oss
配置工作流
验证sql脚本是否正常
仓库层次划分
SRC (Source)：数据缓冲层；原始数据直接同步过来；保留的是所有的数据，理论上粒度和源系统保持一致，同时不丢数据，业务数据库基本上是直接同步过来，日志数据主要从OSS中取出阿里日志服务归档的打点数据。这一层数据保证我们在需要的时候能找到任何原始数据，是仓库数据完整性的一个保证。
ODS (Operational Data Store)：数据明细层；将SRC的数据经过规范化、标准化、解析后，存放到ODS表中
DW (Data Warehouse)：数据仓库层；将ODS层表，根据业务主题梳理建设，记录细粒度的数据，如打点日志跨表、订单宽表等。
MID：数据关联层，根据分析主题梳理建设，记录细粒度数据，如新增用户的订单数据。
APP：数据应用层，这一层面向具体的业务分析需求，主要为报表展示和数据提取，提供数据支持。
DIM (Dimension)：维度表，记录维度信息，参照参考内容的术语维表。
TMP (Temporary)：临时层，用来临时使用的表。
设计原则
公共处理逻辑和模型下沉原则：越是底层公用的处理逻辑更应该在数据调度依赖的底层实现。
成本与性能平衡：适当的数据冗余换取查询和刷新性能。
数据可回滚：处理逻辑不变，在不同时间运行数据结果确定不变。
一致性：相同的字段在不同表字段名相同，尤其是重要字段例如应用类型。
命名：表命名规范需清晰、一致，表名需易于下游理解和使用。
仓库命名规范
分区字段：p_date
分区表的表名必须要有特殊字符来进行标识
按天分区：_d
按周分区：_w
按月分区：_m
按季分区：_q
按半年分区：_hy
按年分区：_y
按小时分区：_h
非分区的关系数据库表，在SRC和ODS层表中 统一增加一个表更新字段（tab_update_time），用于标识表的更新时间
表名命名规范
命名格式
APP层：app_主题域_维度1_[维度2]...[维度n]..._调度周期，维度比较多的取主要和常用维度即可，不超过3个。
MID层：mid_主体主题域_XX_调度周期，例如以订单表关联其它表则主体主题域为订单order。
DW层（仓库层）：dw_主题域_XX_调度周期，例如以订单表关联其它表则主体主题域为订单order。
ODS层（明细层）：ods_来源库名_表名；若表名中已包含来源库信息，可不加；若来源库名较长，可缩写；因在不同数据库中，存在表名相同的表，需要用来源库名区分。
SRC层（缓冲层）：src_来源库类型_来源库名_表名；若表名中已包含来源库信息，可不加；来源库类型m表示mysql，o表示oracle、mg表示mongodb、kf表示kafka、mq代表mq；若来源库名较长，可缩写
拼写规范：只能使用小写英文单词及其缩写、下划线('_')、和阿拉伯数字，字段只能英文字母开头。
分隔规范：采用下划线命名法，所有的独立单词都必须要用下划线('_')分隔。
字段命名规范
字段名组织：字段命名尽量与依赖的底表的相应字段相同，不要创造新的列名。
长度规范：建议整个字段的字符长度不超过64；每个单词长度不超过10个字符。
拼写规范：只能使用小写英文单词及其缩写、下划线('_')、和阿拉伯数字，尽量不用阿拉伯数字，不能使用拼音或者拼音的简写。
冲突限制：不能使用与Hive或者Mysql关键字、函数名相同的命名，不能使用'_'和数字开头。
区分要求：同一个表内有性质比较相近的字段时，需要明确区别，比如下单时间和支付时间，不能使用time1和time2这样。
Wiki维护规范
增加新表、修改表后，及时更新Wiki文档，包括表名列表和建表语句等。
仓库表和抽数脚本维护规范
仅仓库人员可以创建、修改SRC、ODS、KSDW三层的表和抽数脚本，其余人员可以创建、修改MID、APP、DIM、TMP四层的表和抽数脚本。
修改仓库表结构和抽数脚本前，需要先通知组内人员，包括ODS层、DW层、MID层；
抽数脚本开发规范
抽数脚本（.sql文件）要加上注释：创建人、创建时间、表名、表描述、修改时间、修改内容，需要在每个抽数脚本上方添加
建表规范
底层用外部表，上层用内部表。
分隔符
FIELDS _\\001
MAP_:
LINES_\
仓库开发
常用的窗口函数
sql转化为mapreduce、spark过程
处理数据倾斜的基本方式
udf、udaf、udtf的继承类分别是
0 条评论
回复 删除
下一页
