诶，不许动！就在这个普通得不能再普通的日常瞬间，中哥按一下暂停，问你一个问题：你知道这颗“小红心”后来去哪儿了吗？
小红心当然没有随风飘散，而是开启了一场冒险之旅——论路途，它接下来要走的路，也许比玄奘西行还要曲折；论结局，它将汇入奔涌的数据洪流，组成数字世界赖以运转的“真经”。
我们今天的故事，就讲讲这颗小红心的“硬核奇幻漂流”。
（一）对“小红心”最为礼遇的人
在讲小红心的冒险之前，请原谅我稍稍多交代几句背景——说一个坏消息和一个好消息。
先说坏消息吧。
罗永浩早年在吉林大学演讲时曾对孩子们说过这样一段话：
我时常想起这句话，不仅因为它会在我邪念萌发的时候勉励我做个好人，更因为它背后藏着一个有趣的模型：
我们每个人的脑袋瓜里都有一个“投票器”，无论大事小情，只要面对岔路口，都会用“投票器”抉择一下。
一个人一生几亿次投票汇总下来，其实就是他的墓志铭；而无数人的墓志铭汇总起来，就是我们世界的历史线。
如此看来，我们颅内的每一次渺小“投票”都像是给世界输入了一个“数据”，最终会导致这个世界输出的“结果”有一丝丝偏转。
可坏消息来了：我们的物理世界是没有“存证机制”的。
你做了好事不一定被人看到，被人看到不一定被理解，被理解不一定被赞扬，被赞扬不一定被效仿，被效仿时又不一定被下一个人看到。。。于是，这种“数据”的传递慢得惊人，留存准确度也低得惊人。
以至于，“善恶有报”这件事情虽然在逻辑上隐约成立，却在一个人的生命跨度里基本无法被观测到。
。
。
。
。
。
接下来说好消息吧。
2022年的我们，不是全无选择——除了破旧的物理世界，还有崭新的数字世界。
在数字世界里，事情就大快人心得多。每一个字节的数据都可以被分毫不爽地高速传递，进而确定性地、可以量化地对这个世界造成改变。
这么说有点抽象，举个栗子吧：
在物理世界，你看到一个人扶起了摔倒的老奶奶，你对着他比了一个赞，然后就没有然后了。
你看，正是有了数据，数字世界才有了比现实世界更大的演化动力。所以，把数据称为数字世界的石油简直不要太合适。
遗憾的是，纵然数据是个宝，但不同人对它的态度是不同的。
就像石油一样：在原始部落看来这就是黑乎乎的沼泽，弃之如敝履，因为他们无法利用；但对于工业体系完善的国家来说，就会对石油颇为“礼遇”，因为他们懂得如何冶炼它。
那么此时此刻的数字世界，对数据最为礼遇，最会从数据中提炼能源的是谁呢？
要我说，四舍五入就是抖音的母公司，字节跳动。
我认识的字节跳动的老师傅不算多。但这些人却有一点出奇地相似，就是他们都极其尊重数据，甚至说“信仰数据”也不过分。你看，2012年他们起名的时候就把公司直接叫成了数据的计量单位“字节”，可见从第一集就奔着西天取经去了。。。
这几年字节的老师傅们开发了好多有趣的技术，目的就是“三最”——用最高的规格，把数据冶炼成最纯的能源，为用户发挥出最大的价值。
这些技术，组成了一个“旅行社”，把小红心的旅途安排得明明白白。
好了，估计你已经对小红心的奇幻之旅有那么一点好奇了~~为了深刻体会数据技术的历史脉络，我决定带你重走一遍老师傅的取经路。
咱们先坐上时光机，回到2015年吧。
（二）老师傅的“开挂系统”
这颗“小红心”的旅程可能是酱的：
1、它睁开了双眼，还没来得透过屏幕仔细看清主人的模样，就嗖地一下被甩到空中。空中的基站像弹弓一样，迅雷不及掩耳盗铃地把它弹射到轰鸣的服务器中。
2、在服务器中，小红心见到了和它一样的来自各地的数据，它们列队整齐，被安排入住在一个叫做”数据库“的巨大酒店里。
3、这个大酒店里好吃好喝，但就是有些寂寞，各个数据也相互不见面。小红心本以为自己就要在这里颐养天年了。但是，几天之后，它却收到邀请，要去参加一个有趣的游戏。
原来，字节的老师傅们写了一个系统，用来把“A组文章”和“B组文章”的阅读情况分别进行汇总。
你可能有点懵，这是在玩啥？
不瞒你说，这是字节这群老师傅在练绝招：“A/B测试”。
不知道。
不知道不要紧，事实是检验真理的唯一标准。
看到这，你可能撇嘴：这不就是简单的对比实验么，算啥绝招？
客官有所不知，“A/B测试”从实验设计到数据汇总，是一个贼拉费劲儿的事情。
你遇到“午饭吃麦当劳还是肯德基”这样的抉择，肯定不会做个实验，把两家的汉堡薯条都买来，对比谁家的薯条多，谁家的汉堡大，你最多扔个鞋决定一下也就完事儿了，只有遇到重大抉择才会想到用“A/B”来严肃地解决。
可字节这群人却都是“A/B狂人”，买汉堡前先做实验这种事儿他们没准还真能干出来。。。
在字节公司内部，流传着一个“黑话”——遇事不决用A/B。
大到推荐引擎的策略调整，小到App里一个按钮的位置摆放，各种改进，总要设计个实验看看回收数据才能放心，可见“数据测试”已经写入这帮人的DNA了。。。
在AB两种策略里选优就相当于——“这里打得不好，读档重来再打一次”，每次都在“打得好的那一版”的基础上继续往前打。
最终，一点点优势累计，就必然形成数学上的巨大胜率。相比其他一条命拼到死的竞争对手，你说它不胜出谁胜出？
所以，“用A/B”不是绝招，“总用A/B”才是绝招。
可字节跳动这帮人“开挂”也不是没有代价。还是刚才说的，实验设计太太太太太费功夫。。。
我们把刚才几张图拼成完整的流程，你感受一下：
如今字节数据平台负责人罗旋在2014年加入公司。
他还记得那个“震撼”景象：所有的数据报表都是同事们用邮件传来传去，手动比对分析。
这种小米加步枪的状态下，负责技术的老师傅就比较惨：
今天A团队为了把这堆数据捞回来，要请技术老师傅写一堆代码；明天B团队要把那堆数据捞回来，又得请老师傅重新写一堆代码。。。
老师傅长期被“请”，疲于奔命，秀发早晚不保啊。。。
不行，老师傅们一合计，得赶快开发出一套“A/B测试工具”——甭管是哪个团队，想测啥事儿，直接把系统拿去用，最好别霸占俺们的“肉身”。
Albert，就在这个“秀发保卫战”前不久加入字节，负责开发这个名叫“Libra”（天平）的A/B测试工具。
造这个工具的难点是啥呢？
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自己都是初出茅庐，和它相配套的系统更没有经过大规模磨合检验，暗藏着五花八门的坑。。。
Carl回忆。
要命的是，当时有些团队已经开始依赖这套系统，他们吃着火锅唱着歌查着数据，突然系统崩溃，那种感觉就像被麻匪劫了一样慌。
Carl他们也惊出一身冷汗，把伙伴置于危险境地那妥妥有损技术人的尊严啊，这种事儿决不能发生——他们当即使出单身30年的手速，写了一套临时脚本硬生生扛住。
脚本就像临时缠上的胶带，毕竟不是长久之计。
他们只能左右开弓：
左手维护脚本，右手开始写一套永久的高可用方案。
几周之后，新方案火速上线替换掉临时脚本，才算灭火成功。。。
用几个机器人把Zookeeper的任务分担下来。
可是，汗还没来得及擦，新的“险情”又来了。
虽说数仓的建立本来就是为了让人查询各种奇怪的数据。可有些业务团队的脑洞过大，查数据的姿势堪比瑜伽——总让机械臂去够架子边缘的箱子。。。
数仓又不可能躺在椅子上翘腿说：“你查的这个数据太怪了，我不想给你找。”
它只能勉为其难去查，这一下不要紧，机械臂触发Bug“扭了腰”，整个系统就被搞挂了。
Carl他们一开始的想法是，预测一下大家都会用什么怪姿势使用数仓，后来他发现自己天真了：
调用数仓的这群人脑洞可太大了，老师傅根本猜不到他们会怎么出牌，只能遇到一个问题修复一个问题——Bug难免有，及时修好下次不犯就是好同志。
数仓挂掉，业务团队多少是能容忍的，可伴随而来的另一件事儿他们却忍不了：
每一次数仓“因病”去世（挂掉），再投胎转世（重启）都需要十来分钟，这等不起啊。。。
Carl他们猛然意识到，数仓的“重启速度”这种细节，也妥妥是性能的重要组成部分！
老师傅赶紧研究，他们发现数仓重启之所以需要转圈圈那么久，就是因为读取“元信息”的过程比较繁琐，干脆一不做二不休，专门写了一套程序把这些信息存盘管理起来。
需要重启的时候，直接读取这一整套数据，又干净又卫生。
你发现没，那个阶段Carl他们做的事情，好像哪件都说不上惊天动地。但是，如果没有几百个核心业务每天在数仓上反复摩擦，你还真没办法把这些问题都发现，也没办法解决得这么圆润。。。
这个“圆润”，同样为未来埋下了伏笔，我们一会儿再说。
我们的故事快进到2018年，此时Carl他们已经陆续给ClickHouse增加了几百项大小改动，使得“字节版”的ClickHouse已经和母胎的“社区版”有很大区别了，于是他们决定给自己的ClickHouse起个新名，叫做ByteHouse。
这一年，也是Carl最开心的一年。因为随着ByteHouse肉眼可见越来越好用，公司内很多团队的数据工厂都纷纷把ByteHouse数仓作为自己数据处理的重要一环。
更让Carl高兴的是，在业界很多大公司也纷纷开始选择ClickHouse作为数仓核心组件。
ByteHouse出场之后，我们不妨再来看我们的主角“小红心”，它的“奇幻旅程”就和前几年明显不同了。
注意，我画的这个旅游线路是“极简版”。
在实际的“数据旅行”中，计算一个数据没有这么简单。
小红心很可能要在“宾馆”（数据库）“仓库”（数仓）和工厂“数据应用”中来回穿梭，中途要换好几次“大巴”，还要和不同的数据“组团”——一趟旅途分成几百段都很正常。
参加过旅行团的浅友都有过这样的经历：集体坐大巴的时候，总有个别人因为五花八门的理由迟到，一车人只好坐在那里干等，这会大大降低旅行团的行进效率。。。
没错，在“数据旅行团”中，这种事儿同样会发生。。。
就在2018年，随着数据处理流程越来越复杂，老师傅们发现，数据该出现不出现，该发车不发车的情况越来越多。
比如，抖音规定有些报表早晨9点就要计算出来，可是前面的数据没出来，指标就填不进去——将军看不到地图，这仗难道要“盲打”了吗？
数据旅行团的问题，也可以从现实旅行团身上借鉴答案。
没错，数据旅行团需要一个“导游”，而且是一个严厉的导游，谁迟到就打谁屁屁的那种！
（四）数据旅行团的“导游”
“字节有一个很牛的文化，你知道是什么吗？是拉群。”Brian笑着给我讲。
“当年，遇到‘数据流程卡住’的问题，你只要把相关负责人拉到一个群，他们就会神奇地行动起来，自己协商出办法把问题给解决！自驱力杠杠的。”
可问题就在于，“一腔热血”不能解决所有问题。
拉群办事，靠的毕竟是肉身，就像在数据流程的水管破口上用手指头按住那样↓↓↓
可随着数据应用变多，发现的破口越来越多——每次出问题就多拉一个群，到后来，相关负责人手机里的群已经密密麻麻，老师傅们的手指头不够用了↓↓↓
结论很明显：靠人力解决“数据治理”的难题，长远来看根本不可取。
这里，就是Brian和他的同事们展现实力的时刻了。
哦还没给你介绍，Brian是字节跳动数据治理工具DataLeap的负责人。这个DataLeap，就是刚才我们说的“数据旅行团”里的“导游”。
Brian
具体来说，DataLeap保证数据流程的方法，是通过各方签署“SLA”（服务级别协议Service-LevelAgreement）来实现的。
啥是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问我。
“那。。。应该是越多越好吧。”我说。
他说。
“要这么说，样本数量就不能太大，选1万人。”我说。
“1万人测试出来的结果，一定会和1亿人测试的结论相同吗？”他反问。
“那就。。。每次实验选1万人，连续做5次实验，5次结果相互印证，会不会好一点？”我有点心虚。
“你看，这就是问题所在。当样本规模变小的时候，这就变成了一个统计科学问题了。告诉你答案，从统计学的角度来看，‘5万人做5次’的结果并不比‘5万人做1次’的结果更准确。”Albert笑。
“等等，让我捋捋。。。”话聊到这儿，我已经在晕菜的边缘徘徊了。
“其实，我们这些做代码工程出身的，一开始统计学知识也不够。但是从2018年开始，我们意识到自己的局限性，引进了很多数据科学家，我讲的这些结论是跟他们学习以后才明白的。”Albert安慰脆弱的我。
看我的表情还残存一丝倔强，Albert又给我讲了几个栗子：
比如“样本污染问题”。
再比如“分组干扰问题”。
你看，这些问题五花八门，但说到底他们要做的就是一件事儿——在“成本可控”的情况下，尽量保证“决策卫生”，从而把测试结果准确率无限推进到“理论极致”。
所以，从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个坑，不要再让其他公司踩。
老师傅发现，他们要做的还是老三样：
举几个栗子吧。
有很多非互联网企业，还没有自己的App，或者App功能设计不完善。
他们最急需的，就是第一步——收集“小红心”的能力。
收集到了小红心，领克就可以做“A/B测试”，从而一点点改进对车主的服务。
你看，数据链条就这样缓慢地转动起来。
估计浅友里肯定有领克的车主，不知道你最近体验到变化没。
领克还用火山引擎做了更多数据加工，篇幅有限就放在图里了。（点鸡可以变大）
有了小红心，就到了第二步——建造小红心的“仓库”和“工厂”。
2021年，Levi’s（李维斯）已经完成了用户数据库的建立，他们就让字节的老师傅们把数据接入了数据工厂——VeCDP（管理客户数据的平台）。
这样一来，Levi’s就把自己的客户分为六大人群体系，然后对每一类客户进行个性化的推荐和营销。
这样不仅减少了对很多非核心用户的打扰，还能集中精力服务真正的目标用户。
仓库和工厂都有了，接下来就是第三步——给小红心配“导游”。
能走到第三步的企业，已经算是数据领域的佼佼者了，因为这说明他们的数据基础已经完备，开始考虑数据治理的问题了。（你还记得吧，字节也是在数据基础链路建设完整之后才重点搞数据治理的。）
讲实话，目前这样的企业还真不多，“得到”就是其中之一。
得到是很多爱智求真的小伙伴（比如我）手机里的C位App。
客观上来说，这些客户的消费能力还挺强的，所以他们使用得到App时产生的小红心（数据）的价值也很高，必须被重视，必须得到及时的响应。
所以，得到对数据链路的SLA要求贼高，数据决不能迟到。
这不正好是DataLeap的用武之地么？
2021年的时候，字节老师傅帮得到建设了DataLeap的数据体系，从此，数据不到位的情况大大减少。
字节的同学还给我讲了好多案例，篇幅有限我就不给你转述了。
草灰蛇线伏脉千里，你还记得我们之前的那些伏笔么？
他们当年费力做了这么多细节功能，更多是出于纯粹的数据信仰。可是“纯粹”恰恰是改造世界最锋利的武器。
那些默默的努力如今一下子灵魂附体。大概正如那歌词：“人生没有白走的路，每一步都算数”。
（七）没有尽头的数据长征
熟悉中哥的人都知道，我是一个“数据技术信仰者”。
原因其实也很简单，中国总体地大物“薄”，人均来看各种能源都谈不上丰富，漫长的时间里，我们可以依靠的只有每个人的勤劳和忍耐。
正是这样的历史，造就了巨大的人口和统一的市场。而这两样，恰恰是数据的温床，孕育了最丰富的未来能源。
从这个角度看来，我们终究得到了历史的一些眷顾。
在未来几十年，大概率会爆发一场波澜壮阔的“数据技术普及浪潮”，每一个公司都可以用低廉的价格购买一个高效的“数据处理引擎”，就像现在我们买汽车一样简单。
也只有到了数据引擎遍地开花的时候，我们才真正拍胸脯说自己是奔跑在数据上的国家。
坏消息是，我们目前的数据处理效率，还不能支撑那样的未来。
好消息是，老师傅们仍在继续努力。
Carl告诉我，最近ByteHouse正准备研究一个智能化的黑科技：
你还记得我们刚才说过，一个任务到达ByteHouse之后，要有一个工头来进行任务分配的吧。
面对一个任务，究竟应该召唤出多少个“机械臂”去执行子任务呢？如果太多就会浪费算力，如果太少就会拖延时间。
当前的解决方案比较粗暴，就是手动设定的默认值。
可未来ByteHouse进一步渗入各行各业，计算任务会变得更加五花八门，都采用“默认任务分配策略”就不合适了。
所以，黑科技就是：根据现场情况，自动测算最合适的“并行度”来分配任务。
这种润物细无声的“智能化”还发生着在很多地方。
比如在DataTester（Libra）里，目前所有的指标都是分析师自己凭脑袋瓜想出来的。
但Albert告诉我，他们正在尝试研究一种技术，可以通过历史数据和行业属性自动向分析师推荐：“要不要试试这样构建指标？”
这样的智能建议如果足够靠谱，那么各行各业就会进一步摆脱对专业分析师的依赖，利用数据的门槛随之大幅下降。
DataLeap也有类似的黑科技。
Brian说，过去的DataLeap在发现某个数据流卡住的时候（一般是半夜），都会马上打电话叫醒响应团队的方方面面好几位负责人，但很多情况下能解决问题的就是其中一个人。
所以DataLeap正在研究的黑科技就是：
通过数据智能研判这个拥堵具体是由那个小分队造成的，直接给这一个人负责人来精准的“夺命连环Call”，别人该睡还睡。
“提升大家的幸福感嘛！”Brian笑。
举了这三个例子，可能你已经看出来了，未来数据技术发展的一大方向就是“数据处理的智能化”。
智能化浪潮的意义，堪比汽车从手动挡进化成自动挡一样，瞬间让很多没信心开车的人也能学开车了。
除了“智能化”，未来数据处理还会越来越“实时化”。
以前的“小红心旅行”短则几个小时，长则几天，但是在很多场景下，我们等不了这么久：
表的要求越来越高，小红心整个旅途可能在几秒内就得完成。（可以参考我写过的《你在被窝里刷手机岁月静好，一个“神秘引擎”却在远方和时间赛跑》）
当延迟以毫秒计数，数据就会组成一条奔腾的大河。而在大河两岸，新的文明得以被滋养。
就像下面这张完整版大图：
Brian说。
我想了半天：“你这梦想已经不俗了吧？”
告别字节的老师傅们，我忍不住掰着手指头计算。
20多年前，互联网出现；10多年前，智能手机普及；而建立在这些基础之上数据世界，仍是蹒跚的孩子。
一个孩子已经如此强悍，我有理由相信，更多奇迹已经预定了我们的未来。
但成长从来并非易事。
从荒芜到轰鸣，如今数字世界的一切都由一行行微小而具体的代码堆砌而成，过去走到现在并无捷径。由此想见，由现在走到未来也没有捷径。
这可能是一场漫长的数据长征。老师傅只能前赴后继，用一行行代码代替脚步，去丈量大地。
但好在，代码是数字世界的砖石，它一旦创生，就再也不会消逝，我们每向前走一步，就离终点更近一步。
延伸阅读：
《你在被窝里刷手机岁月静好，一个“神秘引擎”却在远方和时间赛跑》
《我遇到一群想把机器人训练成艺术家的人》
《薯条大份更划算？？狂买KFC/麦当劳/汉堡王后，我整理出了终极省钱攻略…》
