摘要：太多的計(jì)算如果我們開(kāi)始增加一個(gè)單線程來(lái)加載數(shù)據(jù)管道，那么這種操作最終肯定是會(huì)失敗的。優(yōu)點(diǎn)所有上述的優(yōu)點(diǎn)調(diào)度和可擴(kuò)展性缺點(diǎn)由于功能的強(qiáng)大，所有學(xué)習(xí)門(mén)檻有點(diǎn)高總結(jié)最后，我們可以畫(huà)出我們一整個(gè)數(shù)據(jù)工程架構(gòu)圖。

作者：chen_h
微信號(hào) & QQ：862251340
微信公眾號(hào)：coderpai
簡(jiǎn)書(shū)地址：http://www.jianshu.com/p/7a72...

在我們深入討論這個(gè) “數(shù)據(jù)工程” 業(yè)務(wù)細(xì)節(jié)之前，我們需要先知道標(biāo)準(zhǔn)（PyData）機(jī)器學(xué)習(xí)數(shù)據(jù)管道的局限性，如下圖所示：

     典型的 PyData 機(jī)器學(xué)習(xí)數(shù)據(jù)管道設(shè)計(jì)，通過(guò) Python 腳本完成鏈接（通常是單線程）

低門(mén)檻

快速部署

可擴(kuò)展性差

對(duì)于機(jī)器學(xué)習(xí)可擴(kuò)展性差問(wèn)題的解釋?zhuān)梢圆榭催@篇文章，有非常詳細(xì)的解釋。在這里，我們將采用一個(gè)更加簡(jiǎn)單的方式來(lái)說(shuō)明這3個(gè)問(wèn)題，為什么這個(gè)數(shù)據(jù)管道的加載是如此的重。

如果我們開(kāi)始增加一個(gè)單線程來(lái)加載 PyData 數(shù)據(jù)管道，那么這種操作最終肯定是會(huì)失敗的。我們不能將這種操作擴(kuò)展到單個(gè)節(jié)點(diǎn)之外，也就是說(shuō)，如果你的數(shù)據(jù)太巨大以至于不能在內(nèi)存中操作，那么你需要對(duì)其進(jìn)行批量處理，否則你將無(wú)法進(jìn)行處理。如果你沒(méi)有足夠的CPU資源去訓(xùn)練一個(gè)模型，那么你只能去購(gòu)買(mǎi)一個(gè)更好的處理器來(lái)解決這個(gè)問(wèn)題，但是如果你已經(jīng)擁有了一個(gè)很好的處理器，那么接下來(lái)又會(huì)發(fā)生什么呢？更糟糕的是，因?yàn)槟Ｐ偷臄?shù)據(jù)輸入請(qǐng)求是由一定的速率要求的，如果模型不能按照一定的速率得到預(yù)測(cè)結(jié)果，那么這將成為整一個(gè)系統(tǒng)的性能瓶頸。Python 中的多線程是有限的，如果一個(gè)線程失敗了，那么系統(tǒng)是沒(méi)有辦法優(yōu)雅的去切換到默認(rèn)值，所以我們只能失敗。

上述所有的問(wèn)題都可以通過(guò)拆分 - 應(yīng)用 - 組合的策略來(lái)解決，該策略允許將一個(gè)任務(wù)分割成多個(gè)子任務(wù)然后并行子啊不同的線程或者節(jié)點(diǎn)上面去計(jì)算，最后將計(jì)算結(jié)果進(jìn)行合并，加快數(shù)據(jù)管道的處理效率。MapReduce 的思想就是來(lái)解決這個(gè)問(wèn)題的，我們可以用任何的語(yǔ)言來(lái)實(shí)現(xiàn)這一個(gè)算法，但是你會(huì)度過(guò)幾小時(shí)的痛苦時(shí)間，因?yàn)閺牧汩_(kāi)始編寫(xiě) MapReduce 是一件非常瘋狂的事。一個(gè)可行的方式是我們利用 Hadoop 的 MapReduce 或者 Spark 的。Hadoop 的操作可能會(huì)慢一點(diǎn)，因?yàn)樗看尾僮髦蠖紩?huì)發(fā)生磁盤(pán)讀寫(xiě)操作（所以現(xiàn)在幾乎沒(méi)有人使用它），但是 Spark 所有的計(jì)算都是發(fā)生在內(nèi)存中，加快了機(jī)器學(xué)習(xí)算法的迭代速度，甚至比一般的流水式數(shù)據(jù)管道還要快（但是你需要一個(gè)很大的內(nèi)存空間）。

