如何illimity银行建立了一个灾难恢复策略Lakehouse

通过安德里亚Gojakovic,Mattia Zeni和哔叽斯梅尔廷

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

分享这篇文章

这篇文章从安德里亚·Gojakovic组长在illimity数据科学与造型。

金融活动的不断增加的复杂性,信息和通信技术的广泛使用,新的场景都需要努力增加了风险金融服务业(FSI)球员,以确保适当的水平的业务连续性。

组织金融服务行业在开发面临独特的挑战灾难恢复(DR)和业务连续性计划和策略。从自然灾害中恢复或另一个灾难性事件迅速对这些组织是至关重要的,失去了正常运行时间可能意味着利润损失、声誉和客户的信心。

illimity银行是意大利第一个进行银行。通过其neprixbob体育客户端下载平台,illimity高潜力的企业提供贷款,购买和管理企业陷入困境的信贷。其直接数字银行,illimitybank.com,为个人和企业提供革命性的数字直接银行服务客户。与资产管理公司(AMC) illimity还创建并管理另类投资基金。

illimity的数据平台是围绕bob体育客户端下载蔚蓝的砖,和它的功能。这个博客描述我们发展我们的博士数据平台的情况下,保证RTOs和rpo illimity和监管机构所要bob体育客户端下载求的螃蟹船环意大利自行车赛(意大利央行)。

解决方案的设计和实现都支持的数据回复它砖总理的伙伴,实施快速、有效实施灾难恢复需求的illimity砖Lakehouse平台。bob体育客户端下载

在灾难恢复监管要求

开发一个数据平台战略,博士的一个子集bob体育客户端下载业务连续性(BC)计划,是复杂的,必须考虑许多因素。计划从一开始业务影响分析(BIA)为每个过程,定义了两个关键指标,应用程序,或数据产品:

恢复时间目标(RTO)定义应用程序的最大可接受的时间可以离线。螃蟹船环意大利自行车赛”进一步将它定义为运营商之间的间隔的宣言的危机和复苏过程的预定的服务水平。它也认为所需的时间发生的事件进行分析,决定需要采取的行动。
恢复点目标(RPO)定义了最大可接受的时间长度,数据可能会丢失由于一场灾难。

这些指标变化和变化取决于关键业务和定义的过程是由监管机构提供。

在这篇文章我们将介绍业务流程视为“关键业务”(即。,拥有一个RTO RPO 4小时¹)。

体系结构

illimity从头开始它的旅程砖在2018年单身工作空间。此后,砖已成为中央的数据平台,所有类型的数据负载:批处理、流媒体、BI、用户探索和分析。bob体育客户端下载

而不是选择了传统的数据仓库解决方案与许多传统银行一样,我们决定完全采用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起程拓殖应用步骤将相关检查存在的变更请求批准。

博士这种方法大大促进我们的策略,因为我们总是相信这两种环境中完全相同,砖的工作区和里面的对象。