我遇到了以下问题，我侦察是相当典型的。
我有一些大数据，比如几百万行。我对其进行了一些重要的分析，例如一个由几个子查询组成的 SQL 查询。我得到了一些结果，例如，属性 X 随着时间的推移而增加。
现在，有两种可能的情况会导致这种情况：
我如何测试第一次发生，而不是第二次？一个逐步调试器，即使存在，也无济于事，因为中间结果仍然可能包含数百万行。
我唯一能想到的就是以某种方式生成一个带有我想要测试的属性的小型合成数据集，并作为单元测试对其进行分析。有没有工具可以做到这一点？特别是但不限于 SQL。
这是一个建议：
这是我通常做的 - 占用最重要的变量（基于您的业务理解和假设 - 您可以随时修改它），对这些属性进行分组以减少行数，然后可以将其导入到 Pivot 中。您应该在每一行中包含相关指标的总和和计数。
确保您没有在上一步中放置任何过滤器。在汇总级别获得完整数据后，您可以在数据透视表中进行操作，看看哪些事情正在发生变化/增加或减少。
如果数据太大而无法在重要参数上进行汇总，则需要将其划分为 3 - 4 个子集，然后再次执行此操作。
希望能帮助到你。
首先，您需要验证您的算法实现是否准确。为此，请使用少量数据样本并检查结果是否正确。在这个阶段，样本不需要代表总体。
验证实施后，您需要验证您尝试预测的变量之间是否存在显着关系。为此，请定义零假设并尝试以显着的置信水平拒绝零假设。（线性回归的假设检验）
您的 SQL 发行版可能有单元测试框架。但是使用像 R 这样的编程语言会更容易实现。
我喜欢多步骤策略：
编写简洁易懂的代码，而不是短小复杂的代码。我知道统计学家喜欢棘手的代码，但在棘手的代码中发现问题是危险的。（我之所以提到这一点，是因为我的一位主管喜欢无证的 500 行 python 脚本——调试这些混乱的东西很有趣，我已经看到了很多这种模式，尤其是来自非 IT 背景的人）
将您的代码分解为更小的函数，这些函数可以在更小的 stes 中进行测试和评估。
寻找连接的元素，例如条件 X 为 Y 的情况数 - 所以这个查询必须返回 Y。通常这更复杂，但可行。
当你第一次运行你的脚本时，用一个小的子样本测试它，并仔细检查一切是否正常。虽然我喜欢 IT 中的单元测试，但统计脚本中的错误通常非常明显，以至于在仔细检查时很容易看到它们。或者它们是有条不紊的错误，可能永远不会被单元测试捕获。
这应该足以确保一个干净的“一次性”工作。但是对于您似乎拥有的时间序列，我要补充一点，您应该检查超出范围的值、不可能的组合等。对我来说，大多数已达到第 4 步的脚本可能没有错误 - 除非有什么变化。最常见的是，数据在变化——这是每次运行都应该检查的东西。为此编写代码既费时又烦人，但它克服了由于数据输入错误而导致的细微错误。