我注意到从表中查询时代码工作簿太慢了。它比使用数据仓库中的 SQL 慢得多。快速提取和连接数据以进行迭代分析的正确工作流程是什么？
2 回答
0
正如我在评论中暗示的那样，这很难回答，因为代码工作簿是为交互性设计的，所以它们通常非常快。这并不意味着它们没有理由变慢。我会在这里列出一些，也许它们可以帮助您加快速度：
直接从原始编写代码工作簿可能会很慢！检查支持特定数据集的文件数量和文件类型。原始这些可能是 CSV 文件，而不是可以让您的计算更快的 snappy/parquet。这将导致代码工作簿在您每次尝试迭代时尝试推断模式。
raw -> clean transform在 pyspark 代码存储库中添加一个简单的代码可能会有所帮助。您的数据集可能优化不佳。数据大小的文件太多。这将导致代码工作簿花费大量时间在磁盘上打开每个文件。您可以通过进入数据集详细信息选项卡 -> 文件来验证文件并检查文件的大小。可能值得在您的干净步骤上添加一个重新分区（与上面相同）。这是火花，不是铸造厂在这里阅读更多内容是拥有一个大的镶木地板文件还是许多较小的镶木地板文件更好？
无论您设置的配额如何，您的组织可能没有足够的计算资源，或者您可能有太多人同时使用代码工作簿。这是您需要与您的平台团队或支持渠道确认的内容。
使用 AQE 和本地模式：当我的数据规模较小时，如何在 Palantir Foundry 转换中获得更好的性能？
如果您使用的是 python：不使用 udfs，这些会使您的代码特别慢，特别是当您与 SQL 进行比较时。PySpark UDF 以Spark 函数与 UDF 性能的速度慢而闻名？
于 2022-02-17T07:17:15.030 回答
0
“快速提取和连接数据以进行迭代分析的正确工作流程是什么？”
对于快速的一次性分析，我建议使用 Foundry JDBC/ODBC 驱动程序（安装在本地计算机上）并查询 Foundry SQL Server。请注意，这仅适用于中等数据集结果大小和低查询复杂性。
这将允许您在查询中获得几秒钟而不是几分钟的周转时间。
于 2022-02-17T12:25:01.633 回答