作者 | Phoebe Wong

譯者 | 陸離

編輯 | Jane

出品 | AI科技大本營（ID：rgznai100）

前言

如何才能成為一名真正的“全棧（full-stack）”數(shù)據(jù)科學家？需要了解哪些知識？掌握哪些技能？

概括來講，一名全能型選手要把數(shù)據(jù)科學過程中從數(shù)據(jù)存儲到把預測模型投入正式生產(chǎn)的每一步都能 hold 住。

一般來說，大家在學習過程中更注重機器學習或深度學習技術的理論學習與應用，數(shù)據(jù)管理方面的知識往往是“事后諸葛亮”；數(shù)據(jù)科學專業(yè)的學生們對如何處理、清洗數(shù)據(jù)等建模技術關注較多，忽略了如何制作“數(shù)據(jù)香腸”。

但是在真實工程環(huán)境中，有近 80%的工作都在圍繞“如何從各種來源獲取原始數(shù)據(jù)”這一步驟，從而為后續(xù)搭建模型做準備；此外，企業(yè)級的項目通常涉及大量數(shù)據(jù)，本地計算機并不具備處理這些數(shù)據(jù)的能力。

因此整個建模過程通常會在云上進行，大多應用和數(shù)據(jù)庫也會托管在其它地方的數(shù)據(jù)中心服務器上，數(shù)據(jù)管理則成為數(shù)據(jù)工程團隊非常關心的事情。

NIST大數(shù)據(jù)分類 (來源：WikiCommons)

由于很多數(shù)據(jù)科學家對數(shù)據(jù)存儲和基礎設施了解甚少，影響了他們在工作中做出正確決策的能力。

而這篇文章就旨在提供一個線路圖，從數(shù)據(jù)庫類型、數(shù)據(jù)存儲和處理的位置和方式，到當前的商業(yè)選擇，給想成為一名數(shù)據(jù)科學家的開發(fā)者們分享必備的數(shù)據(jù)管理知識。

基于此文涉及面廣，系統(tǒng)知識全面，對初級數(shù)據(jù)科學家、數(shù)據(jù)科學專業(yè)的學生、想轉(zhuǎn)行進入數(shù)據(jù)科學領域的開發(fā)者們都很適合；對從業(yè)經(jīng)驗豐富，已深耕此領域的開發(fā)者來說，內(nèi)容偏基礎，不過大家可以基于此文進行更深入地研究，歡迎大家互動交流，分享你的觀點和意見。

非結構化數(shù)據(jù)和大數(shù)據(jù)工具的興起

IBM 305 RAMAC (來源：WikiCommons)

實際上，數(shù)據(jù)科學的本質(zhì)就是數(shù)據(jù)存儲。在進入數(shù)字時代之前，數(shù)據(jù)存儲在我們的大腦中、陶片或紙上，這使得數(shù)據(jù)的收集和分析極其耗時。

1956年，IBM推出了第一臺帶有磁盤的商用計算機，305 RAMAC。整個單元需要30英尺x 50英尺的物理空間，重量超過一噸，租一個這樣的單元，每個月花費 3200 美元，可存儲大約5MB的數(shù)據(jù)。

在隨后60年的時間里，DRAM每GB價格從1965年的26.4億美元大幅下降到2017年的4.9美元。數(shù)據(jù)存儲設備不僅價格極其低廉，而且密度更大、體積更小。

在305 RAMAC的一個磁盤中，每平方英寸存儲100 比特的數(shù)據(jù)，對比之下，今天的一個普通磁盤，每平方英寸存儲數(shù)據(jù)可超過1萬億比特。

數(shù)據(jù)存儲的成本和規(guī)模的大幅降低正是現(xiàn)如今讓大數(shù)據(jù)分析成為可能的主要原因。憑借超低的存儲成本，建設數(shù)據(jù)科學基礎設施，從海量數(shù)據(jù)中收集和提取有用的信息，這也成為了企業(yè)盈利的途徑。

隨著不斷生產(chǎn)和傳輸用戶數(shù)據(jù)的物聯(lián)網(wǎng)（IoT）設備的大量涌現(xiàn)，企業(yè)們正在收集越來越多的用戶行為數(shù)據(jù)，并創(chuàng)造大量的高容量、高速度和高多樣性的信息資產(chǎn)（或稱為“3V大數(shù)據(jù)”）。

