我在 Google 面試過很多優(yōu)秀的候選人，應(yīng)對(duì)普通的編程問題 coding 能力很強(qiáng)，算法數(shù)據(jù)結(jié)構(gòu)也應(yīng)用得不錯(cuò)。

可是當(dāng)我追問數(shù)據(jù)規(guī)模變大時(shí)該怎么設(shè)計(jì)系統(tǒng)，他們卻并不能給出很好的答案，這說明他們?nèi)狈Ρ貍涞囊?guī)模增長(zhǎng)的技術(shù)思維(mindset of scaling)。這會(huì)限制這些候選人的職業(yè)成長(zhǎng)。因?yàn)楫a(chǎn)品從 1 萬(wàn)用戶到 1 億用戶，技術(shù)團(tuán)隊(duì)從 10 個(gè)人到 1000 個(gè)人，你的技術(shù)規(guī)模和數(shù)據(jù)規(guī)模都會(huì)完全不一樣。

今天我們就以大型電商熱銷榜為例，來談一談從 1 萬(wàn)用戶到 1 億用戶，從 GB 數(shù)據(jù)到 PB 數(shù)據(jù)系統(tǒng)，技術(shù)思維需要怎樣的轉(zhuǎn)型升級(jí)?

同樣的問題舉一反三，可以應(yīng)用在淘寶熱賣，App 排行榜，抖音熱門，甚至是胡潤(rùn)百富榜，因?yàn)閷?shí)際上他們背后都應(yīng)用了相似的大規(guī)模數(shù)據(jù)處理技術(shù)。

 

 

真正的排序系統(tǒng)非常復(fù)雜，僅僅是用來排序的特征(features)就需要多年的迭代設(shè)計(jì)。

為了便于這一講的討論，我們來構(gòu)想一個(gè)簡(jiǎn)化的玩具問題來幫助你理解。

假設(shè)你的電商網(wǎng)站銷售 10 億件商品，已經(jīng)跟蹤了網(wǎng)站的銷售記錄：商品 id 和購(gòu)買時(shí)間 {product_id, timestamp}，整個(gè)交易記錄是 1000 億行數(shù)據(jù)，TB 級(jí)。作為技術(shù)負(fù)責(zé)人，你會(huì)怎樣設(shè)計(jì)一個(gè)系統(tǒng)，根據(jù)銷售記錄統(tǒng)計(jì)去年銷量前 10 的商品呢?

舉個(gè)例子，假設(shè)我們的數(shù)據(jù)是：

 

 

我們熱銷榜可以按 product_id 排名，順序?yàn)椋?, 2, 3。

小規(guī)模的經(jīng)典算法

如果上過極客時(shí)間的《數(shù)據(jù)結(jié)構(gòu)與算法之美》，你可能一眼就看出來，這個(gè)問題的解法分為兩步：

 

 

第一步，統(tǒng)計(jì)每個(gè)商品的銷量。你可以用哈希表(hashtable)數(shù)據(jù)結(jié)構(gòu)來解決，這是一個(gè) O(n) 的算法，這里的 n 是 1000 億。

第二步，找出銷量前十，這里可以用經(jīng)典的 Top K 算法，也是 O(n) 的算法。如果你考慮到了這些，先恭喜你答對(duì)了。在小規(guī)模系統(tǒng)中，我們確實(shí)完全可以用經(jīng)典的算法簡(jiǎn)潔漂亮地解決。以 Python 編程的話可能是類似這樣的：

 

但在任何系統(tǒng)中，隨著尺度的變大，很多方法就不再適用。

比如，在小尺度經(jīng)典物理學(xué)中適用的牛頓力學(xué)：

 

 

在高速?gòu)?qiáng)力的物理系統(tǒng)中就不再適用，在狹義相對(duì)論中有另外的表達(dá)：

 

 

在社會(huì)系統(tǒng)中也是一樣，管理 10 個(gè)人的團(tuán)隊(duì)，和治理 14 億人口的國(guó)家，復(fù)雜度也不可同日而語(yǔ)。

具體在我們這個(gè)問題中，同樣是 Top K 算法，當(dāng)數(shù)據(jù)規(guī)模變大時(shí)，會(huì)遇到哪些問題呢?

第一，內(nèi)存占用。

對(duì)于 TB 級(jí)的交易記錄數(shù)據(jù)，很難找到單臺(tái)計(jì)算機(jī)能夠容納那么大的哈希表了。

