企业官网建设流程全解析

原文：towardsdatascience.com/top-5-principles-for-building-user-friendly-data-tables-0dfe168cecc1

在数据科学和数据分析领域工作了七年，我创建和查询了许多表格。有很多次我 wonder，“这个列代表什么？” “为什么在表 A 和表 B 中有两个同名的列？我应该使用哪一个？” "这个表格的粒度是什么？"等等。

如果你遇到过同样的挫折，这篇文章就是为你准备的！

在本文中，我将分享五个原则，这些原则将帮助您创建同事们会欣赏的表格。请注意，这是从数据科学家的角度写的。因此，它不会涵盖传统的数据库设计最佳实践，而是专注于制作用户友好型表格的策略。

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/179c361aa717cefc4f27e4affcdc4209.png

由 DALL·E 创建的图像

I. 单一真实来源

维护每个关键数据点或指标的单一真实来源对于报告和分析非常重要。多个表格中不应有任何重复的逻辑。

为了方便起见，有时我们在多个表格中计算相同的指标。例如，总商品价值 (GMV)的计算可能存在于客户表、月度财务报告表、商家表等。然后，这些列在更多下游表格中引用，并且有更多变化。随着时间的推移，它们可能会出现分歧。一切都很顺利，直到有一天，一个利益相关者来问我们：“为什么这个仪表板中的月度 GMV 与其他的不同？你们的数据错了吗？”当我们深入挖掘数据管道的层层时，我们意识到上个季度我们同意只将已清算的交易包括在 GMV 中，但忘记在每个表中做出更改……这伤害了利益相关者的信任，我们最终会花费越来越多的时间调查和维护复杂的数据模型。

那么，如何解决这个问题呢？在专用表中维护 GMV 计算的单一版本。然后，每个需要 GMV 指标的表格都应该使用这个表格，而不是创建自己的计算逻辑。

禁忌:

• 在不同的表格中保持同一计算的不同版本。

做法:

• 维护每个关键指标的一个版本。

• 在下游表格中引用该真实来源的表格，而不是在各个地方重复逻辑。

II. 一致的粒度

如果表格是按日级别，请保持其按日。在单个表格中混合不同粒度的数据可能导致混淆和数据完整性问题。

这是我真实的例子：我曾经创建了一个表来报告运营服务级别协议（SLA）的性能——我们为不同的运营工作流程定义了 SLA，我们想跟踪我们能够达到 SLA 的频率。SLA 在两个级别上定义：接触点级别（每次交互）和案件级别（整个流程）——一个案件可能会有来回，并且被运营团队的多个人接触。我们希望每个接触点在特定的时间限制内完成，整个案件在时间范围内解决。我认为将一个表直接导入 BI 工具进行报告要容易得多，所以我创建了一个混合两个粒度的表。它有一个名为sla_level的列，有两个值touchpoint和case。我希望能有人根据特定的 SLA 级别进行筛选，以获取他们需要的指标。

为什么这有问题？并不是每个人都了解我刚才解释的上下文。他们通常不会在报告中包含这个过滤器，结果导致一个案件被重复计算，因为它会在案件级别和接触点级别都出现。

我本应该怎么做呢？创建两个表，一个在接触点级别，另一个在案件级别，在表文档中清楚地解释它们之间的差异，并且只为不同的用例使用适当的表。

不要做：

• 在同一个表中混合不同粒度的行或列。这可能导致你的数据被误用和错误的分析。

应该做：

• 每个表中只应有一种粒度类型。

III. 描述性命名约定

我必须承认，我创建了名为txn_temp、tnx_temp_v2、tnx_subset_v3、txn_final的临时表🙂 在你的探索性代码中保留它们是可以的（只要你在回顾时能记住它们代表什么……）。但如果你打算与你的同事分享它们或在官方数据管道中使用它们，你应该给它们更直观的名称。例如，txn_subset_v3应该像refund_transactions这样，清楚地解释了subset是什么，并明确地写出了transactions而不是txn。

同样的原则也适用于列名。这昨天就发生在我身上——我正在查询每月创建的案件数量，我执行了SELECT DATE_TRUNC('month', created_at) AS created_month, COUNT(DISTINCT case_id) FROM cases GROUP BY 1 ORDER BY 1。然后我得到了'created_at' does not exsits错误……仔细一看，我发现时间戳列被命名为created_date，尽管它实际上是日期时间类型。更糟糕的是，不同的表中类似的列可能是created_at、created_time或created_date。

