?譯者 | 朱先忠

審校 | 孫淑娟

當前，數(shù)據(jù)領域的挑戰(zhàn)不再是海量數(shù)據(jù)的處理能力。現(xiàn)代流媒體平臺的高性能以及新一代數(shù)據(jù)存儲允許將計算與存儲層分離，使得我們可以通過非常低的操作工作量來提高系統(tǒng)的可伸縮性。

如果我們還記得著名的大數(shù)據(jù)“五V”（容量、價值、多樣性、速度和準確性，即“Volume, Value, Variety, Velocity, and Veracity”）的話，那么，我們今天應該更清醒地認識到，準確性和價值對于今天的大多數(shù)公司來說仍然是一個挑戰(zhàn)。

數(shù)據(jù)管道是解決這一挑戰(zhàn)的基礎。大規(guī)模設計和構建數(shù)據(jù)管道不僅可以提高系統(tǒng)的開發(fā)速度，而且可以讓整個團隊都可以參與維護和理解。

數(shù)據(jù)卷的處理能力

幾年前，大數(shù)據(jù)領域面臨的技術挑戰(zhàn)主要表現(xiàn)在以下領域：

• 數(shù)據(jù)存儲倉庫（體積和速度方面）：接收和管理大量數(shù)據(jù)。
• 數(shù)據(jù)處理計算層（速度方面）：需要高性能計算層來啟動數(shù)千條數(shù)據(jù)管道，允許以非常快速的方式接收大量數(shù)據(jù)。
• 集成適配器（類型方面）：開發(fā)適配器以與不同類型的數(shù)據(jù)庫組件集成。

IT團隊在開始開發(fā)第一條數(shù)據(jù)管道之前，往往耗費數(shù)年時間構建支持這些功能的數(shù)據(jù)平臺。之后，所有的努力都集中于在短時間內接收大量的數(shù)據(jù)。但這一切都發(fā)生在沒有關注真實商業(yè)價值的情況下。此外，操作這些數(shù)據(jù)平臺往往需要付出巨大的努力。

現(xiàn)在，隨著云技術方案的應用——開源社區(qū)、最新一代云軟件和新的數(shù)據(jù)架構模式的出現(xiàn)等，實現(xiàn)上述這些功能不再成為一種挑戰(zhàn)。

數(shù)據(jù)存儲倉庫

當前，已經存在多種方法可以提供高性能數(shù)據(jù)存儲庫，以便以低操作工作量實時管理大量數(shù)據(jù)。

n 數(shù)據(jù)倉庫：新一代數(shù)據(jù)倉庫將存儲層與計算層分離，并提供基于不同技術的新的可擴展功能，如NoSQL、數(shù)據(jù)湖或具有AI功能的關系數(shù)據(jù)倉庫。

• 關系數(shù)據(jù)庫：使用分片和內存功能的最新關系數(shù)據(jù)庫，提供OLTP和OLAP功能。
• 流媒體平臺：Apache Kafka或Apache Pulsar等平臺，能夠提供每秒處理數(shù)百萬個事件的能力，并支持構建實時管道。

在這種情況下，成功的關鍵是為企業(yè)的應用場景選擇最佳方案的問題。

計算層

當前計算層能夠提供以下功能，以支持執(zhí)行大量并發(fā)管道：

• 無服務器：云平臺提供了簡單的按需擴展。
• 新數(shù)據(jù)存儲庫的計算層：與存儲分離，允許在數(shù)據(jù)庫上執(zhí)行大部分操作，而不會像舊的內部部署系統(tǒng)那樣影響其他負載或擴展限制。
• Kubernetes：我們可以使用Kubernetes API動態(tài)創(chuàng)建作業(yè)容器作為Kubernetes Pods。

集成適配器

開源社區(qū)與新的云軟件供應商一起，提供了各種數(shù)據(jù)適配器來快速提取和加載數(shù)據(jù)。這簡化了不同軟件組件（如數(shù)據(jù)存儲庫、ERP和許多其他組件）之間的集成。

當前面臨的數(shù)據(jù)挑戰(zhàn)

大數(shù)據(jù)公司當前面臨的關鍵挑戰(zhàn)是如何以更全面和可靠的方式提供數(shù)據(jù)。數(shù)據(jù)處理是復雜性的主要因素之一。作為數(shù)據(jù)或業(yè)務分析師，除了在正確的時間獲得信息外，我們還需要了解所分析數(shù)據(jù)的元數(shù)據(jù)，以便做出決策。