你可能想到，那我不要用哈希表去統(tǒng)計(jì)商品銷售量了，我把銷量計(jì)數(shù)放在磁盤里完成好了。比如，就用一個(gè) 1000 億行的文件或者表，然后再把銷量統(tǒng)計(jì)結(jié)果一行一行讀進(jìn)后面的堆樹 / 優(yōu)先級(jí)隊(duì)列。

理論上聽起來不錯(cuò)，實(shí)際上是否真的可行呢?那我們看下一點(diǎn)。

第二，磁盤 I/O 等延時(shí)問題。

當(dāng)數(shù)據(jù)規(guī)模變大，我們難以避免地需要把一些中間結(jié)果存進(jìn)磁盤，以應(yīng)對(duì)單步任務(wù)出錯(cuò)等問題。

一次磁盤讀取大概需要 10ms 的時(shí)間。如果按照上一點(diǎn)提到的文件替代方法，時(shí)間會(huì)很長(zhǎng)。因?yàn)槲覀兪且粋�(gè) O(n * log k) 的算法，這就需要 10ms * 10^9 = 10 ^ 7 s = 115 天的時(shí)間。你可能需要賈躍亭附體，才能忽悠老板接受這樣的設(shè)計(jì)方案了。

這些問題怎么解決呢?你可能已經(jīng)想到，當(dāng)單臺(tái)機(jī)器已經(jīng)無(wú)法適應(yīng)我們數(shù)據(jù)或者問題的規(guī)模，我們需要橫向擴(kuò)展。

大規(guī)模分布式解決方案

之前的思路依然沒錯(cuò)。但是我們需要把每一步從簡(jiǎn)單的函數(shù)算法，升級(jí)為計(jì)算集群的分布式算法。

 

 

統(tǒng)計(jì)每個(gè)商品的銷量

我們需要的第一個(gè)計(jì)算集群，就是統(tǒng)計(jì)商品銷量的集群。

例如，1000 臺(tái)機(jī)器，每臺(tái)機(jī)器一次可以處理 1 萬(wàn)條銷售記錄。對(duì)于每臺(tái)機(jī)器而言，它的單次處理又回歸到了我們熟悉的傳統(tǒng)算法，數(shù)據(jù)規(guī)模大大縮小。

下圖就是一個(gè)例子，圖中每臺(tái)機(jī)器輸入的是 2 條銷售記錄，輸出的是對(duì)于他們的本地輸入而言的產(chǎn)品銷量計(jì)數(shù)。

 

 

找出銷量前 K

我們需要的第二個(gè)計(jì)算集群，則是找出銷量前十的集群。

這里我們不妨把問題抽象一下，抽象出的是銷量前 K 的產(chǎn)品。因?yàn)槟愕睦习咫S時(shí)可能把產(chǎn)品需求改成前 20 銷量，而不是前 10 了。

在上一個(gè)統(tǒng)計(jì)銷量集群得到的數(shù)據(jù)輸出，將會(huì)是我們這個(gè)處理流程的輸入。所以這里需要把分布在各個(gè)機(jī)器上分散的產(chǎn)品銷量匯總出來。例如，把所有 product_id = 1 的銷量全部疊加。

下圖示例是 K = 1 的情況，每臺(tái)機(jī)器先把所有 product_id = 1 的銷量疊加在了一起，再找出自己機(jī)器上銷量前 K = 1 的商品。你可以看到，對(duì)于每臺(tái)機(jī)器而言，他們的輸出就是最終排名前 K = 1 的商品候選者。

 

 

匯總最終結(jié)果

到了最后一步，你需要把在“銷量前 K 集群”中的結(jié)果匯總出來。也就是說，從所有排名前 K=1 的商品候選人中找出真正的銷量前 K=1 的商品。

這時(shí)候完全可以用單一機(jī)器解決了。因?yàn)閷?shí)際上你匯總的就是這 1000 臺(tái)機(jī)器的結(jié)果，規(guī)模足夠小。

 

 

看到這里，你已經(jīng)體會(huì)到處理超大規(guī)模數(shù)據(jù)的系統(tǒng)是很復(fù)雜的。

當(dāng)你辛辛苦苦設(shè)計(jì)了應(yīng)對(duì) 1 億用戶的數(shù)據(jù)處理系統(tǒng)時(shí)，可能你就要面臨另一個(gè)維度的規(guī)模化(scaling)。那就是應(yīng)用場(chǎng)景數(shù)量從 1 個(gè)變成 1000 個(gè)。每一次都為不同的應(yīng)用場(chǎng)景單獨(dú)設(shè)計(jì)分布式集群，招募新的工程師維護(hù)變得不再“可持續(xù)發(fā)展”。

