你在抖音上點的“小紅心”到底去哪了？

　　文 | 史中

　　作為祖國四化建設的接班人，張三睡前喜歡在抖音上刷 妹子 科普短視頻。

　　看到一個不錯的視頻，他按捺不住沖動，野性雙擊點了個贊。看著那個小紅心從屏幕上飄出來，一閃即散。

　　張三暗暗點頭，仿佛和屏幕里的主播心意相通，指尖順勢一滑準備看下一個視頻。

　　誒，不許動！就在這個普通得不能再普通的日常瞬間，中哥按一下暫停，問你一個問題： 你知道這顆“小紅心”后來去哪了嗎？

　　小紅心當然沒有隨風飄散，而是開啟了一場冒險之旅—— 論路途，它接下來要走的路，也許比玄奘西行還要曲折；論結局，它將匯入奔涌的數據洪流，組成數字世界賴以運轉的“真經”。

　　我們今天的故事，就講講這顆小紅心的“硬核奇幻漂流”。

　?。ㄒ唬?ldquo;小紅心”最為禮遇的人

　　在講小紅心的冒險之前，請原諒我稍稍多交代幾句背景——說一個壞消息和一個好消息。

　　先說壞消息吧。

　　羅永浩早年在吉林大學演講時曾對孩子們說過這樣一段話：

　　如果你的一生沒有做出偉大的事業，沒有賺到錢也沒有出名，但是一生耿直剛正不阿，拼著老命把家人照顧好了，梗著脖子去世了，你這一生有沒有改變世界？還是改變了，因為這個世界上多了一個好人。

　　我時常想起這句話，不僅因為它會在我邪念萌發的時候勉勵我做個好人，更因為它背后藏著一個有趣的模型：

　　我們每個人的腦袋瓜里都有一個“投票器”，無論大事小情，只要面對岔路口，都會用“投票器”抉擇一下。

 

　　一個人一生幾億次投票匯總下來，其實就是他的墓志銘；而無數人的墓志銘匯總起來，就是我們世界的歷史線。

　　如此看來， 我們顱內的每一次渺小“投票”都像是給世界輸入了一個“數據”，最終會導致這個世界輸出的“結果”有一絲絲偏轉。

 

　　可壞消息來了：我們的物理世界是沒有 “存證機制”的。

　　你做了好事不一定被人看到，被人看到不一定被理解，被理解不一定被贊揚，被贊揚不一定被效仿，被效仿時又不一定被下一個人看到。。。于是，這種“數據”的傳遞慢得驚人，留存準確度也低得驚人。

　　以至于，“善惡有報”這件事情雖然在邏輯上隱約成立，卻在一個人的生命跨度里基本無法被觀測到。

 

　　接下來說好消息吧。

　　2022年的我們，不是全無選擇——除了破舊的物理世界，還有嶄新的數字世界。

　　在數字世界里，事情就大快人心得多。每一個字節的數據都可以被分毫不爽地高速傳遞，進而確定性地、可以量化地對這個世界造成改變。

　　這么說有點抽象，舉個栗子吧：

　　在物理世界，你看到一個人扶起了摔倒的老奶奶，你對著他比了一個贊，然后就沒有然后了。

　　可是在抖音上，你看到一個人扶起了摔倒老奶奶的視頻，你點了一個贊，這個贊就會像一枚鋼印刻在數據庫里，推動系統把這個視頻推薦給更多人看，最終成為更多人心頭的一個善念。

　　你看，正是有了數據，數字世界才有了比現實世界更大的演化動力。所以，把數據稱為數字世界的石油簡直不要太合適。

 

　　遺憾的是，縱然數據是個寶，但不同人對它的態度是不同的。

　　就像石油一樣：在原始部落看來這就是黑乎乎的沼澤，棄之如敝履，因為他們無法利用；但對于工業體系完善的國家來說，就會對石油頗為“禮遇”，因為他們懂得如何冶煉它。

　　那么此時此刻的數字世界，對數據最為禮遇，最會從數據中提煉能源的是誰呢？

