更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【1】进入官方交流群
随着字节业务的高速增长，业务场景越来越丰富，业务基于数据做的决策也越来越多，对数据的时效性要求也越来越高。原有离线批处理的数据仓库已经无法满足诉求，因此需要打造一套同时具备高时效性和高稳定性的计算能力快速完成对数据的处理，即实时数仓。
直播实时数仓团队隶属于Data-数据平台部门，负责为直播中台业务建设实时数据仓库，为业务侧数据产品提供实时数据能力。
高收益意味着高风险也同时存在，例如数据时效性方面更新延迟超过15分钟，就会有高客诉、甚至资损风险。
2023年之前，各业务实时数仓(直播/电商等)因发布流程问题引发了多起稳定性事故，历史case：2022年上半年直播实时数仓为了修复某份核心分钟指标，选择回补明细层数据的方式做修复，修复任务上线过程中缺少方案评审、影响评估及下游周知等流程，最终因明细层数据回补量级过大导致核心分钟指标产出延迟带来大量客诉反馈。
发布流程常见问题有测试验证缺失、影响评估不准确、上线意识不严谨、上线review随意等。期望有一套流程化工具，自动约束人为不规范操作，降低流程原因导致的事故数、甚至完全规避。
将发布划分为发布前、发布中、发布后三个阶段，对每个阶段的动作做细粒度拆分并分别制定规范流程，从而形成实时数仓任务发布SOP。
发布前-规范自查
- 发布前首先需要做测试验收，主要保证开发命名遵守实时数仓规范、数据产出质量(主要为正确性，与离线diff<0.1%)、任务运行稳定性(测试任务运行期间无延迟情况)。
- 测试验收完成后评估此次上线的影响，并判断是否需要提前周知下游。比如任务重启恢复一般需要3～5分钟、意味着数据更新会有短暂的更新延迟，需要评估是否要向下游依赖方周知。
- 最后整合发布内容、测试结果、影响评估结果等信息，在发布话题群中进行登记，如需周知下游的话手动艾特到下游POC同学。
发布中-复查管控
-
发布中首先会进行围绕代码参数和报警规则配置改动进行自动化巡检，辅助review同学进行code review。review同学分为业务review和技术review。
- 业务review关注业务逻辑，基于业务背景评估代码逻辑调整后的数据质量，并把控发布时间，核心任务发布时间为0～8点，非核心任务发布时间为0～19点(19~24点为业务高峰期)。
- 技术review关注任务稳定性，基于SQL语法、代码参数等评估任务自身性能、基于任务流量及依赖组件特性评估外部依赖环境稳定性等，保障逻辑变更后任务能够快速恢复并稳定运行。
发布后-恢复盯盘
- 发布后会需要从任务状态(Lag消除/Checkpoint状态等)、数据质量(流量波动/数据正确性等)、下游影响(组件稳定性等)三个方面做恢复盯盘，及时发现发布带来的异常影响。
- 如果有预期外的异常时，发布同学及时修复或回滚，并登记发布结果及失败原因(如有)。
阶段一：自研发布流程工具(Hermes平台)
- 实现思路： 发布SOP本身就是一套串行实施的流程，可以将发布上线环境进行流程化拆解为一个个节点，通过编排节点流程及状态机控制流程正常流转运作，从而实现自动约束发布上线流程规范性。
- 使用痛点： 实质上只实现部分流程工具化约束，Hermes和DataLeap平台存在割裂，一次发布流程中用户需要在两个平台上跳转操作，存在用户体验及操作成本问题。
阶段二：基于DataLeap开放平台
- 实现思路： DataLeap开放平台支持业务自定义扩展程序能力，扩展程序可以订阅DataLeap侧OpenEvent监听用户操作、通过OpenAPI与DataLeap进行丰富的交互实现用户行为管控，除此之外开放平台还提供将N个扩展程序以流水线的形式编排的能力。因此将Hermes平台的发布流程工具能力以扩展程序的方式落地到DataLeap，并且通过流水线的能力编排成完整的发布流程流水线，从而实现发布SOP人工约束->平台化自动约束。
- 产品使用流程：
业务背景： 以主播服务平台-直播大屏为例，为主播提供在线人数趋势、进房人数等互动指标和送礼人数、送礼金额等收入指标，主播在开播过程中会基于以上指标做直播策略的调整。
发布要求： 控制发布频率和发布时间降低业务影响，通过流程控制提升发布质量，保障数据时效性和正确性。
# 发布前-规范自查
-
测试验收：
- 模型和指标命名遵守实时数仓规范；
- 数据准确性验证：和离线数仓对应数据进行数据条数与字段值的验证，保障diff在预期内；
- 任务稳定性验证：测试任务运行期间消费无延迟、资源使用在合理范围内。
-
影响评估：任务重启恢复一般需要3～5分钟，直播大屏相关任务上线时就需要提前向下游依赖方周知：xx时间xxx需求上线改动可能会带来3～5分钟的数据更新延迟，请关注数据产品功能情况。
- 发布监测：围绕代码参数和报警规则配置改动进行自动化巡检，辅助review同学进行code review(业务review和技术review)。
- 业务review：关注业务逻辑，基于业务背景评估代码逻辑调整后的数据质量，并把控发布时间。直播大屏相关任务属于核心任务，发布时间为0～8点，此时间段内为业务低峰期、发布影响用户侧感知较弱。
- 技术review：关注任务稳定性，基于SQL语法、代码参数等评估任务自身性能、基于任务流量及依赖组件特性评估外部依赖环境稳定性等，保障逻辑变更后任务能够快速恢复并稳定运行。
# 发布后-恢复盯盘
- 发布后会启动自动盯盘服务，针对任务状态、数据质量等方面做恢复及影响盯盘，及时发现发布带来的异常影响并告警通知发布同学，发布同学收到盯盘告警时，可通过修复或回滚进行恢复。 例如：任务新增维表关联逻辑时使用不当导致数据倾斜、从而数据产出延迟，在盯盘时就能及时发现任务发布后产生的延迟情况并告警，发布同学收到告警消息后快速调整逻辑或者回滚，就能及时避免发布异常导致的事故。
- 发布结束后会推动发布同学进行结果录入，方便后期做发布质量分析、发现不合规的点做定向提升。
- 自22年9月以来，直播实时数仓因发布规范导致的事故数一直保持为0，在数据稳定性方面完成了比较高的目标。除此之外沉淀了一套实时数仓通用发布流程和规范，并通过Hermes+DataLeap开放平台的能力完全实现平台化、自动化，极大的降低规范人工约束/任务恢复人工盯盘的人力成本和出错率，避免发布规范带来的质量问题。
- 目前直播、短视频、电商及生活服务等头部业务的实时数仓团队都已完成接入实时发布流水线，通过实时发布流水线管控发布流程。
一句话描述：提供实时发布复查流程精细化管控，定时发布、顺序发布、发布异常快速发现及发布自动化回滚和发布变更自动周知等能力。