你在抖音上点的“小红心”到底去哪了?
2022-9-9 11:0:57 Author: mp.weixin.qq.com(查看原文) 阅读量:6 收藏

浅友们好~我是史中,我的日常生活是开撩五湖四海的科技大牛,我会尝试各种姿势,把他们的无边脑洞和温情故事讲给你听。如果你想和我做朋友,不妨加微信(shizhongmax)。

你在抖音上点的“小红心”到底去哪了?
文 | 史中
作为祖国四化建设的接班人,张三睡前喜欢在抖音上刷搞笑,不不不,科普短视频。
看到一个不错的视频,他按捺不住冲动,野性双击点了个赞。看着那个小红心从屏幕上飘出来,一闪即散。
张三暗暗点头,仿佛和屏幕里的主播心意相通,指尖顺势一滑准备看下一个视频。
诶,不许动!就在这个普通得不能再普通的日常瞬间,中哥按一下暂停,问你一个问题:你知道这颗“小红心”后来去哪了吗?
小红心当然没有随风飘散,而是开启了一场冒险之旅——论路途,它接下来要走的路,也许比玄奘西行还要曲折;论结局,它将汇入奔涌的数据洪流,组成数字世界赖以运转的“真经”。
我们今天的故事,就讲讲这颗小红心的“硬核奇幻漂流”。
(一)对“小红心”最为礼遇的人 
在讲小红心的冒险之前,请原谅我稍稍多交代几句背景——说一个坏消息和一个好消息。
先说坏消息吧。
罗永浩早年在吉林大学演讲时曾对孩子们说过这样一段话:
如果你的一生没有做出伟大的事业,没有赚到钱也没有出名,但是一生耿直刚正不阿,拼着老命把家人照顾好了,梗着脖子去世了,你这一生有没有改变世界?还是改变了,因为这个世界上多了一个好人。
我时常想起这句话,不仅因为它会在我邪念萌发的时候勉励我做个好人,更因为它背后藏着一个有趣的模型:
我们每个人的脑袋瓜里都有一个“投票器”,无论大事小情,只要面对岔路口,都会用“投票器”抉择一下。