由于 Spark 不但提供了數(shù)據(jù)批處理和流處理，它還提供了 Spark ML 這一個(gè)強(qiáng)大的包。這個(gè)包允許你進(jìn)行分布式機(jī)器學(xué)習(xí)操作，用 Spark jobs 可以完全替代 Python 腳本中的 PyData 數(shù)據(jù)管道和模塊之間的連接器，而且可以很方便的在分布式集群上面運(yùn)行，線程失敗了可以正常重啟。

讓我們?cè)囅胍幌?，我們已?jīng)用 Spark jobs 和 Spark ML 模塊替代了典型模型 PyData ML Pipeline 中的中間腳本，如下圖所示：

                               Improved pipeline

在這個(gè)數(shù)據(jù)管道中還存在一個(gè)弱點(diǎn)：DB。當(dāng)處理的數(shù)據(jù)量超過(guò) 5TB 的時(shí)候，關(guān)系數(shù)據(jù)庫(kù)的處理能力表現(xiàn)不佳。關(guān)系數(shù)據(jù)庫(kù)的分片和復(fù)制是一個(gè)本身就存在的大問(wèn)題，如果你想要去支持如此大的數(shù)據(jù)量，那么這必將是一個(gè)昂貴的冒險(xiǎn)行為。所以當(dāng)我們的數(shù)據(jù)量在達(dá)到 5TB 的天花板之前，可能需要放棄關(guān)系型數(shù)據(jù)庫(kù)。

那么，對(duì)于大數(shù)據(jù)來(lái)說(shuō)，還有那些其他的數(shù)據(jù)存儲(chǔ)方案可以選擇呢？首先，需要一個(gè)分布式數(shù)據(jù)存儲(chǔ)系統(tǒng)，它能夠?qū)谷缦聠?wèn)題：

硬件故障導(dǎo)致的數(shù)據(jù)丟失問(wèn)題

需要一個(gè)高的吞吐量

可以擴(kuò)展到很多的數(shù)據(jù)平臺(tái)

Hadoop 分布式文件系統(tǒng)（HDFS）滿足于以上所有特性，這是 Apache Hadoop 項(xiàng)目中的一部分。而且這個(gè)可以在本地硬件集群上面設(shè)置 HDFS，如果你有幾個(gè) DevOps 專(zhuān)家，那么你就可以部署到任何你喜歡的地方了。為了存儲(chǔ)一些冷數(shù)據(jù)，我們可以考慮 AWS S3 作為存儲(chǔ)器。但是如果你考慮到速度性能，建議不要把 S3 作為整個(gè)模型的一部分。最好將這些熱數(shù)據(jù)存放在計(jì)算資源的附近，比如計(jì)算資源是在云服務(wù)器上面，那么最好將數(shù)據(jù)存放在本地的 HDFS 集群或者云 HDFS 集群中。

但是這個(gè)只是分布式數(shù)據(jù)的基礎(chǔ)設(shè)施，那么存儲(chǔ)數(shù)據(jù)的方式呢？

正如我們已經(jīng)想到的那樣，利用關(guān)系型數(shù)據(jù)庫(kù)是一個(gè)糟糕的選擇。那么，采用純文本的方式呢？令人驚喜的是，.csv 或 .tsv 文件通常是可以被存儲(chǔ)在 HDFS 系統(tǒng)上的，作為快速和不加判斷的方式來(lái)存儲(chǔ)從外部服務(wù)中提交的數(shù)據(jù)（比如，腳本批量接受的數(shù)據(jù)）。

