Azure data lake USQL文件与托管表-数据的物理存储方式？

我对ADL和USQL都是新手。我查阅了相当多的文档和演示文稿，但恐怕我仍然缺少许多答案

简化一点，我有一个大的数据集（每天递增），但它在一个文件中包含关于许多不同客户机的信息。在大多数情况下，数据将针对一个客户进行分析（一份报告=一个客户），但我希望保留进行跨客户分析的可能性（不太常见的情况）。我知道正确划分这些数据的重要性（可能将一个客户机数据放在一起最有意义）。我在研究两种情况：

我将通过将文件拆分为文件夹文件结构来对数据进行分区，这样我就可以完全控制数据的处理方式、文件的大小等

我将使用托管表并设置表分区

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

在场景1中压缩数据的能力（当然要以性能为代价）

通过使用文件和ADL安全性（例如，仅允许访问一个客户端的数据）构建更精细的安全模型的能力

另一方面，使用表要舒服得多，因为我将只处理一个数据源，不必担心提取正确的文件，只需担心查询中的正确过滤器——理论上，USQL应该完成其余的工作

我希望这些表能提供更好的性能

在做出决定之前，我想调查的一个非常重要的因素是，在使用表和分区时，数据的物理存储方式。我已经阅读了文档，发现了一条让我困惑的语句（）：

首先，我们可以看到：

“U-SQL表由文件支持。每个表分区都映射到自己的文件”-这似乎很有意义。我会假设，如果我按客户机设置分区，我将得到与自己进行分区相同的场景。好极了U-SQL将为我完成所有工作！或不是吗

稍后我们可以看到：

..，并且每个INSERT语句都会添加一个附加文件（除非使用ALTER table REBUILD重新生成表）

这让事情变得更复杂了。如果我读得正确，这意味着如果我永远不会重建表，我的数据将以与原始原始文件完全相同的方式进行物理存储，因此性能会很差。我做了一些实验，它似乎是这样工作的。不幸的是，我无法将文件与分区匹配，因为guid不同（存储中的.ss文件与usql视图中的分区具有不同的guid），所以这只是我的猜测

因此，我有几个问题：

是否有一些文档更详细地解释了表重建的工作原理

表重建的性能如何？它会比我的想法更好吗？只附加需要附加的文件（extract->union all->output）

如何监视分区的大小？在我的情况下（运行本地，尚未联机检查），存储中的文件和分区的GUID即使在重建后也不匹配（它们对数据库、架构和表都不匹配）

是否有任何文档更详细地解释.ss文件是如何创建的

你会选择哪种情况？为什么

非常感谢你的帮助

雅库布

编辑：我做了更多的测试，这只会让它更有趣

我采集了7天的数据样本

我‌ 创建了一个按日期分区的表

我创建了8个分区-每天一个+一个默认分区

我导入了7天的数据——结果，在目录中，我得到了8个与分区对应的文件（可能）

我一次成功地导入了同一个文件——结果，在目录中我得到了16个文件（每次导入每个分区1个文件——文件的大小完全匹配）

更确切地说，我又做了一次，得到了24个文件（每次导入每个分区1个，大小匹配）

我重新构建了表——最终又得到了8个文件（8个分区）——这很有意义

我再次导入了文件-最终有16个文件（大小不匹配，所以我猜分区有8个文件，导入有8个文件-每个分区1个）

我重新构建了表-重新加载了8个文件-大小仍在增长-仍然有意义，但是。。。这就是有趣的地方

然后我导入了另一个只包含2天数据的文件 我最后。。。不，你没猜到16个文件。所以我得到了8个大分区的文件，2个大文件和2天的新导入，还有6个非常小的文件

更感兴趣的是，我运行了表格重建

我有8个文件（每个分区）但是。。。它们都是最近修改过的

---

结论？如果我没有弄错的话，这看起来重建实际上会触及我所有的文件，不管我刚刚插入了什么。如果是这种情况，这意味着随着数据的增长，整个场景将变得越来越昂贵。有谁能解释我错了吗

微软最近发布了一份名为“”的白皮书，您应该阅读它。它包括关于分发、哈希v循环和分区的详细说明