搭好資料架構,這7個技術是關鍵

2021-08-18 01:49:23 字數 3486 閱讀 7085

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

企業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資料庫、事件流、容器編排)可以隨著數千個微服務的建立而擴充套件。如果沒有這些資料儲存、事件流和架構編排的新方法,大規模微服務部署將不可能實現。管理大量資料、事件和容器例項所需的基礎設施將無法擴充套件到所需的級別。

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

7.功能即服務

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

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

把事件放在一起

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

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

bingdata

優網助幫

匯聚多平台採集的海量資料,通過大資料技術的分析及**能力為企業提供智慧型化的資料分析、運營優化、投放決策、精準營銷、競品分析等整合營銷服務。

避免這7個誤區,才能讓 巨集 削鐵如泥

當使用引數呼叫巨集時,會將引數替換為巨集主體,並與其他輸入檔案一起檢查結果,以進行更多的巨集呼叫,可以將部分來自巨集主體和部分自變數的巨集呼叫組合在一起。例如,define twice x 2 x define call with 1 x x 1 call with 1 twice x 1 twic...

搞清楚這7個問題,埠就徹底了解了!!

1.埠到底是什麼?埠就是乙個數字而已 這裡的乙個常識是 tcp ip協議中的埠,埠號的範圍從0到65535 2.埠到底是用來幹嘛的?是這樣 當系統呼叫乙個應用程式的時候,會將該程序與乙個埠繫結,這樣一來,傳輸層傳給該埠的資料都被相應的程序接收,與此同時,相應程序發給傳輸層的資料也都通過該埠輸出。所以...

這7個習慣讓我在22歲時成為百萬富翁

22歲的時候你在做什麼?也許還在不知名小公司拿著不高不低的工資,也許還在大學校園慌忙備考,但是本文的主人公tucker hughes已經大學畢業兩年,在20歲就拿到了碩士學位,兩年來,他創辦了兩家商業不動產投資管理公司,收穫頗豐,已經賺到了100萬美元。商業地產競爭激烈,tucker hughes所...