這時(shí)，你需要一個(gè)數(shù)據(jù)處理的框架。

大規(guī)模數(shù)據(jù)處理框架的功能要求

這個(gè)實(shí)際的例子其實(shí)為我們的設(shè)計(jì)增加了新的挑戰(zhàn)。

很多人面對(duì)問題，第一個(gè)想法是找有沒有開源技術(shù)可以用一下。

但我經(jīng)常說服別人不要先去看什么開源技術(shù)可以用，而是從自己面對(duì)的問題出發(fā)獨(dú)立思考，忘掉 MapReduce，忘掉 Apache Spark，忘掉 Apache Beam。

如果這個(gè)世界一無(wú)所有，你會(huì)設(shè)計(jì)怎樣的大規(guī)模數(shù)據(jù)處理框架?你要經(jīng)常做一些思維實(shí)驗(yàn)，試試帶領(lǐng)一下技術(shù)的發(fā)展，而不是永遠(yuǎn)跟隨別人的技術(shù)方向。

在我看來，兩個(gè)最基本的需求是：

高度抽象的數(shù)據(jù)處理流程描述語(yǔ)言。作為小白用戶，我肯定再也不想一一配置分布式系統(tǒng)的每臺(tái)機(jī)器了。作為框架使用者，我希望框架是非常簡(jiǎn)單的，能夠用幾行代碼把業(yè)務(wù)邏輯描述清楚。

根據(jù)描述的數(shù)據(jù)處理流程，自動(dòng)化的任務(wù)分配優(yōu)化。這個(gè)框架背后的引擎需要足夠智能，簡(jiǎn)單地說，要把那些本來手動(dòng)配置的系統(tǒng)，進(jìn)行自動(dòng)任務(wù)分配。

那么理想狀況是什么?對(duì)于上面的應(yīng)用場(chǎng)景，我作為用戶只想寫兩行代碼。

第一行代碼：

sales_count = sale_records.Count()

這樣簡(jiǎn)單的描述，在我們框架設(shè)計(jì)層面，就要能自動(dòng)構(gòu)建成上文描述的“銷量統(tǒng)計(jì)計(jì)算集群”。

第二行代碼

top_k_sales = sales_count.TopK(k)

這行代碼需要自動(dòng)構(gòu)建成上文描述的“找出銷量前 K 集群”。

看到這里，你能發(fā)現(xiàn)這并不復(fù)雜。我們到這里就已經(jīng)基本上把現(xiàn)代大規(guī)模數(shù)據(jù)處理架構(gòu)的頂層構(gòu)造掌握了。而背后的具體實(shí)現(xiàn)，我會(huì)在后面的專欄章節(jié)中為你一一揭曉。

小結(jié)

接下來我為這一講做個(gè)小結(jié)。這一講中，我們粗淺地分析了一個(gè)電商排行榜的數(shù)據(jù)處理例子。

從 GB 數(shù)據(jù)到 TB 數(shù)據(jù)，我們從小規(guī)模算法升級(jí)到了分布式處理的設(shè)計(jì)方案;從單一 TB 數(shù)據(jù)場(chǎng)景到 1000 個(gè)應(yīng)用場(chǎng)景，我們探索了大規(guī)模數(shù)據(jù)處理框架的設(shè)計(jì)。

這些都是為了幫助你更好地理解后面所要講的所有知識(shí)。比如，為什么傳統(tǒng)算法不再奏效?為什么要去借助抽象的數(shù)據(jù)處理描述語(yǔ)言?希望在后面的學(xué)習(xí)過程中，你能一直帶著這些問題出發(fā)。

你好，我是蔡元楠， 目前在 Google Brain 擔(dān)任 AI Healthcare (人工智能的健康醫(yī)療應(yīng)用) 領(lǐng)域資深工程師，也是極客時(shí)間《大規(guī)模數(shù)據(jù)處理實(shí)戰(zhàn)》的專欄作者，這篇文章便出自這個(gè)專欄的第三篇文章。

我在 Google 面試過很多優(yōu)秀的候選人，應(yīng)對(duì)普通的編程問題 coding 能力很強(qiáng)，算法數(shù)據(jù)結(jié)構(gòu)也應(yīng)用得不錯(cuò)。

