USQL文件与托管表-数据如何物理存储？

Question

我对ADL和USQL很陌生。我浏览了很多文档和演示文稿，但恐怕我仍然缺少很多答案。

简单一点，我有大量数据（每天递增），但是在一个文件中包含有关许多不同客户端的信息。在大多数情况下，将为一个客户分析数据（一个报告=一个客户），但是我想保留进行跨客户分析的可能性（更不常见的情况）。我知道正确分区此数据的重要性（可能将一个客户端数据保持在一起是最有意义的）。我正在研究两种情况：

1. 我将自己划分数据，方法是将文件拆分为文件夹-文件结构，在这里我可以完全控制文件的完成方式，文件大小等。
2. 我将使用托管表并设置表分区

我现在正在研究这两种情况的利弊。我想到的一些事情是：

1. 在方案1中压缩数据的能力（当然要以性能为代价）
2. 通过使用文件和ADL安全性（例如，仅授予对一个客户数据的访问权限）来建立更精细的安全性模型的能力
3. 另一方面，使用表更舒适，因为我将只处理一个数据源，而不必担心提取正确的文件，而只担心查询中的正确过滤器-理论上，USQL应该这样做其余的
4. 我希望这些表将提供更好的性能

在做出决定之前，我想研究的一个非常重要的因素是在使用表和分区时如何物理存储数据。我已经阅读了文档，但发现一条令我困惑的声明（https://docs.microsoft.com/en-us/u-sql/ddl/tables）：

首先我们可以读到：

“ U-SQL表由文件支持。每个表分区都映射到其自己的文件”-这似乎很合理。我假设如果我按客户端设置分区，那么最终会遇到与自己进行分区相同的情况。太棒了！ U-SQL将为我完成所有工作！或者..不会吗？

后来我们可以看到：

“ ...，并且每个INSERT语句都会添加一个附加文件（除非使用ALTER TABLE REBUILD重建了表）。”

现在，这使事情变得更加复杂。如果我正确阅读它，这意味着如果我永远不会重建表，则我的数据将以与原始原始文件完全相同的方式物理存储，从而会导致性能下降。我做了一些实验，它似乎可以这样工作。不幸的是，我无法将文件与分区匹配，因为引导是不同的（商店中的.ss文件的引导与usql视图中的分区具有不同的引导），所以这只是我的猜测。

因此，我有几个问题：

1. 是否有一些文档详细解释了TABLE REBUILD的工作原理？
2. TABLE REBUILD的性能如何？它会比我只添加（需要->合并所有->输出）仅需要添加的文件的想法更好地工作吗？
3. 如何监视分区的大小？就我而言（正在本地运行，尚未在线检查），即使重新构建（它们适用于数据库，模式和表）后，存储中文件和分区的引导也不匹配
4. 是否有文档更详细地说明.ss文件如何创建？
5. 您会选择哪种情况？为什么？

非常感谢您的帮助，

Jakub

编辑：我做了更多测试，这只会使它更加吸引人。

1. 我抽样了7天的数据
2. 我创建了一个按日期划分的表
3. 我创建了8个分区-每天一个分区+一个默认分区
4. 我从7天导入了数据-结果，在目录中，我得到了（可能）与分区相对应的8个文件
5. 我一次获得了相同文件的导入-结果，在目录中我得到了16个文件（每个导入每个分区1个-完全匹配的文件大小）
6. 请确保我再次执行此操作，并再次获得24个文件（每个导入每个分区1个，大小匹配）
7. 我做了TABLE REBUILD-再次得到8个文件（8个分区）-有意义
8. 我再次导入了文件-最终有16个文件（大小不匹配，所以我猜我有8个文件用于分区，8个文件用于导入-每个分区1个）
9. 我做了TABLE REBUILD-重新整理了8个文件-大小还在增长-仍然有意义，但是...这很有趣
10. 然后我导入了另一个仅包含 2天数据的文件 我最后...不，你没猜到！ -16个文件。所以我得到了8个具有大分区的文件，2个具有新导入功能的较大文件（为期2天）和6个非常小的文件
11. 更感兴趣的是，我运行了TABLE REBUILD
12. 我最终得到了8个文件（每个分区），但是...它们都是最近修改的

结论？如果我没记错的话，无论我刚刚插入什么内容，重建看起来实际上都会触及我的所有文件。如果是这种情况，则意味着随着时间的增长，整个方案将变得越来越昂贵。有谁能解释我错了吗？

Answer 1

Microsoft最近发布了一份名为“ U-SQL Performance Optimization”的白皮书，您应该阅读该白皮书。它包括有关分发，散列，循环和分区的详细说明。