一个人一生几亿次投票汇总下来,其实就是他的墓志铭;而无数人的墓志铭汇总起来,就是我们世界的历史线。
如此看来,我们颅内的每一次渺小“投票”都像是给世界输入了一个“数据”,最终会导致这个世界输出的“结果”有一丝丝偏转。
可坏消息来了:我们的物理世界是没有“存证机制”的。
你做了好事不一定被人看到,被人看到不一定被理解,被理解不一定被赞扬,被赞扬不一定被效仿,被效仿时又不一定被下一个人看到。。。于是,这种“数据”的传递慢得惊人,留存准确度也低得惊人。
以至于,“善恶有报”这件事情虽然在逻辑上隐约成立,却在一个人的生命跨度里基本无法被观测到。
接下来说好消息吧。
2022年的我们,不是全无选择——除了破旧的物理世界,还有崭新的数字世界。
在数字世界里,事情就大快人心得多。每一个字节的数据都可以被分毫不爽地高速传递,进而确定性地、可以量化地对这个世界造成改变。
这么说有点抽象,举个栗子吧:
在物理世界,你看到一个人扶起了摔倒的老奶奶,你对着他比了一个赞,然后就没有然后了。
可是在抖音上,你看到一个人扶起了摔倒老奶奶的视频,你点了一个赞,这个赞就会像一枚钢印刻在数据库里,推动系统把这个视频推荐给更多人看,最终成为更多人心头的一个善念。
你看,正是有了数据,数字世界才有了比现实世界更大的演化动力。所以,把数据称为数字世界的石油简直不要太合适。
遗憾的是,纵然数据是个宝,但不同人对它的态度是不同的。
就像石油一样:在原始部落看来这就是黑乎乎的沼泽,弃之如敝履,因为他们无法利用;但对于工业体系完善的国家来说,就会对石油颇为“礼遇”,因为他们懂得如何冶炼它。
那么此时此刻的数字世界,对数据最为礼遇,最会从数据中提炼能源的是谁呢?
要我说,四舍五入就是抖音的母公司,字节跳动。
我认识的字节跳动的老师傅不算多。但这些人却有一点出奇地相似,就是他们都极其尊重数据,甚至说“信仰数据”也不过分。你看,2012年他们起名的时候就把公司直接叫成了数据的计量单位“字节”,可见从第一集就奔着西天取经去了。。。
这几年字节的老师傅们开发了好多有趣的技术,目的就是“三最”——用最高的规格,把数据冶炼成最纯的能源,为用户发挥出最大的价值
这些技术,组成了一个“旅行社”,把小红心的旅途安排得明明白白。
好了,估计你已经对小红心的奇幻之旅有那么一点好奇了~~为了深刻体会数据技术的历史脉络,我决定带你重走一遍老师傅的取经路。
咱们先坐上时光机,回到2015年吧。
(二)老师傅的“开挂系统” 
2015年,抖音还没出生。但没关系,它的大哥今日头条已经诞生了。假设有人给某篇头条文章点了赞,也会产生一颗小红心。
这颗“小红心”的旅程可能是酱的:
1、它睁开了双眼,还没来得透过屏幕仔细看清主人的模样,就嗖地一下被甩到空中。空中的基站像弹弓一样,迅雷不及掩耳盗铃地把它弹射到轰鸣的服务器中。
2、在服务器中,小红心见到了和它一样的来自各地的数据,它们列队整齐,被安排入住在一个叫做”数据库“的巨大酒店里。
3、这个大酒店里好吃好喝,但就是有些寂寞,各个数据也相互不见面。小红心本以为自己就要在这里颐养天年了。但是,几天之后,它却收到邀请,要去参加一个有趣的游戏。
原来,字节的老师傅们写了一个系统,用来把“A组文章”和“B组文章”的阅读情况分别进行汇总。
我们的主角小红心恰恰属于A组文章的点赞数据,于是,它和其他众多数据抱在一起,坐在了数据工厂的流水线上,从另一端出来时,它变了模样,成为报表的一部分。
你可能有点懵,这是在玩啥?
不瞒你说,这是字节这群老师傅在练绝招:“A/B测试”。
当时的情况大概是:今日头条刚刚开发出两种文章的推荐策略,可这两种策略哪种能把文章*更精准*地推荐给想看它们的人呢?
不知道。
不知道不要紧,事实是检验真理的唯一标准。
老师傅们选定两组用户,先分别用A、B两个策略为他们推荐文章,然后把这两组文章的点赞、阅读时长等等数据汇总起来,哪个策略返回的数据更好,不就说明它干活儿更棒么?
看到这,你可能撇嘴:这不就是简单的对比实验么,算啥绝招?
客官有所不知,“A/B测试”从实验设计到数据汇总,是一个贼拉费劲儿的事情。
你遇到“午饭吃麦当劳还是肯德基”这样的抉择,肯定不会做个实验,把两家的汉堡薯条都买来,对比谁家的薯条多,谁家的汉堡大,你最多扔个鞋决定一下也就完事儿了,只有遇到重大抉择才会想到用“A/B”来严肃地解决。
图片来自“毕导”,他曾经真的测试过哪种快餐更合算。。。文章链接我放在最后吧。
可字节这群人却都是“A/B狂人”,买汉堡前先做实验这种事儿他们没准还真能干出来。。。
在字节公司内部,流传着一个“黑话”——遇事不决用A/B
大到推荐引擎的策略调整,小到App里一个按钮的位置摆放,各种改进,总要设计个实验看看回收数据才能放心,可见“数据测试”已经写入这帮人的DNA了。。。
如果把做今日头条比作打一场游戏,那么每一次“A/B测试”就相当于一个“存档点”。
在AB两种策略里选优就相当于——“这里打得不好,读档重来再打一次”,每次都在“打得好的那一版”的基础上继续往前打。
最终,一点点优势累计,就必然形成数学上的巨大胜率。相比其他一条命拼到死的竞争对手,你说它不胜出谁胜出?
所以,“用A/B”不是绝招,“总用A/B”才是绝招
可字节跳动这帮人“开挂”也不是没有代价。还是刚才说的,实验设计太太太太太费功夫。。。
我们把刚才几张图拼成完整的流程,你感受一下:
如今字节数据平台负责人罗旋在2014年加入公司。
他还记得那个“震撼”景象:所有的数据报表都是同事们用邮件传来传去,手动比对分析。
这种小米加步枪的状态下,负责技术的老师傅就比较惨:
今天A团队为了把这堆数据捞回来,要请技术老师傅写一堆代码;明天B团队要把那堆数据捞回来,又得请老师傅重新写一堆代码。。。
老师傅长期被“请”,疲于奔命,秀发早晚不保啊。。。
不行,老师傅们一合计,得赶快开发出一套“A/B测试工具”——甭管是哪个团队,想测啥事儿,直接把系统拿去用,最好别霸占俺们的“肉身”。
Albert,就在这个“秀发保卫战”前不久加入字节,负责开发这个名叫“Libra”(天平)的A/B测试工具。
造这个工具的难点是啥呢?
你看,A/B测试最早是用在推荐算法的改进上,推荐算法团队的同学肯定是懂代码的,所以设计给他们用的A/B测试系统并不难;
可是后来,App 的设计团队也想用A/B测试来改进 App 的外观和逻辑,他们就不是那么懂底层代码了;
再后来,运营推广团队也想用A/B测试,决定哪种推广策略拉新效果更好,他们就完全不懂代码了。。。
所以,为了照顾所有人的使用,Libra 的界面就得尽量傻瓜,最好用鼠标拖拽的方式就能创造一个实验。
Albert 回忆。
于是,一群搞底层代码开发出身的老师傅坐在一起,把数据接入、实验设置这些核心功能搞定后,还得围成一圈开始研究怎样做出一个易用的界面。毕竟不是科班出身,搞出来的第一版界面蠢萌蠢萌的。
当时的界面找不到了,给你们看看现在的界面吧(局部)

