数据栈

我们发现，公司处理数据的过程主要分为四个主要阶段，这些阶段与每个阶段数据的外化使用密切相关。

上图中的每个垂直阶段都是一个相对的平衡点，可根据您的资源，规模和组织中数据的重要性来进行操作。例如，一个有 20 个人的具有典型数据需求的团队可能会直接在 Source 级别上很好地工作，并且在他们开始感觉到增长的痛苦之前，不希望进入 Lake 阶段。但是，随着该公司的规模超过 200 名员工，并且他们的数据需求不断增长，将其推进到 Mart 的整个过程将具有不可估量的价值，甚至可能是至关重要的。

Sources

当您开始使用数据时，可能只有几个感兴趣的来源。早期的两个常见来源是 Google Analytics（分析）和产品所使用的 PostgreSQL 或 MySQL 数据库中的应用程序数据。如果您公司中只有少数几个人需要使用这些资源，则可以将其设置为具有直接访问权限；他们直接直接处理数据会更简单，更灵活。

在此早期阶段，您将受益于使用 BI 产品，该产品可让您在需要时编写 SQL，因为您的数据很可能是出于交易目的而构造的，并且通常需要某些复杂查询的全部功能。

Lake

当您开始依赖更多的数据源，并且更频繁地需要合并数据时，您将需要构建一个 Data Lake，这是所有数据以统一格式一起存在的地方。尤其是当您需要使用 Salesforce，HubSpot，Jira 和 Zendesk 等应用程序中的数据时，您将需要为这些数据创建一个主目录，以便可以使用单个 SQL 语法一起访问所有数据，而不是许多不同的 API。

如果这是大量数据（每天> 100GB），则需要将其存储在 S3 中。但是对于大多数使用情况，您将需要将其存储在数据仓库引擎中，例如 Redshift，Panoply，Snowflake 或 Big Query。在这里，您的数据仍处于其原始事务或事件结构中，并且有时会需要一些凌乱的 SQL，这仍然会限制谁可以实际使用数据。但是，Data Lake 将具有更高的性能，可以使用一种 SQL 语法在一个地方使用，并且可以为下一个重要阶段做好准备。

Warehouse (single source of truth)

在 Lake 阶段，当您吸引更多人使用数据时，您必须向他们解释每种模式的奇特之处，哪些数据在哪里以及需要在每个表中进行过滤的特殊条件。这变得很繁重，并且会导致您经常遇到数据的完整性问题。最终，您将需要开始将数据整理到一个单一的真实来源中。从历史上看，这个阶段（创建数据仓库）一直是一场噩梦，并且有许多著作着眼于如何最好地建模数据以进行分析处理。但是，如今这并不困难了，它不仅使您不必向新团队成员解释所有架构的怪异，而且还可以节省您重复，编辑和维护自己的混乱查询的时间。

• 使用您自己的文件或使用 dbt 之类的出色框架，以 SQL 中新的视图模式进行建模。不要使用专有的第三方建模语言；最好用 SQL 完成。它功能强大，性能卓越，与供应商无关，并且您的团队已经知道这一点。

• 不要阅读过多的有关 Inman 或 Kimball 等传奇人物关于尺寸建模的书籍，以免过分思考您的建模。那里的大多数书籍都有几十年的历史了，正如我上文所述，最佳实践是基于完全不同的技术考量。

• 您的分析模型现在应该仅是原始事务模式的简化，过滤，最小化，描述性命名的纯净版本。就像您的公司没有在许多不同的详细 SaaS 应用程序和具有奇特情况和复杂集成的事务性数据库上运行一样，创建它们。而是在单个理想的，完美清洁的整体应用程序上运行。这个理想的应用程序具有干净的操作架构，随着它成为您公司的真理之源，它会慢慢发展。

Marts

当您拥有干净的数据并在其上拥有良好的 BI 产品时，您应该开始注意到公司中的许多人都能够回答他们自己的问题，并且越来越多的人参与其中。这是个好消息：您的公司越来越了解信息，业务和生产力结果也应显示出来。您也不必担心完整性问题，因为您已经对数据进行了建模，并且不断将其维护为干净，清晰的事实来源。

最终，您将在该事实来源中拥有数百张表，并且当用户尝试查找与其相关的数据时，他们将不知所措。您可能还会发现，根据团队，部门或用例的不同，不同的人希望使用以不同方式构造的同一数据。由于这些原因，您将要开始推出 Data Marts。

数据集市是团队或调查主题的更小更具体的真理来源。例如，销售团队可能只需要主仓库中的 12 个左右的表，而营销团队可能需要 20 个表。其中一些是相同的，但有些不同。创建这些数据集市的方法与仓库相同。只需使用视图的 SQL（无论是否实现）指向真相的源来创建新的架构。