可是當(dāng)我追問數(shù)據(jù)規(guī)模變大時(shí)該怎么設(shè)計(jì)系統(tǒng)，他們卻并不能給出很好的答案，這說明他們?nèi)狈Ρ貍涞囊?guī)模增長(zhǎng)的技術(shù)思維(mindset of scaling)。這會(huì)限制這些候選人的職業(yè)成長(zhǎng)。因?yàn)楫a(chǎn)品從 1 萬(wàn)用戶到 1 億用戶，技術(shù)團(tuán)隊(duì)從 10 個(gè)人到 1000 個(gè)人，你的技術(shù)規(guī)模和數(shù)據(jù)規(guī)模都會(huì)完全不一樣。

今天我們就以大型電商熱銷榜為例，來談一談從 1 萬(wàn)用戶到 1 億用戶，從 GB 數(shù)據(jù)到 PB 數(shù)據(jù)系統(tǒng)，技術(shù)思維需要怎樣的轉(zhuǎn)型升級(jí)?

同樣的問題舉一反三，可以應(yīng)用在淘寶熱賣，App 排行榜，抖音熱門，甚至是胡潤(rùn)百富榜，因?yàn)閷?shí)際上他們背后都應(yīng)用了相似的大規(guī)模數(shù)據(jù)處理技術(shù)。

 

 

真正的排序系統(tǒng)非常復(fù)雜，僅僅是用來排序的特征(features)就需要多年的迭代設(shè)計(jì)。

為了便于這一講的討論，我們來構(gòu)想一個(gè)簡(jiǎn)化的玩具問題來幫助你理解。

假設(shè)你的電商網(wǎng)站銷售 10 億件商品，已經(jīng)跟蹤了網(wǎng)站的銷售記錄：商品 id 和購(gòu)買時(shí)間 {product_id, timestamp}，整個(gè)交易記錄是 1000 億行數(shù)據(jù)，TB 級(jí)。作為技術(shù)負(fù)責(zé)人，你會(huì)怎樣設(shè)計(jì)一個(gè)系統(tǒng)，根據(jù)銷售記錄統(tǒng)計(jì)去年銷量前 10 的商品呢?

舉個(gè)例子，假設(shè)我們的數(shù)據(jù)是：

product_idtimestamp

11553721167

21553721199

31553721220

11553721241

我們熱銷榜可以按 product_id 排名，順序?yàn)椋?, 2, 3。

小規(guī)模的經(jīng)典算法

如果上過極客時(shí)間的《數(shù)據(jù)結(jié)構(gòu)與算法之美》，你可能一眼就看出來，這個(gè)問題的解法分為兩步：

 

 

第一步，統(tǒng)計(jì)每個(gè)商品的銷量。你可以用哈希表(hashtable)數(shù)據(jù)結(jié)構(gòu)來解決，這是一個(gè) O(n) 的算法，這里的 n 是 1000 億。

第二步，找出銷量前十，這里可以用經(jīng)典的 Top K 算法，也是 O(n) 的算法。如果你考慮到了這些，先恭喜你答對(duì)了。在小規(guī)模系統(tǒng)中，我們確實(shí)完全可以用經(jīng)典的算法簡(jiǎn)潔漂亮地解決。以 Python 編程的話可能是類似這樣的：

�p復(fù)制代碼def CountSales(sale_records): """Calculate number of sales for each product id. Args: sales_records: list of SaleRecord, SaleRecord is a named tuple, e.g. {product_id: “1”, timestamp: 1553721167}. Returns: dict of {product_id: num_of_sales}. E.g. {“1”: 1, “2”: 1} """ sales_count = {} for record in sale_records: sales_count[record[product_id]] += 1 return sales_countdef TopSellingItems(sale_records, k=10): """Calculate the best selling k products. Args: sales_records: list of SaleRecord, SaleRecord is a named tuple, e.g. {product_id: “1”, timestamp: 1553721167}. K: num of top products you want to output. Returns: List of k product_id, sorted by num of sales. """ sales_count = CountSales(sale_records) return heapq.nlargest(k, sales_count, key=sales_count.get)

但在任何系統(tǒng)中，隨著尺度的變大，很多方法就不再適用。

比如，在小尺度經(jīng)典物理學(xué)中適用的牛頓力學(xué)：

 

 

在高速?gòu)?qiáng)力的物理系統(tǒng)中就不再適用，在狹義相對(duì)論中有另外的表達(dá)：

 

 

在社會(huì)系統(tǒng)中也是一樣，管理 10 個(gè)人的團(tuán)隊(duì)，和治理 14 億人口的國(guó)家，復(fù)雜度也不可同日而語(yǔ)。