很快,各个团队就七嘴八舌地对界面和逻辑提出了各种改进意见——底层数据怎么调度他们不太关心,但是界面和逻辑改进他们很有心得。
在各个团队的“威逼”下,Albert 他们只好硬着头皮继续改进,甚至还专门招聘了前端工程师。
一个给内部用的产品,真的值得在易用性上下这么大功夫么?
可能连 Libra 团队自己也没想到,这恰恰会演变成为后来故事的一个重要伏笔,我们一会儿再说。
随着团队们用 Libra 越来越熟练,一个哲学命题猝不及防地浮出水面:
我们刚才一直在说,A/B测试的目的是选择两个方案里更“好”的那个。可是,究竟什么是“好”,恐怕才是更根本的问题吧?
比如,什么是好的“文章推荐策略”呢?
点进去的人多,就是好策略吗?恐怕不是吧。标题党文章点击多,但用户很可能点进去就退出来,没准还会骂两句。
那么,阅读完成度高,就是好策略吗?似乎也不能这么绝对,很多不太高雅的内容可以吸引读者看完,可这种文章没营养,长期来看读者也不会满意。
Albert 解释。
Albert
那肿么办?
哲学问题,不妨从哲学家那里借鉴答案。哲学家陈嘉映专门写过一本书,就叫《何为良好生活》。
他的结论当然很复杂,但是从技术层面来理解,所谓良好生活其实是“一系列复杂指标的总和”,包括快乐、品行、智识、自我实现等等。
那么以此类推,一个良好的推荐策略也不能只考察“点击量”、“点赞数”或“留存率”这样的单一指标,而是应该把好几个维度的数据集合起来,形成更复杂的指标
Albert 回忆,当时各个团队可以放开手脚随意做实验之后,很快就意识到在指标上的“囊中羞涩”。
那段日子,无论是推荐策略团队,还是产品团队,还是运营推广团队,都绞尽脑汁开始设计奇奇怪怪的指标。
于是,这又引出了新的难题
指标是由无数“小红心”这样的底层数据计算而成的。指标越复杂,就要调度越多的底层数据。
我们不妨把各个团队用来生成报表的各种“数据工厂”想象成炼油厂,把存在数据库的原始数据想象成地底的原油。
在炼油厂规模比较小的时候,也许一口简易油井就足够供应;
可是,现在炼油厂发展壮大,需要综合冶炼各种类型的原油,油井的性能就妥妥成了瓶颈。就是下图中闪烁的红色剪头。
结果就是,2017年时分析师要查一个指标的历史变化情况,大概要等20秒钟才能看到结果。
20秒虽说不长,可分析师不是一天只看一个指标啊,他的工作就是每时每刻看指标。这一天下来,光等就等到颓废。。。
历史喜欢开玩笑——就在工具不怎么凑手的档口,却偏偏来了个大活儿!

