我应该允许从应用程序直接连接到数据仓库吗？

Question

我正在开发一个需要从数据仓库获取数据的应用程序。我一直认为应用程序不应该直接访问数据仓库。随着 Snowflake、RedShift 等数据仓库的改进，这一原则仍然有效，为什么？我似乎在网上找不到太多文档说明不再提供直接访问以及内部和外部应用程序之间是否会有所不同。

此外，从数据仓库向应用程序提供数据的最佳方式是什么？如果应用程序与数据仓库中的专用数据库/模式有直接连接，是否应该创建一个边界，例如将所需的数据从数据仓库导出到 SFTP 站点，以便从那里或其他地方使用。

感谢您的帮助

Answer 1

有一个安全角度，demircioglu 纠正了这一点，为应用程序创建一个帐户，该帐户只能访问它需要的视图。

然后是抽象角度。如果您的应用程序直接访问数据库（也称为 SQL 代码/数据/配置中的 SQL），它现在被锁定到数据库的形状中。

有3种方法可以解决这个问题，

1. 在经典的 RMDB 中，您将使您的应用程序仅调用存储过程，因此您的应用程序中没有“如何”，只有一个接口。因此一切都是灵活的。 Snowflake 有存储过程（现在），所以这是一个选项。
2. 将应用程序编写为仅从视图中选择。尽管要使用视图，您必须有权访问表，但开发人员遵循纪律不从表中读取数据，从而避免应用程序发布周期中数据库的紧密耦合
3. 在App和DB之间放置一个Service，这样App现在是解耦的，而Service虽然紧密耦合，但不是DB，应该由DB团队拥有和控制。

过去创建视图需要一段时间，所以如果你有数千个视图来更新，这可能会很慢（说实话，我不确定，我的观点已经有 4 年多了）。而且您必须相信开发人员不会“只使用表格”，而是“分享原因的知识”并自我执行。

Store Proc 以前并不存在，与 PostgreSQL 相比，访问结果有些痛苦，但这可能是最干净的方法。

在我之前的比较中，我们走的是Service路线，因为它已经存在于Snowflake之前的架构中，因此很容易重新定位Snowflake，而且效果非常好，它也是我们重写SQL的层得到，使用我们正在使用的正确的多租户安全层，并允许我们从“user”表更改为“customer_x_user_view”以及后来的用户定义函数，因此“customer id”可以粘贴到更深的 SQL 中，因此过滤器是被迫下来。这也允许我们在不同的版本上拥有不同的客户，因为我们可以让 v1_views 和 v1_udf 保持活动状态，同时部署使用新表的 v2_views，如果出现问题，我们可以在该服务层中将每个客户交换回 v1 .

这会增加大多数人可能想要预先完成的更多工作，但它对我们来说非常有效。

与所有权衡一样，您应该做什么取决于您需要什么、需要多少以及何时需要。