這些行為（如電子郵件、視頻、音頻、聊天信息、社交媒體帖子）大多產(chǎn)生了非結構化數(shù)據(jù)，這些數(shù)據(jù)占當今企業(yè)數(shù)據(jù)總量的近80%，增長速度是在過去十年中結構化數(shù)據(jù)的兩倍。

圖中顯示了在2017年存儲了125 EB的企業(yè)數(shù)據(jù)，80%是非結構化數(shù)據(jù) (來源：Credit Suisse)

海量數(shù)據(jù)的增長極大地改變了數(shù)據(jù)存儲和分析的方式，因為傳統(tǒng)的工具和方法不具備處理“3V大數(shù)據(jù)”的能力。隨著新技術的發(fā)展，有能力處理不斷增長的數(shù)據(jù)量和數(shù)據(jù)種類，并且速度更快，成本更低。

這些新的工具還對數(shù)據(jù)科學家的工作方式產(chǎn)生了深遠的影響，使他們能夠通過數(shù)據(jù)分析，以及開發(fā)前看起來不可能的應用程序來實現(xiàn)海量數(shù)據(jù)的變現(xiàn)。下面列舉的是我們認為每個數(shù)據(jù)科學家都應該知道的大數(shù)據(jù)管理領域的創(chuàng)新方法。

關系數(shù)據(jù)庫和NoSQL

關系數(shù)據(jù)庫管理系統(tǒng)（RDBMS）出現(xiàn)于20世紀70年代，它將數(shù)據(jù)存儲在具有行和列的表里面，使用結構化查詢語言（SQL）進行查詢和維護數(shù)據(jù)庫。關系數(shù)據(jù)庫基本上就是多個表的集合，每個表中都有一個模式（schema），模式嚴格定義了所存儲數(shù)據(jù)的屬性和類型，以及標識用于訪問的特定行或列的鍵。

RDBMS曾經(jīng)由Oracle和IBM所統(tǒng)治，但現(xiàn)在，出現(xiàn)了許多開源的數(shù)據(jù)庫系統(tǒng)，如MySQL、SQLite和PostgreSQL等等，也同樣很受歡迎。

上圖顯示了RDBMS的受歡迎度排名 (來源：DB-Engines)

由于一些特性非常受歡迎，關系數(shù)據(jù)庫在商業(yè)領域中找到了一席之地，而數(shù)據(jù)完整性是關系數(shù)據(jù)庫中最重要的特性之一。

RDBMS須滿足原子性、一致性、隔離性和持久性（ACID）的要求，它利用一些約束來確保所存儲數(shù)據(jù)是可靠的、準確的，這就使它們成為監(jiān)測和存儲一些諸如帳號、訂單和付款等數(shù)據(jù)信息的理想選擇。

但是，這些約束也帶來了高昂的代價。由于模式和數(shù)據(jù)類型的限制，RDBMS在存儲非結構化或半結構化數(shù)據(jù)方面的表現(xiàn)非常糟糕。死板的模式也使得RDBMS在創(chuàng)建、維護和升級等方面的成本變得更高。

建立RDBMS需要用戶預先擁有特定的用例，對模式的任何更改通常都是非常困難和耗時的。另外，傳統(tǒng)的RDBMS被設計用在一個單機上運行，這意味著它們在處理大量數(shù)據(jù)時的速度要慢得多。

在保證ACID特性的同時，水平擴展RDBMS（分庫分表）也是一項非常具有挑戰(zhàn)性的任務。所有的這些屬性使得傳統(tǒng)關系型數(shù)據(jù)庫管理系統(tǒng)無法處理現(xiàn)如今的大數(shù)據(jù)。

截止到2000年，一些互聯(lián)網(wǎng)公司開發(fā)了大量的非關系型（NoSQL）數(shù)據(jù)庫，因為已有的 RDBMS 可能無法長時間地支撐一個成功的互聯(lián)網(wǎng)公司（下圖是一個關于Facebook在數(shù)據(jù)量開始增長之后如何應對MySQL限制的例子）。

在當時沒有任何已有解決方案的情況下，這些互聯(lián)網(wǎng)公司創(chuàng)造了新的方法和工具來處理收集到的大量非結構化數(shù)據(jù)：谷歌發(fā)布了GFS、MapReduce和BigTable；亞馬遜發(fā)布了DynamoDB；雅虎發(fā)布了Hadoop；Facebook發(fā)布了Cassandra和Hive；LinkedIn發(fā)布了Kafka。