(三)“查数”神器 
2017年,抖音火了,火到不能再火。
打南边来了一亿用户,每人都要上传视频;打北边来了两亿用户,每人都要观看、点赞、评论——汹涌人潮中,“小红心和它的数据朋友们”比从前翻了成千上万倍。
注意,这个时候,如果炼油厂(数据应用)需要原油(数据)的时候,还现场从油田(数据库)里抽取肯定是来不及了。
合理的办法是:创造出一个大仓库,把原油提前整理好放在那里,需要的时候可以第一时间抓取,这个仓库就叫“数仓”
就像下面这样:
建造一个牛X的数仓,刻不容缓。
摆在老师傅面前的技术方案有四五个,就像东邪西毒南帝北丐那样各有千秋。
可挨个尝试了之后,结局很残酷——大多数技术路线都无法满足这么大规模数据的高速调取。。。
如今的数仓团队技术负责人 Carl,正是在这个危急时候加入团队的。
Carl 刚加入没几天,大伙就告诉他噩耗:东邪西毒南帝北丐都顶不住,目前就剩一个“郭靖”看起来还是个苗子。
这就是当时最新的开源分析型数据库 ClickHouse
“虽然但是,啥。。。啥是 ClickHouse?”在数据库领域纵横八年的老司机 Carl 有些尴尬地问。。。
其实这不怪 Carl,在2017年,ClickHouse 诞生不久,刚开始在社区里流行,还没有哪个像样的江湖大佬敢冒险选用这个年轻的“郭靖”,没听说过也再正常不过。
可邪门的是,经过进一步测试,ClickHouse 读写数据的性能总是名列前茅,就像一个闪闪发光的急速机械臂,老师傅越看越爱。
Carl 他们一合计,没人吃螃蟹,并不等于螃蟹不好吃啊。拍拍胸脯,我们先用呗!
老师傅们就这样冲进了战场,用了两个月就基于 ClickHouse 搞出第一版数仓,交给一些敢于尝鲜的规模小一点的业务团队去用。
Carl
可是,吃螃蟹的代价很快就来了。
刚才说过,ClickHouse 就像一个机械臂。可是一个完整的数仓,仅仅有机械臂还不行,还需要有系统负责多个机械臂之间的配合,还要有一系列措施保证机械臂的故障维修。
就像下面这样:
可是,ClickHouse 自己都是初出茅庐,和它相配套的系统更没有经过大规模磨合检验,暗藏着五花八门的坑。。。
当时一个大的数仓里能达到400-500个 ClickHouse 集群,集群之间要实现“高可用”,靠的是 Zookeeper 系统。
这么多集群满负荷运行,压力就会集中在 Zookeeper 身上,弄不好就会挂掉。。。
Carl 回忆。
要命的是,当时有些团队已经开始依赖这套系统,他们吃着火锅唱着歌查着数据,突然系统崩溃,那种感觉就像被麻匪劫了一样慌。
Carl 他们也惊出一身冷汗,把伙伴置于危险境地那妥妥有损技术人的尊严啊,这种事儿决不能发生——他们当即使出单身30年的手速,写了一套临时脚本硬生生扛住。
脚本就像临时缠上的胶带,毕竟不是长久之计。
他们只能左右开弓:
左手维护脚本,右手开始写一套永久的高可用方案。
几周之后,新方案火速上线替换掉临时脚本,才算灭火成功。。。
用几个机器人把 Zookeeper 的任务分担下来。
可是,汗还没来得及擦,新的“险情”又来了。
虽说数仓的建立本来就是为了让人查询各种奇怪的数据。可有些业务团队的脑洞过大,查数据的姿势堪比瑜伽——总让机械臂去够架子边缘的箱子。。。
数仓又不可能躺在椅子上翘腿说:“你查的这个数据太怪了,我不想给你找。”
它只能勉为其难去查,这一下不要紧,机械臂触发 Bug “扭了腰”,整个系统就被搞挂了。
Carl 他们一开始的想法是,预测一下大家都会用什么怪姿势使用数仓,后来他发现自己天真了:
调用数仓的这群人脑洞可太大了,老师傅根本猜不到他们会怎么出牌,只能遇到一个问题修复一个问题——Bug 难免有,及时修好下次不犯就是好同志。
数仓挂掉,业务团队多少是能容忍的,可伴随而来的另一件事儿他们却忍不了:
每一次数仓“因病”去世(挂掉),再投胎转世(重启)都需要十来分钟,这等不起啊。。。
Carl 他们猛然意识到,数仓的“重启速度”这种细节,也妥妥是性能的重要组成部分!
老师傅赶紧研究,他们发现数仓重启之所以需要转圈圈那么久,就是因为读取“元信息”的过程比较繁琐,干脆一不做二不休,专门写了一套程序把这些信息存盘管理起来。
需要重启的时候,直接读取这一整套数据,又干净又卫生。
你发现没,那个阶段 Carl 他们做的事情,好像哪件都说不上惊天动地。但是,如果没有几百个核心业务每天在数仓上反复摩擦,你还真没办法把这些问题都发现,也没办法解决得这么圆润。。。
这个“圆润”,同样为未来埋下了伏笔,我们一会儿再说。
我们的故事快进到2018年,此时 Carl 他们已经陆续给 ClickHouse 增加了几百项大小改动,使得“字节版”的 ClickHouse 已经和母胎的“社区版”有很大区别了,于是他们决定给自己的 ClickHouse 起个新名,叫做 ByteHouse
这一年,也是 Carl 最开心的一年。因为随着 ByteHouse 肉眼可见越来越好用,公司内很多团队的数据工厂都纷纷把 ByteHouse 数仓作为自己数据处理的重要一环。
更让 Carl 高兴的是,在业界很多大公司也纷纷开始选择 ClickHouse 作为数仓核心组件。
这种感觉,就像你在网易云发现了一首评论寥寥的宝藏歌曲,几年后却发现评论已经十万加,所有人都在听——一种“老子就是有眼光的感觉油然而生。
ByteHouse 出场之后,我们不妨再来看我们的主角“小红心”,它的“奇幻旅程”就和前几年明显不同了。
张三给一个视频点了小红心,小红心诞生之后,会先入住数据库这个“宾馆”;
然后它会从宾馆出来,进入 ByteHouse 这个硕大的“仓库”,和来自其他“宾馆”的数据汇合在一起;
接下来,小红心才会根据调遣进入功能各异的数据工厂,用自己的身躯组成报表;
当然,如果有必要,一些报表会继续进入那个“A/B测试”的神器 Libra,最终为这个数字世界里的每一个决策提供依据。
注意,我画的这个旅游线路是“极简版”。
在实际的“数据旅行”中,计算一个数据没有这么简单。
小红心很可能要在“宾馆”(数据库)“仓库”(数仓)和工厂“数据应用”中来回穿梭,中途要换好几次“大巴”,还要和不同的数据“组团”——一趟旅途分成几百段都很正常。
参加过旅行团的浅友都有过这样的经历:集体坐大巴的时候,总有个别人因为五花八门的理由迟到,一车人只好坐在那里干等,这会大大降低旅行团的行进效率。。。
没错,在“数据旅行团”中,这种事儿同样会发生。。。
就在2018年,随着数据处理流程越来越复杂,老师傅们发现,数据该出现不出现,该发车不发车的情况越来越多。
比如,抖音规定有些报表早晨9点就要计算出来,可是前面的数据没出来,指标就填不进去——将军看不到地图,这仗难道要“盲打”了吗?
数据旅行团的问题,也可以从现实旅行团身上借鉴答案。
没错,数据旅行团需要一个“导游”,而且是一个严厉的导游,谁迟到就打谁屁屁的那种!
(四)数据旅行团的“导游” 
“字节有一个很牛的文化,你知道是什么吗?是拉群。”Brian 笑着给我讲。
“当年,遇到‘数据流程卡住’的问题,你只要把相关负责人拉到一个群,他们就会神奇地行动起来,自己协商出办法把问题给解决!自驱力杠杠的。”
可问题就在于,“一腔热血”不能解决所有问题。
拉群办事,靠的毕竟是肉身,就像在数据流程的水管破口上用手指头按住那样↓↓↓