　　要我說，四舍五入就是抖音的母公司，字節跳動。

　　我認識的字節跳動的老師傅不算多。但這些人卻有一點出奇地相似，就是他們都極其尊重數據，甚至說 “信仰數據”也不過分。你看，2012年他們起名的時候就把公司直接叫成了數據的計量單位“字節”，可見從第一集就奔著西天取經去了。。。

　　這幾年字節的老師傅們開發了好多有趣的技術，目的就是 “三最”——用 最高的規格，把數據冶煉成 最純的能源，發揮出 最大的價值。

　　這些技術，組成了一個“旅行社”，把小紅心的旅途安排得明明白白。

　　好了，估計你已經對小紅心的奇幻之旅有那么一點好奇了~~為了深刻體會數據技術的歷史脈絡，我決定帶你重走一遍老師傅的取經路。

　　咱們先坐上時光機，回到2015年吧。

　　（二）老師傅的“開掛系統”

　　2015年，抖音還沒出生。但沒關系，它的大哥今日頭條已經誕生了。假設有人給某篇頭條文章點了贊，也會產生一顆小紅心。

　　這顆“小紅心”的旅程可能是醬的：

　　1、它睜開了雙眼，還沒來得透過屏幕仔細看清主人的模樣，就嗖地一下被甩到空中?？罩械幕鞠駨椆粯樱咐撞患把诙I鈴地把它彈射到轟鳴的服務器中。

　　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秒雖說不長，可分析師不是一天只看一個指標啊，他的工作就是每時每刻看指標。這一天下來，光等就等到頹廢。。。

　　歷史喜歡開玩笑——就在工具不怎么湊手的檔口，卻偏偏來了個大活兒！

　?。ㄈ?ldquo;查數”神器

　　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 的任務分擔下來。

　　可是，汗還沒來得及擦，新的“險情”又來了。

　　雖說數倉的建立本來就是為了讓人查詢各種奇怪的數據?？捎行I務團隊的腦洞過大，查數據的姿勢堪比瑜伽——總讓機械臂去夠架子邊緣的箱子。。。

　　數倉又不可能躺在椅子上翹腿說：“你查的這個數據太怪了，我不想給你找。”

　　它只能勉為其難去查，這一下不要緊，機械臂觸發 Bug “扭了腰”，整個系統就被搞掛了。

　　Carl 他們一開始的想法是，預測一下大家都會用什么怪姿勢使用數倉，后來他發現自己天真了：

　　調用數倉的這群人腦洞可太大了，老師傅根本猜不到他們會怎么出牌，只能遇到一個問題修復一個問題——Bug 難免有，及時修好下次不犯就是好同志。

　　數倉掛掉，業務團隊多少是能容忍的，可伴隨而來的另一件事兒他們卻忍不了：

　　每一次數倉“因病”去世（掛掉），再投胎轉世（重啟）都需要十來分鐘，這等不起啊。。。

　　Carl 他們猛然意識到，數倉的“重啟速度”這種細節，也妥妥是性能的重要組成部分！

　　老師傅趕緊研究，他們發現數倉重啟之所以需要轉圈圈那么久，就是因為讀取“元信息”的過程比較繁瑣，干脆一不做二不休，專門寫了一套程序把這些信息存盤管理起來。

　　需要重啟的時候，直接讀取這一整套數據，又干凈又衛生。

　　你發現沒，那個階段 Carl 他們做的事情，好像哪件都說不上驚天動地。但是，如果沒有幾百個核心業務每天在數倉上反復摩擦，你還真沒辦法把這些問題都發現，也沒辦法解決得這么圓潤。。。

　　這個 “圓潤”，同樣為未來埋下了伏筆，我們一會兒再說。

　　我們的故事快進到2018年，此時 Carl 他們已經陸續給 ClickHouse 增加了幾百項大小改動，使得“字節版”的 ClickHouse 已經和母胎的“社區版”有很大區別了，于是他們決定給自己的 ClickHouse 起個新名，叫做 ByteHouse。