• 這些數(shù)據(jù)意味著什么？它提供了什么數(shù)值？（數(shù)值方面）
• 如何計算數(shù)據(jù)？（數(shù)值方面）
• 數(shù)據(jù)的來源是什么？（數(shù)值方面）
• 數(shù)據(jù)的更新程度如何？（準確性方面）
• 數(shù)據(jù)的質量如何？（準確性方面）

在大型企業(yè)中，存在很多數(shù)據(jù)，但也有很多部門有時使用相似但不同的數(shù)據(jù)。例如，零售公司有兩種類型的庫存：

• 額定庫存：該庫存是理論庫存，基于采購訂單和交貨單。
• 真實庫存：此庫存代表他們在倉庫和商店中擁有的物品。

通常，由于遞送延遲或其他人為錯誤等多方面的原因，這兩種數(shù)值并不匹配。但是，庫存數(shù)據(jù)是計算例如銷售、銷售預測或庫存補充等指標的主要依據(jù)。根據(jù)理論庫存購買新貨物的決定可能會給公司造成數(shù)千美元的損失，并導致一種不可持續(xù)的狀況。但事實情況是，我們只能想象這些決定對其他部門（例如庫存健康度）的影響。

當分析師做出決策時，他們需要知道他們正在使用哪些數(shù)據(jù)來評估風險并做出有意識的選擇。接下來，我們討論的是如何將數(shù)據(jù)轉換為業(yè)務價值的問題。

數(shù)據(jù)管道扮演什么角色？

當我們坐在辦公室想象數(shù)據(jù)（或者閱讀高級文章）時，我們常常想到的只是一個其中包含幾個數(shù)據(jù)域的非常簡單的世界：

但現(xiàn)實情況往往遠比上面的情形更為復雜：

在大數(shù)據(jù)場景中，有數(shù)千條不同級別的數(shù)據(jù)管道在數(shù)據(jù)域或數(shù)據(jù)存儲庫之間不斷攝取和整合數(shù)據(jù)。數(shù)據(jù)管道是提供成功數(shù)據(jù)平臺的最重要組成部分之一；但是，即使在今天，我們在大規(guī)模構建數(shù)據(jù)管道方面也面臨著與多年前相同的挑戰(zhàn)，這體現(xiàn)在：

• 以動態(tài)和靈活的方式提供元數(shù)據(jù)，如歷史數(shù)據(jù)沿襲
• 實現(xiàn)數(shù)據(jù)分析師、數(shù)據(jù)工程師和公司股東之間的輕松協(xié)作
• 輕松向數(shù)據(jù)分析師和利益相關者提供有關數(shù)據(jù)質量和新鮮度的信息

大規(guī)模構建數(shù)據(jù)管道的挑戰(zhàn)是什么？

數(shù)據(jù)管道的目標主要集中在以下四個領域：

• 團隊協(xié)作和理解
• 動態(tài)數(shù)據(jù)沿襲
• 可觀測性
• 數(shù)據(jù)質量

團隊協(xié)作和理解

規(guī)則變化很快，公司必須快速適應。數(shù)據(jù)和信息比以往任何時候都更加重要。

為了快速提供價值，我們需要一個由數(shù)據(jù)科學家、數(shù)據(jù)工程師、分析師和公司股東組成的異構團隊共同工作。他們需要使用一種類似的語言才能變得更為敏捷。當我們所有的數(shù)據(jù)管道都使用Spark或Kafka Streams等技術構建時，技術人員和非技術人員之間的敏捷通信就太復雜了。

從數(shù)據(jù)到信息的旅程始于數(shù)據(jù)管道。

數(shù)據(jù)沿襲

元數(shù)據(jù)對于將數(shù)據(jù)轉換為業(yè)務信息非常重要。它提供了每個人都可以訪問的摘要沿襲，提高了數(shù)據(jù)的可見性、理解力和信心。我們必須動態(tài)提供這些信息，而不是通過永不改變的靜態(tài)文檔或永久持續(xù)的復雜檢查過程。

可觀測性

數(shù)據(jù)管道的可觀測性是一個重大挑戰(zhàn)。通常，可觀察性面向技術團隊，但我們需要提高所有利益相關者（業(yè)務分析師、數(shù)據(jù)分析師、數(shù)據(jù)科學家等）的可視性。

數(shù)據(jù)質量

我們需要改進我們處理數(shù)據(jù)的方式，并開始應用傳統(tǒng)軟件開發(fā)的最佳實踐。從數(shù)據(jù)到作為代碼的數(shù)據(jù)，我們可以借助版本控制、持續(xù)集成或測試等方法實現(xiàn)。

