我们使用循环分配方案在ADL表中插入数据 . 在另一项工作中，我们从表中提取三个不同分区的数据，并观察到分区的顶点数量不均匀 . 例如，在一个分区中，它为264 GB数据创建56个顶点，在另一个分区中，它为209 GB数据创建2个顶点 . 具有少量顶点的分区花费了大量时间来完成 . 在附图中，我不确定为什么SV5和SV3只有2个顶点 . 有没有办法优化这个并增加这些分区的顶点数？
这是表的脚本：
CREATE TABLE IF NOT EXISTS dbo.<tablename>
(
abc string,
def string,
<Other columns>
xyz int,
INDEX clx_abc_def CLUSTERED(abc, def ASC)
)
PARTITIONED BY (xyz)
DISTRIBUTED BY ROUND ROBIN;
Update:
这是一个数据插入脚本：
INSERT INTO dbo.<tablename>
(
abc,
def,
<Other columns>
xyz
)
ON INTEGRITY VIOLATION IGNORE
SELECT *
FROM @logs;
我在分区中执行多个（最多3个）插入 . 但在另一项工作中，我也在选择数据，进行一些处理，截断分区，然后将数据插回分区 . 我想知道为什么Round Robin的默认分配方案只为SV5和SV3创建2个发行版？我希望能为这一数量的数据提供更多的分配 .
2 回答
鉴于您以不同的方式插入，有时候看起来像是在插入SV1正在读取的数据的脚本中，这些脚本得到了很好的估计，而其他脚本则导致U-SQL做得非常糟糕 . 当您使用循环法但未指定分发时，U-SQL将根据编译时估计的数据大小为您选择一个 . 对于HASH和DIRECT HASH也是如此 . 对此最坚如磐石的缓解是，只要您非常了解所需的分布，就可以使用INTO子句指定分发数量 . 50-200的任何东西看起来都会让你处于最佳状态 .
我看到你在分区内使用分区和分发 .
您是否将所有数据一次性插入到分区中，或者每个分区有多个
INSERT语句？如果是后者，请注意每个
INSERT语句都会向分区添加一个新文件，然后由它自己的顶点进行处理 .此外，
ROUND ROBIN分布单独应用于每个分区文件 .因此，最终可能会提取大量已提取的通讯组 .
如果我对您的方案的解释是正确的，请使用
ALTER TABLE REBUILD来压缩分区 .