　　這一年，也是 Carl 最開心的一年。因為隨著 ByteHouse 肉眼可見越來越好用，公司內很多團隊的數據工廠都紛紛把 ByteHouse 數倉作為自己數據處理的重要一環。

　　更讓 Carl 高興的是，在業界很多大公司也紛紛開始選擇 ClickHouse 作為數倉核心組件。

　　這種感覺，就像你在網易云發現了一首評論寥寥的寶藏歌曲，幾年后卻發現評論已經十萬加，所有人都在聽——一種“老子就是有眼光 ”的感覺油然而生。

　　ByteHouse 出場之后，我們不妨再來看我們的主角“小紅心”，它的“奇幻旅程”就和前幾年明顯不同了。

　　張三給一個視頻點了小紅心，小紅心誕生之后，會先入住數據庫這個“賓館”；

　　然后它會從賓館出來，進入 ByteHouse 這個碩大的“倉庫”，和來自其他“賓館”的數據匯合在一起；

　　接下來，小紅心才會根據調遣進入功能各異的數據工廠，用自己的身軀組成報表；

　　當然，如果有必要，一些報表會繼續進入那個“A/B測試”的神器 Libra，最終為這個數字世界里的每一個決策提供依據。

　　注意，我畫的這個旅游線路是“極簡版”。

　　在實際的“數據旅行”中，計算一個數據沒有這么簡單。

　　小紅心很可能要在“賓館”（數據庫）“倉庫”（數倉）和工廠“數據應用”中來回穿梭，中途要換好幾次“大巴”，還要和不同的數據“組團”——一趟旅途分成幾百段都很正常。

　　參加過旅行團的淺友都有過這樣的經歷：集體坐大巴的時候，總有個別人因為五花八門的理由遲到，一車人只好坐在那里干等，這會大大降低旅行團的行進效率。。。

　　沒錯，在“數據旅行團”中，這種事兒同樣會發生。。。

　　就在2018年，隨著數據處理流程越來越復雜，老師傅們發現，數據該出現不出現，該發車不發車的情況越來越多。

　　比如，抖音規定有些報表早晨9點就要計算出來，可是前面的數據沒出來，指標就填不進去——將軍看不到地圖，這仗難道要“盲打”了嗎？

　　數據旅行團的問題，也可以從現實旅行團身上借鑒答案。

　　沒錯，數據旅行團需要一個 “導游”，而且是一個嚴厲的導游，誰遲到就打誰屁屁的那種！

　?。ㄋ模祿眯袌F的“導游”

　　“字節有一個很牛的文化，你知道是什么嗎？是拉群。”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測試的就有這么多，那么每時每刻產生的總報表數就更多了，進而，底層的數倉和數據庫被調用的次數就更更更多了。

　　這種情況下，老師傅反倒比以前壓力更大，各個環節都被倒逼要優化“數據旅行”的支出——又讓馬兒跑，又得馬兒不吃草。

　　小紅心必須得“窮游”了↓↓↓

　?。ㄎ澹└F游的小紅心

　　“問你個問題，每個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 給我介紹了一個字節獨創的理念，叫 “數據的分布式自制”。

　　這是啥呢？

　　舉個例子，像抖音、今日頭條這樣的頂流業務，對數據的要求就是“變態級”的，哪怕數據晚到一秒鐘，可能都是事故?？墒菍τ谧止潈炔縿倓偡趸男I務，就沒必要這么較真，數據晚半個小時似乎也沒問題。

　　于是，DataLeap 就加入了一個功能，可以根據大家不同的容忍程度，自助調整數據鏈條的“松緊”。

　　“干嘛要調，不是數據傳遞越快越好嗎？”我問。

　　因為時間就是金錢。

　　對數據要求嚴格，就必須在全鏈路的計算、存儲、監控都下足本錢，成本自然就高；

　　反之如果對數據時效要求不高，就可以坐慢車，大大節省成本。

　　他說。

　　就像這樣，飛機火車汽車隨便挑。

