使用分区键的 SnappyData table 定义
SnappyData table definitions using partition keys
通读文档 (http://snappydatainc.github.io/snappydata/streamingWithSQL/) 并对此项有疑问：
"Reduced shuffling through co-partitioning: With SnappyData, the partitioning key used by the input queue (e.g., for Kafka sources), the stream processor and the underlying store can all be the same. This dramatically reduces the need to shuffle records."
如果我们使用 Kafka 并使用键（单个值）在主题中对数据进行分区。是否可以将这个单个键从 kafka 映射到 snappy table 中标识的多个分区键？
是否有某种哈希将多个密钥转换为单个密钥？
减少改组的好处似乎很重要，并试图了解这里的最佳实践。
谢谢！
使用 DirectKafka 流，每个分区从自己指定的主题中提取数据。如果没有为存储指定分区 table，那么每个 DirectKafka 分区将只放入本地存储桶，然后一切都会很好地排列，而不需要任何额外的东西。唯一需要注意的是足够数量的主题（因此分区）以获得更好的并发性 - 理想情况下至少与集群中的处理器内核总数一样多，因此所有内核都很忙。
显式分区存储 table 时，SnappyData 的存储已调整为使用与 Spark HashPartitioning 相同的散列（对于列和行的 "PARTITION_BY" 选项 tables) 因为那是在 Catalyst SQL 执行层使用的那个。所以执行和存储总是并置的。
然而，将其与从 DirectKafka 分区中摄取对齐将需要一些手动工作（将 kafka 主题分区与 HashPartitioning 对齐，然后让每个 DirectKafka 分区的首选位置与存储相匹配）。将在即将发布的版本中进行简化。
通读文档 (http://snappydatainc.github.io/snappydata/streamingWithSQL/) 并对此项有疑问：
"Reduced shuffling through co-partitioning: With SnappyData, the partitioning key used by the input queue (e.g., for Kafka sources), the stream processor and the underlying store can all be the same. This dramatically reduces the need to shuffle records."
如果我们使用 Kafka 并使用键（单个值）在主题中对数据进行分区。是否可以将这个单个键从 kafka 映射到 snappy table 中标识的多个分区键？
是否有某种哈希将多个密钥转换为单个密钥？
减少改组的好处似乎很重要，并试图了解这里的最佳实践。
谢谢！
使用 DirectKafka 流，每个分区从自己指定的主题中提取数据。如果没有为存储指定分区 table，那么每个 DirectKafka 分区将只放入本地存储桶，然后一切都会很好地排列，而不需要任何额外的东西。唯一需要注意的是足够数量的主题（因此分区）以获得更好的并发性 - 理想情况下至少与集群中的处理器内核总数一样多，因此所有内核都很忙。
显式分区存储 table 时，SnappyData 的存储已调整为使用与 Spark HashPartitioning 相同的散列（对于列和行的 "PARTITION_BY" 选项 tables) 因为那是在 Catalyst SQL 执行层使用的那个。所以执行和存储总是并置的。 然而，将其与从 DirectKafka 分区中摄取对齐将需要一些手动工作（将 kafka 主题分区与 HashPartitioning 对齐，然后让每个 DirectKafka 分区的首选位置与存储相匹配）。将在即将发布的版本中进行简化。