按业务重点与技术层重点进行组织[已关闭]

Question

我们正在为我们的组织建立一个雪花环境。我们正在 Snowflake 中创建第一个数据库，我们可以设计和构建以业务为中心的数据库（信用卡数据库或营销数据库）或以层为中心的数据库（STG、DOMAIN、DATAMART、SHARED 等）。

示例：

我们打算将营销和信用卡数据加载到 Snowflake 中。这可以通过两种方式设计：

最佳技术将根据个人需求和要求确定。

根据实际经验，这两种方法的优缺点是什么？

Answer 1

你永远不会得到正确的结果。我的意思是，如果你有 100% 的源数据，100% 理解输出目标，并且你知道如何获得这些结果，并且你知道所有目标都会得到满足，并且数据或公司中的任何内容都不会改变。 然后你就可以在第一次实现时得到正确的结果。

所以你知道你知道这一切，此时这个问题就是一个拍背练习。或者你知道你不知道所有这些事情，所以你为什么要问，除非你知道你知道你不知道，但你也知道别人不知道，他们不会接受你的答案，所以你是要求我们猜测这个人缺少什么，这样他们就可以从“专家”那里听到它。 或者你不擅长构建东西，所以不知道你不知道东西，并且确实认为它可以正确完成。

普遍接受的计划是找出你的关键需求是什么，并努力实现这些需求，当事情没有按计划展开时（在变化的来源到来时），你可以调用它，解决它，或者设置一个新的计划。目标/目的。

因此，对于我们最初的实现，不会丢失数据（就像之前的供应商产品中发生的那样），因此我们将所有数据保留在 S3 存储桶中。这非常有效，直到世界发生了变化（GDPR），解决这个问题会造成伤害并花费大量成本。但那些年后，额外的成本对于我们已经获得的东西来说是可以接受的。

然后我们还有半结构化数据（一直在变化），因此我们尽可能少地加载到表中。因此，当我们发现情况发生变化时，我们并没有承诺数据丢失。这真的很棒。存储成本稍高一些，但存储成本占我们总账单的 8%，所以不是最大的成本。

我们当时了解我们的数据处理需求，因此推出了我们自己的工具（dbt 之前），并且多年来重写了部分管道，因为我们需要更高的复杂性，以处理新的工作负载，并且随着 Snowflake 推出新功能。老实说，大多数其他人的工具和 Snowflake 功能在首次发布时都不值得更换。但随着 Snowflake 了解客户需求，功能变得更加通用。但即使是现在，我还是更喜欢我们的工具而不是 dbt。但现在不使用工具 X 是否合理，没那么容易。再说一次，从第一天开始，随着时间的推移而改变。

Snowflake 正在改变性能和计费（使它们更加用户友好），因此当这些发生时，我们找到了方法来转移成本以获得更好的结果（账单大小、数据时间、答案的复杂性），现在再次是第一次正确，就在进行实验并发现，如果我们构建像 XYZ 这样的东西，它对于这些工作负载会表现得更好，而这些答案将变得更加重要。

以至于我们第一年年底的年度成本是 低于 5 年后我们每月的费用，我们对此感到非常高兴。因为我们所做的事情比我们最初想象的要多 20 倍。