【数据架构】3种类型的数据架构组件：应用程序、仓库和湖泊

有什么区别，为什么重要？

当我刚开始涉足分析领域时，数据架构非常令人生畏。这些术语对我来说是陌生的，人们会把“ETL”和“数据湖”之类的术语扔来扔去，我会点头同意，对他们在说什么只有模糊的感觉，然后把它放在“太难了”的框里。

今天，我想简单地描述数据架构的三个部分；应用程序、数据仓库和数据湖。我会把重点放在你作为一个企业内部的人需要知道的事情上（而不是分析），为了保持实用性，我会举一个我们大多数人可能至少每周都会做的例子，用信用卡买东西。

应用程序数据库

应用程序是生成数据的地方。

比方说，我每周都去乐购购物。当我交出我的卡付款时，卡申请将登记我在4月19日下午5点05分向乐购支付了45.50英镑（有一些中间步骤，但对于本文来说，这并不重要）。但卡应用程序只生成和保存卡的数据，没有关于你是否也持有抵押贷款、你的地址、你的营销偏好等的信息。现在说，你想了解客户每月的交易总数，根据客户是否也有抵押贷款来划分。仅仅使用卡应用程序数据是不可能的，这就是为什么我们需要一个数据仓库。

数据仓库

数据仓库是真相的单一版本。将不同的应用程序数据组合在一起并重新格式化，以便以相同的方式定义和结构化来自不同应用程序的数据。

按照我的Tesco示例，卡应用程序中的交易数据被传输到数据仓库。来自抵押贷款应用程序的数据也会传输到数据仓库，以查看哪些客户持有抵押贷款及其未偿余额。我们还从第三方获取数据；每个月我们都会收到来自信贷机构的报告，其中包括每个客户的信用评分。数据移动的频率取决于数据的类型。客户的信用评分仅每月可用，而信用卡交易数据则是分分钟发生的。这就是数据架构师的用武之地，他们定义了移动数据的最佳频率。

现在，有了不同的来源，我们可以对客户每月的交易数量进行分析，根据客户是否持有抵押贷款进行划分。

数据仓库保存一定程度的历史数据（我们的数据仓库通常保存2-3年），这就是数据湖的来源。

数据湖

数据湖基本上是一个巨大的停车场。数据湖主要用于需要访问数据的机会下降的老化数据。

回到我的例子，你可以想象英国每天发生的卡交易数量（数百万！）。将这些数据长期保存在数据仓库中是不现实的，因为这会减慢速度，而且保存这些数据可能会很昂贵。固定时间后，卡交易数据将从数据仓库转移到数据湖。它仍然可以访问，但不在分析师日常使用的表格中。

作为一个商业人士或产品所有者，我需要了解多少？

事实是，不多，但有一些“注意”领域可能会影响工作的可行性或完成请求的时间长度。

如果我们需要的数据不在数据仓库或数据湖中，数据和分析团队将需要与应用程序所有者接触，以建立将数据传输到数据仓库的流程。这可能需要时间，并且可能涉及数据共享协议。

如果数据很旧并且在数据湖中，则数据是可用的，但分析师可能需要更多的时间来提取数据，因此您可能希望在项目计划中留出更多的时间。

在本文中，我们没有考虑数据是存储在物理服务器上还是存储在云中的区别，但这是另当别论的！

谢谢你的阅读，如果有任何反馈，请告诉我。

参考文献：

Inmon，W.H.（2019）数据架构：数据科学家的入门读物。第2版。加利福尼亚州圣地亚哥：爱思唯尔。