![]()
浅友们好~我是史中，我的日常生活是开撩五湖四海的科技大牛，我会尝试各种姿势，把他们的无边脑洞和温情故事讲给你听。如果你想和我做朋友，不妨加微信（shizhongmax）。
作为祖国四化建设的接班人，张三睡前喜欢在抖音上刷 妹子 科普短视频。看到一个不错的视频，他按捺不住冲动，野性双击点了个赞。看着那个小红心从屏幕上飘出来，一闪即散。张三暗暗点头，仿佛和屏幕里的主播心意相通，指尖顺势一滑准备看下一个视频。诶，不许动！就在这个普通得不能再普通的日常瞬间，中哥按一下暂停，问你一个问题：你知道这颗“小红心”后来去哪了吗？小红心当然没有随风飘散，而是开启了一场冒险之旅——论路途，它接下来要走的路，也许比玄奘西行还要曲折；论结局，它将汇入奔涌的数据洪流，组成数字世界赖以运转的“真经”。我们今天的故事，就讲讲这颗小红心的“硬核奇幻漂流”。在讲小红心的冒险之前，请原谅我稍稍多交代几句背景——说一个坏消息和一个好消息。罗永浩早年在吉林大学演讲时曾对孩子们说过这样一段话：如果你的一生没有做出伟大的事业，没有赚到钱也没有出名，但是一生耿直刚正不阿，拼着老命把家人照顾好了，梗着脖子去世了，你这一生有没有改变世界？还是改变了，因为这个世界上多了一个好人。
我时常想起这句话，不仅因为它会在我邪念萌发的时候勉励我做个好人，更因为它背后藏着一个有趣的模型：我们每个人的脑袋瓜里都有一个“投票器”，无论大事小情，只要面对岔路口，都会用“投票器”抉择一下。
一个人一生几亿次投票汇总下来，其实就是他的墓志铭；而无数人的墓志铭汇总起来，就是我们世界的历史线。如此看来，我们颅内的每一次渺小“投票”都像是给世界输入了一个“数据”，最终会导致这个世界输出的“结果”有一丝丝偏转。可坏消息来了：我们的物理世界是没有“存证机制”的。你做了好事不一定被人看到，被人看到不一定被理解，被理解不一定被赞扬，被赞扬不一定被效仿，被效仿时又不一定被下一个人看到。。。于是，这种“数据”的传递慢得惊人，留存准确度也低得惊人。以至于，“善恶有报”这件事情虽然在逻辑上隐约成立，却在一个人的生命跨度里基本无法被观测到。2022年的我们，不是全无选择——除了破旧的物理世界，还有崭新的数字世界。在数字世界里，事情就大快人心得多。每一个字节的数据都可以被分毫不爽地高速传递，进而确定性地、可以量化地对这个世界造成改变。在物理世界，你看到一个人扶起了摔倒的老奶奶，你对着他比了一个赞，然后就没有然后了。可是在抖音上，你看到一个人扶起了摔倒老奶奶的视频，你点了一个赞，这个赞就会像一枚钢印刻在数据库里，推动系统把这个视频推荐给更多人看，最终成为更多人心头的一个善念。你看，正是有了数据，数字世界才有了比现实世界更大的演化动力。所以，把数据称为数字世界的石油简直不要太合适。遗憾的是，纵然数据是个宝，但不同人对它的态度是不同的。就像石油一样：在原始部落看来这就是黑乎乎的沼泽，弃之如敝履，因为他们无法利用；但对于工业体系完善的国家来说，就会对石油颇为“礼遇”，因为他们懂得如何冶炼它。那么此时此刻的数字世界，对数据最为礼遇，最会从数据中提炼能源的是谁呢？我认识的字节跳动的老师傅不算多。但这些人却有一点出奇地相似，就是他们都极其尊重数据，甚至说“信仰数据”也不过分。你看，2012年他们起名的时候就把公司直接叫成了数据的计量单位“字节”，可见从第一集就奔着西天取经去了。。。这几年字节的老师傅们开发了好多有趣的技术，目的就是“三最”——用最高的规格，把数据冶炼成最纯的能源，发挥出最大的价值。这些技术，组成了一个“旅行社”，把小红心的旅途安排得明明白白。好了，估计你已经对小红心的奇幻之旅有那么一点好奇了~~为了深刻体会数据技术的历史脉络，我决定带你重走一遍老师傅的取经路。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”才是绝招。可字节跳动这帮人“开挂”也不是没有代价。还是刚才说的，实验设计太太太太太费功夫。。。他还记得那个“震撼”景象：所有的数据报表都是同事们用邮件传来传去，手动比对分析。这种小米加步枪的状态下，负责技术的老师傅就比较惨：今天A团队为了把这堆数据捞回来，要请技术老师傅写一堆代码；明天B团队要把那堆数据捞回来，又得请老师傅重新写一堆代码。。。老师傅长期被“请”，疲于奔命，秀发早晚不保啊。。。不行，老师傅们一合计，得赶快开发出一套“A/B测试工具”——甭管是哪个团队，想测啥事儿，直接把系统拿去用，最好别霸占俺们的“肉身”。Albert，就在这个“秀发保卫战”前不久加入字节，负责开发这个名叫“Libra”（天平）的A/B测试工具。你看，A/B测试最早是用在推荐算法的改进上，推荐算法团队的同学肯定是懂代码的，所以设计给他们用的A/B测试系统并不难；可是后来，App 的设计团队也想用A/B测试来改进 App 的外观和逻辑，他们就不是那么懂底层代码了；再后来，运营推广团队也想用A/B测试，决定哪种推广策略拉新效果更好，他们就完全不懂代码了。。。所以，为了照顾所有人的使用，Libra 的界面就得尽量傻瓜，最好用鼠标拖拽的方式就能创造一个实验。
于是，一群搞底层代码开发出身的老师傅坐在一起，把数据接入、实验设置这些核心功能搞定后，还得围成一圈开始研究怎样做出一个易用的界面。毕竟不是科班出身，搞出来的第一版界面蠢萌蠢萌的。当时的界面找不到了，给你们看看现在的界面吧（局部）很快，各个团队就七嘴八舌地对界面和逻辑提出了各种改进意见——底层数据怎么调度他们不太关心，但是界面和逻辑改进他们很有心得。在各个团队的“威逼”下，Albert 他们只好硬着头皮继续改进，甚至还专门招聘了前端工程师。一个给内部用的产品，真的值得在易用性上下这么大功夫么？可能连 Libra 团队自己也没想到，这恰恰会演变成为后来故事的一个重要伏笔，我们一会儿再说。随着团队们用 Libra 越来越熟练，一个哲学命题猝不及防地浮出水面：我们刚才一直在说，A/B测试的目的是选择两个方案里更“好”的那个。可是，究竟什么是“好”，恐怕才是更根本的问题吧？点进去的人多，就是好策略吗？恐怕不是吧。标题党文章点击多，但用户很可能点进去就退出来，没准还会骂两句。那么，阅读完成度高，就是好策略吗？似乎也不能这么绝对，很多不太高雅的内容可以吸引读者看完，可这种文章没营养，长期来看读者也不会满意。
哲学问题，不妨从哲学家那里借鉴答案。哲学家陈嘉映专门写过一本书，就叫《何为良好生活》。他的结论当然很复杂，但是从技术层面来理解，所谓良好生活其实是“一系列复杂指标的总和”，包括快乐、品行、智识、自我实现等等。那么以此类推，一个良好的推荐策略也不能只考察“点击量”、“点赞数”或“留存率”这样的单一指标，而是应该把好几个维度的数据集合起来，形成更复杂的指标。Albert 回忆，当时各个团队可以放开手脚随意做实验之后，很快就意识到在指标上的“囊中羞涩”。那段日子，无论是推荐策略团队，还是产品团队，还是运营推广团队，都绞尽脑汁开始设计奇奇怪怪的指标。指标是由无数“小红心”这样的底层数据计算而成的。指标越复杂，就要调度越多的底层数据。我们不妨把各个团队用来生成报表的各种“数据工厂”想象成炼油厂，把存在数据库的原始数据想象成地底的原油。在炼油厂规模比较小的时候，也许一口简易油井就足够供应；可是，现在炼油厂发展壮大，需要综合冶炼各种类型的原油，油井的性能就妥妥成了瓶颈。就是下图中闪烁的红色剪头。
结果就是，2017年时分析师要查一个指标的历史变化情况，大概要等20秒钟才能看到结果。20秒虽说不长，可分析师不是一天只看一个指标啊，他的工作就是每时每刻看指标。这一天下来，光等就等到颓废。。。历史喜欢开玩笑——就在工具不怎么凑手的档口，却偏偏来了个大活儿！![]()
打南边来了一亿用户，每人都要上传视频；打北边来了两亿用户，每人都要观看、点赞、评论——汹涌人潮中，“小红心和它的数据朋友们”比从前翻了成千上万倍。注意，这个时候，如果炼油厂（数据应用）需要原油（数据）的时候，还现场从油田（数据库）里抽取肯定是来不及了。合理的办法是：创造出一个大仓库，把原油提前整理好放在那里，需要的时候可以第一时间抓取，这个仓库就叫“数仓”。摆在老师傅面前的技术方案有四五个，就像东邪西毒南帝北丐那样各有千秋。可挨个尝试了之后，结局很残酷——大多数技术路线都无法满足这么大规模数据的高速调取。。。如今的数仓团队技术负责人 Carl，正是在这个危急时候加入团队的。Carl 刚加入没几天，大伙就告诉他噩耗：东邪西毒南帝北丐都顶不住，目前就剩一个“郭靖”看起来还是个苗子。这就是当时最新的开源分析型数据库 ClickHouse。“虽然但是，啥。。。啥是 ClickHouse？”在数据库领域纵横八年的老司机 Carl 有些尴尬地问。。。其实这不怪 Carl，在2017年，ClickHouse 诞生不久，刚开始在社区里流行，还没有哪个像样的江湖大佬敢冒险选用这个年轻的“郭靖”，没听说过也再正常不过。可邪门的是，经过进一步测试，ClickHouse 读写数据的性能总是名列前茅，就像一个闪闪发光的急速机械臂，老师傅越看越爱。Carl 他们一合计，没人吃螃蟹，并不等于螃蟹不好吃啊。拍拍胸脯，我们先用呗！老师傅们就这样冲进了战场，用了两个月就基于 ClickHouse 搞出第一版数仓，交给一些敢于尝鲜的规模小一点的业务团队去用。刚才说过，ClickHouse 就像一个机械臂。可是一个完整的数仓，仅仅有机械臂还不行，还需要有系统负责多个机械臂之间的配合，还要有一系列措施保证机械臂的故障维修。可是，ClickHouse 自己都是初出茅庐，和它相配套的系统更没有经过大规模磨合检验，暗藏着五花八门的坑。。。当时一个大的数仓里能达到400-500个 ClickHouse 集群，集群之间要实现“高可用”，靠的是 Zookeeper 系统。这么多集群满负荷运行，压力就会集中在 Zookeeper 身上，弄不好就会挂掉。。。
要命的是，当时有些团队已经开始依赖这套系统，他们吃着火锅唱着歌查着数据，突然系统崩溃，那种感觉就像被麻匪劫了一样慌。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，就是刚才我们说的“数据旅行团”里的“导游”。具体来说，DataLeap 保证数据流程的方法，是通过各方签署“SLA”（服务级别协议 Service-Level Agreement）来实现的。假如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 里提前规定好：这样遇到问题的时候，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两组用户在真实世界里本来就有关系，是同事、家人、朋友，会口耳相传。但是，你又不能一组选在重庆一组选在新疆。因为这样两组样本本身差异太大，新疆人爱吃大盘鸡，不想要你的火锅底料。。。
你看，这些问题五花八门，但说到底他们要做的就是一件事儿——在“成本可控”的情况下，尽量保证“决策卫生”，从而把测试结果准确率无限推进到“理论极致”。所以，从2018年开始，数据科学家们在 Libra 里面内置了很多保证“决策卫生”的流程和功能。它们就像一个个“安全气囊”，保证不太懂统计科学的新手司机也能上秋名山飚车。。。显然，要实现全流程“穷游”，数据仓库同样需要技术升级。可是，数仓这东西非常精密，所有组件都紧紧咬合在一起，牵一发动全身，没办法“微整形”，要整就整“大手术”。
在2020年左右，ByteHouse 的各种小优化已经做到极致，拱不动了。Carl 他们咬咬牙——与其逃避命运，不如主动出击——决定对 ByteHouse 进行两场大手术。我们回到前面的比喻，把 ByteHouse 看做一个仓库。原本这个仓库是每一个货架（存储资源）旁边都站着一个固定机械臂（计算资源），需要这个货架上的数据，它就拿下来。但是可想而知，如果仓库规模不断变大，机械臂数量也会线性增多。然而，不是每个货架上的数据时刻都需要存取——大部分时间机械臂（计算资源）都在闲置中，资源浪费。所谓存算分离，就是把机械臂变成移动的，需要哪个货架上的数据，就过去拿。可想而知，这样的改造不仅能节省很多“机械臂”，还能腾出“货架”的空间。原本 ClickHouse 的任务分配模式是“树状”的：一个查询任务来了，就需要一个“工头”把任务分配给很多机械臂，它们把数据找来，再汇总给工头。可这样有个明显的缺点，就是工头一个人成为了系统的瓶颈，尤其是在数据汇总的时候，大家都把数据给它，它就会忙不过来。所谓“并行处理”，就是让机械臂们自己分别汇总，然后把汇总后的结果报给工头，就能大大缩短计算的时间。别看这两台手术从逻辑上听上去不难理解，但是要完成改造，需要深入数仓内部的最细节代码，相当于把每一颗螺丝都进行改造，再精巧地封装回去，难度直逼开颅手术——Carl 他们整整干了两年。就在 ByteHouse 做手术的时候，DataLeap 也没闲着。Brian 给我介绍了一个字节独创的理念，叫“数据的分布式自制”。举个例子，像抖音、今日头条这样的顶流业务，对数据的要求就是“变态级”的，哪怕数据晚到一秒钟，可能都是事故。可是对于字节内部刚刚孵化的小业务，就没必要这么较真，数据晚半个小时似乎也没问题。于是，DataLeap 就加入了一个功能，可以根据大家不同的容忍程度，自助调整数据链条的“松紧”。对数据要求严格，就必须在全链路的计算、存储、监控都下足本钱，成本自然就高；反之如果对数据时效要求不高，就可以坐慢车，大大节省成本。
比如，有些没人用的就数据会一直占据存储空间，可是团队却不舍得删，就像不敢扔家里的旧书，生怕哪天还要看。可是，存储用的硬盘却是实打实的成本啊！眼看每天都有新数据源源不断进来，存储资源成本越来越高。。。因为所有的数据链路都在 DataLeap 上创建，它就自然能知道哪些数据访问量比较高，哪些数据一直在“万年冷宫”。根据数据的热度，DataLeap 就能精准建议团队删除一些最冷的数据。这样一来，不仅存储成本大大降低，数据也可以在合适的机会被销毁。故事讲到这，我们的主角小红心的“数据旅行团”又有了新升级。首先，它的整个旅途在保证质量的情况下，会变得更便宜；其次，在完成所有旅程之后，它最终还会回归自然。直到这一刻，小红心才真正走完了它“驱动世界”的旅途。
给你看下全景图吧：
刚才我为了方便你理解，一直在强调“穷游”，好像老师傅都很抠门似的。但，这样磨炼极致的数据处理体系，难道仅仅是为了省钱吗？别忘了，数据是数字世界的石油——不仅仅是字节跳动需要数据石油，也不仅仅是互联网行业需要数据石油，我们现实世界里的工厂、饭店、机场、银行，千行百业全部都在源源不断地产生数据，他们当然也有权力使用数据石油。可问题在于：不同行业的“数据密度”是不同的。互联网行业天生泡在数据石油里，如中东土豪一样；但一些传统行业就像贫油国，有些数据并不丰富，有些开采难度较大。这种情况下，还要斥巨资建设数据处理体系，他们就没有动力了。。。换句话说，只有一个性价比足够高的数据处理体系，才能融入千行百业，帮助他们来开采自己的石油。字节这群老师傅忽然抬头，发现整个江湖之上，自己对于数据技术的处理已经到了独孤求败的地步。于是，高层慎重讨论，准备把这些年积累下来的各种技术开放出来，服务广大企业。2021年，数据老师傅们来了个一秒变装——从服务公司内部业务，转向服务衣食住行、千行百业。字节这些系统也来了个一秒变装——A/B 测试系统 Libra 改名为 DataTester，用户增长分析系统TEA 改名为 DataFinder，数据洞察工具风神改名为 DataWind、客户数据平台 Mirror 改名为 VeCDP，一起装在了叫做“VeDI”的数智平台里。其实，各行各业建设数据体系，本质上就是把字节走过的路重走一遍，火山引擎的价值恰恰是——字节踩过的10086个坑，不要再让其他公司踩。有很多非互联网企业，还没有自己的 App，或者 App 功能设计不完善。他们最急需的，就是第一步——收集“小红心”的能力。字节的一位同学告诉我，他们刚刚帮助领克汽车改进了 App 的设计，让领克的车主可以不用说话，仅仅通过在 App 里的各种操作就展现出他们的诉求，就像今日头条和抖音所做的那样。收集到了小红心，领克就可以做“A/B测试”，从而一点点改进对车主的服务。估计浅友里肯定有领克的车主，不知道你最近体验到变化没。领克还用火山引擎做了更多数据加工，篇幅有限就放在图里了。（点鸡可以变大）有了小红心，就到了第二步——建造小红心的“仓库”和“工厂”。2021年，Levi’s（李维斯）已经完成了用户数据库的建立，他们就让字节的老师傅们把数据接入了数据工厂——VeCDP（管理客户数据的平台）。这样一来，Levi’s 就把自己的客户分为六大人群体系，然后对每一类客户进行个性化的推荐和营销。这样不仅减少了对很多非核心用户的打扰，还能集中精力服务真正的目标用户。仓库和工厂都有了，接下来就是第三步——给小红心配“导游”。能走到第三步的企业，已经算是数据领域的佼佼者了，因为这说明他们的数据基础已经完备，开始考虑数据治理的问题了。（你还记得吧，字节也是在数据基础链路建设完整之后才重点搞数据治理的。）讲实话，目前这样的企业还真不多，“得到”就是其中之一。得到是很多爱智求真的小伙伴（比如我）手机里的C位 App。客观上来说，这些客户的消费能力还挺强的，所以他们使用得到 App 时产生的小红心（数据）的价值也很高，必须被重视，必须得到及时的响应。所以，得到对数据链路的 SLA 要求贼高，数据决不能迟到。2021年的时候，字节老师傅帮得到建设了 DataLeap 的数据体系，从此，数据不到位的情况大大减少。字节的同学还给我讲了好多案例，篇幅有限我就不给你转述了。很多客户没有专业的数据分析师，这时候 Libra 的傻瓜式操作就非常合适；各行各业使用数据的模式千奇百怪，ByteHouse 早年被锻炼出来的圆润皮实就发挥了作用；各个公司的数据发展水平不同，有的对数据质量要求高，有的对数据质量容忍度高，这个时候 DataLeap 的分布式治理功能恰恰能派上用场。
他们当年费力做了这么多细节功能，更多是出于纯粹的数据信仰。可是“纯粹”恰恰是改造世界最锋利的武器。那些默默的努力如今一下子灵魂附体。大概正如那歌词：“人生没有白走的路，每一步都算数”。原因其实也很简单，中国总体地大物“薄”，人均来看各种能源都谈不上丰富，漫长的时间里，我们可以依靠的只有每个人的勤劳和忍耐。正是这样的历史，造就了巨大的人口和统一的市场。而这两样，恰恰是数据的温床，孕育了最丰富的未来能源。在未来几十年，大概率会爆发一场波澜壮阔的“数据技术普及浪潮”，每一个公司都可以用低廉的价格购买一个高效的“数据处理引擎”，就像现在我们买汽车一样简单。也只有到了数据引擎遍地开花的时候，我们才真正拍胸脯说自己是奔跑在数据上的国家。坏消息是，我们目前的数据处理效率，还不能支撑那样的未来。Carl 告诉我，最近 ByteHouse 正准备研究一个智能化的黑科技：你还记得我们刚才说过，一个任务到达 ByteHouse 之后，要有一个工头来进行任务分配的吧。面对一个任务，究竟应该召唤出多少个“机械臂”去执行子任务呢？如果太多就会浪费算力，如果太少就会拖延时间。可未来 ByteHouse 进一步渗入各行各业，计算任务会变得更加五花八门，都采用“默认任务分配策略”就不合适了。所以，黑科技就是：根据现场情况，自动测算最合适的“并行度”来分配任务。比如在 DataTester（Libra） 里，目前所有的指标都是分析师自己凭脑袋瓜想出来的。但 Albert 告诉我，他们正在尝试研究一种技术，可以通过历史数据和行业属性自动向分析师推荐：“要不要试试这样构建指标？”这样的智能建议如果足够靠谱，那么各行各业就会进一步摆脱对专业分析师的依赖，利用数据的门槛随之大幅下降。Brian 说，过去的 DataLeap 在发现某个数据流卡住的时候（一般是半夜），都会马上打电话叫醒响应团队的方方面面好几位负责人，但很多情况下能解决问题的就是其中一个人。通过数据智能研判这个拥堵具体是由那个小分队造成的，直接给这一个人负责人来精准的“夺命连环 Call”，别人该睡还睡。举了这三个例子，可能你已经看出来了，未来数据技术发展的一大方向就是“数据处理的智能化”。智能化浪潮的意义，堪比汽车从手动挡进化成自动挡一样，瞬间让很多没信心开车的人也能学开车了。除了“智能化”，未来数据处理还会越来越“实时化”。以前的“小红心旅行”短则几个小时，长则几天，但是在很多场景下，我们等不了这么久：比如，你搜索了一件衣服，下一秒你就希望电商马上给你推荐相似的款式；比如，火电厂周围的风向变了，就需要马上调整空冷岛风扇的转速，补偿风向对散热的影响；比如，居民的用电情况发生改变，就需要马上调整电网输送功率，保持供电用电平衡。
当延迟以毫秒计数，数据就会组成一条奔腾的大河。而在大河两岸，新的文明得以被滋养。虽然有点俗，但我的梦想就是通过产品化的方式，让未来更多的人能够用到数据。人做的事情越来越少，自动化越来越多，直到人类从一条条数据链路中被完全解放出来。
二十多年前，互联网出现；十多年前，智能手机普及；而建立在这些基础之上数据世界，仍是蹒跚的孩子。一个孩子已经如此强悍，我有理由相信，更多奇迹已经预定了我们的未来。从荒芜到轰鸣，如今数字世界的一切都由一行行微小而具体的代码堆砌而成，过去走到现在并无捷径。由此想见，由现在走到未来也没有捷径。这可能是一场漫长的数据长征。老师傅只能前赴后继，用一行行代码代替脚步，去丈量大地。但好在，代码是数字世界的砖石，它一旦创生，就再也不会消逝，我们每向前走一步，就离终点更近一步。延伸阅读：
《你在被窝里刷手机岁月静好，一个“神秘引擎”却在远方和时间赛跑》
《我遇到一群想把机器人训练成艺术家的人》
《薯条大份更划算？？狂买KFC/麦当劳/汉堡王后，我整理出了终极省钱攻略…》
![]()
用数据
再自我介绍一下吧。我叫史中，是一个倾心故事的科技记者。我的日常是和各路大神聊天。如果想和我做朋友，可以搜索微信：shizhongmax。
哦对了，如果喜欢文章，请别吝惜你的“在看”或“分享”。让有趣的灵魂有机会相遇，会是一件很美好的事情。
Thx with ![]()
in Beijing
文章来源: http://mp.weixin.qq.com/s?__biz=MzU0NDEwMTc1MA==&mid=2247519842&idx=1&sn=f0708a66465a3d1546fab33cce405224&chksm=fb038a7bcc74036daaef946ce44f141c6086cb99108ecb7411f1b049234af470d75942f7caa9#rd
如有侵权请联系:admin#unsafe.sh