可随着数据应用变多,发现的破口越来越多——每次出问题就多拉一个群,到后来,相关负责人手机里的群已经密密麻麻,老师傅们的手指头不够用了↓↓↓
结论很明显:靠人力解决“数据治理”的难题,长远来看根本不可取。
这里,就是 Brian 和他的同事们展现实力的时刻了。
哦还没给你介绍,Brian 是字节跳动数据治理工具 DataLeap 的负责人。这个 DataLeap,就是刚才我们说的“数据旅行团”里的“导游”
Brian
具体来说,DataLeap 保证数据流程的方法,是通过各方签署“SLA”(服务级别协议 Service-Level Agreement)来实现的。
啥是 SLA?
我们还是沿用之前的例子:
假如A团队必须在早晨9点把一个报表准时提交给抖音的负责人,那么B团队就要在早晨6点前把所有指标算出来;
以此往前推,C团队就要在凌晨3点前把计算指标所需的数据都准备好;
再往前推,C团队计算所需的更底层数据在凌晨1点就要由D团队准备好。
在这个共识的基础上,A、B、C、D 四个团队就在 DataLeap 上签字画押,也就是签署 SLA。
这下,数据链路上重要节点的责任就被“铁路警察,各包一段”了。
在字节内部,每天都会新增一些“数据旅行线路”——用 DataLeap 来建立线路的时候,就可以同时签署相应的 SLA。
假如以后遇到问题,数据卡在了C团队那里,DataLeap 会直接给C团队弹出报警,让他们赶快处理,如果没有即使修复,事故责任就落在了C团队头上。
就像一个有趣的“击鼓传锅”游戏。(开玩笑的,大家很友好不会甩锅,DataLeap只是帮各个团队明晰了权责。)
Brian 特别提醒我,不要把 DataLeap 想象成冰冷的“签字画押”工具,它还有很多温馨的黑科技。
比如,老师傅在 DataLeap 里内置了一个算法,可以根据表现自动给一条数据链路的“健康度”打分。
如果某个数据传输节点设置不合理,或者给存储计算分配的资源太抠门,或者历史上出现了多次延时,都会影响这条数据链路的分数。
相关团队只要经常关注各条数据链路的分数,就能把问题消灭在萌芽中了。
再比如,DataLeap 还可以设定每条数据链路的“优先级”
假设抖音每天需要1000个数据流来产生1000种报表,那么,万一遇到不可抗力,计算资源吃紧,在规定时间内只能算出40%的报表。
这时候应该肿么办呢?
这是个经典的“吃自助餐”问题:肚子有限,怎么才能吃回本?肯定是先吃最值钱的龙虾!
所以,抖音团队也应该先挑最重要的报表计算——他们可以在 DataLeap 里提前规定好:
100个“一级任务”;
300个“二级任务”;
600个“三级任务”。
这样遇到问题的时候,DataLeap 就可以自动保证数据按照轻重缓急的顺序被计算,最大程度减小损失。
故事发展到这个阶段,我们的主角小红心的“奇幻旅途”又升级了。
在它穿梭在数据库、数仓、数据分析系统的过程中,旁边会时刻站着一个导游(DataLeap),絮絮叨叨苦口婆心地帮它安排行程,催它一个个赶通告。
至此,字节这群老师傅花了几年时间精心构建出来的“数据豪华旅行团”,就已基本呈现在你面前。
请注意,“豪华”这两个字不是我随意加的修饰,其实在2018年,每颗小红心旅行一趟下来,总体花费的成本比现在高不少,堪称豪华。
但这种“豪华”没啥骄傲的,这其实代表着性价比不那么极致。
在2018年以后,一方面全球经济形势都遇到了寒潮,大家都不富裕;另一方面,人们对数字世界的依赖却只增不减,要处理的小红心还是越来越多。
Albert 算了算,如今 Libra 上每天新增的实验有2000个,同时进行中的实验数更是数以万计。
进入A/B测试的就有这么多,那么每时每刻产生的总报表数就更多了,进而,底层的数仓和数据库被调用的次数就更更更多了。
这种情况下,老师傅反倒比以前压力更大,各个环节都被倒逼要优化“数据旅行”的支出——又让马儿跑,又得马儿不吃草。
小红心必须得“穷游”↓↓↓
(五)穷游的小红心 
“问你个问题,每个A/B实验应该选择多少样本做对比,才能得出科学的结果?”Albert 问我。
“那。。。应该是越多越好吧。”我说。
首先,测试是非常耗费计算资源的,如果实验规模过大,同时上这么多实验,Libra 肯定撑不住。
再说,如果一个 App 有1亿用户,测试样本就把1亿用户分成两个5000万,那就不是实验,而是实际发生了。如果A策略有缺陷,就会对A策略覆盖的5000万用户都都造成不可逆的负面影响。
他说。
“要这么说,样本数量就不能太大,选1万人。”我说。
“1万人测试出来的结果,一定会和1亿人测试的结论相同吗?”他反问。
“那就。。。每次实验选1万人,连续做5次实验,5次结果相互印证,会不会好一点?”我有点心虚。
“你看,这就是问题所在。当样本规模变小的时候,这就变成了一个统计科学问题了。告诉你答案,从统计学的角度来看,‘5万人做5次’的结果并不比‘5万人做1次’的结果更准确。”Albert 笑。
“等等,让我捋捋。。。”话聊到这儿,我已经在晕菜的边缘徘徊了。
“其实,我们这些做代码工程出身的,一开始统计学知识也不够。但是从2018年开始,我们意识到自己的局限性,引进了很多数据科学家,我讲的这些结论是跟他们学习以后才明白的。”Albert 安慰脆弱的我。
看我的表情还残存一丝倔强,Albert 又给我讲了几个栗子:
比如“样本污染问题”
很多团队每次做“A/B测试”,都会一直选择ID是奇数的用户为A组,ID是偶数的用户为B组。
这就有问题了,假如两次*本应独立*的实验用的分组情况完全相同,甲实验就会干扰乙实验。
乙实验观察到“A策略比B策略好”,这很可能是因为在甲实验里的A策略比B策略好,由于样本选取不科学,这个“好”在第二次实验里仍然在发挥作用。。。
也就是说,两次实验发生了“交叉污染”。。。
再比如“分组干扰问题”
你在重庆挑选了A、B两组用户做拉新,介绍一个新用户注册抖音就给一包火锅底料(这是随便编的策略)。
但是很可能A、B两组用户在真实世界里本来就有关系,是同事、家人、朋友,会口耳相传。
两个策略就会相互干扰,呈现出失真的结果。
所以,必须让 A、B两组用户越不认识越好。
但是,你又不能一组选在重庆一组选在新疆。因为这样两组样本本身差异太大,新疆人爱吃大盘鸡,不想要你的火锅底料。。。
你看,这些问题五花八门,但说到底他们要做的就是一件事儿——在“成本可控”的情况下,尽量保证“决策卫生”,从而把测试结果准确率无限推进到“理论极致”
所以,从2018年开始,数据科学家们在 Libra 里面内置了很多保证“决策卫生”的流程和功能。它们就像一个个“安全气囊”,保证不太懂统计科学的新手司机也能上秋名山飚车。。。
显然,要实现全流程“穷游”,数据仓库同样需要技术升级。
可是,数仓这东西非常精密,所有组件都紧紧咬合在一起,牵一发动全身,没办法“微整形”,要整就整“大手术”。
在2020年左右,ByteHouse 的各种小优化已经做到极致,拱不动了。Carl 他们咬咬牙——与其逃避命运,不如主动出击——决定对 ByteHouse 进行两场大手术。
这第一台手术就是“存算分离”
我们回到前面的比喻,把 ByteHouse 看做一个仓库。原本这个仓库是每一个货架(存储资源)旁边都站着一个固定机械臂(计算资源),需要这个货架上的数据,它就拿下来。
但是可想而知,如果仓库规模不断变大,机械臂数量也会线性增多。
然而,不是每个货架上的数据时刻都需要存取——大部分时间机械臂(计算资源)都在闲置中,资源浪费。
所谓存算分离,就是把机械臂变成移动的,需要哪个货架上的数据,就过去拿。可想而知,这样的改造不仅能节省很多“机械臂”,还能腾出“货架”的空间。
就像下面这样↓↓↓
第二台手术就是“并行处理”
原本 ClickHouse 的任务分配模式是“树状”的:
一个查询任务来了,就需要一个“工头”把任务分配给很多机械臂,它们把数据找来,再汇总给工头。可这样有个明显的缺点,就是工头一个人成为了系统的瓶颈,尤其是在数据汇总的时候,大家都把数据给它,它就会忙不过来。
所谓“并行处理”,就是让机械臂们自己分别汇总,然后把汇总后的结果报给工头,就能大大缩短计算的时间。
别看这两台手术从逻辑上听上去不难理解,但是要完成改造,需要深入数仓内部的最细节代码,相当于把每一颗螺丝都进行改造,再精巧地封装回去,难度直逼开颅手术——Carl 他们整整干了两年。
就在 ByteHouse 做手术的时候,DataLeap 也没闲着。
Brian 给我介绍了一个字节独创的理念,叫“数据的分布式自制”
这是啥呢?
举个例子,像抖音、今日头条这样的顶流业务,对数据的要求就是“变态级”的,哪怕数据晚到一秒钟,可能都是事故。可是对于字节内部刚刚孵化的小业务,就没必要这么较真,数据晚半个小时似乎也没问题。
于是,DataLeap 就加入了一个功能,可以根据大家不同的容忍程度,自助调整数据链条的“松紧”。
“干嘛要调,不是数据传递越快越好吗?”我问。
因为时间就是金钱。
对数据要求严格,就必须在全链路的计算、存储、监控都下足本钱,成本自然就高;
反之如果对数据时效要求不高,就可以坐慢车,大大节省成本。
他说。
就像这样,飞机火车汽车随便挑。
Brian 他们搞出的“抠门”操作还有很多。
比如,有些没人用的就数据会一直占据存储空间,可是团队却不舍得删,就像不敢扔家里的旧书,生怕哪天还要看。
可是,存储用的硬盘却是实打实的成本啊!眼看每天都有新数据源源不断进来,存储资源成本越来越高。。。
DataLeap 一看,这个事儿我能帮忙啊!
因为所有的数据链路都在 DataLeap 上创建,它就自然能知道哪些数据访问量比较高,哪些数据一直在“万年冷宫”。根据数据的热度,DataLeap 就能精准建议团队删除一些最冷的数据。
这样一来,不仅存储成本大大降低,数据也可以在合适的机会被销毁。
故事讲到这,我们的主角小红心的“数据旅行团”又有了新升级。
首先,它的整个旅途在保证质量的情况下,会变得更便宜
其次,在完成所有旅程之后,它最终还会回归自然。直到这一刻,小红心才真正走完了它“驱动世界”的旅途。