其中一些公司開放了他們的源代碼，一些公司則發(fā)布了他們詳細的研究設計論文，這也就促進了各種新數(shù)據(jù)庫與新技術的激增，而NoSQL數(shù)據(jù)庫成為了行業(yè)中的一個主要的參與者。

上圖顯示了自2000年以來各種數(shù)據(jù)庫系統(tǒng)激增的情況。來源：Korflatis et. al (2016)

NoSQL數(shù)據(jù)庫與模式無關，它提供了存儲和操作大量非結構化和半結構化數(shù)據(jù)所需的靈活性。用戶不需要知道在創(chuàng)建數(shù)據(jù)庫的時候?qū)⒋鎯δ男╊愋偷臄?shù)據(jù)，系統(tǒng)可以適應數(shù)據(jù)類型和模式的變化。

NoSQL數(shù)據(jù)庫可以跨節(jié)點分發(fā)數(shù)據(jù)，它通常具有更高的水平伸縮性和分區(qū)容錯性。但是，這些性能優(yōu)勢同時也還伴隨著成本的開銷。NoSQL數(shù)據(jù)庫不符合ACID特性，因而，數(shù)據(jù)一致性也無法得到保證。

相反，它們提供了“最終一致性”：當舊數(shù)據(jù)被覆蓋時，它們將返回暫時有些出入的結果。

例如，當人們同時搜索同一個詞的時候，谷歌的搜索引擎索引不能更新這個詞的相關數(shù)據(jù)，因此它在我們搜索時不會返回給我們最新的數(shù)據(jù)結果，但它會返回最合適的結果。

雖然這個特性在絕對需要保證數(shù)據(jù)一致性的情況下（如金融交易）不太適合，但對于那些需要效率而不是精確度的任務的場景，它卻非常的適合。

現(xiàn)在，NoSQL分為幾個不同的類別，每個類別都有其特定的作用。

• 鍵值存儲，如Redis、DynamoDB和Cosmos DB，只用于存儲鍵值對，并提供檢索與已知鍵相關聯(lián)的值的基本功能。當速度因素很重要的時候，它們在簡單的數(shù)據(jù)庫模式下執(zhí)行的效率最高。

• 寬列存儲，如Cassandra、Scylla和HBase，將數(shù)據(jù)存儲在列族或表中，并用來為大型分布式系統(tǒng)管理PB級的數(shù)據(jù)量。

• 文檔存儲，如MongoDB和Couchbase，以XML或JSON格式存儲數(shù)據(jù)，文檔名稱作為主鍵，文檔內(nèi)容作為值。文檔可以包含許多不同的值類型，并且可以嵌套，使它們特別適用于管理分布式系統(tǒng)的半結構化數(shù)據(jù)。

• 圖形數(shù)據(jù)庫，如Neo4J和Amazon Neptune等將數(shù)據(jù)表示為相關聯(lián)節(jié)點或?qū)ο蟮木W(wǎng)絡，以便于數(shù)據(jù)的可視化和圖形化分析。圖形數(shù)據(jù)庫對于分析異構數(shù)據(jù)點之間的關系特別的有用，例如防欺詐或Facebook的好友關系圖。

MongoDB是目前最流行的NoSQL數(shù)據(jù)庫，它為一些一直在使用傳統(tǒng)RDBMS方法處理非結構化數(shù)據(jù)的企業(yè)帶來了巨大的幫助。

這里有兩個行業(yè)例子：MetLife花費了多年的時間，試圖在一個可以處理其所有保險產(chǎn)品的RDBMS上建立一個集中式的客戶數(shù)據(jù)庫，之后，一個Hackathon的人在數(shù)小時內(nèi)就用MongoDB創(chuàng)建了一個數(shù)據(jù)庫，該數(shù)據(jù)庫在不到90天就投入了生產(chǎn)。

YouGov是一家每小時收集5GB數(shù)據(jù)的市場調(diào)查公司，它將所有的數(shù)據(jù)從RDBMS遷移到了MongoDB，存儲空間節(jié)省了70%。

數(shù)據(jù)倉庫、數(shù)據(jù)湖和數(shù)據(jù)沼澤

