如何illimity銀行建立了一個災難恢複策略Lakehouse

通過安德裏亞Gojakovic,Mattia Zeni和嗶嘰斯梅爾廷

2022年5月9日在公司博客上

分享這篇文章

這篇文章從安德裏亞·Gojakovic組長在illimity數據科學與造型。

金融活動的不斷增加的複雜性,信息和通信技術的廣泛使用,新的場景都需要努力增加了風險金融服務業(FSI)球員,以確保適當的水平的業務連續性。

組織金融服務行業在開發麵臨獨特的挑戰災難恢複(DR)和業務連續性計劃和策略。從自然災害中恢複或另一個災難性事件迅速對這些組織是至關重要的,失去了正常運行時間可能意味著利潤損失、聲譽和客戶的信心。

illimity銀行是意大利第一個進行銀行。通過其neprixBeplay体育安卓版本平台,illimity高潛力的企業提供貸款,購買和管理企業陷入困境的信貸。其直接數字銀行,illimitybank.com,為個人和企業提供革命性的數字直接銀行服務客戶。beplay体育app下载地址與資產管理公司(AMC) illimity還創建並管理另類投資基金。

illimity的數據平台是圍繞Beplay体育安卓版本蔚藍的磚,和它的功能。這個博客描述我們發展我們的博士數據平台的情況下,保證RTOs和rpo illimity和監管機構所要Beplay体育安卓版本求的螃蟹船環意大利自行車賽(意大利央行)。

解決方案的設計和實現都支持的數據回複它磚總理的夥伴,實施快速、有效實施災難恢複需求的illimity磚Lakehouse平台。Beplay体育安卓版本

在災難恢複監管要求

開發一個數據平台戰略,博士的一個子集Beplay体育安卓版本業務連續性(BC)計劃,是複雜的,必須考慮許多因素。計劃從一開始業務影響分析(BIA)為每個過程,定義了兩個關鍵指標,應用程序,或數據產品:

恢複時間目標(RTO)定義應用程序的最大可接受的時間可以離線。螃蟹船環意大利自行車賽”進一步將它定義為運營商之間的間隔的宣言的危機和複蘇過程的預定的服務水平。它也認為所需的時間發生的事件進行分析,決定需要采取的行動。
恢複點目標(RPO)定義了最大可接受的時間長度,數據可能會丟失由於一場災難。

這些指標變化和變化取決於關鍵業務和定義的過程是由監管機構提供。

在這篇文章我們將介紹業務流程視為“關鍵業務”(即。,擁有一個RTO RPO 4小時¹)。

體係結構

illimity從頭開始它的旅程磚在2018年單身工作空間。此後,磚已成為中央的數據平台,所有類型的數據負載:批處理、流媒體、BI、用戶探索和分析。Beplay体育安卓版本

而不是選擇了傳統的數據倉庫解決方案與許多傳統銀行一樣,我們決定完全采用Lakehouse通過利用三角洲湖作為我們的數據的主要格式(99%的所有數據在illimity三角洲表)和服務磚的SQL。數據攝取和轉換工作計劃和策劃Azure數據工廠(ADF)和磚的工作。托管在我們的NoSQL數據MongoDB,而我們選擇Azure的本地商業智能解決方案,PowerBI,因為我們的儀表盤和報表的需求。為了正確地跟蹤,標簽和保證正確的數據訪問,我們整合Azure範圍和Immuta到我們的體係結構。

下圖顯示了磚我們組織架構的一部分。我們建立了兩種類型的工作區,技術和用戶工作空間分組在Azure資源組。

每個銀行的9個部門有專門技術工作空間在非生產和生產環境,部門的開發人員都是所有者和管理員。所有自動化工作將在執行技術工作區,和業務用戶通常不會操作。一個用戶工作區允許訪問部門的業務用戶。這是探索和分析活動發生的地方。

這兩種類型的工作區連接到相同的,共享的,Azure數據湖Gen 2 (ADLS)和Azure為PostgreSQL數據庫分別為數據和元數據。這兩個是一個單一的實例共享所有銀行的部門。