快速存儲(chǔ)

最大容量是有限的

需要去讀取整個(gè)文件

查詢不是很容易

那么 NoSQL 數(shù)據(jù)庫(kù)呢？請(qǐng)注意，并不是所有的 NoSQL 數(shù)據(jù)庫(kù)都是分布式的。

查詢方便

高吞吐量

維護(hù)成本高

Cassandra 是分布式 NoSQL 數(shù)據(jù)庫(kù)的一個(gè)典型選擇，但是他仍然需要一個(gè)專(zhuān)門(mén)的 DevOps 來(lái)設(shè)置，維護(hù)，監(jiān)視，擴(kuò)展等等。因此，分布式 NoSQL 是存儲(chǔ)數(shù)據(jù)的默認(rèn)選項(xiàng)，因?yàn)槲覀冃枰粋€(gè)可以方便查詢的數(shù)據(jù)庫(kù)。

對(duì)于那些想要減少 DevOps 人員工作量的人來(lái)說(shuō)，有一個(gè)簡(jiǎn)單的解決方案就是使用 Parquet。

與 Spark 能很好的結(jié)合

Columnar，這可以讓分析人員加快查詢速度

不是分布式數(shù)據(jù)庫(kù)，只是一些文件，較少維護(hù)工作

讀取速度很快

存儲(chǔ)效率很高

架構(gòu)混亂

迭代困難

我們把上面講的架構(gòu)設(shè)計(jì)都反應(yīng)在一張圖中，如下圖：

隨著 spark jobs 數(shù)量的增加，數(shù)據(jù)管道變得雜亂無(wú)章，所以有很多的事情需要去處理：

作業(yè)調(diào)度

時(shí)間依賴(lài)型的作業(yè)

邏輯相關(guān)的作業(yè)（任務(wù)鏈）

監(jiān)控和報(bào)警

故障轉(zhuǎn)移恢復(fù)（重試失敗的作業(yè)，而不是整個(gè)數(shù)據(jù)管道）

作業(yè)可視化（儀表盤(pán)）

其他工作流的管理方式

有一些解決方案可以去管理重新編排這些數(shù)據(jù)管道，我們來(lái)重點(diǎn)來(lái)介紹其中的 2 個(gè)。

Python 開(kāi)發(fā)的一個(gè)簡(jiǎn)單的工作流管理解決方案，由 Spotify 開(kāi)源。

低門(mén)檻

依賴(lài)管理（鏈?zhǔn)浇Y(jié)構(gòu)）

具有狀態(tài)和錯(cuò)誤跟蹤的 WEB UI 集中式作業(yè)管理器

故障恢復(fù)

沒(méi)有調(diào)度

沒(méi)有流媒體

難以擴(kuò)展

更加復(fù)雜和有效的工作流管理工具，由 Airbnb 開(kāi)發(fā)和開(kāi)源。

所有上述的優(yōu)點(diǎn) + 調(diào)度和可擴(kuò)展性

由于功能的強(qiáng)大，所有學(xué)習(xí)門(mén)檻有點(diǎn)高

最后，我們可以畫(huà)出我們一整個(gè)數(shù)據(jù)工程架構(gòu)圖。如下圖所示：

CoderPai 是一個(gè)專(zhuān)注于算法實(shí)戰(zhàn)的平臺(tái)，從基礎(chǔ)的算法到人工智能算法都有設(shè)計(jì)。如果你對(duì)算法實(shí)戰(zhàn)感興趣，請(qǐng)快快關(guān)注我們吧。加入AI實(shí)戰(zhàn)微信群，AI實(shí)戰(zhàn)QQ群，ACM算法微信群，ACM算法QQ群。長(zhǎng)按或者掃描如下二維碼，關(guān)注 “CoderPai” 微信號(hào)（coderpai）