具體在我們這個(gè)問題中，同樣是 Top K 算法，當(dāng)數(shù)據(jù)規(guī)模變大時(shí)，會(huì)遇到哪些問題呢?

第一，內(nèi)存占用。

對(duì)于 TB 級(jí)的交易記錄數(shù)據(jù)，很難找到單臺(tái)計(jì)算機(jī)能夠容納那么大的哈希表了。

你可能想到，那我不要用哈希表去統(tǒng)計(jì)商品銷售量了，我把銷量計(jì)數(shù)放在磁盤里完成好了。比如，就用一個(gè) 1000 億行的文件或者表，然后再把銷量統(tǒng)計(jì)結(jié)果一行一行讀進(jìn)后面的堆樹 / 優(yōu)先級(jí)隊(duì)列。

理論上聽起來不錯(cuò)，實(shí)際上是否真的可行呢?那我們看下一點(diǎn)。

第二，磁盤 I/O 等延時(shí)問題。

當(dāng)數(shù)據(jù)規(guī)模變大，我們難以避免地需要把一些中間結(jié)果存進(jìn)磁盤，以應(yīng)對(duì)單步任務(wù)出錯(cuò)等問題。

一次磁盤讀取大概需要 10ms 的時(shí)間。如果按照上一點(diǎn)提到的文件替代方法，時(shí)間會(huì)很長(zhǎng)。因?yàn)槲覀兪且粋�(gè) O(n * log k) 的算法，這就需要 10ms * 10^9 = 10 ^ 7 s = 115 天的時(shí)間。你可能需要賈躍亭附體，才能忽悠老板接受這樣的設(shè)計(jì)方案了。

這些問題怎么解決呢?你可能已經(jīng)想到，當(dāng)單臺(tái)機(jī)器已經(jīng)無(wú)法適應(yīng)我們數(shù)據(jù)或者問題的規(guī)模，我們需要橫向擴(kuò)展。

大規(guī)模分布式解決方案

之前的思路依然沒錯(cuò)。但是我們需要把每一步從簡(jiǎn)單的函數(shù)算法，升級(jí)為計(jì)算集群的分布式算法。

 

 

統(tǒng)計(jì)每個(gè)商品的銷量

我們需要的第一個(gè)計(jì)算集群，就是統(tǒng)計(jì)商品銷量的集群。

例如，1000 臺(tái)機(jī)器，每臺(tái)機(jī)器一次可以處理 1 萬(wàn)條銷售記錄。對(duì)于每臺(tái)機(jī)器而言，它的單次處理又回歸到了我們熟悉的傳統(tǒng)算法，數(shù)據(jù)規(guī)模大大縮小。

下圖就是一個(gè)例子，圖中每臺(tái)機(jī)器輸入的是 2 條銷售記錄，輸出的是對(duì)于他們的本地輸入而言的產(chǎn)品銷量計(jì)數(shù)。

 

 

找出銷量前 K

我們需要的第二個(gè)計(jì)算集群，則是找出銷量前十的集群。

這里我們不妨把問題抽象一下，抽象出的是銷量前 K 的產(chǎn)品。因?yàn)槟愕睦习咫S時(shí)可能把產(chǎn)品需求改成前 20 銷量，而不是前 10 了。

在上一個(gè)統(tǒng)計(jì)銷量集群得到的數(shù)據(jù)輸出，將會(huì)是我們這個(gè)處理流程的輸入。所以這里需要把分布在各個(gè)機(jī)器上分散的產(chǎn)品銷量匯總出來。例如，把所有 product_id = 1 的銷量全部疊加。

下圖示例是 K = 1 的情況，每臺(tái)機(jī)器先把所有 product_id = 1 的銷量疊加在了一起，再找出自己機(jī)器上銷量前 K = 1 的商品。你可以看到，對(duì)于每臺(tái)機(jī)器而言，他們的輸出就是最終排名前 K = 1 的商品候選者。

 

 

匯總最終結(jié)果

到了最后一步，你需要把在“銷量前 K 集群”中的結(jié)果匯總出來。也就是說，從所有排名前 K=1 的商品候選人中找出真正的銷量前 K=1 的商品。

這時(shí)候完全可以用單一機(jī)器解決了。因?yàn)閷?shí)際上你匯總的就是這 1000 臺(tái)機(jī)器的結(jié)果，規(guī)模足夠小。

 

 

看到這里，你已經(jīng)體會(huì)到處理超大規(guī)模數(shù)據(jù)的系統(tǒng)是很復(fù)雜的。

