大數據架構的幾個關鍵技術

企業IT基礎設施平台的重新建構是一項複雜的任務。重新建構平台通常由一系列變化的關鍵業務驅動因素引發，現在情況正是如此。簡而言之，主導企業IT技術的近30年的平台無法再滿足推動業務發展所需的工作負載的需求。

數位轉型的核心是數據，它已成為商業中最有價值的事務。由於格式不相容，傳統資料庫的局限性，以及無法靈活地合併來自多個來源的數據，組織長期以來一直受到其使用數據的困擾。新興技術的出現有望改變這一切。

改善軟體部署模式是消除資料使用障礙的一個主要面向。更高的「資料靈活性」還需要更靈活的資料庫和更具可擴展性的即時串流平台。實際上，事實上，至少有七種基礎技術可以結合在一起，為企業提供一種靈活的、即時的「資料結構」。

與他們正在取代的技術不同，這七種軟體創新能夠擴展以滿足許多用戶和許多用例的需求。對於企業而言，他們有能力實現更快、更明智的決策，並創造更好的客戶體驗。

1. NoSQL資料庫

RDBMS在資料庫市場上佔據了近30年的主導地位。但是，面對資料量的不斷增長以及資料處理速度的加快，傳統關係資料庫已經顯示出其不足之處。 NoSQL資料庫由於其速度和擴展能力而被接管。就文件資料庫而言，它們從軟體工程的角度提供了一個更簡單的模型。這種更簡單的開發模式可加快產品上市速度，並協助企業更快回應客戶和內部使用者的需求。

2.即時串流平台

即時回應客戶對客戶體驗至關重要。在過去的10年中面向消費者的行業經歷了巨大的顛覆，這並不神秘。這與企業對用戶即時反應的能力有關。轉向即時模型需要事件流。

訊息驅動的應用程式已存在多年。然而，如今的串流媒體平台的規模比以往要大得多，成本也低得多。最近串流媒體技術的進步為許多優化業務的新方式打開了大門。透過為軟體開發和測試團隊提供即時回饋循環，事件流還可以幫助企業提高產品質量，並更快地開發新的軟體。

3. Docker和容器

容器對開發人員和操作人員，以及組織本身都有很大的好處。傳統的基礎架構隔離方法是靜態分割區，也就是為每個工作負載分配一個單獨的固定資源區塊(無論是實體伺服器或虛擬機器)。靜態分區可以更容易排除故障，但是實質未充分利用的硬體成本很高。例如，Web伺服器平均只使用了可用總運算量的10%。

容器技術的巨大好處是它能夠創造一種新的隔離方式。那些最了解容器的人員可能會相信他們可以透過使用Ansible、Puppet或Chef等工具來獲得相同的好處，但實際上這些技術具有很強的互補性。此外，無論企業如何努力，這些自動化工具都無法實現在不同基礎設施和硬體設定之間自由移動工作負載所需的隔離。同一個容器可以在本地資料中心的裸機硬體上或公有雲中的虛擬機器上運行，無需進行任何更改。這是真正的工作負載移動性。

4.容器儲存庫

容器儲存庫對於敏捷性至關重要。如果沒有用於建立容器映像的DevOps進程以及用於儲存它們的回收站，每個容器都必須建立在每一台機器中，以便可以運行。透過儲存庫，可以在讀取該儲存庫的電腦上啟動容器映像。在多個資料中心處理時，這變得更加複雜。如果在一個資料中心內建立一個容器影像，那麼如何將影像移動到另一個資料中心?理想情況下，透過利用融合資料平台，企業將有能力在資料中心之間對儲存庫實現鏡像。

這裡的一個關鍵細節是，內部部署和雲端運算之間的鏡像功能可能與企業的資料中心之間的鏡像功能差異很大。融合資料平台將透過提供這些功能為企業解決這個問題，而不管組織中使用的是資料中心基礎設施還是雲端運算基礎設施。

5.容器編排

每個容器看起來都有它自己的私人作業系統，而不是靜態硬體分割區。與虛擬機器不同，容器不需要計算和記憶體的靜態分區。這使管理員能夠在伺服器上啟動大量容器，而無需擔心大量的記憶體量。有了像Kubernetes這樣的容器編排工具，啟動容器，移動它們並在環境中的其他地方重新啟動容器變得非常容易。