磚與起程拓殖自動化部署

在決定之前管理所有磚資源作為基礎設施代碼(IaC)通過起程拓殖,所有這些物體的變化都是手動完成的。這導致出錯手動更改非生產和生產環境。分權體係結構和前向數據網格的模型,整個數據基礎設施的銀行是由一個團隊管理,造成瓶頸和長時間分辨率為內部票。我們已經創建了起程拓殖和Azure管道為每個團隊使用模板,允許獨立,同時保證合規。

這裏有一些實際以來發生了變化,采用起程拓殖作為我們的實際數據資源管理工具:

集群和庫他們安裝在手動創建和維護,導致運行時環境之間的不匹配,優化集群大小和過時的庫版本。起程拓殖允許團隊來管理他們的磚運行時根據需要在不同的環境中,而現在所有的庫是存儲為Azure工件,避免陳舊的包的版本。當創建集群起程拓殖,雙重需要批準的Azure管道創建這些資源,以避免人為錯誤,擴界和不必要的成本。強製性標簽在所有集群讓我們正確分配單獨的項目成本,讓我們計算每個集群的股本回報率(ROE)。
用戶和權限在數據庫和集群手動添加了磚。創建的組不符合那些出現在Azure Active Directory和定義的數據用戶可以訪問審計目的幾乎是不可能的。現在用戶配置管理通過SCIM,所有管理acl起程拓殖,拯救我們的團隊的時間每周授予這些權限。

在項目的開始,我們使用實驗資源出口國和生成的代碼幾乎所有我們已經在工作區中手動配置:集群和工作配置,安裝、組、權限。我們必須手工重寫一些代碼,但它極大地救了我們最初的努力。

盡管起程拓殖有一個陡峭的學習曲線和一個引人注目的投資必須重構現有流程,我們開始收獲的好處很少的時間。除了管理策略,博士IaC的方法保存數據團隊illimity無數小時的管理工作,留下更多的時間進行有效的項目創造價值。

采用一個災難恢複策略

當決定如何處理博士,有不同的策略可供選擇。由於強烈的RPO和RTO的要求金融機構在illimity,我們決定采用一個主動/被動Warm備用方法,保持實時數據存儲和數據庫,除了最低生活部署。DR站點必須擴大來處理所有生產工作負載的一場災難。這使我們反應更快的一場災難,同時控製成本。

我們當前的設置中可以看到下圖博士。這是一個簡化的視圖考慮在一個部門隻有一個工作區,但以下注意事項可以很容易地推廣。我們複製在兩個Azure地區整個雲計算基礎設施。每個組件都是部署在這兩個地區,但二級區域的計算資源是關閉,直到災難事件發生時。這讓我們在幾分鍾內做出反應。

在這篇文章中,我們將隻關注磚博士戰略的一部分。這包括工作區,Azure為PostgreSQL數據庫和Azure數據存儲Gen2湖。

磚的對象

磚的工作空間內,有多個對象需要恢複在新的地區發生災難。在illimity,我們起程拓殖部署實現這一目標通過利用我們的環境。工作空間中的對象(例如,集群,用戶和組,工作,掛載點,權限和秘密)通過起程拓殖管理腳本。當我們部署一個新的工作空間或更新現有的一個,我們要確保這兩個地區的部署。這樣,二級區域總是最新的,準備好開始處理請求的一個災難事件。自動工作,不需要做任何事情,因為觸發工作操作集群自動開始工作。為用戶工作區,一個可用的集群啟動時用戶需要執行一個操作數據。

表複製

表時,在磚有兩種主要的對象,需要備份:數據在存儲賬戶和元數據metastore。有多個選項當選擇一個博士的策略。在illimity,我們決定選擇一個被動的備份解決方案,而不是設置手動流程保持同步,也就是說,利用低級的複製功能由雲提供商提供,Azure。

數據複製

三角洲湖提供ACID事務,這增加了每個操作的可靠性,和時間旅行。後者是特別重要的。時間旅行可以讓我們輕鬆地從錯誤中恢複和災難恢複是至關重要的。