给你看下全景图吧:

刚才我为了方便你理解,一直在强调“穷游”,好像老师傅都很抠门似的。但,这样磨炼极致的数据处理体系,难道仅仅是为了省钱吗?
当然不是。
别忘了,数据是数字世界的石油——不仅仅是字节跳动需要数据石油,也不仅仅是互联网行业需要数据石油,我们现实世界里的工厂、饭店、机场、银行,千行百业全部都在源源不断地产生数据,他们当然也有权力使用数据石油。
可问题在于:不同行业的“数据密度”是不同的。互联网行业天生泡在数据石油里,如中东土豪一样;但一些传统行业就像贫油国,有些数据并不丰富,有些开采难度较大。
这种情况下,还要斥巨资建设数据处理体系,他们就没有动力了。。。
换句话说,只有一个性价比足够高的数据处理体系,才能融入千行百业,帮助他们来开采自己的石油。
字节这群老师傅忽然抬头,发现整个江湖之上,自己对于数据技术的处理已经到了独孤求败的地步。于是,高层慎重讨论,准备把这些年积累下来的各种技术开放出来,服务广大企业。
这就是后来大名鼎鼎的“火山引擎”
(六)成为“利器” 
2021年,数据老师傅们来了个一秒变装——从服务公司内部业务,转向服务衣食住行、千行百业。
字节这些系统也来了个一秒变装——A/B 测试系统 Libra 改名为 DataTester,用户增长分析系统TEA 改名为 DataFinder,数据洞察工具风神改名为 DataWind、客户数据平台 Mirror 改名为 VeCDP,一起装在了叫做“VeDI”的数智平台里。
就像这样(点击可以看大图)
其实,各行各业建设数据体系,本质上就是把字节走过的路重走一遍,火山引擎的价值恰恰是——字节踩过的10086个坑,不要再让其他公司踩。
老师傅发现,他们要做的还是老三样:
1、帮助企业建立“收集小红心”的能力;
2、帮助企业建造小红心的“仓库”和“工厂”;
3、帮助企业给小红心的旅途配备“导游”。
举几个栗子吧。
有很多非互联网企业,还没有自己的 App,或者 App 功能设计不完善。
他们最急需的,就是第一步——收集“小红心”的能力
字节的一位同学告诉我,他们刚刚帮助领克汽车改进了 App 的设计,让领克的车主可以不用说话,仅仅通过在 App 里的各种操作就展现出他们的诉求,就像今日头条和抖音所做的那样。
收集到了小红心,领克就可以做“A/B测试”,从而一点点改进对车主的服务。
你看,数据链条就这样缓慢地转动起来。
估计浅友里肯定有领克的车主,不知道你最近体验到变化没。
领克还用火山引擎做了更多数据加工,篇幅有限就放在图里了。(点鸡可以变大)
有了小红心,就到了第二步——建造小红心的“仓库”和“工厂”
2021年,Levi’s(李维斯)已经完成了用户数据库的建立,他们就让字节的老师傅们把数据接入了数据工厂——VeCDP(管理客户数据的平台)。
这样一来,Levi’s 就把自己的客户分为六大人群体系,然后对每一类客户进行个性化的推荐和营销。
这样不仅减少了对很多非核心用户的打扰,还能集中精力服务真正的目标用户。
仓库和工厂都有了,接下来就是第三步——给小红心配“导游”。
能走到第三步的企业,已经算是数据领域的佼佼者了,因为这说明他们的数据基础已经完备,开始考虑数据治理的问题了。(你还记得吧,字节也是在数据基础链路建设完整之后才重点搞数据治理的。)
讲实话,目前这样的企业还真不多,“得到”就是其中之一。
得到是很多爱智求真的小伙伴(比如我)手机里的C位 App。
客观上来说,这些客户的消费能力还挺强的,所以他们使用得到 App 时产生的小红心(数据)的价值也很高,必须被重视,必须得到及时的响应。
所以,得到对数据链路的 SLA 要求贼高,数据决不能迟到。