另一个例子是我们有时会添加一个由row_number()窗口函数创建的列，以便轻松查询表中分区的前一个或最后一个发生。我多次看到人们只是将列名留为rn。嗯……现在？实数？注册护士？即使你知道它代表 row_number，你仍然需要查找底层的 SQL 代码来理解分区是什么以及顺序如何。因此，如果你确实需要在最终表中保留此列，请将其命名为描述性的，例如row_num_by_customer_order_date_asc。这是一个更长的名称，但在我看来，较长的名称比简短但容易混淆的名称更好。

在表格中保持一致的命名约定也会很有帮助。例如，所有客户级别的表格都可以使用customer_前缀命名，因此你有customer_demographics、customer_status、customer_signup_information等。

DON’Ts:

• 命名为xxx_temp、xxx_v1、xxx_final的表格。

• 表格或列名中的非常规/混淆的缩写。

• 同一级别和主题的表格但命名非常不同（例如customer_demographics和status_of_customer）。

DOs:

• 清晰、描述性、直观的表和列名——较长的名称比简短但容易混淆的名称更好。

• 表格中列名的一致命名约定。

IV. 合适的数据类型和格式

当谈到直观的表格时，不仅需要描述性的表和列名，还需要合适的数据类型和格式。

让我给你举一些例子：

1. 假设我们在不同的表格中都有country字段，例如客户所在的国家、交易的商家国家、账单地址国家等。然而，其中一些是完整的国家名称（United Stated），一些是两位数的国家代码（US），还有一些是小写（us）。然后，你将构建一个欺诈检测模型，你想要创建一个特征来判定商家国家是否与客户的账单地址国家相同。理想情况下，这可以通过简单的连接来完成，但在这个情况下，你必须检查两个列中的所有国家值是否一致。结果，你需要清理大量值并找到一些国家名称到两位数国家代码的映射来连接两个表格。这是一个非常容易出错的过程。

2. 我们都喜欢二进制列——当我们需要根据某些常见段进行筛选时，它们非常有用。然而，我在这里看到它们既有TRUE/FALSE格式，也有1/0格式。更糟糕的是？有时1/0是整数类型，有时是字符串……显然，将它们都保持为TRUE/FALSE格式会更好。

3. 对于所有像transaction_amount、delivery_fee或product_price这样的货币价值字段，它们也应该使用一致的单位。如果其中一些是以美元计价，而另一些是以分计价，你就可以轻松地计算出 100 倍或更高的利润，或者声称一笔盈利的交易实际上是亏损的。

不应该做的：

• 对于相似列，应使用不同的数据类型或格式。

应该做的：

• 使用适当的数据类型。例如，始终使用TRUE/FALSE布尔值表示二进制列；xx_time列始终使用日期时间格式，而xx_date列应使用日期格式。

• 保持一致的格式。例如，所有的country字段都使用两位数的国家代码，所有与金钱相关的字段都使用美元。

V. 完整的文档

最后但同样重要的是，一个好的表格总是伴随着完整的表格文档。好的文档确保了使用表格的每个人都会理解它的用途并适当使用它。

然而，什么是“完整的表格文档”却是一个单独的话题，可能值得一篇单独的文章。但根据我的观点，以下是关键组成部分：

1. 表格描述：这个表格的目的是什么？数据主题是什么？人们应该在什么时候使用这个表格？表格的粒度是什么？用户应该注意的任何警告？

2. 列文档：每列的数据类型和含义。如果某列有复杂的计算逻辑，解释该逻辑也很重要。

3. 数据源：数据从哪里来？在理想状态下，数据用户应该能够轻松地探索数据血缘，以便理解上游表和列。当我们需要调试数据问题或度量变化时，这非常有帮助。

4. 频率和新鲜度：表格多久更新一次，最后一次更新是什么时候？

不应该做的：

• 创建没有文档或不完整信息的表格；

• 当更新表格逻辑时，不要使文档过时。

应该做的：

• 总是保持表格文档的完整性和最新性。

这些是我制作对数据同事友好的表格的五大原则。遵循它们，数据调查将更快，分析将更简单，模型将更准确。

你还想在列表中添加其他内容吗？请在下面评论！

如果你喜欢这篇文章，请关注我并查看我关于数据科学、分析和 AI 的其他文章。

超越线形图和柱状图：7 种不常见但强大的可视化类型

机器学习中数据泄露的七个常见原因

精通 SQL 优化：从功能性到高效查询