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

作者：chen_h
微信號 & QQ：862251340
微信公眾號：coderpai
簡書地址：http://www.jianshu.com/p/7a72...

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

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

低門檻

快速部署

可擴展性差

對于機器學習可擴展性差問題的解釋，可以查看這篇文章，有非常詳細的解釋。在這里，我們將采用一個更加簡單的方式來說明這3個問題，為什么這個數(shù)據(jù)管道的加載是如此的重。

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

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

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

讓我們試想一下，我們已經(jīng)用 Spark jobs 和 Spark ML 模塊替代了典型模型 PyData ML Pipeline 中的中間腳本，如下圖所示：

                               Improved pipeline

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

那么，對于大數(shù)據(jù)來說，還有那些其他的數(shù)據(jù)存儲方案可以選擇呢？首先，需要一個分布式數(shù)據(jù)存儲系統(tǒng)，它能夠?qū)谷缦聠栴}：

硬件故障導致的數(shù)據(jù)丟失問題

需要一個高的吞吐量

可以擴展到很多的數(shù)據(jù)平臺

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

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

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

快速存儲

最大容量是有限的

需要去讀取整個文件

查詢不是很容易

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

查詢方便

高吞吐量

維護成本高

Cassandra 是分布式 NoSQL 數(shù)據(jù)庫的一個典型選擇，但是他仍然需要一個專門的 DevOps 來設(shè)置，維護，監(jiān)視，擴展等等。因此，分布式 NoSQL 是存儲數(shù)據(jù)的默認選項，因為我們需要一個可以方便查詢的數(shù)據(jù)庫。

對于那些想要減少 DevOps 人員工作量的人來說，有一個簡單的解決方案就是使用 Parquet。

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

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

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

讀取速度很快

存儲效率很高

架構(gòu)混亂

迭代困難

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

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

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

時間依賴型的作業(yè)

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

監(jiān)控和報警

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

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

其他工作流的管理方式

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

Python 開發(fā)的一個簡單的工作流管理解決方案，由 Spotify 開源。

低門檻

依賴管理（鏈式結(jié)構(gòu)）

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

故障恢復

沒有調(diào)度

沒有流媒體

難以擴展

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

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

由于功能的強大，所有學習門檻有點高

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

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