一、前要
内容包括但不限于平台对内和对外的需求、代码开发、测验和上线流程规范。
以大数据技术平台架构的视角，梳理如何与数仓、数据分析同学协作的规范示例，仅供参考。
二、环境信息
首先需要梳理出各组件的部署方式、host及版本等信息，让其他平台、数仓或数据分析同学了解平台底座的部署情况。
三、需求流程
3.1 主流程
整体需求主流程如下。
3.2 需求发起
3.2.1 需求发起人
包括但不限于如下人员。
- 数仓开发
- 数据分析
- 数据产品
- 内部人员（主动挖掘）
3.2.2 需求类型
- 业务需求：需要通过组件支撑的业务需求，例如应用脚本开发
- 组件功能需求：组件功能扩展，例如connector扩展或造轮子
- 组件bug需求：由于组件设计缺陷或版本自身缺陷导致的bug，需要结合社区和源码进行解决
3.2.3 需求渠道
- Tapd/DevOps/禅道（协作管理平台）
- 主要为组件bug需求，例如提交地址：数据平台_线上BUG汇总
- 飞书/钉钉/企业微信（企业办公平台）
- 主要为紧急且重要的问题/需求，可通过DA（数据需求入口群）、问题群或私聊反馈（允许私聊/私活，但需要内部互通，避免信息差），当前相关问题会记录于统一锚点：新集群问题记录
- 线下沟通
- 较为繁杂的需求可通过线下沟通，需要进行拆解和确认，例如：数仓需求记录
3.2.4 需求对接人
如果团队当前还处于发展中未成熟阶段，不建议采用【统一对接人】的方式，可采用【一主多从】的策略，即除团队负责人外，其他成员都可以为’需求对接人’，但无论谁是’需求对接人’，都需将需求记录于【需求池】，避免信息差。
- 团队负责人
- 组件责任人
- 每个组件的管理（技术支持/答疑）需要指定第一责任和第二责任人
- 需求池
- 对需求的记录，避免需求丢失，有助于建立清晰的需求回溯，需求池记录列表：大数据平台需求池
3.3 需求处理
3.3.1 内部评估
- 对于可快速响应和处理的小需求可跳过这步及后续的流程，例如doris因为大sql内存oom而导致读写失败的问题
- 对于无法快速响应和处理的需求，需要由对接人组织临时会议，进行内部评估，例如doris升级事项
- 内部评估需要确认事项
- 需求是否合理及是否需要进行后续处理
- 明确需求优先级
- 明确需求处理人
3.3.2 计划排期
- 由需求处理人根据需求优先级进行排期，并反馈给内外部相关人员
3.3.3 方案评审
- 由需求处理人输出方案，方案形式可采用列表、123陈述、流程图或文档形式
- 对于复杂需求/项目可先后输出概要和详细方案，例如需要自研中间件或应用系统底座等
- 由需求处理人组织，评审方式可在座位上或会议等形式进行
- 参会人员必须两人或两人以上，视需求而定是否需要拉上发起人
3.3.4 开发交付
- 根据排期时间进行开发、测试及交付，如若因其它紧急事项需优先处理，可协调顺延
- 具体流程参考如下【开发流程】
四、开发流程
包括开发、测试和上线流程。
4.1 开发
- 如果有概要或详细方案设计（流程图），需严格遵循
- 按排期进行开发，每周或隔天进行进度反馈，避免信息差
- 对于公共工具类和api，可建立私有maven仓库进行统一管理
- 开发完的程序无法通过测试，则需要即刻进行返工重新发起后续流程
4.2 Code Review
- 随着时间推移，组件改造、脚本或api等开发代码量会越来越多，代码review需重视
- 促进团队技术氛围
- 提升代码质量及统一规范
- 避免’当局者迷’和’重复造轮’现象
- cr环节需要耗费一定的时间，故排期时需要包含cr的时间
4.3 测试
- 需输出相应的测试用例，包含但不限于自测、联调、场景验证和读写压测等
- 用例形式不限，可通过列表、123陈述、流程图或思维导图的形式输出
4.4 上线
- 上线流程需遵循【运维规范】
- 涉及组件内容变更（bug修复、参数调整、组件升级和重启等）需提前发出公告
4.4.1 升级公告示例
[喇叭][喇叭]【Doris Be2.0升级通知】 @人员 变更时间：2023-08-08 12:12 至 2023-08-08 13:13 变更类型：BE滚动升级 变更版本：1.2.6-release升级至2.0-roc3 变更内容：仅升级BE 变更原因： 1. 引入workgroup和倒排索引等2.0新特性 2. 使用新优化器提升整体查询效率 3. ...... 测验结果：升级前测试报告 回滚策略：无 预计影响范围：doris上游任务可能会存在闪断
4.4.2 调优公告示例
[喇叭][喇叭]【Dolphinscheduler调优通知】 @人员 变更时间：2023-08-08 13:13 至 2023-08-08 14:14 变更类型：调优重启 变更内容： 1. datasource调整为druid 2. 默认连接大小由50调整为100 3. 新增ldap模块，ds登录改为sso账号密码登录 预计影响范围：所有ds调度任务（重启后自动重试）
4.4.3 重启公告示例
[喇叭][喇叭]【Doris Be紧急重启通知】 @人员 变更时间：2023-08-08 00:00 至 2023-08-08 01:01 变更类型：重启 变更内容：无 变更原因：进程假死 预计影响范围：doris上游任务可能会存在闪断
4.4.4 完成公告示例
【XXX完成通知】 完成时间：2023-08-08 08:08 完成结果：升级完成/调优完成/重启完成 完成说明：顺风顺水顺财神
五、开发规范
5.1 数据库
- 拒绝select *
- 所有表都需要添加注释
- 临时库/表名必须以tmp_工号为前缀
- 根据需求取舍选择范式或反范式设计
- 库名、表名和字段名禁止使用保留字段
- 库名、表名和字段名必须使用小写字母，并采用下划线分割
5.2 JAVA
详细可参考阿里Java编码规范 。
5.2.1 命名
- 类名使用UpperCamelCase风格，但以下情形例外：DO / BO / DTO / VO / AO / PO等
- 常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长
- 方法名、参数名、成员变量、局部变量都统一使用lowerCamelCase风格，必须遵从驼峰形式
5.2.2 常量
- 不允许任何魔法值 （ 即未经定义的常量 ） 直接出现在代码中
- long 或者 Long 初始赋值时，使用大写的 L ，不能是小写的 l ，小写容易跟数字 1 混淆，造成误解
5.2.3 注释
- 谨慎注释掉代码；在上方详细说明，而不是简单地注释掉；如果无用，则删除
- 类、类属性、类方法的注释必须使用 Javadoc 规范，使用/*内容/格式，不得使用 // xxx 方式
5.3 Git策略
如图所示，主要分3类分支
- prod/online：生产发布的唯一出口分支。
- test/pre：测试/预上线分支，从prod/online拉取代码。
- feature：需求或新特性开发分支，从prod/online拉取代码。
5.4 Code Review
- 测试前需进行cr，或者同步进行
- 对每次的merge request都进行cr，即mr即cr，避免mr堆积
- cr时可先输出代码的主流程图，事半功倍
- 小需求私下review
- 可2~3人到电脑旁review
- 先讲需求再review
- 核心流程会议review
- 主要review流程，让参会人员都熟悉流程
- 其次再review核心代码以及配置相关的内容
大数据平台开发规范示例分享至此结束，查阅过程中若遇到问题欢迎留言交流
