大表与多表 - 规范化数据

Question

我目前正在开展一个项目，该项目每周收集客户人口统计数据并将增量（来自前几周）存储为新记录。这个过程将包含 160 个变量和几亿人（我的管理层和一家咨询公司需要这样做，尽管大约 100 个变量看似无用）。这些变量将从我们 Teradata 仓库中的 9 个不同的表中收集。

我打算把它分成 2 个表。

1. 包含常用人口统计数据的表格（约 60 个变量来自 3 个表格）
   • 标准化（1 个客户 ID 并为每个人口统计变量添加日期）
2. 具有很少或未使用的人口统计数据的表格（约 100 个变量来自 6 个表格）
   • 标准化（1 个客户 ID 并为每个人口统计变量添加日期）

MVC 用于尽可能多地节省空间，因为它所依赖的数据库由于备份限制而在大小上受到限制。 （请注意，客户 ID 目前消耗表 1 大小的 30% (3.5gb)，因此额外的表会增加存储成本）

将通过查找与分析师选择的日期相关的最新记录来访问表：

SELECT cus_id,demo
    FROM db1.demo_test 
    WHERE (cus_id,add_dt) IN (
        SELECT cus_id, MAX(add_dt) 
            FROM db1.dt_test 
            WHERE add_dt <= '2013-03-01'  -- Analyst selected Point-in-Time Date
         GROUP BY 1)
GROUP BY 1,2

此数据将用于建模目的，因此合理的 SELECT 速度是可以接受的。

1. 这种方法对于存储和查询来说是否合理？
   • 个别表是否太大？
2. 是否有更好的建议方法？
   • 我对进一步拆分的担忧是
     • 由于日期和客户 ID 等不可压缩字段造成的空间
     • 联接 2-3 个表的速度（我怀疑内部联接可能使用很少的资源。）

请原谅我对这件事的无知。我通常使用不会长期存在的大型表（我的职业是数据分析师），或者我为长期数据收集构建的表仅包含少数列。

Answer 1

Rob 的补充说明：

您当前的 PI/分区是什么？

目前的表现是否不尽如人意？

分析师如何访问除时间点之外的任何其他常见条件？

根据您的需要，（prev_dt，add_dt）可能比单个 add_dt 更好。加载的开销更大，但查询可能就像 prev_dt 和 end_dt 之间的 date ... 一样简单。

在 (cus_id) 和 (add_dt) 上的连接索引也可能会有所帮助。

您可以用 RANK 替换 MAX（子查询）（MAX 通常较慢，只有当 cus_id 为 PI 时，RANK 可能会更糟）：

SELECT *
FROM db1.demo_test 
QUALIFY 
  RANK() OVER (PARTITION BY cus_id ORDER BY add_dt DESC) = 1

在 TD14 中，您可以将单个表拆分为列分区表的两个行容器。

...

Answer 2

160 列的表格宽度，稀疏填充不一定是不正确的物理实现（在 3NF 中标准化或略微去标准化）。我还看到不经常访问的属性被移动到 documentation 表的情况。如果您选择在您的物理实现中实现后者，那么每个表共享相同的主索引将符合您的最佳利益。这允许将这些表（60 个属性和 100 个属性）连接到 Teradata 上的 AMP 本地。

如果对表的访问还包括add_dt 列，您可能希望在此列上创建一个分区主索引。这将允许优化器在查询的 WHERE 子句中包含 add_dt 列时消除其他分区的扫描。另一种选择是在add_dt 列上测试按值排序的二级索引 的行为。