在新的基礎設施元件到位之後，諸如MapR-DB或MongoDB之類的文檔資料庫，MapR-ES或Apache Kafka之類的事件串流平台(諸如Kubernetes之類的編排工具)，以及在Docker容器中實作用於建置和部署軟體的DevOps流程之後，人們必須了解應該在這些容器中部署哪些元件的問題。

6.微服務

從歷史上看，微服務的概念並不新鮮。現今的差異在於，啟用技術(NoSQL資料庫、事件流、容器編排)可以隨著數千個微服務的建立而擴展。如果沒有這些資料儲存、事件流和架構編排的新方法，大規模微服務部署將不可能實現。管理大量資料、事件和容器實例所需的基礎設施將無法擴展到所需的層級。

微服務都是與提供敏捷性有關。微服務通常由一個功能或一組功能組成。工作的功能單元越小且越集中，建立、測試和部署服務就越容易。這些服務必須解耦，否則企業將失去敏捷性的微服務承諾。微服務可以依賴其他服務，但通常透過負載平衡的REST API或事件流。透過使用事件流，企業可以利用請求和回應主題輕鬆追蹤事件的歷史記錄。由於整個請求流和請求中的所有資料都可以在任何時間點重播，因此這種方法對故障排除具有重大的益處。

由於微服務封裝了一小部分工作，並且由於它們彼此分離，因此隨著時間的推移更換或幾乎沒有障礙地升級服務。在原有模式下，依賴像RPC這樣的緊密耦合意味著必須關閉所有連接，然後重新建立它們。負載平衡是實現這些的一個大問題，因為人工配置使它們容易出錯。

7.功能即服務

正如人們已經看到微服務在行業中佔據主導地位，所以人們也會看到無伺服器運算的興起或可能更準確地將其稱為功能即服務(FaaS)。 FaaS以這樣一種方式創建微服務，即程式碼可以包裝在輕量級框架中，內置於容器中，按需執行(基於某種觸發器)，然後自動進行負載平衡，多虧有了輕量級框架。 FaaS的美妙之處在於它讓開發人員幾乎完全專注於該功能。因此，FaaS看起來是微服務方法的合乎邏輯的結論。

觸發事件是FaaS的關鍵組成部分。沒有它，只有在需要完成工作的情況下，才能呼叫功能和消耗資源。功能的自動呼叫使得FaaS真正有價值。想像一下，每當有人讀取使用者的設定檔時，都會有一個審計事件，這是一個必須運作以通知安全團隊的功能。更具體地說，它可能僅過濾出某些類型的記錄。它可以是具有選擇性的，畢竟它是一個完全可自訂的業務功能。需要注意的是，使用像FaaS這樣的部署模型來完成這樣的工作流程非常簡單。

把事件放在一起

觸發服務背後的魔力其實不過是事件流中的事件。某些類型的事件比其他事件更頻繁地用作觸發器，但是企業如果希望成為觸發器的事件都可能成為觸發器。觸發事件可以是文件更新，對新文件執行OCR過程，然後將OCR過程中的文字加入NoSQL資料庫。如果人們以更有趣的方式思考，每當上傳圖像時，都可以透過機器學習框架進行圖像辨識和評分。這裡沒有根本的限制。如果定義了觸發器事件，則發生了一些事件，該事件觸發該功能，並且該功能完成其工作。

FaaS將成為採用微服務的下一個階段。然而，接近FaaS時必須考慮一個主要因素，那就是供應商鎖定。 FaaS隱藏了特定的儲存機制、特定的硬體基礎架構和編排，這對開發人員來說都是很棒的事情。但由於這種抽象，託管的FaaS產品是IT產業有史以來最大的供應商鎖定機會之一。由於這些API不是標準化的，因此從公有雲中的FaaS產品遷移幾乎是不可能的，不會失去已經完成的近100%的工作。如果透過利用來自融合資料平台的事件以更有條理的方式接近FaaS，那麼在雲端運算提供者之間移動將變得更加容易。