隨著數(shù)據(jù)源的不斷增多，使用多個數(shù)據(jù)庫進行數(shù)據(jù)分析的工作變得效率低下、成本高昂。在2000年之后，出現(xiàn)了一種稱為數(shù)據(jù)倉庫（Data Warehouse）的解決方案，它能將企業(yè)所有數(shù)據(jù)庫中的數(shù)據(jù)集中起來。

數(shù)據(jù)倉庫通過創(chuàng)建一個來自不同數(shù)據(jù)源（內(nèi)部和外部）數(shù)據(jù)的存儲庫，支持從操作系統(tǒng)到分析和決策系統(tǒng)的數(shù)據(jù)流。

在大多數(shù)的情況下，數(shù)據(jù)倉庫是一個關系型數(shù)據(jù)庫，它存儲了為收集業(yè)務信息而優(yōu)化的已處理數(shù)據(jù)。

它收集了來自交易系統(tǒng)和業(yè)務應用系統(tǒng)的具有預定結構和模式的數(shù)據(jù)，這些數(shù)據(jù)通常用于生成經(jīng)營報告和分析結果。

但是，由于進入數(shù)據(jù)倉庫的數(shù)據(jù)需要在存儲之前就進行處理，還存在著大量的非結構化數(shù)據(jù)，這可能需要耗費大量的時間和資源。

因此，企業(yè)開始維護數(shù)據(jù)湖（Data Lakes），它能以任何規(guī)模存儲企業(yè)的所有結構化和非結構化的數(shù)據(jù)。創(chuàng)建一個能存儲原始數(shù)據(jù)的數(shù)據(jù)湖，無需一開始就定義數(shù)據(jù)結構和模式。

數(shù)據(jù)湖允許用戶執(zhí)行分析任務，而無需將數(shù)據(jù)遷移到單獨的分析系統(tǒng)上，從而使企業(yè)能夠從以前不能用于分析的新數(shù)據(jù)源中獲得信息，例如，通過使用日志文件、訪問數(shù)據(jù)、社交媒體和物聯(lián)網(wǎng)設備中的數(shù)據(jù)來創(chuàng)建機器學習模型。

通過隨時都可以分析企業(yè)所有的數(shù)據(jù)，數(shù)據(jù)科學家們可以回答更多的新業(yè)務問題，或者用新數(shù)據(jù)解決舊問題。

上圖是數(shù)據(jù)倉庫與數(shù)據(jù)湖的對比(來源：AWS)

數(shù)據(jù)湖的體系結構面臨的一個常見挑戰(zhàn)是，如果沒有合適的數(shù)據(jù)質(zhì)量和數(shù)據(jù)治理框架，當數(shù)以TB計的結構化和非結構化的數(shù)據(jù)流入數(shù)據(jù)湖時，往往很難對其內(nèi)容進行分類和排序。

數(shù)據(jù)湖就變成了數(shù)據(jù)沼澤（Data Swamps），因為它們變得太亂了，無法使用。許多組織現(xiàn)在要求進行更多的數(shù)據(jù)治理和元數(shù)據(jù)管理。

分布式和并行計算：Hadoop、 Spark和MPP

雖然企業(yè)對數(shù)據(jù)存儲和計算的需求在過去幾十年里突飛猛進地增長，但傳統(tǒng)硬件的發(fā)展還遠遠跟不上要求。

企業(yè)數(shù)據(jù)不再適合標準存儲，處理大多數(shù)的大數(shù)據(jù)分析任務所需要的計算能力可能需要數(shù)周、數(shù)月，或者根本不可能在普通計算機上完成。

為了解決這一問題，許多新技術已經(jīng)發(fā)展到多臺計算機協(xié)同工作，將數(shù)據(jù)庫分發(fā)給數(shù)千臺商品服務器來進行處理。

當多個計算機連接起來形成一個網(wǎng)絡并共同完成同一任務的時候，這些計算機就形成了一個集群。

一個集群可以看作是一臺計算能力強大的計算機，它可以使用普通的硬件，非常低廉的成本，但可以顯著地提高性能、可用性和可擴展性。

Apache Hadoop是分布式數(shù)據(jù)基礎設施的一個例子，它利用集群來存儲和處理海量的數(shù)據(jù)，并支持數(shù)據(jù)湖體系結構。

數(shù)據(jù)庫技術的發(fā)展過程(來源：Business Analytic 3.0)