这不正好是 DataLeap 的用武之地么?
2021年的时候,字节老师傅帮得到建设了 DataLeap 的数据体系,从此,数据不到位的情况大大减少。
字节的同学还给我讲了好多案例,篇幅有限我就不给你转述了。
草灰蛇线伏脉千里,你还记得我们之前的那些伏笔么?
很多客户没有专业的数据分析师,这时候 Libra 的傻瓜式操作就非常合适;
各行各业使用数据的模式千奇百怪,ByteHouse 早年被锻炼出来的圆润皮实就发挥了作用;
各个公司的数据发展水平不同,有的对数据质量要求高,有的对数据质量容忍度高,这个时候 DataLeap 的分布式治理功能恰恰能派上用场。
他们当年费力做了这么多细节功能,更多是出于纯粹的数据信仰。可是“纯粹”恰恰是改造世界最锋利的武器。
那些默默的努力如今一下子灵魂附体。大概正如那歌词:“人生没有白走的路,每一步都算数”。
(七)没有尽头的数据长征 
熟悉中哥的人都知道,我是一个“数据技术信仰者”。
原因其实也很简单,中国总体地大物“薄”,人均来看各种能源都谈不上丰富,漫长的时间里,我们可以依靠的只有每个人的勤劳和忍耐。
正是这样的历史,造就了巨大的人口和统一的市场。而这两样,恰恰是数据的温床,孕育了最丰富的未来能源。
从这个角度看来,我们终究得到了历史的一些眷顾。
在未来几十年,大概率会爆发一场波澜壮阔的“数据技术普及浪潮”,每一个公司都可以用低廉的价格购买一个高效的“数据处理引擎”,就像现在我们买汽车一样简单。
也只有到了数据引擎遍地开花的时候,我们才真正拍胸脯说自己是奔跑在数据上的国家。
坏消息是,我们目前的数据处理效率,还不能支撑那样的未来。
好消息是,老师傅们仍在继续努力。
Carl 告诉我,最近 ByteHouse 正准备研究一个智能化的黑科技:
你还记得我们刚才说过,一个任务到达 ByteHouse 之后,要有一个工头来进行任务分配的吧。
面对一个任务,究竟应该召唤出多少个“机械臂”去执行子任务呢?如果太多就会浪费算力,如果太少就会拖延时间。
当前的解决方案比较粗暴,就是手动设定的默认值。
可未来 ByteHouse 进一步渗入各行各业,计算任务会变得更加五花八门,都采用“默认任务分配策略”就不合适了。
所以,黑科技就是:根据现场情况,自动测算最合适的“并行度”来分配任务。
这种润物细无声的“智能化”还发生着在很多地方。
比如在 DataTester(Libra) 里,目前所有的指标都是分析师自己凭脑袋瓜想出来的。
但 Albert 告诉我,他们正在尝试研究一种技术,可以通过历史数据和行业属性自动向分析师推荐:“要不要试试这样构建指标?”
这样的智能建议如果足够靠谱,那么各行各业就会进一步摆脱对专业分析师的依赖,利用数据的门槛随之大幅下降。
DataLeap 也有类似的黑科技。
Brian 说,过去的 DataLeap 在发现某个数据流卡住的时候(一般是半夜),都会马上打电话叫醒响应团队的方方面面好几位负责人,但很多情况下能解决问题的就是其中一个人
所以 DataLeap 正在研究的黑科技就是:
通过数据智能研判这个拥堵具体是由那个小分队造成的,直接给这一个人负责人来精准的“夺命连环 Call”,别人该睡还睡。
“提升大家的幸福感嘛!”Brian 笑。
举了这三个例子,可能你已经看出来了,未来数据技术发展的一大方向就是“数据处理的智能化”
智能化浪潮的意义,堪比汽车从手动挡进化成自动挡一样,瞬间让很多没信心开车的人也能学开车了。
除了“智能化”,未来数据处理还会越来越“实时化”
以前的“小红心旅行”短则几个小时,长则几天,但是在很多场景下,我们等不了这么久:
比如,你搜索了一件衣服,下一秒你就希望电商马上给你推荐相似的款式;
比如,火电厂周围的风向变了,就需要马上调整空冷岛风扇的转速,补偿风向对散热的影响;
比如,居民的用电情况发生改变,就需要马上调整电网输送功率,保持供电用电平衡。
实时报表的要求越来越高,小红心整个旅途可能在几秒内就得完成。(可以参考我写过的《你在被窝里刷手机岁月静好,一个“神秘引擎”却在远方和时间赛跑》
当延迟以毫秒计数,数据就会组成一条奔腾的大河。而在大河两岸,新的文明得以被滋养。
就像下面这张完整版大图:
虽然有点俗,但我的梦想就是通过产品化的方式,让未来更多的人能够用到数据。
人做的事情越来越少,自动化越来越多,直到人类从一条条数据链路中被完全解放出来。
Brian 说。
我想了半天:“你这梦想已经不俗了吧?”
告别字节的老师傅们,我忍不住掰着手指头计算。
二十多年前,互联网出现;十多年前,智能手机普及;而建立在这些基础之上数据世界,仍是蹒跚的孩子。
一个孩子已经如此强悍,我有理由相信,更多奇迹已经预定了我们的未来。
但成长从来并非易事。
从荒芜到轰鸣,如今数字世界的一切都由一行行微小而具体的代码堆砌而成,过去走到现在并无捷径。由此想见,由现在走到未来也没有捷径。
这可能是一场漫长的数据长征。老师傅只能前赴后继,用一行行代码代替脚步,去丈量大地。
但好在,代码是数字世界的砖石,它一旦创生,就再也不会消逝,我们每向前走一步,就离终点更近一步。

延伸阅读:

《你在被窝里刷手机岁月静好,一个“神秘引擎”却在远方和时间赛跑》

《我遇到一群想把机器人训练成艺术家的人》

《薯条大份更划算??狂买KFC/麦当劳/汉堡王后,我整理出了终极省钱攻略…》

用数据

为你想要的世界投票

再自我介绍一下吧。我叫史中,是一个倾心故事的科技记者。我的日常是和各路大神聊天。如果想和我做朋友,可以搜索微信:shizhongmax

哦对了,如果喜欢文章,请别吝惜你的“在看”“分享”。让有趣的灵魂有机会相遇,会是一件很美好的事情。

Thx with  in  Beijing


文章来源: https://mp.weixin.qq.com/s?__biz=MzU0NDEwMTc1MA==&mid=2247519842&idx=1&sn=f0708a66465a3d1546fab33cce405224&chksm=fb038a7bcc74036daaef946ce44f141c6086cb99108ecb7411f1b049234af470d75942f7caa9#rd
如有侵权请联系:admin#unsafe.sh