當(dāng)你辛辛苦苦設(shè)計(jì)了應(yīng)對(duì) 1 億用戶的數(shù)據(jù)處理系統(tǒng)時(shí)，可能你就要面臨另一個(gè)維度的規(guī)�；�(scaling)。那就是應(yīng)用場(chǎng)景數(shù)量從 1 個(gè)變成 1000 個(gè)。每一次都為不同的應(yīng)用場(chǎng)景單獨(dú)設(shè)計(jì)分布式集群，招募新的工程師維護(hù)變得不再“可持續(xù)發(fā)展”。

這時(shí)，你需要一個(gè)數(shù)據(jù)處理的框架。

大規(guī)模數(shù)據(jù)處理框架的功能要求

在「02 篇 怎樣設(shè)計(jì)下一代數(shù)據(jù)處理技術(shù)?」中，我們對(duì)于數(shù)據(jù)處理框架已經(jīng)有了基本的方案。這里這個(gè)實(shí)際的例子其實(shí)為我們的設(shè)計(jì)增加了新的挑戰(zhàn)。

很多人面對(duì)問題，第一個(gè)想法是找有沒有開源技術(shù)可以用一下。

但我經(jīng)常說服別人不要先去看什么開源技術(shù)可以用，而是從自己面對(duì)的問題出發(fā)獨(dú)立思考，忘掉 MapReduce，忘掉 Apache Spark，忘掉 Apache Beam。

如果這個(gè)世界一無(wú)所有，你會(huì)設(shè)計(jì)怎樣的大規(guī)模數(shù)據(jù)處理框架?你要經(jīng)常做一些思維實(shí)驗(yàn)，試試帶領(lǐng)一下技術(shù)的發(fā)展，而不是永遠(yuǎn)跟隨別人的技術(shù)方向。

在我看來，兩個(gè)最基本的需求是：

高度抽象的數(shù)據(jù)處理流程描述語(yǔ)言。作為小白用戶，我肯定再也不想一一配置分布式系統(tǒng)的每臺(tái)機(jī)器了。作為框架使用者，我希望框架是非常簡(jiǎn)單的，能夠用幾行代碼把業(yè)務(wù)邏輯描述清楚。

根據(jù)描述的數(shù)據(jù)處理流程，自動(dòng)化的任務(wù)分配優(yōu)化。這個(gè)框架背后的引擎需要足夠智能，簡(jiǎn)單地說，要把那些本來手動(dòng)配置的系統(tǒng)，進(jìn)行自動(dòng)任務(wù)分配。

那么理想狀況是什么?對(duì)于上面的應(yīng)用場(chǎng)景，我作為用戶只想寫兩行代碼。

第一行代碼：

�p復(fù)制代碼sales_count = sale_records.Count()

這樣簡(jiǎn)單的描述，在我們框架設(shè)計(jì)層面，就要能自動(dòng)構(gòu)建成上文描述的“銷量統(tǒng)計(jì)計(jì)算集群”。

第二行代碼

�p復(fù)制代碼top_k_sales = sales_count.TopK(k)

這行代碼需要自動(dòng)構(gòu)建成上文描述的“找出銷量前 K 集群”。

看到這里，你能發(fā)現(xiàn)這并不復(fù)雜。我們到這里就已經(jīng)基本上把現(xiàn)代大規(guī)模數(shù)據(jù)處理架構(gòu)的頂層構(gòu)造掌握了。而背后的具體實(shí)現(xiàn)，我會(huì)在后面的專欄章節(jié)中為你一一揭曉。

小結(jié)

接下來我為這一講做個(gè)小結(jié)。這一講中，我們粗淺地分析了一個(gè)電商排行榜的數(shù)據(jù)處理例子。

從 GB 數(shù)據(jù)到 TB 數(shù)據(jù)，我們從小規(guī)模算法升級(jí)到了分布式處理的設(shè)計(jì)方案;從單一 TB 數(shù)據(jù)場(chǎng)景到 1000 個(gè)應(yīng)用場(chǎng)景，我們探索了大規(guī)模數(shù)據(jù)處理框架的設(shè)計(jì)。

這些都是為了幫助你更好地理解后面所要講的所有知識(shí)。比如，為什么傳統(tǒng)算法不再奏效?為什么要去借助抽象的數(shù)據(jù)處理描述語(yǔ)言?希望在后面的學(xué)習(xí)過程中，你能一直帶著這些問題出發(fā)。

作者：蔡元楠

標(biāo)簽： [db:TAGG]

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。