快⼿数据质量保障体系及在直播场景的实践 by彭文华
这是彭文华的第160篇原创，祝大家除夕快乐！
最近分享数据治理的内容比较多，实在是因为这里面值得吐槽的东西太多了。今天带你了解一下快手直播数据治理的内容，是已经财务自由的快手大佬杨钊老师的分享，主要内容是介绍快手的数据质量体系，以及在直播场景中的实践。看看咱平时看的快手直播数据到底是咋来的，又是咋做的直播数据保障的。
另外，我在挑战春节不打烊，每天都分享原创文章，欢迎加我个人微信：shirenpengwh，加入催更群，小鞭子催我快快写稿
快手数据质量保障体系
先放一个杨钊大佬的帅照镇楼：
杨钊大佬在数据治理领域经验非常丰富。上次分享的时候，讲的都是非常干的内容。前两天快手上市了，我这也是羡慕的紧呐！赶紧过来拍拍马屁，看能不能蹭一顿饭吃。
这就是快手数据质量保障体系。有些人很奇怪，这数据质量体系就数据质量体系了，为啥还加个“保障”俩字？
哥们，离线数据任务断了咱再跑一次就完事了，最多设置一个执行幂等，任务失败自动重跑就好了。只要不耽误第二天用，你爱跑几次跑几次。
但是直播不一样啊！这边榜一大哥正花钱打赏呢，你这些统计数据都必须得精准啊，要不用户还不疯了？所以直播的数据质量必须得保障！
其实数据质量保障这件事提出来，保障目标也就出来了。如上图所示，就是数据必须完整、准确、一致、及时。其实这几方面也正是数据质量控制的核心6性中提取出来的。
数据质量6性：
准确性：正确的描述对象；
合规性：以标准、合规格式存储数据；
一致性：同一指标数据值保持一致，不冲突；
重复性：同一数据记录保持唯一、不重复；
及时性：关键数据及时传送到目标位置；
完备性：确保该有的数据都有。
下面我们挨个看看快手是如何确保数据高质量的。
这是保证数据完整性的手段。咱集中看中间的保障策略，其中，有四块内容：
资源优化：计算和存储等资源的保障，这个可不能省；
质检：从记录条数和值域进行检查，这是数据质量监测惯用的方法。如果是离线数据，还可以对文件做hash，然后比对hash值就行；
测试：同质检部分；
应急预案：各种异常情况的预案，防止突发事件。这个应急预案后面有详细说明。
保障数据完整，主要是确保任务都执行完了，执行之后有没有数。所以对重复、正确的验证就比较少。目的不一样么。
这是保证数据准确性的策略，主要也是四大块：
指标管理：其实就是统一定义指标的含义、统计口径等信息，做到全局唯一、统一归口；
质检：检查主键重复、数值波动情况、指标下界。与数据完整性中的质检相比，准确性层面做的就细很多，指标波动过大、上下超限，都会被监测出来。依我推论，还会设定不同的区域，超多少黄灯，超多少是红灯之类的。
测试：主要做对比测试、主键重复、计算逻辑层面的测试核查。同样会很细，反复对比测试确保数据执行幂等，计算逻辑测试则是计算结果数据要与之前定义的业务逻辑保持一致，确保数据的业务表达准确、精准；
应急预案：同上，下文另行说明。
如果说数据完整和准确主要靠反复的质检和测试就能搞定，那数据一致就不是测试能搞定的了，这得从底层就开始设计好。因为即便是同一段代码执行两次，没做好执行幂等，结果也会是不一样的，更别说实时和离线两条完全不一样的代码、不一样的执行引擎了。那样肯定会导致直播的时候一个数，第二天复盘的时候又是另外一个数，这用户还不炸锅了？
数据一致性保障策略统一分四方面：
指标管理：确保同一个指标在不同场景中的定义一致；
模型规范：表命名、字段命名、含义必须完全统一。我们简单可以理解为：指标+模型=阿里的One Model。
质检：这里只需要做数值的一致性检测就行了。
应急预案：同上。
这是数据及时性的保障，这个就要多一些了，分为5个层面：
资源优化：分为资源保障、链路优化、任务优化，这个没的说，直播作为收入最大的来源，资源不放这类放哪里？不过咱也得做好资源的合理利用；
模型规范：层次调用，一方面做解耦，另一方面减少重复计算；
分级保障：设置调度优先级、资源优先级。这是在发生资源不足、热点问题的时候，优先保证重要业务数据的产出。这里有点微服务中的服务降级、隔离的味道。
质量演练：链路切换，快手设置了主链路、备用链路两条链路，一旦主链路发生故障，立刻切换备用链路，保障数据的及时准确计算好；
应急预案：降级预案、异常预案，这跟前面的分级保障加起来，就是微服务的服务降级、隔离、熔断、限流啊！齐活了！
说个题外话，虽然这几张片子里都提到了，但是最让人忽略的是组织保障。其实我认为组织保障才是数据质量保障体系中最核心的一环，因为很多公司压根就认为数据治理就是数据团队的内务，就应该数据团队自己搞定。
这一点快手就做的很好，请注意组织保障中的几个字“意识提升”，为这几个字，我得敬几位大佬一杯。以后还请在各种场合多多宣导此事，让那些老板们看看这件事情的重要程度。
数据保障体系的直播实践
前面都是理论层面、方法论的东西，我觉得你也能说出个1234来。理论说的再好，也得落到纸面上才行。杨钊大佬就拿“快手之夜”的直播数据后台保障来给大家讲讲怎么做的。
快手直播之夜的数据挑战还真是不小。同时在线人数315w，互动总量1.34亿。实时性和数据量倒是其次，关键的是参与方非常多，数据一致性要求就非常高了。还有，运营那帮家伙的脑洞简直是没有底线的，各种玩法能弄死你，计算逻辑能绕死你，没个高考140分以上根本算不明白。
快手之夜是10.30日，按照事前、事中、事后自然的分为三个阶段。事情最多的是事前阶段，最紧张的是事中了。
事前除了做好指标管理、链路梳理和资源申请之外，还要做双链路设计、压力测试、分级保障和应急预案。这就跟微服务中的服务保障非常类似了。我估计快手的开发团队也是全程陪同数据团队一起设计和开发的。毕竟，在快手直播的场景中，数据也已经是业务的一环了。
这就是双链路的设计。主链路和备用链路同时在跑，一旦发生故障，即刻切换备用链路。抽样的数据是用来做质检和测试用的。
技术选型Flink+Kafka+Druid，Flink的实时计算能力已经不用再夸了，Kafka是必备的，Druid凭借高并发实时导入，且导入即刻查询、查询亚秒级响应、可扩展至PB级别等特性，非常适合直播场景。至于什么不太支持关联、精准去重、不支持主键更新等问题在这里其实不算啥大毛病。
这是全链路压测的逻辑。业内压测一般也是分级分层的，先上个1倍量，再加到3-5倍，然后加到10倍量。之所以要加到这么大，是因为网民经常会抽风，一不小心就会有各种热点，头大。热点问题一直是各大公司非常恼火的事情。即便是到了2021年，各路明星一出事，微博照样挂。不是微博技术不行，也不是服务器不够，而是短时间几百万甚至几千万的点击同一个页面，这已经比DDOS更强了好么？所以没事别去凑热闹，第二天有人给你分析的透透的。
这是数据任务分级保障的逻辑，最上面的被挡住了，难受！其实这意思就是越重要的任务，越不能降级，越要高保障，不能让业务感知到有问题。
这是应急预案，从制度、巡检和应急处理三个层面做好相关预案工作。用制度确保所有人整齐划一、落实到位；用产品和系统提升巡检的效率，减少对人的依赖；识别各种异常、风险，拟定不同的应对方案，并在合适的时候进行相应的应急方案处理。
这是事中的应急保障处理逻辑。事中的专人专责肯定是要的，定时巡检那肯定是一刻也不能停，兄弟们估摸着都得通宵了。及时沟通自然不必说，应急保障随时启动。
基本上的逻辑就是各种信息收集、各种监控、巡检，发现任何异常，应急小组立刻按照应急预案进行决策、执行，最后跟进问题是否得到解决。
这是事后复盘的逻辑。即便是事前有完全准备，真正到执行的时候，调皮的捣蛋之神还是会过来凑个热闹。一番手忙脚乱是免不了的，但是不用着急，大局能控住就行。但是事后咱得把这些问题都记录下来，丰富完善咱的应急预案啊！
这是未来的规划，快手还准备做故障注入，用来测试整体的质量保障系统的健壮性。你可能会说，这不是给自己找麻烦么？怎么说呢？开发体系那边为了加强自己的系统健壮性，还整了一个“混沌工程”，专门给系统闹事、找问题的。只有这样，咱的技术才能不断地提升，你说对吧？
以上就是快手数据质量保障体系和直播实践的所有分享内容。各位感兴趣，可以下载ppt保存。
扩展阅读：《4.快手数据质量体系及在直播场景的实践-杨钊》，公众号“大数据架构师”后台回复“快手保障”即可下载。
今天的分享就是这样。欢迎大家加我个人微信号：shirenpengwh ，一起探讨大数据、数据分析相关知识。每天分享一篇原创内容给大家，我们一起学习，共同进步。
配合以下文章享受更佳