當你想到Hadoop的時候，就想想“數(shù)據(jù)分發(fā)”。Hadoop由三個主要的部分組成：Hadoop分布式文件系統(tǒng)（HDFS），它是一種跨多個（分布式）物理硬盤來存儲和監(jiān)測數(shù)據(jù)的方式；

MapReduce，是一種跨分布式處理器處理數(shù)據(jù)的框架；還有另一個是資源協(xié)商者（YARN），這是一個集群管理框架，它在分布式系統(tǒng)上協(xié)調(diào)資源，如CPU的大小、內(nèi)存的多少和網(wǎng)絡帶寬分配等等。

Hadoop的處理層是一個特別值得注意的創(chuàng)新：MapReduce使用一種兩步計算的方式，用于以一個可靠的、容錯的方式處理分布在大型商用集群中的大數(shù)據(jù)集。

第一步是將數(shù)據(jù)分發(fā)到多臺計算機（Map）上，每臺計算機對分發(fā)的數(shù)據(jù)片執(zhí)行并行計算。第二步是以成對的方式合并這些計算結果（Reduce）。

谷歌在2004年發(fā)表了一篇關于MapReduce的論文，2006年的時候，在開源Apache環(huán)境中實現(xiàn)了MapReduce的一個Yahoo程序員看到了這篇論文，得以為每個企業(yè)提供了使用商業(yè)硬件來存儲前所未有的數(shù)據(jù)量的能力。

盡管這個想法有很多開源的實現(xiàn)，但Google的MapReduce卻一直保持著優(yōu)勢，有點像Jacuzzi或Kleenex。

Hadoop是為迭代計算而設計的，它在一次操作中從磁盤掃描大量的數(shù)據(jù)，將處理任務分發(fā)到多個節(jié)點，并將結果返回并存儲到磁盤上。

使用Hadoop和HBase，查詢ZB級的索引數(shù)據(jù)可以在10-12秒內(nèi)完成，而在傳統(tǒng)數(shù)據(jù)倉庫環(huán)境中運行則需要4個小時。

Hadoop通常用于生成復雜的分析模型或海量數(shù)據(jù)存儲的應用程序，例如回顧性和預測性分析、機器學習和模式匹配、客戶細分和客戶流失分析，以及活動歸檔等等。

但是，MapReduce用于處理批量的數(shù)據(jù)，因此它不適合處理實時數(shù)據(jù)。Apache Spark是在2012年發(fā)布的，可以用來填補這一空白。Spark是一種并行數(shù)據(jù)處理工具，它通過在內(nèi)存中處理數(shù)據(jù)來提高運行速度和效率。

它與MapReduce的原理相同，但通過在內(nèi)存中完成大部分的計算工作，并且僅在內(nèi)存已滿或計算完成的時候才會寫入磁盤，因此，它的運行速度會快得多。

這種內(nèi)存計算允許Spark“在內(nèi)存中運行程序比在Hadoop MapReduce中快100倍，比在磁盤上快10倍”。

然而，當數(shù)據(jù)集太大而導致內(nèi)存不足（通常是數(shù)百GB以上）的時候，Hadoop MapReduce可能比Spark表現(xiàn)的更好。

Spark還擁有一套強大的數(shù)據(jù)分析庫，涵蓋了廣泛的功能：用于SQL的Spark SQL和結構化數(shù)據(jù)，用于機器學習的MLib，用于流式計算的Spark Streaming和用于圖形分析的GraphX。

由于Spark的重點是計算，所以它沒有自帶的存儲系統(tǒng)，而是運行在各種存儲系統(tǒng)之上，如 Amazon S3、Azure Storage和Hadoop’s HDFS。

在MPP系統(tǒng)中，所有的節(jié)點都是互連的，數(shù)據(jù)可以通過網(wǎng)絡進行交換(來源：IBM)

Hadoop和Spark并不是唯一利用集群處理海量數(shù)據(jù)的技術。另一個流行的分布式查詢處理方法稱為大規(guī)模并行處理（Massively Parallel Processing ，MPP）。

類似于MapReduce，MPP跨多個節(jié)點分發(fā)數(shù)據(jù)處理任務，并且節(jié)點利用更加快速的并行處理方式。

但與Hadoop不同的是，MPP是在RDBMS中使用的，并使用“無共享”式的體系結構，每個節(jié)點使用多核處理器處理自己的數(shù)據(jù)片，使它們比傳統(tǒng)的RDBMS快很多倍。

