NIST Big Data Taxonomy (Source: WikiCommons)

Phoebe Wong和Robert Bennett

要成為真正的"全棧"資料科學家，或者被許多博主和僱主稱為"獨角獸"，您必須掌握資料科學過程的每個步驟-從儲存資料到完成產品的整個過程（通常是預測模型）。但是，大多數資料科學培訓都集中在機器/深度學習技術上。資料管理知識通常被認為是事後的想法。資料科學專業的學生通常會使用膝上型電腦上儲存的文字檔案中經過處理和清理的資料來學習建模技能，而忽略瞭如何製作資料香腸。學生通常不會意識到在行業環境中，從各種來源獲取原始資料以進行建模通常是工作的80％。而且，由於企業專案通常涉及本地無法處理的大量資料，因此整個建模過程通常在雲上進行，大多數應用程式和資料庫託管在其他資料中心的伺服器上。即使在學生畢業後，找到了資料科學家的工作之後，資料管理通常也變成了由單獨的資料工程團隊負責的事情。結果，太多的資料科學家對資料儲存和基礎設施知之甚少，這常常損害了他們在工作中做出正確決定的能力。本文的目的是為2019年資料科學家應瞭解的資料管理提供一個路線圖-從資料庫型別，資料在何處，以及如何儲存和處理到當前資料的商業選擇，-以便有抱負的"獨角獸"可以自己更深入地學習，或者至少在面試和雞尾酒會上發出足夠多的聲音。

非結構化資料和大資料工具的興起

IBM 305 RAMAC (Source: WikiCommons)

資料科學的故事實際上就是資料儲存的故事。 在數字化時代之前，資料被儲存在我們的頭腦中，粘土板上或紙上，這使得彙總和分析資料非常耗時。 1956年，IBM推出了第一臺帶有磁碟驅動器的商用計算機305 RAMAC。 整個裝置需要30英尺x 50英尺的物理空間，重達一噸，每月花費3200美元，公司可以租用該裝置以儲存多達5MB的資料。 從那以後的60年中，DRAM的每千兆位元組價格已從1965年的26.4億美元下降到2017年的4.9美元。除了價格便宜之外，資料儲存也變得越來越密集/越來越小。 305 RAMAC中的磁碟儲存每平方英寸儲存一百位，而如今的典型磁碟儲存每平方英寸儲存超過萬億位。

資料儲存成本和大小的顯著降低結合在一起，才使當今的大資料分析成為可能。 以超低的儲存成本，建立資料科學基礎架構，以從大量資料中收集和提取見解，已成為企業的獲利方法。 隨著大量IoT裝置不斷生成和傳輸使用者資料，企業正在收集數量越來越多的有關資料，從而建立了大量的高容量，高速度和高多樣性的資訊資產（或 "大資料的三個Vs"）。 其中大多數活動（例如電子郵件，影片，音訊，聊天訊息，社交媒體帖子）都會生成非結構化資料，這些資料佔當今企業總資料的近80％，並且其增長速度是過去十年中結構化資料的兩倍。

