网校分钟级数仓体系建设与价值探索
一、背景与名词解释
数据已经被当作一种生产要素在日常的经营活动中扮演着无可替代的地位，作为数据的中枢和底座，数据中台一直致力于为全公司提供高效高质的服务，提升数据价值。本文简要介绍了数据中台网校实时数仓团队近半年来基于此目标所作的一系列努力和探索。为了方便读者理解，以下是一些名词解释：
数仓：数据仓库简称
分钟级数仓：当前业内实时数仓的一种解决方案，比较契合当前公司主要业务场景，在高可用、高性能上都有不俗的表现
“三高一低”：数据团队内部的指导思想，指”高效率、高质量、高稳定、低成本“
天枢：内部BI平台，数据分析可视化平台
/////
二、数仓价值思考
假设总体成本不制约日常数据生产活动情况，数仓价值可以简单替换成如下公示：
数仓价值 = 指标单位价值 × 指标个数 × 指标平均生产效率× (1-指标获取成本系数) × PV × UV
（注：公式更可能的将多种正、反因素结合再一起思考，不作严谨的数学讨论）
关于指标获取成本的解释：
根据这个公式我们有以下有助于提升数仓价值的推论：
●优先做高价值需求
●领域指标越丰富越好
●指标的生产速度越快越好
●保证指标的及时触达
●保证指标的易于理解
●提升指标的曝光度（模型说明、数据字典、渠道）
●增加指标的使用人数
归纳为两条数仓价值主线：
1.数据生产（价值创造，产生基础价值）
2.数据运营（价值输出，放大价值）
以上同时契合“三高一低”的指导思想，实时数仓近半年的工作大多都是围绕此展开，下面进行介绍。
/////
三、实时数仓半年来相关工作
3.1 确立分钟级数仓为实时数仓整体架构
主要基于以下两个理由：
更多内容可以参考网校实时数仓建设实践,关于分钟级开发步骤介绍可以参考分钟级数仓项目开发手册。当前我们已经将续报、转化、行课、实时销量等重要场景全部迁移到分钟级数仓，运行平稳。
3.2 设计质量保障方案为稳定生产保驾护航
采用新架构后我们也遇到了很多困难，一个痛点是作业链路经常性的不稳定，导致出过一些事故，我们对平台工具的期望大大超过平台能给予的响应速度（“业务快于生产，生产快于监控”）。为了保障业务生产，我们独自设计质量保障方案。
如下为当前全链路监控全景图（任务状态监控为最基本监控默认已全部添加）
我们采用更多数据内容上的监控来兜底更多可能的异常情况，简单介绍一下：
基础监控
（自适应任务和表的新建和删除，自动监控）
●ods一致性监控：监控业务库同步到数仓ods的数据是否出现延迟，ods数据是链路的顶级，这个监控非常重要。
●最新批次是否生成监控 & 数据最大更新时间监控：监控CDM层和ADS层任务是否出现延迟和异常。
进阶监控（手动）
●指标监控：对重点指标的进一步监控
●离线和实时兜底监控：相同口径下的实时指标和离线兜底的T-1日监控
我们整合现有资源，通过和后端团队合作，完成上述方案的落地，最终实现自动化监控（监控覆盖率自动100%），已经长期平稳运行。通过上述方案，在工具侧逐渐完善的这段空窗期，我们保障了正常生产的平稳、有序进行。
自动化监控的实现简易图：
3.3 从0到1开创实时数据治理建设体系的先河
主要交流下稳定性（高可用）上面的我们的治理经验。
3.3.1指导思想
上图来自“三高一低”指导思想中高稳定部分，基于此和产品、业务共创的事故定级标准。
看板事故定级：
3.2.2如何着手
问题思考上以指标为抓手，问题解决上以系统工具落地为根本解决方案；方法论上主要基于OSM（Objective & Strategy & Measure）和PDCA（PLAN&DO & CHECK & ADJUST）两套方法论。OSM用来分析和解决问题；PDCA用来持续迭代更新我们的方法论、工具等。
以下是我们的一个拆解过程：
关于稳定我们的思考是：
1.SLA内不发生问题
不发生问题的定义是尽量降低事故发生的频率，在问题初期就及时解决和治理，提高稳定性。
2.SLA内及时解决问题
属于补救措施，依赖定位和解决问题的速度，和问题的多寡（问题尽量事前解决）、难易度。
稳定性相关因素：
●主体
含义：一般是指执行的代码、脚本，是逻辑实体。
影响稳定性的因素：口径、人为引起的bug、作业资源使用不合理、效率低等。
●客体
含义：一般是主体所依赖的其它实体，例如环境、资源和工具等，具体来说包括：
生产工具，例如T系列等平台工具
存储、计算引擎（yarn、holo、hive、hdfs）
影响稳定性的因素：工具、网络、计算引擎是否正常
目前数仓能够量化的指标有：
北极星一级指标：破线（故障）率、S0事故个数
一级指标是最终的观测和结果指标，一级指标直接和目标（无S0事故）挂钩
北极星二级指标：cpu和内存（水位）是否正常、监控覆盖率、监控配置合理率、历史重复问题个数
二级指标是我们的过程监测指标，是我们为了实现一级指标所做的拆解，要考虑二级指标完成是否能够完成一级指标的充分条件。
关于暂时无法量化的，我们只能作一些针对性的改进，使之逼近期望的目标，以下是计划中或者已经完成的相关改进点：
●重保期间稳定性保障方案
●上下游多级协同保障方案
●DQC报警中的地址链接是任务的日志链接
●报警只显示error等关键信息
●建立问题知识库
要求运维、平台和阿里（外部）保持随时良好的沟通环境，保证有问题能够随时协助解决
同时考虑到当前是基于以数仓作业的问题来作为整个中台架构系统的反馈链路，对于非数仓问题如何推动工具侧和运维侧提升其稳定性和针对问题的响应速度以及解决问题的效率也是一种路径：
3.3.3 稳定性成果展示
稳定性治理上的成果
●月度S0事故逐渐收敛：7个（8月） -> 4个（9月）-> 0个（10月），7月份相关指标才开始记录，收敛的主要原因是数仓及时发现和解决问题，以及平台工具问题的收敛。
●常态化治理的抓手，积累治理经验后续直接转化为平台工具。
以下截图展示了是我们治理过程中的一些看板工具
（a）稳定性看板，9月份事故为例
（b）监控覆盖率 & 配置合理率看板
（c）慢query和慢任务治理
3.4 在进一步释放和扩大数据价值的努力
如何让一份数据更容易触达到客户，和触达到更多的客户？在提升数据易用性，提升数据的曝光和放大数据价值上我们是这么思考的，并也作了很多努力。
3.4.1 支持多种数据链路触达方式
当前在计划中和已经实现的实时数据输出方式有：
●BI（分析平台工具、例如天枢）
●Kafka
●T-query
●T-service
3.4.2 建立分钟级数仓开发规范
为了提升数据易用性和一致性，我们首先重新定义和整理了数仓开发规范，具体细节参照文档。
3.4.3 数据字典
同样目标于提升数据易用性，保证数据出口的一致性，相似于T-Meta（数据中台自研的数据管理工具），只是从指标出发，可以理解为指标管理的查询和管理部分，通过以指标为入口和提供更多指标相关的信息，方便用户找到想要的数据。
与产品共创的数据字典方案
3.5 数仓价值的外化
对于自己的工作我们也做了思考和量化，帮助我们思考我们做的怎么样，如何做的更好。
3.5.1 数据生产的成果
我们有清晰的数据资产全景图（主要实体包括：数据服务、数据模型、数据任务、数据指标以及之间的各种关系），相较于T-meta会整合更多信息，支持数据开发人员和数据使用人员两种不同角色的使用，见数据资产。
3.5.2 数据运营的成果
数据治理等运营成果的外化，评估我们在数据治理上的目标和进度。例如以下在周期内的一个治理成绩的总结性展示：
“破线率降低多少”
“S0事故由
多少降低为多少”
“监控覆盖率提升了多少”
/////
四、总结
至此我们实现了一套完整的分钟级数仓从数据生产到数据运营的系统解决方案，不仅当前保障了我们链路运行的平稳，同时后续作为分钟级数据仓库的方法论可以快速的在工具层上实现，赋能于其他分钟级数仓团队。当然我们仍然还有很多之处，但是我们会努力做到更好！
/////