在堆栈中的哪个位置可以最好地将分析数据仓库数据与从第三方 API 抓取+缓存的数据合并？

Posted 2023-03-29

【中文标题】在堆栈中的哪个位置可以最好地将分析数据仓库数据与从第三方 API 抓取+缓存的数据合并？

【英文标题】：Where in the stack to best merge analytical data-warehouse data with data scraped+cached from third-party APIs?

【发布时间】：2021-10-14 15:35:26

【问题描述】：

背景资料

我们向用户出售一种 API，用于分析和呈现来自公共记录的公司财务投资组合数据。

我们有一个“分析数据仓库”，其中包含用于计算金融投资组合的所有原始数据。这个数据仓库由 ETL 管道提供，因此不属于我们的 API 服务器本身。 （例如，API 服务器对分析数据仓库只有只读权限；数据仓库中数据的模式迁移与 ETL 管道一起存在，而不是与 API 服务器一起存在；等等）

我们还有一个小型文档存储（实际上是一个配置了持久性的 Redis 实例）， 归 API 层所有。 API 层运行各种作业以写入此存储，然后根据需要查询数据。您可以将此存储视为 API 层内存状态的各个位的共享持久缓存。 API 层在此处存储 API 密钥黑名单等内容。

问题陈述

我们所有的输入数据都以美元计价，我们的计算以美元为单位。但是，我们为客户提供查询时间选项，以将响应及时转换为另一种货币。我们通过让 API 层运行后台作业来抓取汇率数据，然后将其缓存在文档存储中来做到这一点。每当需要将查询结果转换为特定货币时，各个 API 层节点都会（in-memory-cached-with-TTL）从存储中的此汇率键中获取。

起初，我们认为这种单位转换并不是真正“关于”我们的数据，而只是关于 API 的用户体验，因此我们认为这完全是 API 层的问题，存储交换是有意义的——率数据到我们的文档存储中。

（此外，我们注意到，通过不将我们的数据库结果预先转换为数据库端的特定货币，特定投资组合查询的计算结果变得更加缓存友好；我们做事的方式，我们可以在查询之间缓存和重用投资组合查询结果，即使查询需要不同货币的结果。）

但最近我们已经扩展到允许合作伙伴客户也可以直接针对我们的分析数据仓库执行复杂的数据科学/商业智能查询。事实证明，他们通常还需要在其 BI 查询中进行最终汇率转换——尽管此处不涉及 API 层。

看起来，为了满足 BI 查询的需求，汇率数据“应该”实际上与财务数据一起存在于分析数据仓库中；并且 ETL 管道“应该”负责执行获取和输入汇率数据所需的 API 抓取。

但这感觉是错误的：汇率数据与我们的财务数据具有不同的生命周期和完整性约束。汇率是通过抓取获得的肮脏和短暂的时间点样本，而财务数据是可靠的历史事件流。汇率会不断更新/覆盖，而财务数据只能追加。等等。

对于需要访问后端“应用程序状态”以实现此类“查询结果呈现”需求的分析查询的需求，最佳实践是什么？还是我一开始就将这个汇率数据视为“应用程序状态”是错误的？

【参考方案1】：

我觉得你的场景有趣的是汇率数据何时适用。

在 API 的情况下，一切都与其他货币的实时值有关，并且在您的 API 应用范围 (Redis) 中具有最新值是有意义的。

但是，我假设您的分析数据仓库的表格包含在特定时间进行的购买。在这些情况下，当前汇率与交易价值并不真正相关。

这可能意味着您希望将汇率历史存储在您的仓库中，或者扩展“购买”表以存储当时所有货币的值。