在我在Anaplan的五年以上，传统的观点是，我们应该消除稀疏性以有效地建模。在过去的一年中，作为计划标准计划的一部分，我们一直在重新评估所有现有的最佳实践，技术和稀疏性，并作为该评论的一部分包括在内。在本文（第一部分）中，我将解释什么是稀疏性，以及为什么不应该害怕它。
什么是稀疏？
Anaplan是一个基于持有数据和计算的模块的多维计划平台。这些模块主要由描述数据不同方面的列表（或维度）组成。在大多数情况下，这些模块包含多个列表，使其具有多维。
让我们以以下方式为例。假设我们有一个包含以下维度的模块：
- 顾客
- 产品
- 频道
- 每月2年的每月时间表
如果每个客户在每个频道中均出售每个产品，每个月，我们都会拥有密集的数据。在这种情况下，100％密度。但是，在现实世界中，这种情况极为罕见 - 某些产品很可能仅由某些客户出售，而不是所有渠道或几个月都包含数据点。
在多维范式中，具有零或空数据的是我们定义稀疏度（“差距”）的方式。稀疏数据集（存储在模块中）是比数据或计算的乘积更多的差距。
为什么稀疏性被认为是一个问题？
因此，以上面的示例为例，假设我们为每个维度提供以下项目：
- 100个客户
- 1000种产品
- 10个频道
- 26时间（2 * 12个月 + 2年总计）
使用此组合的单个订单项将需要2600万个单元格（100 * 1000 * 10 * 26）。该表显示了每种数据类型所需的内存量：
- 布尔：1字节= 0.026GB
- 列表，日期，时间：4个字节= 0.104GB
- 数字= 8个字节= 0.208GB
- 文字：8个字节= 0.208GB
这些值与列表格式或文本字符串中的数字有多大的数字或数量是相同的。
Anaplan模块中的大多数数据包含数字，因此您可以看到，当我们在列表中添加更多项目或扩展模型时间表时，模型的大小会大大增加。这是稀疏模块被认为是一个问题的主要原因：它们很大！
从历史上看，稀疏管理积极建模是一项关键技术。当我们通过更深入的分析发展思维，并更好地了解客户使用Anaplan平台的方式时，我们摆脱了使模型尺寸尽可能小以减少工作空间使用情况的方法。
在实践中，这意味着模型者不是通过组合数据集中存在的有效组合的列表来创建新结构，而不是创建许多稀疏性的模块。由此产生的层次结构有许多名称 - 构成，编号，连接和组合 - 但结果是相同的，看起来像这样：
客户1
- 产品1
- 频道1
- 频道3
- 产品2
- 频道5
- 频道2
- 产品3
- 频道4
- 频道10
客户2
- 产品4
- 频道7
- 频道9
- 产品5
- 频道6
- 频道8
这种方法导致细胞计数要小得多，因为所得模块现在仅包含两个维度（组合的层次结构列表和时间）。该组合层次结构是密集的，因为仅存在有效的组合，并且消除了大多数零值（尽管在一个月维度中可能仍然有一点稀疏性）。这是减少模型大小的有效技术，但确实带有一些问题，我将介绍一下第二部分本文。
但是首先，让我消除与稀疏相关的其他一些神话。
误解1-模型越大，它会执行的越差
这是完全不真实的。是的，模型越大，它将包含的数据越多，但是大小和性能之间没有直接相关性。模型的性能基于模型的设计和计算结构，而不仅仅是大小。为了给您一些背景，我们在该领域看到的最糟糕的模型的大小小于1GB，但花费了三十分钟以上。我们有许多型号超过100GB，并且在两分钟内开放。精心设计的模型会大规模执行。
误解2 -稀疏模块效率低下
我会部分同意这一点，但仅与模块大小有关（请参阅误解3）。在计算方面，稀疏模块效率不高。Anaplan的发动机（Hyperblock）旨在与多维结构一起使用。在核心上，定向的无环图（D.A.G.）索引数据以计算上游数据点发生变化时所需的内容。因此，一旦模型打开并进行了完整的计算，此后的计算非常有效。Anaplan不会重新计算零，因为无事可做。什么也没有变。
误解3 -多维模块总是比具有组合层次列表的模块大
这与我之前提到的技术有关。这不像前两个点那样黑白，但是在某些情况下，这个前提是完全错误的。让我给你一个榜样。
处理交易数据的长期技术之一是将所有“维度”组合为单一输入或交易列表。使用一个唯一的密钥，其中包括时间段（例如一个月），记录是在一维模块中导入并存储在Anaplan中的单行。最终的模块看起来像这样：
模块和结构是100％密度的；干得好！好吧，不。
我们通过从密钥中删除时间尺度并将时间添加为数据模块中的维度来研究将数据存储在二维模块中的影响。结果令人惊讶！
看看数据的大小：
- 按月的2年数据
- 3个要创建独特性的元素
- 80％稀疏
- 模型1使用了包括日期的交易键
- 模型2是多维的，随时间为维度
您会看到，Model 2不仅比模型1的开放速度超过90％，而且还小于75％以上。考虑到稀疏的多维模块比密集模块占用更多的空间，这怎么可能？好吧，原因是列表项目本身也构成了模型大小的一部分。在讨论单元格计算时，我没有提到它，因为列表不会添加到单元格数本身，但是每个列表项目都使用500B，因此列表越大，使用的空间就越多。
查看两个模型中每个唯一交易列表的大小。从密钥中删除日期导致仅创建了300K唯一的交易，而不是73m。反过来，这导致了较小的交易明细模块。稀疏模块比大型密集模块更有效地计算出来，并且与较小的列表相结合，我们看到了改进的模型开放时间。
加入我第二部分，我将讨论多维结构与组合层次结构的利弊。