将本地数据库移至云时如何设置Snowflake环境

在像Oracle和SQL Server这样的本地数据库环境中,通常将有多个物理服务器,并且在每个物理服务器中将有多个数据库。 例如,在典型的本地Oracle / SQL Server数据仓库环境中,公司将拥有3套独立的物理服务器,每套用于开发,测试和生产。

在这些物理服务器的每一个中,将创建多个数据库。 这些数据库中的每一个都将用于特定目的,例如,一个数据库可以是从ERP系统中提取数据的金融系统仓库(FIN_DW),另一个可以是从HR系统中提取数据的HR仓库(HR_DW)。来自Salesforce等CRM系统的数据,可以称为CRM_DW。 在每个数据库中可以有多个架构,在每个架构中可以有多个表,视图和其他对象。

因此,在您的内部部署环境中,每个服务器总共可以有3个这样的数据库–

DEV / TEST / PROD物理服务器

在本地环境中,下图描绘了对象的典型层次结构

雪花如何运作

当公司与Snowflake签约时,会获得一个类似的网址

https://companyname.snowflakecomputing.com/

在Snowflake中,数据库是最高级别,并且在数据库内部可以有多个模式,而在模式内部可以有多个表和视图。 因此,换句话说,Snowflake没有像Dev,Test或Production物理服务器这样的服务器概念。

在Snowflake中,下图描绘了对象的典型层次结构

如何在Snowflake中组织本地数据库

鉴于此,就对象(没有开发,测试和生产物理服务器的概念)而言,Snowflake环境要“低一级”。如何组织Snowflake系统以匹配内部部署。 有两种解决方法–

1. 迁移时,将顶级对象保留为单独的数据库

在这种方法中,您将在Snowflake中创建的数据库数量是本地物理服务器数x每个数据库中的数据库数。

在上面的示例中,您将在Snowflake中创建9个数据库–

CRM_DW_DEV

HR_DW_DEV

FIN_DW_DEV

CRM_DW_TEST

HR_DW_TEST

FIN_DW_TEST

CRM_DW_PROD

HR_DW_PROD

FIN_DW_PROD

如果您的内部部署服务器数量很少,并且每个服务器中都有少量数据库,则此方法会很好用。 但是您的公司可能有4–5个物理服务器(Sandbox,Dev,Test,Production等),每个服务器中都有10–20个数据库。 您可以想象在Snowflake中如何增加数据库的数量。 在此示例中,您将查看40至100个数据库之间的任何位置。

您将必须在Snowflake中维护所有这些数据库,并为每个数据库分配安全性和角色。 另外,我认为您将拥有一个非常混乱且混乱的环境,以便长期维护许多数据库。

我看到的最大问题之一是,通常生产服务器比开发服务器或测试服务器具有更高的安全性和访问控制。 在本地环境中,对生产环境中的服务器和数据库进行了审核,并受到SOX的控制。 在Snowflake中,如果最终拥有10–20个生产数据库而没有完整的物理服务器,则将很难向审计团队报告内部控制。

2. 创建与本地物理服务器一样多的“虚拟数据库”

通过这种方法,您可以在Snowflake的顶层创建3个数据库–

1.发展

2.测试

3.生产

这将代表内部部署环境中的3台物理服务器。 然后,您可以在这3个数据库中创建3个本地数据库(CRM_DW,HR_DW,FIN_DW)作为架构。 如果数据库具有多个架构,则可以在这些数据库中创建多个架构。 例如,如果CRM_DW具有2个称为Marketing_Schema和Sales_Schema的架构,则可以在“开发”,“测试”和“生产”数据库下将它们作为2个独立的架构创建为CRM_DW_Marketing_Schema和CRM_DW_Sales_Schema。 然后可以在每个这些模式下创建相应的表和视图。

我在此方法中看到的优点是,您可以使用更结构化的方式查看Snowflake环境。 您将拥有一个Development,Test和Production数据库,然后属于它们的所有模式和表都将位于这些数据库中。 您可以对生产数据库进行更高级别的安全控制,并且可以向审核员证明您具有与生产本地服务器相似的控制。

我看到的这种方法的唯一缺点是,您在内部部署环境中的数据库下有许多架构。 在这种情况下,您仅需使用前面的数据库名称来重命名架构即可,以区分它们。

摘要

在将本地数据仓库移至Snowflake之前,有必要对如何组织Snowflake环境进行一些思考。 由于您没有物理开发,测试或生产服务器的概念,因此可以尝试使用上面的选项2来模仿它。 如果每个物理服务器中都有许多数据库,并且每个数据库中的模式数量较少,则选项2会很好地工作。 如果每个数据库中都有很多架构,而每个物理服务器中数据库数量较少,那么选项1可能更适合您的情况。