一些MPP數(shù)據(jù)庫，如Pivotal Greenplum，擁有成熟的機器學習庫，允許進行庫內(nèi)數(shù)據(jù)分析。

然而，與傳統(tǒng)的RDBMS一樣，大多數(shù)MPP數(shù)據(jù)庫不支持非結構化數(shù)據(jù)，甚至結構化數(shù)據(jù)也需要通過一些處理之后才能適應MPP的基礎結構。

因此，為MPP數(shù)據(jù)庫設置數(shù)據(jù)管道需要花費額外的時間和資源。

由于MPP數(shù)據(jù)庫是支持ACID特性的，并且比傳統(tǒng)的RDBMS執(zhí)行速度要快得多，因此它們通常用于高級企業(yè)數(shù)據(jù)倉庫解決方案，如Amazon Redshift、 Pivotal Greenplum和 Snowflake。

作為一個行業(yè)案例，紐約證券交易所每天接收4~5TB的數(shù)據(jù)量，并進行復雜的分析、市場調(diào)查、容量規(guī)劃和監(jiān)測。

該公司一直在使用一個幾乎無法承擔數(shù)據(jù)處理工作的傳統(tǒng)數(shù)據(jù)庫系統(tǒng)，它需要數(shù)小時才能加載完成，查詢速度也非常的差。遷移到MPP數(shù)據(jù)庫后，他們每日的運行數(shù)據(jù)分析時間減少了8個小時。

云服務

另一個徹底改變的企業(yè)大數(shù)據(jù)分析能力的創(chuàng)新是云服務的興起。

在云服務出現(xiàn)之前，企業(yè)不得不從軟件和硬件的供應商那里購買本地數(shù)據(jù)存儲軟件、設備和數(shù)據(jù)分析解決方案，這通常要支付永久性的軟件許可費用以及每年的硬件維護費和技術服務費。

除此之外，還有電力、空調(diào)、網(wǎng)絡安全、容災保護、IT技術人員等方面的成本，用于建設和維護內(nèi)部基礎設施。

即使在技術上有能力存儲和處理大數(shù)據(jù)的時候，大多數(shù)企業(yè)也會發(fā)現(xiàn)海量數(shù)據(jù)的存儲和處理的成本太高了。

另外，擴展內(nèi)部基礎設施還需要一個設計和采購的過程，這需要很長的時間來實施，并需要大量的資金預算。許多潛在有價值的數(shù)據(jù)收集和分析可能就因此被放棄了。

云服務的提供商：例如基礎設施即服務（IaaS）和存儲即服務（SaaS）(來源：IMELGRAT.ME)

當云服務在2000年末被引入的時候，內(nèi)部自建模式開始迅速地失去了市場份額——在過去十年里，全球云服務市場份額每年增長15%。

云服務平臺提供對各種服務（從虛擬計算到存儲基礎設施再到數(shù)據(jù)庫）的定制，這些服務在線通過用多少付多少的方式提供，為用戶靈活快速地訪問和低成本的數(shù)據(jù)存儲，以及為虛擬計算資源提供了便利條件。

云服務提供商負責其所有硬件和軟件的采購和維護，他們通常擁有龐大的服務器網(wǎng)絡和技術支持團隊來提供可靠的服務。

許多企業(yè)在使用之后發(fā)現(xiàn)，他們可以通過云服務顯著降低運營成本和提高運營效率，并且能夠利用現(xiàn)成的云資源和內(nèi)置的可伸縮性更快地開發(fā)和生產(chǎn)產(chǎn)品。

不僅沒有了自建基礎設施的巨大成本和周期，云服務還避免了搭建大數(shù)據(jù)平臺的麻煩，并有效地使中小企業(yè)的大數(shù)據(jù)分析工作更加的靈活。

這里有幾種云服務模型，其中公有云是最常見的。

• 在公有云中，所有硬件、軟件和其它的支撐基礎設施都由云服務提供商自行搭建和管理。用戶與其他的“云租戶”共享云基礎設施，并可以通過Web瀏覽器訪問他們的服務。

• 而具有特殊安全需求的組織通常會使用私有云，如政府機構和金融機構等。在私有云中，服務和基礎設施僅提供給一個組織使用，并在私有網(wǎng)絡上進行維護。私有云可以是本地的，也可以由第三方服務提供商托管。

