前言
如何才能成為一名真正的「全棧（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