　　Brian 他們搞出的“摳門”操作還有很多。

　　比如，有些沒人用的就數據會一直占據存儲空間，可是團隊卻不舍得刪，就像不敢扔家里的舊書，生怕哪天還要看。

　　可是，存儲用的硬盤卻是實打實的成本?。⊙劭疵刻於加行聰祿丛床粩噙M來，存儲資源成本越來越高。。。

　　DataLeap 一看，這個事兒我能幫忙??！

　　因為所有的數據鏈路都在 DataLeap 上創建，它就自然能知道哪些數據訪問量比較高，哪些數據一直在“萬年冷宮”。根據數據的熱度，DataLeap 就能精準建議團隊刪除一些最冷的數據。

　　這樣一來，不僅存儲成本大大降低，數據也可以在合適的機會被銷毀。

　　故事講到這，我們的主角小紅心的“數據旅行團”又有了新升級。

　　首先，它的整個旅途在保證質量的情況下，會 變得更便宜；

　　其次，在完成所有旅程之后，它最終還會 回歸自然。直到這一刻，小紅心才真正走完了它“驅動世界”的旅途。

　　給你看下全景圖吧：

　　剛才我為了方便你理解，一直在強調“窮游”，好像老師傅都很摳門似的。但，這樣磨煉極致的數據處理體系，難道僅僅是為了省錢嗎？

　　當然不是。

　　別忘了， 數據是數字世界的石油——不僅僅是字節跳動需要數據石油，也不僅僅是互聯網行業需要數據石油， 我們現實世界里的工廠、飯店、機場、銀行，千行百業全部都在源源不斷地產生數據，他們當然也有權力使用數據石油。

　　可問題在于：不同行業的 “數據密度”是不同的?；ヂ摼W行業天生泡在數據石油里，如中東土豪一樣；但一些傳統行業就像貧油國，有些數據并不豐富，有些開采難度較大。

　　這種情況下，還要斥巨資建設數據處理體系，他們就沒有動力了。。。

　　換句話說，只有一個性價比足夠高的數據處理體系，才能融入千行百業，幫助他們來開采自己的石油。

　　字節這群老師傅忽然抬頭，發現整個江湖之上，自己對于數據技術的處理已經到了獨孤求敗的地步。于是，高層慎重討論，準備把這些年積累下來的各種技術開放出來，服務廣大企業。

　　這就是后來大名鼎鼎的 “火山引擎”。

　?。┏蔀?ldquo;利器”

　　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 的分布式治理功能恰恰能派上用場。

　　他們當年費力做了這么多細節功能，更多是出于純粹的數據信仰?？墒?ldquo;純粹”恰恰是改造世界最鋒利的武器。

　　那些默默的努力如今一下子靈魂附體。大概正如那歌詞：“人生沒有白走的路，每一步都算數”。

　?。ㄆ撸]有盡頭的數據長征

　　熟悉中哥的人都知道，我是一個“數據技術信仰者”。

　　原因其實也很簡單，中國總體地大物“薄”，人均來看各種能源都談不上豐富，漫長的時間里，我們可以依靠的只有每個人的勤勞和忍耐。

　　正是這樣的歷史，造就了巨大的人口和統一的市場。而這兩樣，恰恰是數據的溫床，孕育了最豐富的未來能源。

　　從這個角度看來，我們終究得到了歷史的一些眷顧。

　　在未來幾十年，大概率會爆發一場波瀾壯闊的“數據技術普及浪潮”，每一個公司都可以用低廉的價格購買一個高效的“數據處理引擎”，就像現在我們買汽車一樣簡單。

　　也只有到了數據引擎遍地開花的時候，我們才真正拍胸脯說自己是奔跑在數據上的國家。

　　壞消息是，我們目前的數據處理效率，還不能支撐那樣的未來。

　　好消息是，老師傅們仍在繼續努力。

　　Carl 告訴我，最近 ByteHouse 正準備研究一個智能化的黑科技：