三角洲的主要存儲文件,我們選擇了一種GRS-RA Azure數據存儲Gen2湖。這個選擇讓我們接近博士以被動的方式,在某種意義上,二級區域的複製是委托給Azure。事實上,Geo-redundant讀訪問存儲(GRS-RA)同步複製數據三次在一個物理位置的主要地區使用LRS (Locally-redundant存儲)。此外,它異步複製數據的物理位置輔助區域。GRS提供持久性存儲資源至少16 9是在一個給定的一年。的RPO, Azure存儲的RPO不到15分鍾,雖然目前還沒有SLA需要多長時間複製數據到輔助區域。

由於延遲複製跨地區,我們需要確保所有的文件屬於一個特定版本的三角洲表不存在最後一個損壞的表。為了解決這個問題,我們創建了一個腳本,該腳本將執行在二級地區發生災難事件和停機時,檢查是否所有的表的狀態是一致的,所有文件的一個特定的版本。如果不滿足一致性要求,表的腳本還原以前版本使用Delta-native時間旅行,在指定的RPO是保證。

Metastore複製

第二部分是一個需要在處理三角洲表metastore。它允許用戶注冊表和管理表ACL。在illimity,我們選擇了一個外部蜂巢Metastore內部蜂巢Metastore管理,主要用於複製自身的能力在不同的地區,沒有實現手動策略。這是符合博士選擇被動的解決方案。metastore由一個完全Geo-replicated Azure為PostgreSQL數據庫管理。當我們從任何修改元數據工作區主要地區,它會自動傳播到二級地區。在停機的情況下,二級區域的工作區總是最新的元數據,允許一個一致的觀點表、權限,等。統一目錄將很快的標準內部metastore磚,將提供額外的功能,如cross-workspace訪問、集中治理、血統,等等,這將簡化複製metastore博士。

在illimity修改一個磚的工作區

在illimity,我們決定有嚴格的政策磚工作區創建和修改的。每個工作區可以隻通過編輯起程拓殖並通過web UI變化是完全禁止的。這是實現本地,因為創建的UI不允許修改集群通過起程拓殖。此外,隻有少數允許選擇用戶管理員在一個工作區。這允許在我們的組織,我們的模板和責任部門負責人進行更改。

每個illimity分工定義一個應用的過程的狀態變化數據磚工作區通過使用Azure DevOps (ADO)管道。ADO管道照顧起程拓殖計劃和應用的實際操作步驟,它們相當於創建、更新或刪除資源,版本配置代碼中定義的Git存儲庫。

每個起程拓殖應用ADO管道負責實施步驟主要和次要區域。這樣,工作空間的定義聲明的部門將被複製完全相同的方式在不同的地區,確保總校準和災難恢複準備。

開發過程的維護和更新各種磚的工作空間,使用Azure DevOps,是由下列的指導方針

的主分支每個存儲庫將保持起程拓殖配置的兩個環境(UAT和刺激),它將定義的當前(和正式批準)狀態不同的資源。可能直接提交是禁用的分支。一個審批流程通過拉請求總是必需的。
任何改變資源在各種環境中必須通過改變他們起程拓殖代碼。任何新特性(如圖書館集群上安裝,新磚集群,等等),從而改變UAT或刺激環境的狀態,必須開發孩子的主分支上。
隻有改變生產環境中,用戶還必須打開一個變更請求(杆),需要Change-advisory董事會(出租車)批準,沒有它就不可能對生產資源進行更改。將請求從指定的審批人員在他們的部門需要確認。
批準,代碼將在主分支和合並在這一點上,它將有可能啟動Azure DevOps管道,負責執行起程拓殖適用於傳播變化的主要地區和在二級地區。
用於生產環境的變化,實際Azure DevOps起程拓殖應用步驟將相關檢查存在的變更請求批準。

博士這種方法大大促進我們的策略,因為我們總是相信這兩種環境中完全相同,磚的工作區和裏麵的對象。