英文原文：https://luminousmen.com/post/data-management-skills我的朋友問了我一個有意思的問題：有哪些技能值得數據管理專家學習，以及如何建立發展路線圖？事實上，這個問題也讓我陷入深思，因為我的腦海中還沒有一個清晰的框架。本文僅僅是我對於這個問題的一些想法，並且很大部分是我對數據管理的當前狀態與未來的推測。
閱讀本文的前置知識
首先，和其他任何領域一樣，有一些基礎知識是任何軟體工程師都應該了解的。
簡而言之，我假設來到大數據領域的人已經知道某種程式語言，並且對例如算法、SQL、版本控制（VCS）、系統生命發展周期（SDLC）、網絡、Linux 和 CI/CD 等基礎知識有所了解。無論如何，這些軟體工程的通用實踐都是無處不在的。這是我認為在任何軟體工程領域都需要了解的基礎。如果你不了解它們，那麼請你最好先學習它們。也許你另有高見，也可以與我討論。
大數據基礎
我認為這是另一個層面的基礎知識。舉例來說，這裡我可以強調程式語言的重要性。因為在大數據的世界裡，有一些語言是佔據主導地位的。如果不了解這些語言，要完成某些事情非常難（甚至可以說是不可能的）。當然，這指的是例如 Java、Scala 這些 JVM 語言，也許 Kotlin 很快也會加入其中，當然還有 Python——無論做什麼事情，Python 都是第二佳的語言，也是數據科學的程式語言事實標準。
除了程式語言以外，還有一些我認為應該學習的大數據的術語和基礎概念，比如水平拓展、分布式系統、異步通信、CAP 定理、最終一致性、共識問題、可用性、持久性、可靠性、彈性、容錯能力、災難恢復等。你不需要對這些術語有非常深刻的理解，但如果你希望在這個領域有所成就的話，你至少還是先谷歌一下。
現在，讓我們來談談這個領域是如何發展的，或者更準確的說，它所面臨的挑戰。
數據上的挑戰
在某種形式上，這個層面的知識是指當處理數據時你需要解決的問題。你可以這樣想：有大數據的地方，就有大的問題和挑戰。
當你在進行某個層面上的數據處理工作時，你將需要一些特定的技能。下面我們就來深入了解它們。
大部分的大數據工作流程包含了如下幾層：
數據層（Data Layer）
隨著存儲信息數量的增長，數據存儲一直都是首要問題。這是任何與數據打交道的系統的基礎——有許多技術可以存儲海量的原始數據，這些原始數據可以來自傳統的數據源，比如 OLTP 資料庫，也可以來自更新的、更非結構化的數據源，比如日誌文件、傳感器、網站分析數據、文檔檔案數據和媒體檔案數據。如你所見，這些領域差異巨大，有著各自的領域特點，而我們需要從所有這些領域收集數據。
第一件重要的事情就是用於存儲數據的格式，如何將其存儲結構最優化以及如何最優地存儲這些數據。當然，在此時你會想到大數據領域的常見格式，例如 Parquet、CSV、Avro。另外，也可以考慮使用壓縮工具，例如 Bzip2、Snappy、Lzo 等等。此外，優化工作基本上要麼涉及適當的分區，要麼是一些存儲特定的東西。
支撐數據層的主要技術，當然是具有 HDFS 的 Hadoop——一個非常經典的大規模文件系統。因為它的持久性和在傳統設備上無限的擴容能力，它已經非常流行了。然而，最近越來越多的數據被存儲在雲端，或者至少是混合雲——企業正在從過時的本地存儲系統遷移到類似 AWS S3、GCP GCS 或者是 Azure Blob 這樣的託管服務。
對於 SQL 的解決方案，最流行的應用是 Hive 或者 Presto，或者是更有趣的數據倉庫解決方案。我認為它們位於基礎的 SQL 引擎之上。我們稍後會詳細討論。
對於 NoSQL 的解決方案，它要麼是支持 ACID 的 Cassandra、文檔數據模型且數據大小可管理的 MongoDB 或者是用於可伸縮解決方案的 AWS DynamoDB（如果你在 AWS Cloud 上）。
對於圖資料庫，我只能想起 Neo4j。它非常適用於存儲圖數據或者相關信息，比如一群人和他們之間的關係。對這類信息在傳統的 SQL 資料庫建模會是非常困難且低效的。
數據湖（Data Lake）
數據湖是一個公司的集中存儲庫，它可以存儲所有關於業務的結構化和非結構化的數據。在數據湖中，我們按數據的原樣來存儲數據，而不進行結構化處理，然後在此之上進行不同類型的分析。
當今的數位化轉型實際上是將數據驅動的方案應用於業務的各個層面，從而創造競爭優勢。這也是為什麼越來越多的公司希望構建自己的數據湖解決方案的原因。這種趨勢仍在繼續，這些技能還是被市場需要的。
在數據湖領域，最流行的的工具仍然是用於本地化方案的 HDFS，以及各類來自 AWS GCP 和 Azure 的雲數據存儲方案。除此之外，還有一些數據平臺正在嘗試填補一些細分市場並且創建集成解決方案，比如 Cloudera、Apache Hudi、Delta Lake。
數據倉庫（Data Warehouse）
數據倉庫可以被描述成用於存儲已經處理好的業務數據的傳統資料庫，但它針對聚合請求作出了優化。無論如何，它還是和數據湖一樣，都是構建分析和數據驅動決策的基礎。它與數據湖之間並不排斥，而是相互補充。
數據集市是旨在滿足某種特定的業務功能要求而設計的數據倉庫解決方案的最後一層。數據集市具有從不同的數據源提取數據的能力，這使它成為數據倉庫領域的一種增長趨勢。
流行的數據倉庫解決方案包括 Teradata、Snowflake、BigQuery 和 AWS Redshift。
數據總線（Data Hub)
現在我們有了數據倉庫，來以數據的最終結論的形式對信息進行排序和呈現（其餘的信息被丟棄了）；也有了數據湖——「存儲了所有的內容，因為你永遠不知道什麼時候會用到它們」。而數據總線專注於既不屬於第一類也不屬於第二類的數據。
數據總線的架構允許你把數據留在原處，提供了集中的處理能力，但不提供存儲能力。現在，數據在它所在的地方被搜索和訪問。但是，因為需要對數據總線進行規劃和管理，企業必須投入大量的時間和精力來決定數據的含義、數據從哪裡來以及它在被放在數據總線之前必須完成哪些轉換。
數據總線是存儲架構的另一種理念。我敢打賭，它在未來一定會獲得關注——所有它所需要的支持組件現在都已經可以獲得了。
數據提取（Data Ingestion）
為了創建數據存儲，你需要把數據從不同的數據源接入數據層，不管是數據湖、數據倉庫還是只是 HDFS。數據源可以是像 Salesforce 這樣的客戶關係管理（CRM）公司，也可以是像 SAP 這樣的企業資源計劃系統，還可以是像 Postgres 這樣的關係型資料庫，或者是任何的日誌文件、文檔、社交網絡圖等等。並且數據可以通過批處理任務上傳或者是通過實時流上傳。
有很多用於數據提取的工具，其中一個非常常見的工具是 Sqoop。它提供了一個基於 Java 的可擴展框架，可以用於編寫把數據導入 Hadoop 的驅動。Sqoop 運行在 Hadoop 的 MapReduce 框架上，也可以用於把數據從 Hadoop 導入到關係型資料庫中。
另一個非常常見的工具是 Flume。它適用於數據流的輸入比數據流的使用更快的場景。一般來說，Flume 用於把數據流導入 HDFS 或者是 Kafka，此時它承擔是是 Kafka 的 Producer 的角色。多個 Flume agent 可以被用於從多個數據源收集數據到 Flume collector。
另一個受歡迎的工具是 Nifi。Nifi 處理器是面向文件的，沒有模式（schema）。這意味著一些數據可以被表示成 FlowFile 的形式（它可以是位於磁碟上的實際文件或者是其他位置上獲得的數據塊）。每個處理器負責理解數據的內容，以對數據進行處理。所以，如果一個處理器理解格式 A，另一個處理器只能理解格式 B，你可能需要在兩個處理器之間轉換數據格式。
另外，還有一個消息總線領域中可以被稱作標準之一的 Kafka。它是一個開源的流消息總線，可以從你的數據源創建提要，對數據建立分區並且以流的形式傳送給消費者。Apache Kafka 是一個能在大規模生產環境中使用的，成熟且功能強大的解決方案。
數據處理（Data Precessing）
感謝上述數據提取的管道，現在數據已經傳送到了數據層。現在，你需要能處理海量數據的技術，以便於分析和處理這些數據。數據分析師和數據工程師希望能夠對大數據進行查詢，這需要強大的計算能力。數據處理層必須將數據優化以促進更有效的分析，並提供計算引擎來執行查詢。
這裡最流行的模式是 ETL（Extract-Transform-Load），它是一種非常流行的數據處理範式。從本質上來說，我們把數據從數據源中提取、清理、然後轉換成結構化的信息，並將其上傳到目標的資料庫、數據倉庫或者是數據湖。
成功實現這一模式的工具之一便是 Apache Spark。我認為它是大數據工具包中最重要的工具之一，任何有海量數據處理經驗的人應該都已經掌握它了。它在 Hadoop，Mesos，Kubernetes 或其他平臺上對結構化或非結構化數據執行並行查詢。 Spark 還提供 SQL 接口，並具有良好的流處理和內置的機器學習功能。
ELT（Extract Load Transform）
現在有一種從 ETL 遷移到 ELT 的趨勢，在 ELT 當中，轉換（Transformation）的步驟發生在數據倉庫裡，而不是數據倉庫之上。在我看來，這種趨勢來自於對數據的了解不足。因為傳統上，為了使數據更穩定和對用戶而言更可訪問，對於什麼數據需要進入數據倉庫有許多的計劃和嚴格限制。然後這也帶來了輸入數據格式的更改和輸出結構格式的更改等等。
像 Snowflake、AWS Redshift 這樣的工具允許在載入的數據（甚至可以是非結構化的數據）之上創建一個抽象層，來為數據提供一個簡單的 SQL API，而無需考慮那個字母 T——轉換。
從批處理到實時處理
現在一個很清晰的趨勢是，實時數據收集系統正在迅速地取代批處理的 ETL，這使得流數據成為了現實。越來越多的提取層和處理層正在轉向實時，這又反過來促使我們學習新的概念、使用可以同時進行批處理和實時處理的多功能工具，例如 Spark 和 Flink。
內存內處理（In-Memory）
由於內存變得越來越便宜，並且企業依賴於實時處理的結果，因此內存計算使得他們能夠擁有更豐富和更具有交互性的數據儀錶板，這些儀錶板能提供最新的數據並且隨時都可以幾乎實時地提供報告。通過在內存（而非硬碟）中分析數據，他們可以即時查看數據，並且對數據快速做出決策。
在大多數情況下，所有已知的解決方案都已經使用或者嘗試使用這種方法。這裡還是同樣地，Spark 是最容易理解的例子，同時還有數據網格的實現，例如 Apache Ignite。
Apache Arrow 結合了列式數據格式和內存計算的優點。它提供了這些現代技術的性能優勢的同時也提供了複雜數據和動態模式的靈活性。實際上，我不知道還有沒有其他類似的格式。
管理上的挑戰
這是另一個知識領域，它基本上位於一個稍微有所不同的平面，但與數據直接相關。管理上的挑戰涉及隱私、安全、治理和數據/元數據管理。
搜索與信息獲取
信息檢索系統是一個算法網絡，用於根據用戶需要來搜索相關數據或者文檔。
為了對海量數據進行有效的搜索，通常建議不要執行簡單的掃描——然後就出現了各種工具和解決方案。我認為其中最常用的一個工具是 ElasticSearch。它被用於網際網路搜索、日誌分析和大數據分析。ElasticSearch 之所以受歡迎，是因為它易於安裝、無需其他軟體便可擴展至上百個節點、並由於其內置的 REST API 而易於使用。
另外，其他出名的工具包括 Solr、Sphinx 和 Lucene。
數據治理（Data Govenance）
這可能是大數據領域其中一個非常重要、但仍然被低估的領域，並且在我看來，還沒有非常好的解決方案。數據治理的目的是建立方法、職責和流程以標準化、集成、保護和存儲數據。如果沒有有效的數據治理，企業中不同系統的數據的不一致性將無法消除。這會使數據集成變得更複雜，並導致數據集成問題，從而影響到業務智能、企業報告和數據分析應用的準確性。
我顯然不是這個領域的專家，但我所見過的這個領域的相關工具包括 Informatica、Teradata、Semarchy。
安全
不斷增加的數據量對防止入侵、洩漏和網絡工具的保護措施造成了額外的挑戰，因為數據保護的水平與數據、供應商和人員的增長不同步。全面的、端到端的數據保護措施不僅僅包括在整個生命周期（無論是在靜止狀態還是在傳輸狀態）對數據進行加密，還需要從項目的一開始就對其進行保護。如你所見，這可能影響到我們在本文中提到的所有領域和方面。並且，和信息安全的所有內容一樣，這類對策很難正確地實施。
諸如 GDPR、CCPA、LGPD 之類的隱私法規的出現對違規行為制定了嚴重的懲罰措施。企業必須考慮數據的機密性，並且在這些領域的專家也變得越來越重要。
在這個領域中，值得關注的工具包括：Apache Kerberos, Apache Ranger, Apache Accumulo.
數據目錄（Data Catalog）
通常來說，在一個公司裡，我們有大量不同形式、不同存儲方式以及不同格式的數據，並且對數據有不同級別的訪問權限。為了找到你需要的數據，你要麼需要知道在哪裡可以找到它，要麼需要知道在哪裡開始查找（如果有這樣的一個地方）。這就是所謂的數據目錄（data directory 或 data catalog）的作用。
企業數據源的管理是一個必不可少的過程，它是基於企業內各個局限的群體所知道的信息的。但是，要收集所有和存儲在企業中的數據所相關的元數據並管理它並不容易，因為人員會離開企業、數據會被刪除或添加。因此，建立數據目錄是一項非常重要但複雜的任務。
在這個領域中，非常出名的工具有：Apache Atlas 和來自雲服務商的其他解決方案。
分析上的挑戰
數據分析與業務智能是一種用於制定數據驅動的決策的一種方法，它提供了有助於業務發展的信息。利用這個層面的技術，你可以啟動查詢來回答某個業務相關的問題，對數據進行切片與切塊，構建數據儀錶板並創建清晰的可視化結果。
有了更多的數據，你可以做出更準確的預測和更可靠的方案，並且以此建立新的預測，在機器學習的階梯上不斷高攀。
機器學習
機器學習是一種特殊的數據分析方法，它可以讓你創建能夠分析海量複雜數據的模型，並做出預測和決策，而不需要為此進行詳盡的編程工作。越來越多的企業使用機器學習的方法來完成它們的日常運營分析和正常的業務運營。
在過去，機器學習在一定程度上受到以下方面的限制：在數據工程師團隊將方案部署到生產環節之前，數據科學家無法對解決方案進行評估和測試。實際上，大多數組織都有一個傳統的業務智能/分析團隊，然後還有一個單獨的數據科學團隊和數據工程師團隊。現在，這些技能已經開始出現重疊，並且隨著大數據慢慢轉向分析和基於大數據建立知識，這些團隊將更加深入地合作。因為如果沒有機器學習，大數據就太「大」了。因此，我認為至少需要了解機器學習的基本概念。
當然，還應該特別注意機器學習所依賴的知識，例如統計學、機器學習的優化方法、偏差/方差、需要理解的不同指標，等等。在應用機器學習時，你基本上只需要了解基本的機制，而具體的公式是不重要的。但是，那些不理解語言背後的模型的人，通常來說會犯非常愚蠢的錯誤。
關於機器學習還有很多要說的，但我把這些話題留到下次。機器學習中還分了許多領域——自然語言處理、計算機視覺、推薦系統、知識表示等等。但是，通常當你開始理解了某一方面，你其實已經知道有哪些內容你是不理解的。因此，你可以深入地學習。
如果你希望成為一名機器學習工程師（算法工程師），先確保你了解 Python。它是一個機器學習領域的通用語。然後，各種不同的用於處理數據的框架也值得學習，例如 Numpy、Pandas、Dask 和已經提到的 Apache Spark。當然，還有最受歡迎的機器學習庫：Scikit-Leaen 和 XGBoost。
我認為每個人應該都明白機器學習中真正重要的方向或多或少都與深度學習有關。當然，經典算法也不會消失在我們的視線中，因為在大多數情況下，它們已經足以構建一個好的模型。但當然，未來是建立在神經網絡之上的。深度學習的魔力在於，隨著數據的增加，它會變得更好。另外，其他值得了解的術語包括轉移學習、1cycle 策略、CUDA 和 GPU 優化等。
深度學習最流行的庫是帶有 fast.ai 的 Pytorch、帶有 Keras 的 TensorFlow（我認為它在不遠的將來應該會被人們棄用，但還是在此提及一下。）
分布式機器學習
另一個值得一提的技術是分布式機器學習。正如我所說，大數據正在慢慢走向基於海量數據的更為複雜的數據分析。存儲在中央存儲庫的大型數據集需要巨大的處理和運算能力，所以分布式機器學習是正確的方向。儘管它還存在很多問題（在以後的文章中會繼續討論）。
我個人對這種方法很有興趣，但它除了大型企業以外，和其他任何人都沒有關係。模型精度對大公司來說至關重要，而這只能從有著數百萬個參數和海量數據的大型模型中獲取。對於其他人，正如我所說，基於數據子集和預聚合數據的經典算法就已經對實際應用有非常好的效果了。
我可以列舉幾個在這個方向有用的工具：Spark Mllib、H2O、Horovod、Mxnet、DL4j，也還還有 Apache Ignite。
實時分析
儘管大公司通常看重實時的數據管理，但並不是所有公司都選擇實時的大數據分析。理由可能各異：缺少實操經驗或者資金不足、擔心其可能導致的相關問題或者是一般意義上的管理惰性。然而，那些實施實時數據分析的公司將獲得很大的競爭優勢。
這方面的工具包括 Apache Spark Streaming、Apache Ignite Streaming、AWS Kinesis。
數據科學的自動化
為以某種方式自動化數據預處理、特徵工程、模型選擇和配置以及結果評估工作，人們發明了自動機器學習（AutoML）。AutoML 可以自動化這些任務，並能夠對在哪個方面可以繼續深入研究給出理解。
當然，這聽起來很棒，但是它效果如何？這個問題的答案取決於你如何使用它。這個問題的重點在於了解人類所擅長的方面的和機器所擅長的方面。人們善於將現有數據和真實事件相結合——他們了解業務領域、了解特定數據的含義。機器擅長統計信息、存儲和更新狀態並執行重複過程。通過自動化機器學習框架，類似探索性數據分析、數據預處理、超參數調整、模型選擇和把模型放入生產環境這樣的任務可以在某種程度上實現自動化。但是好的特徵工程和提煉可實施的見解可以由了解業務需求的人類數據科學家來完成。通過分離這些活動，我們現在就可以很簡單地從 AutoML 中受益。而且我認為，在未來 AutoML 將會取代大部分數據科學家的工作。
而且，我認為值得注意的是，這個行業正在經歷機器學習平臺解決方案的強勁發展（例如 Amazon Sagemaker、Microsoft Azure ML、Google Cloud ML 等等）。而隨著機器學習的使用不斷增長，許多企業正轉向現成的機器學習平臺來加快產品上市時間，減少運維成本和提高成功率（包括機器學習模型的部署量和調試量）。
可視化
我們的文化是視覺化的，並且可視化正在越來越成為了解每天生成的大數據的關鍵工具。數據可視化通過一種簡單而易於理解的方式來指導數據、突出趨勢和偏差，以此來講述故事。好的可視化可以告訴我們事實、消除數據中的噪音、並突出顯示有用的信息和業務前景。
在我看來，這個方向最受歡迎的工具是 Tableau、Looker 以及所有上述提及的技術棧，這些技術棧在某種程度上對於建立數據倉庫和進行數據管理的必要的。
Tableau 是一個功能十分強大的表格化業務智能與數據可視化工具，它連接了數據，使你能夠執行詳細的、全面的數據分析，並且繪製圖表和儀錶板。
Looker 是一個基於雲的業務智能平臺，在你配置好用於描述你的數據的可視化設置後，它允許你使用 SQL 定義的指標來查詢和分析大量數據。
運維上的挑戰
為了解決上文所述的所有問題，你需要有正確架構基礎設施，並且為該基礎設施配套合理的管理、監控、和配置環境。而這還不是我在本節中要介紹的所有內容——還包括工作流的編排以及在數據管理中的各個方面開發運維（DevOps）實踐。
Kubernetes
微服務的建設問題很久以前就得到解決了。所有嚴肅的解決方案都是構建在微服務架構上的。然後 Docker 容器、k8s、Helm、Terraform、Vault、Consul 和所有相關的東西都出現了。這一切都在不經意間成為了標準。
日誌管理（Log Management）
日誌管理是處理日誌事件的過程，這些日誌由不同的軟體應用和運行這些應用的基礎架構產生。它可以包括日誌的搜集、分析、存儲和搜索，其最終的目的是使用數據來進行故障排除，並獲取業務、應用和基礎架構的信息。
在這個方面，其中一個最重要的工具是 ELK。它包含以下幾個部分：ElasticSearch（文本搜索工具）、Logstash 和 Beat（數據傳送工具）、Kibana（數據可視化工具）。它們一起提供了用於實時數據分析的一個完整的工具。雖然它們可以被設計成一起使用，但它們每個都是一個單獨的項目。ELK 提供了用於在線分析的功能，例如報告創建、警報、日誌搜索等等。這使得它不僅僅成為了 DevOps 的通用工具，更是上述提及的所有領域的通用工具。
另一個工具是 Splunk，它是一個機器數據工具，為用戶、管理員、開發人員提供了即時接收和分析所有由應用程式、基礎架構中的網絡設備和其他任何機器所創建的數據的能力。Splunk 可以通過圖表、警報、報告等提供實時信息，從而接收機器數據，並把它轉換成實時的分析。
工作流編排（Pipeline Orchetration）
工作流編排是容錯的工作流程的自動化管理。大多數大型的數據解決方案由封裝在工作流程中的重複的數據處理操作組成。工作流編排工具幫助自動化這些工作流程。它們可以以一種容錯的方式計劃作業，執行工作流以及協調任務之間的依賴關係。在這個方面，我過去經常聽到的名字是 Oozie，而現在主要是 Airflow 或 AWS Step Functions。
雲服務
很明顯，在大數據領域，未來是建立在雲上的。所以，每個對數據管理有興趣的人都最好了解雲的概念。
除了應用於雲的層面的編程模式之外（例如 API 網關模式、發布/訂閱模式、邊車「Sidecar」模式），你還會遇到不同的概念，例如基礎設施即代碼、無服務。當然還有架構上的概念（N 層架構、微服務、鬆散耦合等等）。我個人認為，它使我在更高層面上對工程方法的原理有了的更深入的理解，在架構方法層面的理解也有了一些提升。
現在的雲提供商有 GCP、AWS 和 Azure 等等，我相信沒人會說選項只有它們（譯者註：國內也有阿里雲、騰訊雲等選擇）。你可能決定選擇 AWS（舉例來說），但所有雲都是以相同的方式設計的。儘管它們有各自的特色，並且並非所有的雲服務商都相互匹配。
我從哪開始學習 AWS？
當你打開AWS的文檔，就會看見一個非常長的 AWS 服務的列表，但是這僅僅是全局目錄的全局目錄！沒錯——Amazon 現在實在是太大了。在寫這篇文章的這一章節的時候，該目錄大約有 250 個服務。學習 AWS 的是所有服務是不現實的。也沒有理由去學習所有的服務。
John Markoff 說過：「網際網路已經進入了它的樂高時代」。AWS 服務就像樂高——你找到正確的部件，並把它們組合起來。
為了強調最重要的部分，按照 AWS 歷史上的先後出現順序來排序是很合理的辦法。它們包括：
S3——存儲EC2——虛擬機+EBS硬碟RDS——資料庫Route53——DNSVPC——網絡ELB——負載均衡器CloudFront——內容分發網絡（CDN）SQS/SNS——消息IAM——對所有東西的訪問權限控制CloudWatch——日誌/指標然後，還有現代的微服務的部分，包括 Lambda、DynamoDB、API Gateway、CloudFront、IAM、SNS、SQS、Step Functions、EventBridge。
數據/解決方案的遷移
從本地解決方案到雲服務的數據遷移的集成和準備過程是非常複雜且耗時的。除了遷移大量現有數據外，在遷移完成之前的幾周或幾個月內，公司還必須同步其數據源和平臺。
除了遷移之外，企業還需要準備災難恢復計劃，從而在不犧牲業務的前提下，為任何可能發生的事情做好準備。顯然。這裡的解決方法也是遷移到雲。
機器學習運維（MLOps)
我們的機器學習算法很好，但是要取得好的結果，確實需要大量的數據專家、數據工程師、領域專家以及更多的支持人員。專家的費用並不是非常高昂，可另一個障礙是我們對這種技術的理解仍然是比較原始的。最後，將模型投入生產環境並保持最新是最後的障礙。因為在生產環節中，通常只有使用用與學習過程的相同昂貴且複雜的架構，模型才能實現在學習過程中創建的結果。我們應該理解，部署到生產環節是一個過程，而不是一個步驟，它需要在模型開發的很久之前就開始。它的第一步是定義業務目標、可以從數據中提取的價值假設和用於其業務的商業思路。
機器學習運維——是一個結合了機器學習過程和在商業過程中實現所開發的模型的方法的技術。這個概念作為一種與機器學習模型和機器學習方法相關的開發運維技術而出現。開發運維是一種軟體開發的方法，它提升了單個變動的實施速度，並與此同時保持了靈活性和可靠性。它通過多種方法來達成這一點，包括持續開發。將功能劃分成多個獨立的微服務、自動化測試以及自動化部署單個變動、全局性能監視、對所檢測到的故障的快速響應，等等。
MLOps，或者是用於機器學習的開發運維，允許數據科學團隊和 IT 團隊協作，並通過監控、驗證和管理模型，來加速模型的開發和實現。
當然，這個領域也沒有什麼特別新的技術——每個人都曾經或多或少的接觸過這些技術。現在僅僅是新出現了一個炒作詞彙，其背後往往是現成的解決方案，例如 Seldon、Kubeflow、或者 MLflow。
除此之外，有許多工具能將機器學習模型部署到生產環節，除了我們上述已經提到的工具之外，我認為最流行的工具有 TensorFlow Serving 和 Vowpal Wabbit。現有的機器學習平臺所使用的管理機器學習應用生命周期（從數據到實驗到生產環節的）的方法也值得研究：Google TFX、Facebook FBLearner、Uber Michelangelo、AWS Sagemaker、Standford DAWN、 TensorFlow Extended、Airbnb 的 Bighead 等等。
結論
最後，我寫了很多東西，但看起來像什麼都沒說。我絕不認為自己是所有方面的專家，在本文，我僅僅是對技術進行了一些考證與猜測。但是，正如你從文章中所看到那樣，許多技術在大數據的不同領域都有重疊，而且還不止於此。掌握了它們，你就不用擔心找不到工作。但不要一味追求技術的潮流，而是要掌握與時俱進的技能。而且，最關鍵的技能很可能是軟技能。
與數據工程相關的學習曲線本來就很陡峭了，現在還在變得更加陡峭。開發人員的編程項目的背後需要對企業各個領域的知識和對許多工具和現有解決方案的了解。
在數據管理方案，我們還處在「西部大開發」的階段，特別是在機器學習領域。
延伸閱讀：
大屏數據可視化設計與實踐-InfoQ
關注我並轉發此篇文章，私信我「領取資料」，即可免費獲得InfoQ價值4999元迷你書，點擊文末「了解更多」，即可移步InfoQ官網，獲取最新資訊～