• 混合云將私有云與公有云結合起來，使組織能夠同時獲得兩者的優(yōu)勢。在混合云中，數(shù)據(jù)和應用程序可以在私有云和公有云之間進行傳輸和訪問以獲得更大的靈活性：例如，公有云可用于高訪問量、低安全性的數(shù)據(jù)，而私有云可用于敏感的、業(yè)務關鍵型的數(shù)據(jù)，如財務報告、金融數(shù)據(jù)等等。

• 多云模型則涉及到多個云平臺，每個平臺都提供特定的應用服務。多云可以是公有云、私有云和混合云的組合，以實現(xiàn)組織的目標為目的。組織通常選擇多云是為了滿足一些特定的業(yè)務，以及位置和時間上的需求，并避免供應商的局限性。

案例研究：構建端到端的數(shù)據(jù)科學基礎設施

設計一個可行的數(shù)據(jù)產(chǎn)品，不僅僅是用Scikit-Learn（Scikit-learn是專門面向機器學習的Python開源框架）構建一個機器學習模型，還要對其進行反復優(yōu)化，并加載到服務器上。

不同數(shù)據(jù)環(huán)境下的機器學習包(來源：Kosyakov (2016))

它需要了解企業(yè)生態(tài)系統(tǒng)的所有部分是如何協(xié)同工作的，從數(shù)據(jù)流入的位置和方式、數(shù)據(jù)處理和轉(zhuǎn)換的環(huán)境、企業(yè)可視化和展現(xiàn)數(shù)據(jù)的慣例，以及如何將模型輸出轉(zhuǎn)換為某些其它的企業(yè)應用的輸入。

它的主要目標包括創(chuàng)建一個易于維護的過程，在這個過程中，模型可以被迭代，性能是可復制的，模型的輸出可以可視化地展現(xiàn)出來并能讓老板們輕松地理解，以便他們能做出更加明智的業(yè)務決策。

實現(xiàn)這些目標需要選擇正確的工具，并了解同行們都正在做什么以及做出了什么成果。接下來，我們用一個場景來加以說明。

假設你剛剛被一家度假推薦App的初創(chuàng)公司聘為首席數(shù)據(jù)科學家，該公司預計將收集數(shù)百GB的關于用戶每天的數(shù)據(jù)，包括結構化的（客戶資料、溫度、價格和交易記錄）和非結構化的（客戶的帖子、評論和圖片文件）。

你的預測模型需要每周都重新訓練新的數(shù)據(jù)，并根據(jù)需要即時提出合理化建議。想讓自己的這款 APP 應用能大受歡迎，數(shù)據(jù)的收集、存儲和分析能力必須是可擴展的。

你將如何設計數(shù)據(jù)處理過程和模型產(chǎn)品化呢？你需要什么樣的工具來完成工作呢？既然這是一家初創(chuàng)公司，而你是數(shù)據(jù)科學家中的首席，或許也是唯一的數(shù)據(jù)科學家，那么就只能由你來做這些決定。

首先，你必須了解如何設置數(shù)據(jù)管道，管道接收來自數(shù)據(jù)源的原始數(shù)據(jù)，并進行數(shù)據(jù)處理，然后將處理過的數(shù)據(jù)寫入數(shù)據(jù)庫。

理想化的數(shù)據(jù)管道具有較低的事件延遲（在收集到數(shù)據(jù)后能夠立即進行數(shù)據(jù)查詢）、可伸縮性（能夠在產(chǎn)品擴展時處理海量數(shù)據(jù)）、交互式查詢功能（支持批量查詢和較小規(guī)模的交互式查詢，使數(shù)據(jù)科學家能夠查找表和模式）、版本控制功能（在不關閉管道和丟失數(shù)據(jù)的情況下對管道進行修改的能力）；

監(jiān)控功能（數(shù)據(jù)一旦停止輸入管道應促發(fā)警報）、可測試性（在不中斷的情況下測試管道的能力）。

或許最重要的是它最好不要干擾日常的業(yè)務操作，例如，如果你正在測試新的模型，進而導致數(shù)據(jù)庫操作停止，則操作會回滾。