125 Exabytes of enterprise data was stored in 2017; 80% was unstructured data. (Source: Credit Suiss

大量的資料增長極大地改變了資料的儲存和分析方式，因為傳統的工具和方法無法應對"三個大資料"的特性。開發出了能夠處理不斷增長的數量和種類的資料的新技術，並且速度更快，成本更低。 這些新工具還對資料科學家的工作方式產生深遠影響-允許他們透過執行分析和構建以前無法實現的新應用程式，透過海量資料獲利。 以下是我們認為每位資料科學家都應瞭解的主要大資料管理創新。

關係資料庫和NoSQL

關係資料庫管理系統（RDBMS）於1970年代問世，它使用結構化查詢語言（SQL）語句查詢和維護資料庫，將資料儲存為具有行和列的表。 關係資料庫基本上是表的集合，每個表都具有一個模式，該模式嚴格定義了它們儲存的資料的屬性和型別，以及用於標識特定列或行以方便訪問的鍵。 RDBMS格局曾經由Oracle和IBM統治，但是如今許多開源選項（例如MySQL，SQLite和PostgreSQL）同樣受歡迎。

RDBMS ranked by popularity (Source: DB-Engines)

關係資料庫由於具有一些非常吸引人的特性而在商業世界中找到了自己的位置。在關係資料庫中，資料完整性絕對至關重要。 RDBMS透過施加許多約束條件來確保儲存的資料可靠且準確，從而滿足跟蹤，儲存，帳號，訂單，和付款。但是這些限制伴隨著代價高昂的折衷。由於架構和型別的限制，RDBMS在儲存非結構化或半結構化資料時非常糟糕。嚴格的架構也使RDBMS的設定，維護和增長變得更加昂貴。設定RDBMS要求使用者事先具有特定的用例。對模式的任何更改通常都是困難且耗時的。此外，傳統的RDBMS被設計為在單個計算機節點上執行，這意味著在處理大量資料時，它們的速度大大降低。分片RDBMS以便在保持ACID合規性的同時進行水平擴充套件也非常具有挑戰性。所有這些屬性使傳統的RDBMS不能很好地處理現代大資料。

到2000年代中期，現有的RDBMS不再能夠處理一些非常成功的線上業務的變化需求和指數增長，結果開發了許多非關係（或NoSQL）資料庫（這是有關Facebook如何處理的故事，資料量開始增長時受到MySQL的限制）。 當時還沒有任何已知的解決方案，這些線上業務發明了新的方法和工具來處理他們收集的大量非結構化資料：Google建立了GFS，MapReduce和BigTable； 亞馬遜建立了DynamoDB； 雅虎建立了Hadoop； Facebook建立了Cassandra和Hive； LinkedIn建立了Kafka。 這些業務中有一些是開源的。 一些發表的研究論文詳細介紹了它們的設計，導致使用新技術的資料庫激增，NoSQL資料庫成為該行業的主要參與者。

An explosion of database options since the 2000's. Source: Korflatis et. al (2016)

NoSQL資料庫與模式無關，並提供儲存和處理大量非結構化和半結構化資料所需的靈活性。使用者無需知道在設定過程中將儲存什麼型別的資料，並且系統可以適應資料型別和架構的更改。設計用於在不同節點之間分佈資料，NoSQL資料庫通常具有更高的水平可擴充套件性和容錯性。但是，這些效能優勢也要付出代價-NoSQL資料庫不符合ACID，並且不能保證資料的一致性。相反，它們提供了"最終的一致性"：當舊資料被覆蓋時，它們會暫時返回錯誤的結果。例如，當人們同時搜尋給定術語時，Google的搜尋引擎索引無法覆蓋其資料，因此當我們進行搜尋時，它不會為我們提供最新的結果，但可以為我們提供最新，最佳的答案它可以。儘管此設定在絕對需要資料一致性（例如財務交易）的情況下不起作用；對於需要速度而不是精確度的任務來說，這是很好的選擇。

現在有幾種不同的NoSQL類別，每種類別都有特定的用途。鍵值儲存（例如Redis，DynamoDB和Cosmos DB）僅儲存鍵值對，並提供用於檢索與已知鍵關聯的值的基本功能。當速度很重要時，它們最適合使用簡單的資料庫架構。列儲存（例如Cassandra，Scylla和HBase）將資料儲存在列或表中，並被構建為在大規模分散式系統中管理的PB級資料。文件儲存（例如MongoDB和Couchbase）以XML或JSON格式儲存資料，文件名稱為鍵（key），文件內容為值（value）。這些文件可以包含許多不同的值型別，並且可以巢狀，使它們特別適合於管理分散式系統中的半結構化資料。諸如Neo4J和Amazon Neptune之類的圖形資料庫將資料表示為相關節點或物件的網路，以便於資料視覺化和圖形分析。圖形資料庫對於分析異構資料點之間的關係特別有用，例如在欺詐預防或Facebook的朋友圖形中。

MongoDB是目前最流行的NoSQL資料庫，並且為一些使用傳統RDBMS方法處理非結構化資料的企業提供了可觀的價值。 這是兩個行業示例：大都會人壽（MetLife）花費了數年時間試圖在可以處理其所有保險產品的RDBMS上建立集中式客戶資料庫之後，內部駭客馬拉松中的某人在數小時內就用MongoDB構建了一個數據庫，並在90天內投入生產。 市場研究公司YouGov每小時收集5GB的資料，透過從RDBMS遷移到MongoDB，節省了以前使用的70％的儲存容量。

資料倉庫，資料湖和資料沼澤

隨著資料來源的不斷增長，使用多個數據庫執行資料分析變得效率低下且成本高昂。 1980年代出現了一種稱為資料倉庫的解決方案，該解決方案集中了企業所有資料庫中的資料。 資料倉庫透過建立來自各種來源（內部和外部）的單個數據儲存庫，支援從作業系統到分析/決策系統的資料流。 在大多數情況下，資料倉庫是一個關係資料庫，用於儲存經過處理的資料，這些資料針對收集業務見解進行了最佳化。 它收集來自交易系統和業務應用程式的具有預定結構和架構的資料，並且該資料通常用於運營報告和分析。

但是，由於儲存在資料倉庫中的資料需要在儲存之前進行預處理，使用當今大量的非結構化資料，這可能會花費大量時間和資源。 作為對策，企業在2010年開始維護Data Lakes，該資料湖以任意規模儲存企業的所有結構化和非結構化資料。 資料湖儲存原始資料，無需先定義資料結構和架構即可進行設定。 資料湖使使用者無需將資料移至單獨的分析系統即可執行分析，從而使企業能夠從以前無法進行分析的新資料來源中獲取見解，例如，透過使用日誌檔案中的資料構建機器學習模型， 點選流，社交媒體和物聯網裝置。 透過使所有企業資料易於分析，資料科學家可以回答一組新的業務問題，或者用新資料解決舊問題。

Data Warehouse and Data Lake Comparisons (Source: AWS)

Data Lake體系結構的一個共同挑戰是，如果沒有適當的資料質量和治理框架，當數以千億計的結構化和非結構化資料流入Data Lakes時，對它們的內容進行分類通常變得非常困難。 由於儲存的資料太亂而無法使用，因此資料湖可能會變成資料沼澤。 現在，許多組織都在呼籲採取更多的資料治理和元資料管理實踐，以防止形成資料沼澤。

分散式和並行處理：Hadoop，Spark和MPP

在過去的幾十年中，儘管儲存和計算需求突飛猛進，但傳統硬體的發展還不足以跟上步伐。企業資料不再完全適合標準儲存，處理大多數大資料分析任務所需的計算能力可能需要數週，數月，甚至根本無法在標準計算機上完成。為了克服這一缺陷，許多新技術已經發展為包括多臺計算機協同工作，將資料庫分發到數千個商用伺服器。連線計算機網路並共同完成同一任務時，這些計算機將組成一個群集。群集可以看作是一臺計算機，但是可以透過使用商品硬體以更低的成本大大提高一臺功能更強大的計算機的效能，可用性和可伸縮性。 Apache Hadoop是分散式資料基礎架構的一個示例，該基礎架構利用群集來儲存和處理大量資料，並啟用了Data Lake體系結構。

Evolution of database technologies (Source: Business Analytic 3.0)

當您考慮Hadoop時，請考慮"分散式"。Hadoop由三個主要元件組成：Hadoop分散式檔案系統（HDFS），一種跨多個（分散式）物理硬碟驅動器儲存和跟蹤資料的方式； MapReduce，一個用於在分散式處理器上處理資料的框架；還有另一個資源協商程式（YARN），它是一個群集管理框架，可在分散式計算機之間協調諸如CPU使用率，記憶體和網路頻寬分配之類的事物的分佈。 Hadoop的處理層是一項特別引人注目的創新：MapReduce是一種兩步計算方法，用於以可靠，容錯的方式處理分佈在大型商業硬體叢集中的大型（TB級或更大）資料集。第一步是將資料分佈在多臺計算機（map）上，每臺計算機並行對其資料切片執行計算。下一步是以成對的方式合併這些結果（reduce）。 Google於2004年在MapReduce上發表了一篇論文，該論文得到了Yahoo程式設計師的青睞，他們於2006年在開源Apache環境中實現了該功能，從而為每家企業提供了使用商品硬體儲存前所未有的資料量的功能。即使該想法有許多開源實現，Google品牌名稱MapReduce仍然存在，就像Jacuzzi或Kleenex。

Hadoop專為迭代計算而構建，可透過一次操作從磁碟掃描大量資料，將處理分佈在多個節點上，並將結果儲存回磁碟。 在Hadoop和HBase中，在傳統的資料倉庫環境中執行需要4個小時才能執行的索引資料的ZB級查詢可以在10到12秒內完成。 Hadoop通常用於生成複雜的分析模型或大容量資料儲存應用程式，例如追溯和預測分析。 機器學習和模式匹配； 客戶細分和客戶流失分析； 和活動檔案。

但是MapReduce批次處理資料，因此不適合處理實時資料。 Apache Spark成立於2012年，以填補這一空白。 Spark是一個並行資料處理工具，透過在記憶體中處理資料來最佳化速度和效率。它以相同的MapReduce原理執行，但是透過完成記憶體中的大多數計算並且僅在記憶體已滿或計算完成時才寫入磁碟，它執行得更快。這種記憶體內計算使Spark"在記憶體中執行程式的速度比Hadoop MapReduce快100倍，在磁碟上的速度快10倍。"但是，當資料集太大而導致RAM不足成為問題時（通常為數百GB或更多） ），Hadoop MapReduce可能會勝過Spark。 Spark還具有廣泛的資料分析庫，涵蓋了廣泛的功能：用於SQL和結構化資料的Spark SQL；MLib用於機器學習，Spark Streaming用於流處理，而GraphX用於圖形分析。由於Spark的重點是計算，因此它沒有自己的儲存系統，而是在各種儲存系統（例如Amazon S3，Azure儲存和Hadoop的HDFS）上執行。

In an MPP system, all the nodes are interconnected and data could be exchanged across the network (S

並非只有Hadoop和Spark能夠利用群集來處理大量資料。分散式查詢處理的另一種流行的計算方法稱為大規模並行處理（MPP）。與MapReduce相似，MPP在多個節點之間分佈資料處理，並且節點並行處理資料以提高速度。但是與Hadoop不同，MPP用於RDBMS，並使用"無共享"架構-每個節點都使用多核處理器處理自己的資料片段，使其速度比傳統RDBMS快許多倍。一些MPP資料庫，例如Pivotal Greenplum，具有成熟的機器學習庫，可用於資料庫內分析。但是，與傳統的RDBMS一樣，大多數MPP資料庫不支援非結構化資料，甚至結構化資料也需要進行一些處理才能適合MPP基礎結構；因此，要花費更多的時間和資源來建立MPP資料庫的資料管道。由於MPP資料庫符合ACID標準，並且提供的速度比傳統RDBMS快得多，因此它們通常用於高階企業資料倉庫解決方案中，例如Amazon Redshift，Pivotal Greenplum和Snowflake。作為一個行業示例，紐約證券交易所每天接收4到5TB的資料，並進行復雜的分析，市場監視，容量計劃和監視。該公司一直在使用無法處理工作負載的傳統資料庫，該資料庫要花幾個小時才能載入，查詢速度也很慢。轉移到MPP資料庫後，其每日分析執行時間減少了八個小時。

雲服務

徹底改變企業大資料分析功能的另一項創新是雲服務的興起。 在雲服務可用之前的糟糕年代，企業不得不從軟體和硬體供應商那裡購買本地資料儲存和分析解決方案，通常要支付前期永久性軟體許可費以及年度硬體維護和服務費。 最重要的是用於構建和維護本地基礎結構的電源，冷卻，安全，災難保護，IT人員等的成本。 即使從技術上講，可以儲存和處理大資料，但大多數企業發現大規模進行此操作成本過高。 使用本地基礎架構進行擴充套件還需要大量的設計和採購過程，這需要很長時間才能實施，並且需要大量的前期資金。 結果，許多潛在有價值的資料收集和分析可能性被忽略了。

"As a Service" providers: e.g. Infrastructure as a Service (IaaS) and Storage as a Service (STaaS) (

在2000年代末推出雲服務後，本地模型開始迅速失去市場份額-在過去十年中，全球雲服務市場每年以15％的速度增長。雲服務平臺提供按需付費的方式透過網際網路交付的各種服務（從虛擬計算到儲存基礎結構再到資料庫）的訂閱，為客戶提供快速訪問靈活且低成本的儲存，和虛擬計算資源。雲服務提供商負責所有硬體和軟體的購買與維護，並且通常擁有龐大的伺服器網路和支援人員以提供可靠的服務。許多企業發現他們可以使用雲服務顯著降低成本並提高運營效率，並且能夠利用現成的雲資源及其內建的可擴充套件性更快地開發和生產其產品。透過消除建立本地基礎架構的前期成本和時間承諾，雲服務還降低了採用大資料工具的障礙，並有效地使中小型企業的大資料分析民主化。

有幾種雲服務模型，最常見的是公共雲。在公共雲中，所有硬體，軟體和其他支援基礎結構均由雲服務提供商擁有和管理。客戶與其他"雲租戶"共享雲基礎架構，並透過Web瀏覽器訪問其服務。私有云通常由具有特殊安全需求的組織（例如政府機構和金融機構）使用。在私有云中，服務和基礎架構專用於一個組織，並在私有網路上維護。私有云可以是本地的，也可以由其他地方的第三方服務提供商託管。混合雲將私有云與公共雲結合在一起，使組織可以利用兩者的優勢。在混合雲中，資料和應用程式可以在私有云和公共雲之間移動，以實現更大的靈活性：公共雲可用於大批次，低安全性資料，私有云可用於敏感的關鍵業務資料，例如財務報告。多雲模型涉及多個雲平臺，每個平臺都提供特定的應用程式服務。多雲可以是公共雲，私有云和混合雲的組合，以實現組織的目標。組織經常選擇多雲以適合其特定的業務，位置和時間需求，並避免供應商鎖定。

案例研究：為推薦應用程式構建端到端資料科學基礎架構

Machine learning packages for different types of data environment (Source: Kosyakov (2016))

構建行之有效的資料科學產品，所涉及的不只是使用scikit-learn構建機器學習模型，對其進行定製並將其載入到伺服器上。 它需要了解企業生態系統的所有部分如何協同工作，從資料在何處/如何流入資料，處理/轉換資料的環境，企業如何視覺化/呈現資料，以及模型輸出如何轉換為其他一些企業應用程式的輸入。 主要目標涉及建立易於維護的流程； 在哪裡可以迭代模型，並且效能可重現； 其他利益相關者可以輕鬆理解和視覺化模型的輸出，以便他們可以做出更明智的業務決策。 要實現這些目標，就需要選擇正確的工具，並瞭解行業中其他人在做什麼，以及什麼才是最佳實踐。

讓我們用一個場景進行說明：假設您剛剛被聘為度假推薦應用程式的首席資料科學家，該應用程式有望收集數百GB的結構化（客戶資料，溫度，價格和交易記錄）和非結構化（每日來自使用者的帖子/評論和圖片檔案）資料。 您的預測模型將需要每週用新資料重新訓練，並根據需要立即提出建議預測。 由於您希望該應用程式會大受歡迎，因此資料收集，儲存和分析功能必須具有極高的可擴充套件性。 您將如何設計資料科學流程，並生產模型？ 完成工作需要哪些工具？ 由於這是一家初創企業，而您是資料科學家的領導（也許是唯一的），因此由您來做出這些決定。

首先，您必須弄清楚如何建立資料管道，該管道將從資料來源中獲取原始資料，處理資料，並將處理後的資料饋送到資料庫中。理想的資料管道具有較低的事件等待時間（能夠在收集到資料後立即查詢資料）；可擴充套件性（能夠隨著您的產品規模處理大量資料）；互動式查詢（同時支援批處理查詢和較小的互動式查詢，這些查詢允許資料科學家探索表和模式）；版本控制（在不中斷管道且不會丟失資料的情況下更改管道的能力）；監視（當資料停止進入時，管道應生成警報）；和測試（能夠不間斷地測試管道的能力）。也許最重要的是，最好不要干擾日常業務運營-例如如果您正在測試的新模型導致您的運營資料庫陷入癱瘓。建立和維護資料管道通常是資料工程師的責任（有關更多詳細資訊，本文對為初創企業構建資料管道進行了很好的概述），但是資料科學家至少應該熟悉該過程，其侷限性，以及訪問處理後的資料進行分析所需的工具。

接下來，您必須決定是要設定本地基礎結構還是使用雲服務。 對於一家初創公司而言，最重要的是在不擴充套件運營資源的情況下擴充套件資料收集。 如前所述，內部部署基礎架構需要大量的前期和維護成本，因此雲服務對於初創公司而言往往是更好的選擇。 雲服務允許擴充套件以適應需求並需要最少的維護工作，因此您的一小團隊人員可以專注於產品和分析，而不是基礎架構管理。

Examples of vendors that provide Hadoop-based solutions (Source: WikiCommons)

為了選擇雲服務提供商，您必須首先建立分析所需的資料，以及最適合這些資料型別的資料庫和分析基礎架構。 由於您的分析渠道中既有結構化資料又有非結構化資料，因此您可能要同時設定資料倉庫和資料湖。 資料科學家需要考慮的重要事情是儲存層是否支援構建模型所需的大資料工具，以及資料庫是否提供有效的資料庫內分析。 例如，某些ML庫（例如Spark的MLlib）不能有效地與資料庫一起用作資料的主要介面-必須先從資料庫中解除安裝資料，然後才能對其進行操作，這可能是非常耗時的， 當您必須定期重新訓練模型時，它會增長並可能成為瓶頸（從而導致另一種"回滾"情況）。

對於雲中的資料科學，大多數雲提供商都在努力開發機器學習功能，以使資料科學家能夠使用儲存在其自己平臺中的資料輕鬆構建和部署機器學習模型（亞馬遜擁有SageMaker，谷歌擁有BigQuery ML，微軟有Azure機器學習）。 但是工具集仍在開發中，並且常常不完整：例如，BigQuery ML當前僅支援線性迴歸，邏輯和多類邏輯迴歸，K-means聚類和TensorFlow模型匯入。 如果您決定使用這些工具，則必須徹底測試它們的功能，以確保它們能夠按照您的要求進行操作。

選擇雲提供商時要考慮的另一項主要事情是鎖定供應商。如果選擇專有的雲資料庫解決方案，則很可能將無法訪問本地環境中的軟體或資料，因此更換供應商將需要遷移到其他資料庫可能會很昂貴。解決此問題的一種方法是選擇支援開源技術的供應商（這裡是Netflix解釋為什麼他們使用開源軟體的原因）。使用開源技術的另一個優勢是，它們傾向於吸引更大的使用者群體，這意味著您可以更輕鬆地僱用具有經驗和技能的人員來在基礎架構中工作。解決該問題的另一種方法是選擇使用其他主要雲提供商作為儲存後端來提供雲資料庫解決方案的第三方供應商（例如Pivotal Greenplum和Snowflake），如果適合，您還可以將資料儲存在多個雲中。

最後，由於您希望公司發展，因此必須採取穩健的雲管理實踐來保護您的雲，並防止資料丟失和洩漏，例如管理資料訪問並保護介面和API。 您還希望實施資料治理最佳實踐，以保持資料質量並確保您的Data Lake不會變成資料沼澤。

如您所見，在企業資料科學專案中，除了調整機器學習模型中的超引數之外，還有更多其他功能！ 我們希望這個高層次的概述能使您學習更多有關資料管理的知識，並且也許可以從中獲得一些啟發，從而給資料工程師留下深刻的印象。

（本文翻譯自Phoebe Wong的文章Everything a Data Scientist Should Know About Data Management* 參考https://towardsdatascience.com/everything-a-data-scientist-should-know-about-data-management-6877788c6a42）