作者 | Phoebe Wong
譯者 | 陸離
編輯 | Jane
前言
如何才能成為一名真正的“全棧（full-stack）”資料科學家？需要了解哪些知識？掌握哪些技能？
概括來講，一名全能型選手要把資料科學過程中從資料儲存到把預測模型投入正式生產的每一步都能 hold 住。
一般來說，大家在學習過程中更注重機器學習或深度學習技術的理論學習與應用，資料管理方面的知識往往是“事後諸葛亮”；資料科學專業的學生們對如何處理、清洗資料等建模技術關注較多，忽略瞭如何製作“資料香腸”。
但是在真實工程環境中，有近 80%的工作都在圍繞“如何從各種來源獲取原始資料”這一步驟，從而為後續搭建模型做準備；此外，企業級的專案通常涉及大量資料，本地計算機並不具備處理這些資料的能力。
因此整個建模過程通常會在雲上進行，大多應用和資料庫也會託管在其它地方的資料中心伺服器上，資料管理則成為資料工程團隊非常關心的事情。
NIST大資料分類 （來源：WikiCommons）
由於很多資料科學家對資料儲存和基礎設施瞭解甚少，影響了他們在工作中做出正確決策的能力。
而這篇文章就旨在提供一個線路圖，從資料庫型別、資料儲存和處理的位置和方式，到當前的商業選擇，給想成為一名資料科學家的開發者們分享必備的資料管理知識。
基於此文涉及面廣，系統知識全面，對初級資料科學家、資料科學專業的學生、想轉行進入資料科學領域的開發者們都很適合；對從業經驗豐富，已深耕此領域的開發者來說，內容偏基礎，不過大家可以基於此文進行更深入地研究，歡迎大家互動交流，分享你的觀點和意見。
非結構化資料和大資料工具的興起
IBM 305 RAMAC （來源：WikiCommons）
實際上，資料科學的本質就是資料儲存。在進入數字時代之前，資料儲存在我們的大腦中、陶片或紙上，這使得資料的收集和分析極其耗時。
1956年，IBM推出了第一臺帶有磁碟的商用計算機，305 RAMAC。整個單元需要30英尺x 50英尺的物理空間，重量超過一噸，租一個這樣的單元，每個月花費 3200 美元，可儲存大約5MB的資料。
在隨後60年的時間裡，DRAM每GB價格從1965年的26。4億美元大幅下降到2017年的4。9美元。資料儲存裝置不僅價格極其低廉，而且密度更大、體積更小。
在305 RAMAC的一個磁碟中，每平方英寸儲存100 位元的資料，對比之下，今天的一個普通磁碟，每平方英寸儲存資料可超過1萬億位元。
資料儲存的成本和規模的大幅降低正是現如今讓大資料分析成為可能的主要原因。憑藉超低的儲存成本，建設資料科學基礎設施，從海量資料中收集和提取有用的資訊，這也成為了企業盈利的途徑。
隨著不斷生產和傳輸使用者資料的物聯網（IoT）裝置的大量湧現，企業們正在收集越來越多的使用者行為資料，並創造大量的高容量、高速度和高多樣性的資訊資產（或稱為“3V大資料”）。
這些行為（如電子郵件、影片、音訊、聊天資訊、社交媒體帖子）大多產生了非結構化資料，這些資料佔當今企業資料總量的近80%，增長速度是在過去十年中結構化資料的兩倍。
圖中顯示了在2017年儲存了125 EB的企業資料，80%是非結構化資料 （來源：Credit Suisse）
海量資料的增長極大地改變了資料儲存和分析的方式，因為傳統的工具和方法不具備處理“3V大資料”的能力。隨著新技術的發展，有能力處理不斷增長的資料量和資料種類，並且速度更快，成本更低。
這些新的工具還對資料科學家的工作方式產生了深遠的影響，使他們能夠透過資料分析，以及開發前看起來不可能的應用程式來實現海量資料的變現。下面列舉的是我們認為每個資料科學家都應該知道的大資料管理領域的創新方法。
關係資料庫和NoSQL
關係資料庫管理系統（RDBMS）出現於20世紀70年代，它將資料儲存在具有行和列的表裡面，使用結構化查詢語言（SQL）進行查詢和維護資料庫。關係資料庫基本上就是多個表的集合，每個表中都有一個模式（schema），模式嚴格定義了所儲存資料的屬性和型別，以及標識用於訪問的特定行或列的鍵。
RDBMS曾經由Oracle和IBM所統治，但現在，出現了許多開源的資料庫系統，如MySQL、SQLite和PostgreSQL等等，也同樣很受歡迎。
上圖顯示了RDBMS的受歡迎度排名 （來源：DB-Engines）
由於一些特性非常受歡迎，關係資料庫在商業領域中找到了一席之地，而資料完整性是關係資料庫中最重要的特性之一。
RDBMS須滿足原子性、一致性、隔離性和永續性（ACID）的要求，它利用一些約束來確保所儲存資料是可靠的、準確的，這就使它們成為監測和儲存一些諸如帳號、訂單和付款等資料資訊的理想選擇。
但是，這些約束也帶來了高昂的代價。由於模式和資料型別的限制，RDBMS在儲存非結構化或半結構化資料方面的表現非常糟糕。死板的模式也使得RDBMS在建立、維護和升級等方面的成本變得更高。
建立RDBMS需要使用者預先擁有特定的用例，對模式的任何更改通常都是非常困難和耗時的。另外，傳統的RDBMS被設計用在一個單機上執行，這意味著它們在處理大量資料時的速度要慢得多。
在保證ACID特性的同時，水平擴充套件RDBMS（分庫分表）也是一項非常具有挑戰性的任務。所有的這些屬性使得傳統關係型資料庫管理系統無法處理現如今的大資料。
截止到2000年，一些網際網路公司開發了大量的非關係型（NoSQL）資料庫，因為已有的 RDBMS 可能無法長時間地支撐一個成功的網際網路公司（下圖是一個關於Facebook在資料量開始增長之後如何應對MySQL限制的例子）。
在當時沒有任何已有解決方案的情況下，這些網際網路公司創造了新的方法和工具來處理收集到的大量非結構化資料：谷歌釋出了GFS、MapReduce和BigTable；亞馬遜釋出了DynamoDB；雅虎釋出了Hadoop；Facebook釋出了Cassandra和Hive；LinkedIn釋出了Kafka。
其中一些公司開放了他們的原始碼，一些公司則釋出了他們詳細的研究設計論文，這也就促進了各種新資料庫與新技術的激增，而NoSQL資料庫成為了行業中的一個主要的參與者。
上圖顯示了自2000年以來各種資料庫系統激增的情況。來源：Korflatis et。 al （2016）
NoSQL資料庫與模式無關，它提供了儲存和操作大量非結構化和半結構化資料所需的靈活性。使用者不需要知道在建立資料庫的時候將儲存哪些型別的資料，系統可以適應資料型別和模式的變化。
NoSQL資料庫可以跨節點分發資料，它通常具有更高的水平伸縮性和分割槽容錯性。但是，這些效能優勢同時也還伴隨著成本的開銷。NoSQL資料庫不符合ACID特性，因而，資料一致性也無法得到保證。
相反，它們提供了“最終一致性”：當舊資料被覆蓋時，它們將返回暫時有些出入的結果。
例如，當人們同時搜尋同一個詞的時候，谷歌的搜尋引擎索引不能更新這個詞的相關資料，因此它在我們搜尋時不會返回給我們最新的資料結果，但它會返回最合適的結果。
雖然這個特性在絕對需要保證資料一致性的情況下（如金融交易）不太適合，但對於那些需要效率而不是精確度的任務的場景，它卻非常的適合。
現在，NoSQL分為幾個不同的類別，每個類別都有其特定的作用。
鍵值儲存，如Redis、DynamoDB和Cosmos DB，只用於儲存鍵值對，並提供檢索與已知鍵相關聯的值的基本功能。當速度因素很重要的時候，它們在簡單的資料庫模式下執行的效率最高。
寬列儲存，如Cassandra、Scylla和HBase，將資料儲存在列族或表中，並用來為大型分散式系統管理PB級的資料量。
文件儲存，如MongoDB和Couchbase，以XML或JSON格式儲存資料，文件名稱作為主鍵，文件內容作為值。文件可以包含許多不同的值型別，並且可以巢狀，使它們特別適用於管理分散式系統的半結構化資料。
圖形資料庫，如Neo4J和Amazon Neptune等將資料表示為相關聯節點或物件的網路，以便於資料的視覺化和圖形化分析。圖形資料庫對於分析異構資料點之間的關係特別的有用，例如防欺詐或Facebook的好友關係圖。
MongoDB是目前最流行的NoSQL資料庫，它為一些一直在使用傳統RDBMS方法處理非結構化資料的企業帶來了巨大的幫助。
這裡有兩個行業例子：MetLife花費了多年的時間，試圖在一個可以處理其所有保險產品的RDBMS上建立一個集中式的客戶資料庫，之後，一個Hackathon的人在數小時內就用MongoDB建立了一個數據庫，該資料庫在不到90天就投入了生產。
YouGov是一家每小時收集5GB資料的市場調查公司，它將所有的資料從RDBMS遷移到了MongoDB，儲存空間節省了70%。
資料倉庫、資料湖和資料沼澤
隨著資料來源的不斷增多，使用多個數據庫進行資料分析的工作變得效率低下、成本高昂。在2000年之後，出現了一種稱為資料倉庫（Data Warehouse）的解決方案，它能將企業所有資料庫中的資料集中起來。
資料倉庫透過建立一個來自不同資料來源（內部和外部）資料的儲存庫，支援從作業系統到分析和決策系統的資料流。
在大多數的情況下，資料倉庫是一個關係型資料庫，它儲存了為收集業務資訊而最佳化的已處理資料。
它收集了來自交易系統和業務應用系統的具有預定結構和模式的資料，這些資料通常用於生成經營報告和分析結果。
但是，由於進入資料倉庫的資料需要在儲存之前就進行處理，還存在著大量的非結構化資料，這可能需要耗費大量的時間和資源。
因此，企業開始維護資料湖（Data Lakes），它能以任何規模儲存企業的所有結構化和非結構化的資料。建立一個能儲存原始資料的資料湖，無需一開始就定義資料結構和模式。
資料湖允許使用者執行分析任務，而無需將資料遷移到單獨的分析系統上，從而使企業能夠從以前不能用於分析的新資料來源中獲得資訊，例如，透過使用日誌檔案、訪問資料、社交媒體和物聯網裝置中的資料來建立機器學習模型。
透過隨時都可以分析企業所有的資料，資料科學家們可以回答更多的新業務問題，或者用新資料解決舊問題。
上圖是資料倉庫與資料湖的對比（來源：AWS）
資料湖的體系結構面臨的一個常見挑戰是，如果沒有合適的資料質量和資料治理框架，當數以TB計的結構化和非結構化的資料流入資料湖時，往往很難對其內容進行分類和排序。
資料湖就變成了資料沼澤（Data Swamps），因為它們變得太亂了，無法使用。許多組織現在要求進行更多的資料治理和元資料管理。
分散式和平行計算：
Hadoop、 Spark和MPP
雖然企業對資料儲存和計算的需求在過去幾十年裡突飛猛進地增長，但傳統硬體的發展還遠遠跟不上要求。
企業資料不再適合標準儲存，處理大多數的大資料分析任務所需要的計算能力可能需要數週、數月，或者根本不可能在普通計算機上完成。
為了解決這一問題，許多新技術已經發展到多臺計算機協同工作，將資料庫分發給數千臺商品伺服器來進行處理。
當多個計算機連線起來形成一個網路並共同完成同一任務的時候，這些計算機就形成了一個叢集。
一個叢集可以看作是一臺計算能力強大的計算機，它可以使用普通的硬體，非常低廉的成本，但可以顯著地提高效能、可用性和可擴充套件性。
Apache Hadoop是分散式資料基礎設施的一個例子，它利用叢集來儲存和處理海量的資料，並支援資料湖體系結構。
資料庫技術的發展過程（來源：Business Analytic 3。0）
當你想到Hadoop的時候，就想想“資料分發”。Hadoop由三個主要的部分組成：Hadoop分散式檔案系統（HDFS），它是一種跨多個（分散式）物理硬碟來儲存和監測資料的方式；
MapReduce，是一種跨分散式處理器處理資料的框架；還有另一個是資源協商者（YARN），這是一個叢集管理框架，它在分散式系統上協調資源，如CPU的大小、記憶體的多少和網路頻寬分配等等。
Hadoop的處理層是一個特別值得注意的創新：MapReduce使用一種兩步計算的方式，用於以一個可靠的、容錯的方式處理分佈在大型商用叢集中的大資料集。
第一步是將資料分發到多臺計算機（Map）上，每臺計算機對分發的資料片執行平行計算。第二步是以成對的方式合併這些計算結果（Reduce）。
谷歌在2004年發表了一篇關於MapReduce的論文，2006年的時候，在開源Apache環境中實現了MapReduce的一個Yahoo程式設計師看到了這篇論文，得以為每個企業提供了使用商業硬體來儲存前所未有的資料量的能力。
儘管這個想法有很多開源的實現，但Google的MapReduce卻一直保持著優勢，有點像Jacuzzi或Kleenex。
Hadoop是為迭代計算而設計的，它在一次操作中從磁碟掃描大量的資料，將處理任務分發到多個節點，並將結果返回並存儲到磁碟上。
使用Hadoop和HBase，查詢ZB級的索引資料可以在10-12秒內完成，而在傳統資料倉庫環境中執行則需要4個小時。
Hadoop通常用於生成複雜的分析模型或海量資料儲存的應用程式，例如回顧性和預測性分析、機器學習和模式匹配、客戶細分和客戶流失分析，以及活動歸檔等等。
但是，MapReduce用於處理批次的資料，因此它不適合處理實時資料。Apache Spark是在2012年釋出的，可以用來填補這一空白。Spark是一種並行資料處理工具，它透過在記憶體中處理資料來提高執行速度和效率。
它與MapReduce的原理相同，但透過在記憶體中完成大部分的計算工作，並且僅在記憶體已滿或計算完成的時候才會寫入磁碟，因此，它的執行速度會快得多。
這種記憶體計算允許Spark“在記憶體中執行程式比在Hadoop MapReduce中快100倍，比在磁碟上快10倍”。
然而，當資料集太大而導致記憶體不足（通常是數百GB以上）的時候，Hadoop MapReduce可能比Spark表現的更好。
Spark還擁有一套強大的資料分析庫，涵蓋了廣泛的功能：用於SQL的Spark SQL和結構化資料，用於機器學習的MLib，用於流式計算的Spark Streaming和用於圖形分析的GraphX。
由於Spark的重點是計算，所以它沒有自帶的儲存系統，而是執行在各種儲存系統之上，如 Amazon S3、Azure Storage和Hadoop’s HDFS。
在MPP系統中，所有的節點都是互連的，資料可以透過網路進行交換（來源：IBM）
Hadoop和Spark並不是唯一利用叢集處理海量資料的技術。另一個流行的分散式查詢處理方法稱為大規模並行處理（Massively Parallel Processing ，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資料庫後，他們每日的執行資料分析時間減少了8個小時。
雲服務
另一個徹底改變的企業大資料分析能力的創新是雲服務的興起。
在雲服務出現之前，企業不得不從軟體和硬體的供應商那裡購買本地資料儲存軟體、裝置和資料分析解決方案，這通常要支付永久性的軟體許可費用以及每年的硬體維護費和技術服務費。
除此之外，還有電力、空調、網路安全、容災保護、IT技術人員等方面的成本，用於建設和維護內部基礎設施。
即使在技術上有能力儲存和處理大資料的時候，大多數企業也會發現海量資料的儲存和處理的成本太高了。
另外，擴充套件內部基礎設施還需要一個設計和採購的過程，這需要很長的時間來實施，並需要大量的資金預算。許多潛在有價值的資料收集和分析可能就因此被放棄了。
雲服務的提供商：例如基礎設施即服務（IaaS）和儲存即服務（SaaS）（來源：IMELGRAT。ME）
當雲服務在2000年末被引入的時候，內部自建模式開始迅速地失去了市場份額——在過去十年裡，全球雲服務市場份額每年增長15%。
雲服務平臺提供對各種服務（從虛擬計算到儲存基礎設施再到資料庫）的定製，這些服務線上透過用多少付多少的方式提供，為使用者靈活快速地訪問和低成本的資料儲存，以及為虛擬計算資源提供了便利條件。
雲服務提供商負責其所有硬體和軟體的採購和維護，他們通常擁有龐大的伺服器網路和技術支援團隊來提供可靠的服務。
許多企業在使用之後發現，他們可以透過雲服務顯著降低運營成本和提高運營效率，並且能夠利用現成的雲資源和內建的可伸縮性更快地開發和生產產品。
不僅沒有了自建基礎設施的巨大成本和週期，雲服務還避免了搭建大資料平臺的麻煩，並有效地使中小企業的大資料分析工作更加的靈活。
這裡有幾種雲服務模型，其中公有云是最常見的。
在公有云中，所有硬體、軟體和其它的支撐基礎設施都由雲服務提供商自行搭建和管理。使用者與其他的“雲租戶”共享雲基礎設施，並可以透過Web瀏覽器訪問他們的服務。
而具有特殊安全需求的組織通常會使用私有云，如政府機構和金融機構等。在私有云中，服務和基礎設施僅提供給一個組織使用，並在私有網路上進行維護。私有云可以是本地的，也可以由第三方服務提供商託管。
混合雲將私有云與公有云結合起來，使組織能夠同時獲得兩者的優勢。在混合雲中，資料和應用程式可以在私有云和公有云之間進行傳輸和訪問以獲得更大的靈活性：例如，公有云可用於高訪問量、低安全性的資料，而私有云可用於敏感的、業務關鍵型的資料，如財務報告、金融資料等等。
多雲模型則涉及到多個雲平臺，每個平臺都提供特定的應用服務。多雲可以是公有云、私有云和混合雲的組合，以實現組織的目標為目的。組織通常選擇多雲是為了滿足一些特定的業務，以及位置和時間上的需求，並避免供應商的侷限性。
案例研究：
構建端到端的資料科學基礎設施
設計一個可行的資料產品，不僅僅是用Scikit-Learn（Scikit-learn是專門面向機器學習的Python開源框架）構建一個機器學習模型，還要對其進行反覆最佳化，並載入到伺服器上。
不同資料環境下的機器學習包（來源：Kosyakov （2016））
它需要了解企業生態系統的所有部分是如何協同工作的，從資料流入的位置和方式、資料處理和轉換的環境、企業視覺化和展現資料的慣例，以及如何將模型輸出轉換為某些其它的企業應用的輸入。
它的主要目標包括建立一個易於維護的過程，在這個過程中，模型可以被迭代，效能是可複製的，模型的輸出可以視覺化地展現出來並能讓老闆們輕鬆地理解，以便他們能做出更加明智的業務決策。
實現這些目標需要選擇正確的工具，並瞭解同行們都正在做什麼以及做出了什麼成果。接下來，我們用一個場景來加以說明。
假設你剛剛被一家度假推薦App的初創公司聘為首席資料科學家，該公司預計將收集數百GB的關於使用者每天的資料，包括結構化的（客戶資料、溫度、價格和交易記錄）和非結構化的（客戶的帖子、評論和圖片檔案）。
你的預測模型需要每週都重新訓練新的資料，並根據需要即時提出合理化建議。想讓自己的這款 APP 應用能大受歡迎，資料的收集、儲存和分析能力必須是可擴充套件的。
你將如何設計資料處理過程和模型產品化呢？你需要什麼樣的工具來完成工作呢？既然這是一家初創公司，而你是資料科學家中的首席，或許也是唯一的資料科學家，那麼就只能由你來做這些決定。
首先，你必須瞭解如何設定資料管道，管道接收來自資料來源的原始資料，並進行資料處理，然後將處理過的資料寫入資料庫。
理想化的資料管道具有較低的事件延遲（在收集到資料後能夠立即進行資料查詢）、可伸縮性（能夠在產品擴充套件時處理海量資料）、互動式查詢功能（支援批次查詢和較小規模的互動式查詢，使資料科學家能夠查詢表和模式）、版本控制功能（在不關閉管道和丟失資料的情況下對管道進行修改的能力）；
監控功能（資料一旦停止輸入管道應促發警報）、可測試性（在不中斷的情況下測試管道的能力）。
或許最重要的是它最好不要干擾日常的業務操作，例如，如果你正在測試新的模型，進而導致資料庫操作停止，則操作會回滾。
建立和維護資料管道通常是資料工程師的職責（本文對初創公司建立資料管道有一個更詳細的概述），但是資料科學家至少也應該熟悉這個過程和它的侷限性，以及對處理過的資料進行分析的工具。
接下來，你必須決定企業是要自建基礎設施還是使用雲服務。對於初創公司來說，首要任務是在不增加有限資源的情況下擴大資料收集量。
如前面所說，自建基礎設施需要巨大的前期投入和維護成本，因此雲服務往往是初創公司更好的選擇。
雲服務允許自由擴充套件來滿足需求，並且只需要很少的維護工作，這樣你的小團隊就可以專注於產品設計和資料分析工作了，而不是對基礎設施的管理。
上圖顯示了一些提供基於Hadoop解決方案的供應商 （來源：WikiCommons）
為了選擇一個雲服務商，你必須先確定要分析的資料，然後再確定最適合這些資料型別的資料庫和基礎設施。
由於在資料分析的管道當中既有結構化資料，也有非結構化資料，所以你可能希望同時建立資料倉庫和資料湖。
資料科學家需要考慮的一個重要問題是，儲存層是否支援構建模型所需要的大資料工具，以及資料庫是否提供了有效的庫內分析功能。
例如，Spark的MLlib等一些機器學習庫不能有效地將資料庫作為主要介面使用，必須先從資料庫中把資料下載下來，然後才能對其進行操作，這可能會隨著資料量的增長而越來越耗時，而當你不得不定期重新訓練模型的時候，這就將會成為效能的瓶頸。
對於雲端的資料科學，大多數雲服務提供商正在努力開發他們的本地機器學習功能，這就允許資料科學家可以使用儲存在自己平臺上的資料來輕鬆構建和部署機器學習模型（亞馬遜有SageMaker，谷歌有BigQuery ML，微軟有 Azure Machine Learning）。
但是這些工具集目前仍然處於開發完善階段，而且功能上時常不太完整，例如，BigQuery ML目前只支援線性迴歸、二元邏輯迴歸和多類邏輯迴歸、K-means聚類和TensorFlow模型匯入。
如果決定使用這些工具，你必須完整地測試一下它們的功能，以確保能完成你的任務。
選擇雲服務提供商時要考慮的另一個重要問題是產品供應商的選擇。如果選擇專有的雲資料庫解決方案，則很可能無法訪問本地環境中的應用或資料，而更換供應商則需要遷移到其它的資料庫系統，這很可能會產生高昂的成本。
解決這個問題的一個方法是選擇支援開源技術的供應商（這裡是Netflix解釋為什麼使用開源軟體的理由）。
使用開源技術的另一個優勢是，它們往往會吸引更多的使用者，這意味著可以更容易地找到熟悉你的基礎架構並具有相關工作經驗和技能的技術人員。
還有另外一個方法，就是選擇一個第三方供應商（如Pivotal Greenplum和Snowflake），他們使用一些主要的雲服務提供商作為資料儲存端來提供雲資料庫解決方案，這將允許你把資料同時儲存在多個雲平臺上，如果這適合你的初創公司的需求。
最後，由於你是這家初創公司的首席資料科學家，並且希望公司能夠發展壯大，那麼你必須建立一個強大的雲服務管理機制來保護你的雲安全，防止資料的丟失和洩漏，比如管理資料訪問許可權、保護各種資料介面和API。當然你還希望實現最佳的資料治理效果，以維護資料的質量，並確保資料湖不會變成資料沼澤。
正如我們所看到的那樣，在企業資料科學專案中調整的超引數的數量要比在機器學習模型中的多得多。我們希望這個較高水平的概述能讓你有興趣瞭解更多關於資料管理領域方面的知識，能學到一些東西吸引更多的開發者們成為資料工程師。
https：//towardsdatascience。com/everything-a-data-scientist-should-know-about-data-management-6877788c6a42
【END】
熱 文推 薦
你點的每個“在看”，我都認真當成了喜歡