　　你還記得我們剛才說過，一個任務到達 ByteHouse 之后，要有一個工頭來進行任務分配的吧。

　　面對一個任務，究竟應該召喚出多少個“機械臂”去執行子任務呢？如果太多就會浪費算力，如果太少就會拖延時間。

　　當前的解決方案比較粗暴，就是手動設定的默認值。

　　可未來 ByteHouse 進一步滲入各行各業，計算任務會變得更加五花八門，都采用“默認任務分配策略”就不合適了。

　　所以，黑科技就是：根據現場情況，自動測算最合適的“并行度”來分配任務。

　　這種潤物細無聲的“智能化”還發生著在很多地方。

　　比如在 DataTester（Libra） 里，目前所有的指標都是分析師自己憑腦袋瓜想出來的。

　　但 Albert 告訴我，他們正在嘗試研究一種技術，可以通過歷史數據和行業屬性自動向分析師推薦：“要不要試試這樣構建指標？”

　　這樣的智能建議如果足夠靠譜，那么各行各業就會進一步擺脫對專業分析師的依賴，利用數據的門檻隨之大幅下降。

　　DataLeap 也有類似的黑科技。

　　Brian 說，過去的 DataLeap 在發現某個數據流卡住的時候（一般是半夜），都會馬上打電話叫醒響應團隊的方方面面 好幾位負責人，但很多情況下能解決問題的就是 其中一個人。

　　所以 DataLeap 正在研究的黑科技就是：

　　通過數據智能研判這個擁堵具體是由那個小分隊造成的，直接給這一個人負責人來精準的“奪命連環 Call”，別人該睡還睡。

　　“提升大家的幸福感嘛！”Brian 笑。

　　舉了這三個例子，可能你已經看出來了，未來數據技術發展的一大方向就是 “數據處理的智能化”。

　　智能化浪潮的意義，堪比汽車從手動擋進化成自動擋一樣，瞬間讓很多沒信心開車的人也能學開車了。

　　除了“智能化”，未來數據處理還會越來越 “實時化”。

　　以前的“小紅心旅行”短則幾個小時，長則幾天，但是在很多場景下，我們等不了這么久：

　　比如，你搜索了一件衣服，下一秒你就希望電商馬上給你推薦相似的款式；

　　比如，火電廠周圍的風向變了，就需要馬上調整空冷島風扇的轉速，補償風向對散熱的影響；

　　比如，居民的用電情況發生改變，就需要馬上調整電網輸送功率，保持供電用電平衡。

　　實時報表的要求越來越高，小紅心整個旅途可能在幾秒內就得完成。（可以參考我寫過的 《你在被窩里刷手機歲月靜好，一個“神秘引擎”卻在遠方和時間賽跑》 ）

　　當延遲以毫秒計數，數據就會組成一條奔騰的大河。而在大河兩岸，新的文明得以被滋養。

　　就像下面這張完整版大圖：

　　雖然有點俗，但我的夢想就是通過產品化的方式，讓未來更多的人能夠用到數據。

　　人做的事情越來越少，自動化越來越多，直到人類 從一條條數據鏈路中被完全解放出來。

　　Brian 說。

　　我想了半天：“你這夢想已經不俗了吧？”

　　告別字節的老師傅們，我忍不住掰著手指頭計算。

　　二十多年前，互聯網出現；十多年前，智能手機普及；而建立在這些基礎之上數據世界，仍是蹣跚的孩子。

　　一個孩子已經如此強悍，我有理由相信，更多奇跡已經預定了我們的未來。

　　但成長從來并非易事。

　　從荒蕪到轟鳴，如今數字世界的一切都由一行行微小而具體的代碼堆砌而成，過去走到現在并無捷徑。由此想見，由現在走到未來也沒有捷徑。

　　這可能是一場漫長的數據長征。老師傅只能前赴后繼，用一行行代碼代替腳步，去丈量大地。

　　但好在，代碼是數字世界的磚石，它一旦創生，就再也不會消逝，我們每向前走一步，就離終點更近一步。