創(chuàng)建和維護數(shù)據(jù)管道通常是數(shù)據(jù)工程師的職責（本文對初創(chuàng)公司創(chuàng)建數(shù)據(jù)管道有一個更詳細的概述），但是數(shù)據(jù)科學家至少也應該熟悉這個過程和它的局限性，以及對處理過的數(shù)據(jù)進行分析的工具。

接下來，你必須決定企業(yè)是要自建基礎設施還是使用云服務。對于初創(chuàng)公司來說，首要任務是在不增加有限資源的情況下擴大數(shù)據(jù)收集量。

如前面所說，自建基礎設施需要巨大的前期投入和維護成本，因此云服務往往是初創(chuàng)公司更好的選擇。

云服務允許自由擴展來滿足需求，并且只需要很少的維護工作，這樣你的小團隊就可以專注于產(chǎn)品設計和數(shù)據(jù)分析工作了，而不是對基礎設施的管理。

上圖顯示了一些提供基于Hadoop解決方案的供應商 (來源：WikiCommons)

為了選擇一個云服務商，你必須先確定要分析的數(shù)據(jù)，然后再確定最適合這些數(shù)據(jù)類型的數(shù)據(jù)庫和基礎設施。

由于在數(shù)據(jù)分析的管道當中既有結構化數(shù)據(jù)，也有非結構化數(shù)據(jù)，所以你可能希望同時建立數(shù)據(jù)倉庫和數(shù)據(jù)湖。

數(shù)據(jù)科學家需要考慮的一個重要問題是，存儲層是否支持構建模型所需要的大數(shù)據(jù)工具，以及數(shù)據(jù)庫是否提供了有效的庫內(nèi)分析功能。

例如，Spark的MLlib等一些機器學習庫不能有效地將數(shù)據(jù)庫作為主要接口使用，必須先從數(shù)據(jù)庫中把數(shù)據(jù)下載下來，然后才能對其進行操作，這可能會隨著數(shù)據(jù)量的增長而越來越耗時，而當你不得不定期重新訓練模型的時候，這就將會成為性能的瓶頸。

對于云端的數(shù)據(jù)科學，大多數(shù)云服務提供商正在努力開發(fā)他們的本地機器學習功能，這就允許數(shù)據(jù)科學家可以使用存儲在自己平臺上的數(shù)據(jù)來輕松構建和部署機器學習模型（亞馬遜有SageMaker，谷歌有BigQuery ML，微軟有 Azure Machine Learning）。

但是這些工具集目前仍然處于開發(fā)完善階段，而且功能上時常不太完整，例如，BigQuery ML目前只支持線性回歸、二元邏輯回歸和多類邏輯回歸、K-means聚類和TensorFlow模型導入。

如果決定使用這些工具，你必須完整地測試一下它們的功能，以確保能完成你的任務。

選擇云服務提供商時要考慮的另一個重要問題是產(chǎn)品供應商的選擇。如果選擇專有的云數(shù)據(jù)庫解決方案，則很可能無法訪問本地環(huán)境中的應用或數(shù)據(jù)，而更換供應商則需要遷移到其它的數(shù)據(jù)庫系統(tǒng)，這很可能會產(chǎn)生高昂的成本。

解決這個問題的一個方法是選擇支持開源技術的供應商（這里是Netflix解釋為什么使用開源軟件的理由）。

使用開源技術的另一個優(yōu)勢是，它們往往會吸引更多的用戶，這意味著可以更容易地找到熟悉你的基礎架構并具有相關工作經(jīng)驗和技能的技術人員。

還有另外一個方法,就是選擇一個第三方供應商（如Pivotal Greenplum和Snowflake），他們使用一些主要的云服務提供商作為數(shù)據(jù)存儲端來提供云數(shù)據(jù)庫解決方案，這將允許你把數(shù)據(jù)同時存儲在多個云平臺上，如果這適合你的初創(chuàng)公司的需求。

最后，由于你是這家初創(chuàng)公司的首席數(shù)據(jù)科學家，并且希望公司能夠發(fā)展壯大，那么你必須建立一個強大的云服務管理機制來保護你的云安全，防止數(shù)據(jù)的丟失和泄漏，比如管理數(shù)據(jù)訪問權限、保護各種數(shù)據(jù)接口和API。當然你還希望實現(xiàn)最佳的數(shù)據(jù)治理效果，以維護數(shù)據(jù)的質(zhì)量，并確保數(shù)據(jù)湖不會變成數(shù)據(jù)沼澤。

原文鏈接：