數(shù)據(jù)管道是如何發(fā)展的？

當我們研究新的數(shù)據(jù)技術趨勢時，我們可以觀察到存在于開源社區(qū)或商業(yè)軟件初創(chuàng)公司（如Airbyte、Meltano、dbt labs、DataHub或OpenLineage）中的一些積極舉措。

上面這些應用案例顯示了數(shù)據(jù)處理領域如何演變?yōu)椋?/p>

• 利用新的數(shù)據(jù)存儲庫增強功能，從ETL（提取、轉換、加載）模型過渡到ELT（提取、加載、轉換）模型
• 提供以代碼形式管理數(shù)據(jù)的功能
• 提高數(shù)據(jù)理解和可觀察性

上述功能是使我們能夠大規(guī)模構建數(shù)據(jù)管道并提供業(yè)務價值的關鍵。

從數(shù)據(jù)準備到數(shù)據(jù)理解的歷程

理解是將數(shù)據(jù)轉化為信息的第一步。轉換層在這個過程中起著關鍵作用。通常，轉換層是瓶頸，因為數(shù)據(jù)工程師和業(yè)務分析師的語言不同，所以協(xié)作很復雜。然而，諸如dbt之類的新工具正試圖改進這一點。

什么是dbt？

dbt（數(shù)據(jù)構建工具，即“Data Build Tool”）是一種用于轉換層的開源CLI工具，它支持業(yè)務數(shù)據(jù)分析師和工程師在數(shù)據(jù)生命周期中使用通用語言以及軟件開發(fā)最佳實踐（如版本控制、連續(xù)集成/部署和連續(xù)測試）進行協(xié)作。

公司范圍內的通用語言

SQL是公司的通用語言，允許所有利益相關者在整個數(shù)據(jù)生命周期中參與討論。SQL使數(shù)據(jù)和業(yè)務分析師能夠使用版本控制工具通過SQL語句協(xié)作編寫或修改轉換。

ELT（提取、加載、轉換）

數(shù)據(jù)世界發(fā)生了很大變化。目前，大多數(shù)數(shù)據(jù)存儲庫都具有良好的性能和可擴展性。而且，新的場景改變了轉換過程的規(guī)則。在許多情況下，數(shù)據(jù)存儲庫比外部流程更適合工作。dbt執(zhí)行ELT過程的轉換，利用新數(shù)據(jù)存儲庫的功能并在數(shù)據(jù)倉庫中運行數(shù)據(jù)轉換查詢。

數(shù)據(jù)作為代碼

dbt允許在Git存儲庫中以代碼的形式管理數(shù)據(jù)轉換，并應用持續(xù)集成最佳實踐。它提供了測試功能，包括基于SQL查詢的單元測試模塊，或使用宏對其進行擴展，以增加更復雜場景中的覆蓋率。

沿襲和元數(shù)據(jù)

dbt允許我們在每次運行數(shù)據(jù)轉換時動態(tài)生成數(shù)據(jù)沿襲和元數(shù)據(jù)。如今存在許多成熟的平臺（例如阿里云的DataHub或Datakin的OpenLineage）能夠與企業(yè)的業(yè)務進行集成，而且這些平臺都提供了豐富的企業(yè)可見性支持。

結論

近年來，很多大數(shù)據(jù)公司在提高數(shù)據(jù)處理性能和攝取能力方面都投入了大量精力，但質量和理解仍然是導致決策艱難的問題領域。如果我們不理解大量數(shù)據(jù)，或者數(shù)據(jù)質量很差，那么我們很快就會收到大量無關的數(shù)據(jù)。然而，為了提供增加業(yè)務價值的信息，必須有一層可擴展、可維護和可理解的數(shù)據(jù)管道。

請牢記：不做決定比根據(jù)不準確的數(shù)據(jù)做決定更好——尤其是當你沒有意識到數(shù)據(jù)是錯誤的時候。

譯者介紹

朱先忠，51CTO社區(qū)編輯，51CTO專家博客、講師，濰坊一所高校計算機教師，自由編程界老兵一枚。早期專注各種微軟技術（編著成ASP.NET AJX、Cocos 2d-X相關三本技術圖書），近十多年投身于開源世界（熟悉流行全棧Web開發(fā)技術），了解基于OneNet/AliOS+Arduino/ESP32/樹莓派等物聯(lián)網開發(fā)技術與Scala+Hadoop+Spark+Flink等大數(shù)據(jù)開發(fā)技術。

原文標題：??Challenges to Designing Data Pipelines at Scale???，作者：Miguel Garcia?