当你将地理空间功能嵌入通用数据工具时，会发生什么？更多人开始使用地理数据。
我刚从首届 云原生地理空间大会 回来。这次会议非常精彩，如果 Jed 和团队再次举办，我强烈推荐你参加。
在分组讨论和走廊交流中，一个核心问题是如何扩大地理空间技术的受众群体。如何更好地向各行各业和领域传达地理数据的实用性？虽然讨论了许多策略和案例研究，但我反复想到的还是 DuckDB。
这张图表本可能非常黯淡！对“地理空间”(作为类似术语的良好替代词)的兴趣持续下降并趋于平缓，直至2023年底——恰逢DuckDB发布其空间扩展功能。
当然，关于相关性和因果关系的标准保留意见仍然适用，但我倾向于相信这张图表。
DuckDB将处理地理数据的门槛降低到仅需两行代码：
install spatial;
load spatial;
如果扩展已安装，只需一行代码。
在此之前，从冷启动开始运行可能需要安装甚至编译多个开源软件包，仔细记录路径位置，搭建专用数据库……工作量之大，可能让数据通用人员望而却步，或其 IT 部门不予支持。
借助 DuckDB 空间扩展，非专业人士进行地理空间工作成为可能。这一切均在 SQL 环境中完成……这使得生态系统得以扩展。
在云原生地理空间大会的会议间隙，我讨论了空间扩展和这张图表，不禁思考：如果没有DuckDB空间功能，Overture Maps Foundation 是否能达到今天的应用规模？也许……但可能性不大。
我期待帮助图表末尾的增长曲线继续向上延伸。
更新：
Hacker News上正在就此展开一场精彩讨论，DuckDB团队的Max也分享了他的观点：
我认为关键在于DuckDB的空间扩展通过静态打包所有内容(包括将默认的PROJ坐标投影系统数据库内联到二进制文件中)，并为多个平台(包括WASM)提供支持，从而为一系列标准开源GIS软件包提供了SQL接口。也就是说，除了libc外，没有其他依赖关系。
没错，DuckDB 确实做了很多事情，包括向量化内存外执行、列式压缩存储，以及一系列其他扩展，使其功能远超各部分之和。但尽管我一直在努力提升空间扩展的性能和通用性(今年我设计了新的几何引擎，空间连接优化刚合并到开发分支)， 但用户能够通过利用 GDAL、通过 SQL 转换，或下载最新 Overture 数据集，在不破坏整个工作流的情况下，轻松转换多种地理空间格式，这一特性很可能成为早期采用者的核心卖点。
我非常感激他的团队承担了这些复杂性，以便将它们从用户体验中移除。
我是DuckDB的忠实粉丝，主要从事地理空间分析工作，包括地理区域划分(如Uber H3六边形)、计算Haversine距离、计算几何图形面积、确定点所属的几何图形等。这些功能在geopandas或postgis中以某种形式已经存在，因此DuckDB的空间扩展并未带来全新功能。
但作为引擎，DuckDB的优势在于它允许我在本地桌面上直接处理大规模的Parquet/Geoparquet文件(向量化和并行化)。在这方面，它优于geopandas。这无疑是一项提升工作效率的改进。
DuckDB还拥有一个扩展架构，支持更复杂的地理空间功能，如希尔伯特曲线和Uber H3支持。
https://duckdb.org/docs/stable/extensions/spatial/functions….
https://duckdb.org/community_extensions/extensions/h3.html
我完全同意这一点。对我来说，使用 DuckDB 处理随机数据集时，其用户体验提升非常显著。我发现使用DuckDB探索数据集比使用Pandas、Postgres或Databricks要容易得多。
空间功能在我上次进行大量地理空间工作时刚刚推出，但即使在那时，它们也非常出色。
顺便说一句，我有一个初级员工会将数据集加载到PowerBI中进行首次探索，而这实际上是一个令人惊讶的有用工作流程。
Pandas 非常出色，曾是我长期依赖的工具，但使用 Pandas 时我经常遇到内存问题和规模扩展问题，而这些问题在使用 Polars 或 DuckDB 时从未出现过。我不确定现在是否仍然如此，因为我知道这些工具已经进行了更新，但当时确实存在这些问题。使用 Geopandas 时也遇到了相同的问题。
直接使用GDAL和其他库的体验实在不佳。如果你有QGIS(另一个优秀的工具)的工作流程，切换到Jupyter笔记本进行转换会让人感到沮丧，但那似乎是最好的选择。
总体而言，地理空间分析似乎比常规数据分析落后了大约10年。shapefile格式因ESRI的 dominance 而普遍使用，但坦率地说这不是一个理想的格式。PostGIS很棒，geopandas也很棒，但数据生态系统中远不止Postgres和pandas。几年前PowerBI几乎没有地理空间支持。我认为PowerBI的Shapemaps仅使用TopoJSON？
所有这些都是为了说明，DuckDB的地理空间功能非常酷且实用。
> 附带一提，我曾有一位初级员工会直接将数据集加载到PowerBI中进行首次探索，这种工作流程实际上非常实用。
与DuckDB相比，PowerBI在哪些方面特别实用？
图形展示。优秀的BI工具本质上是高效的探索性数据分析工具。
为什么你使用haver-sine而不是地心投影或重新投影？
我之前在项目中一直使用重新投影，将坐标投影到“本地”CRS，主要是因为geopandas推荐并围绕此构建，但现在我希望计算全球范围内物体的距离，我真的很想知道这里有什么好的选择。
我只是个应用程序开发者，不是地理空间专家，但重投影似乎应该由库在后台处理，除非有特定需求。我习惯了像PostGIS的
ST_Distance(geography point1, geography point2)这样的操作，它会以米为单位给出正确答案。如果你需要更快的距离计算，可以轻松切换到球面或笛卡尔距离。ST_Area(geography geog)，它会给你形状在地球上任何位置的面积，单位是平方米。“正确答案”会因应用场景和分析师而异。这就是为什么存在如此多的坐标参考系统。如果你将所有数据保存在 3857 坐标系中，你将得到以米为单位的答案，但这是否“正确”取决于距离或几何对象的位置、大小以及你的精度阈值。因此，实际上，每个人的需求必然是“特定的”。
可以参考Vincenty [1]或Karney(更稳健的解决方案)[2]。Vincenty对于大多数应用场景应已足够。
[1] https://en.wikipedia.org/wiki/Vincenty's_formulae
[2] https://github.com/pbrod/karney
重投影在局部范围内准确，但在大规模应用时不准确。
测地线是最准确的(Vincenty 等)，但计算量较大。
Haversine 是一个不错的折中方案。
但它在大规模应用时真的不准确吗？
我明白绘制投影时会存在比例失真，但如果我将所有计算都以赤道上0,0点为基准，以米为单位计算南北和东西方向的距离，难道所有距离计算不会都是准确的吗？
比如，5,000,000米东偏和0米北偏，距离原点就是5,000公里。我看不出来随着距离增加，这种计算方式会变得不准确。
不准确性是从哪里引入的？当我将投影重新转换回地球上的坐标时？
顺便说一句，你可以将你的评论输入ChatGPT，它会给你一个合理的答案。简短的回答是：失真。
仅从希尔伯特参考来看，我好奇为何没有一个函数能根据给定的精度级别，返回曲线上包含对应空间子矩形的线段集合。这种功能是否被封装在其他地方？
> 此前，从冷启动开始运行可能需要安装甚至编译多个开源软件包，仔细记录路径位置，搭建专用数据库……工作量之大，可能让数据通用人员不愿动手，或其IT部门也不支持。
我已经能够“CREATE EXTENSION postgis;”超过十年了。PG、MySQL、Oracle、MS SQL Server 和 SQLite 很久以前就有空间扩展。DuckDB 在安装难度上没有实质性差异。
这需要数据已经存在于 Postgres 中，否则你需要先将数据 ETL 到其中。
而DuckDB可以直接处理现有数据(Parquet、TSV、SQLite、Postgres等，无论是在磁盘、S3等位置)，无需ETL步骤(尽管如果数据尚未以列式格式存储，速度会较慢……但仍可正常工作)。
我直接使用 Parquet 数据，无需 ETL 步骤。我可以在 Jupyter 或 Python REPL 中直接执行 duckdb.query(“from ‘*.parquet’”)
如果我理解有误，请纠正我，但我认为这在 PostGIS 中是不可能实现的。(即使 pg_parquet 需要复制数据？[1])
[1] https://www.crunchydata.com/blog/pg_parquet-an-extension-to-…
是的，如果你想使用GeoParquet，并且希望将数据保存在该格式中。我能理解你的例子这样做更方便。但大多数地理空间数据并非采用这种格式。你可能有shapefile、geopackage、geojson等格式，谁知道呢？从QGIS到ESRI，有大量软件支持不同格式以解决不同问题。我认为GeoParquet，尽管可能是目前最快的地理空间矢量数据格式，但并不常见，而且文章也没有声称它是。因此，对于一个普通用户试图回答一些GIS问题来说，一些ETL是不可避免的。考虑到这一点，安装PostGIS和安装DuckDB都需要一些ETL，以及学习一些查询和分析语言。DuckDB 可能是一种改进，但它绝不是像引用中所描述的那样是一个巨大的飞跃。
来自 DuckDB 地理空间文档：
SELECT * FROM ‘./path/to/some/shapefile/dataset.shp’;
COPY table TO ‘some/file/path/filename.geojson’ WITH (FORMAT gdal, DRIVER ‘GeoJSON’, LAYER_CREATION_OPTIONS ‘WRITE_BBOX=YES’);
这对我来说非常有用。
而 ogr2ogr 也很有用：
ogr2ogr -f “PostgreSQL” -t_srs “EPSG:2274” PG:“host=host user=user dbname=database password=trustno1 schemas=schema” shapefile.shp -nln new_name_for_table
我将尝试使用DuckDB并将其与PostGIS进行比较。最终，我认为我的问题在于，我通过连接到同一数据库的应用程序使用所有矢量输出。
是的，这是DuckDB的一个质量问题示例：尽管它可以在其他情况下通配文件，但它传递参数给GDAL的方式意味着通配符会被字面解释而不是展开。因此我无法查询包含三千万个 GeoJSON 文件的目录。而在 geopandas 中这不是问题，因为 ipython 作为完整的交互式开发环境，允许我以任意方式生成通配符。
我认为这是 SQL 模式的根本问题。你可以尝试让事情正常工作，但一旦出错该怎么办？
我认为这是因为它尚未在空间模块中实现。DuckDB目前正在对批量处理/扫描/合并多个文件的方式进行重大重构，这与近期对数据湖格式的关注密切相关，但我的计划是在下个版本发布后，待该部分代码稳定后再着手处理空间模块的实现。
> SQL模式的根本问题。
SQL是一种领域特定语言(DSL)，而所有领域特定语言只能实现引擎解析DSL所支持的功能。
但据我所知，所有 SQL 数据库都允许你编写自定义扩展，这些扩展正是如此：它们通过新的范式扩展了数据库的基本功能。例如，PostGIS 使 PostgreSQL 支持地理空间功能，或那些启用模糊匹配/搜索的扩展。
由于 SQL 基本上是一个图灵完备的领域特定语言(DSL)，几乎没有什么事情是它做不到的，即使语法可能不适合所有人。
你可以使用DuckDB在IPython中解决通配符问题。这样你就不用担心使用Geopandas时出现内存不足的问题。
没错。先加载到Postgres，然后查询。Duck的独特卖点就像将8个常见工具/功能整合到一个平台下。
原文读起来就像另一篇DuckDB的营销文章，从夸张的赞美到标题中毫无根据的声明
简单的安装优势被夸大了，我认为真正重点是云原生集成和极高的可扩展性
我测试了Spatialite，它运行正常，但插入数据时的设置过程有点繁琐。
“import geopandas”也存在且已存在一段时间。撇开调侃不谈，DuckDB的特殊之处何在？我希望作者能展示一些实际示例，以便我更好地理解他们的主张。
我回复了另一个评论，但我认为关键在于duckDB的空间扩展通过静态打包所有内容(包括将默认的PROJ坐标投影系统数据库内联到二进制文件中)，为多个平台(包括WASM)提供了一个SQL接口，访问一整套标准的开源GIS软件包。也就是说，除了libc之外，没有其他依赖关系。
是的，DuckDB 做了很多其他事情，包括向量化大于内存的执行、列式压缩存储以及其他扩展生态系统，使其超越了各部分的总和。但尽管我一直在努力使空间扩展更加高效和广泛适用(今年我设计了一个新的几何引擎，空间连接优化刚刚合并到开发分支)， 但您可通过利用 GDAL 转换、SQL 转换，或下载最新 Overture 数据集，而无需因更新 QGIS 导致整个工作流程中断，这一特性很可能成为早期采用者的核心卖点。
(免责声明：我参与了duckdb-spatial @ duckdblabs的开发)
我不是原帖作者，但感谢您如此详细的解答。您提到的集成和降低使用门槛的优势，与我在其他领域工具使用中的体验高度契合，您的解释让这些关联变得清晰。
这是基于@maxxen工作的一个示例——由于DuckDB(+空间扩展)可以编译为Wasm，我构建了一个基于浏览器的Shapefile到CSV转换工具：https://www.honeycombmaps.com/tools/shapefile-to-csv-convert…
这是一个非常优秀的回复，正是我希望文章能达到的效果，感谢！
哦，是的，文章在“2 行代码即可安装”之后突然结束了
如果我只关心存储和操作经纬度数据，使用 GeoParquet 而不是直接使用 Parquet 是否有强烈的理由？
我很好奇它是否能更好地压缩数据，或者有其他优势。我看到很多人在网上说它压缩效果很好(但主要是与.shp等格式相比)，而普通Parquet(如.gz.parquet或.snappy.parquet)已经做得非常出色。因此，我不确定是否值得花时间去研究它……
目前我主要使用Spark处理普通Parquet，有时也会用ClickHouse。
根据我对GeoParquet规范的理解，主要区别在于几何数据使用Parquet的字节数组类型以WKB格式存储。字节数组可以进行增量编码。此外还存储了一些额外元数据，如坐标参考系统(CRS)和边界框。
当使用EPSG:4326经纬度时，我认为GeoParquet相较于单独的列存储并不会带来任何优势(这是我通常的做法，且速度已经足够快)。
如果你使用范围查询来分批获取Parquet文件的某些部分，你可以考虑使用希尔伯特曲线对数据进行排序，这可能限制需要获取的行组数量以执行查询。
> 其中一个重要原因是，duckdbs的空间扩展通过静态打包所有内容(包括将默认的PROJ坐标投影系统数据库内联到二进制文件中)并提供多平台支持(包括WASM)，为一整套标准开源GIS软件包提供了SQL接口。也就是说，除了libc外，没有其他传递依赖关系。
过去二十年，而非十年，PostGIS 始终在开创这一领域，并让 everyone 逐渐适应。在 GIS 领域，DuckDB 甚至鲜为人知。我甚至不确定QGIS是否能连接到DuckDB，或许它能连接一段时间，但它确实长期支持Spatialite，而且最后但同样重要的是——ESRI肯定还没听说过DuckDB。这已经占了地理空间世界的一半。
这整篇文章都极度偏颇，令人遗憾。
实际上，他们确实支持https://www.esri.com/arcgis-blog/products/arcgis-pro/announc…
我错过它并不奇怪，3.4版本直到2024年11月25日才发布，以ESRI的标准来看，这几乎就是昨天的事。考虑到新版本的价格和采用速度(注：许多政府机构仍使用10.x/11.x分支)。
这并不改变我之前的观点，即没有人对DuckDB感兴趣太久，而整个服务器端处理理念主要基于PostGIS。
作为一个对DuckDB不熟悉但至少对地理空间工具有些了解的人(虽然已经有好几年了)：天啊，这真是太酷了。整个ETL流程一直是最头疼的部分，即使使用专业的商业工具也是如此，而一个稳定、一体化、即插即用的层级设计确实极具吸引力。
只是文章作者在标题上大肆渲染时，或许应该至少提一下这一点(嘿，读完这篇文章后，或许这个标题确实有道理！ 🙂 )。
重新阅读这篇文章，它专注于一个并非亮点(安装本身)的部分，我禁不住发笑并想“这是有史以来最糟糕的销售宣传”。 😉
我一直在研究DuckDB——虽然它有许多技术优势，但我认为主要卖点将是易用性。它结合了SQLite的运营优势，同时具备强大的可扩展性和简洁的文档。
从事DevOps工作的人对糟糕的SaaS供应商或过时的开源选项感到沮丧，这些选项的设置成本很高。DuckDB是一个成熟的项目，提供了一种替代方案，因此在业余爱好者中很容易成为热门选择(我认为在规模化后，机会成本会发生变化，它变得不太吸引人)。
DevOps 人员对它的采用情况如何？
我仍然收到反馈，许多开发人员对阅读和编写 SQL 并不太熟悉。他们在学校学习了简单的 SELECT 语句，但对 JOIN 和 GROUP BY 感到困惑。
随口一说：他们应该提升 SQL 技能。不需要掌握 9 个 JOIN、GROUP BY 和 HAVING 等高级技巧，但至少要掌握两个 JOIN 和 GROUP。如果已经理解 3NF，那么 JOIN 等操作只需两周就能掌握。
我更倾向于选择这个方案，而非走 DuckDB 的道路。
它不适合许多存储工作负载，因为它只允许单个进程写入。例如，你不会希望20个应用服务器将日志、指标或跟踪写入单个DuckDB实例。相反，你应该让它们写入轮换日志文件，这些文件以某种方式聚合后，通过Grafana等工具查询DuckDB。
因此，将其作为轻量级数据科学工具使用，在地理空间等特定工作负载方面表现更出色，可以节省更多运营成本。无论您需要在何处进行这些计算，它都能发挥出色的性能。
我并不认为 sql 是一项必须掌握的开发运营技能，但数据库的基本知识当然是必不可少的。在在线内容和大语言模型(LLMs)之间，只要您能够通过解释分析等方法逐步改进查询，就足够了。
DuckDB 可以被视为分析引擎而非存储引擎。它是 OLAP 而非 OLTP。
从什么时候开始，强大的 SQL 知识不再是开发者的核心技能？我猜这是前端与后端专业化趋势导致的？
我不知道它是否曾经是核心技能。你可以问任何开发者。许多人告诉我，SQL 不是他们每天都会使用的东西，所以即使他们学过，通常也会很快忘记。
SQL 已经深深植根于我的肌肉记忆中，因为我从事基于大型数据集的机器学习模型工作。我花了大量时间通过试错才掌握了 SQL。我猜大多数开发者缺乏练习机会，因为他们的工作很少涉及SQL。
现在再深入学习SQL已无意义，AI助手已基本解决了SQL查询问题。只需用自然语言提出需求即可。
我并不完全认同。
SQL 查询是正确性至关重要的领域之一，因为下游应用程序依赖于这些查询的准确性。如果查询出现错误，尤其是在 ETL 过程中，可能会产生大量垃圾数据并持续很长时间(我这是基于亲身经历的发言)。纠正错误可能需要很长时间(通过回填)，有时原始数据可能已不可用。
我使用大语言模型(LLMs)来生成编写复杂 SQL 的想法，但在部署之前，我总是需要先 100% 理解查询。错误代价高昂，有时甚至是不可逆的。我需要信任但也要核实，这需要深厚的 SQL 知识。
要编写正确的 SQL，你不仅需要了解语法，还需要了解架构(很容易提供给大语言模型(LLM))和预期的数据值(你可以向大语言模型(LLM)提供一个有用的采样，但领域知识更有帮助)。数据中有很多令人惊讶的东西，只有通过目视检查才能发现。(尽管我认为，借助 MCO，大语言模型(LLM) 有一天将能够通过采样数据库来检查数据本身)
这表明我应预期SQL生成的数据很可能存在错误，因为撰写SQL的人往往缺乏深厚知识，且由于缺乏或几乎没有真实数据作为参考，验证结果正确性极为困难。
既然我已预期SQL会产生一定程度的混乱，为何不将AI纳入系统设计中？
测试SQL的正确性与SQL的生成方式无关。当然，审查和测试任何内容都很重要。我的观点是，当前AI助手的水平已经足够好，无需花费大量时间手动编写复杂查询。
虽然AI助手可以提供解决问题的思路，但我强烈反对“学习毫无意义”的观点。你应该理解AI的建议，因为它也可能非常糟糕或运作不当。(如果它产生了幻觉，你会注意到语法错误，这确实不需要学习…)
让 SQL 查询达到最佳性能仍然更像是一门艺术，而不是一门具体的科学。大语言模型(LLM) 生成一个看起来可以工作的查询(正确性问题另当别论)的可能性，远大于生成一个性能最佳的查询。虽然这对于分析中常见的一次性查询可能并不重要，但当你开始担心可扩展性时，即使是最微小的调整也会产生巨大的影响。
DuckDB支持Parquet格式，并能以SQL语法在跨大量Parquet文件的巨大数据集上操作，如同处理单个虚拟文件。我认为其核心优势在于可利用向量指令处理Parquet数据。这非常“实用”。
DuckDB 的每一个方面都独具特色。Pandas 在表格数据分析领域远远落后于当前技术水平。
作者补充：其独特之处在于，你可以从零开始快速处理空间数据，且无需切换工具，直接在现有的通用数据分析工具中完成。这大大扩大了地理空间数据处理者的受众范围。
(Geopandas也很棒。)
我对Postgres非常熟悉，使用PostGIS似乎也挺简单。使用DuckDB能获得更多优势吗？
我通常存储位置数据并计算到这些位置的距离。使用DuckDB实现这些功能会更快吗？
对于你的用例(ST_Distance)，可能没有区别。如果你已经将数据存储在 Postgres 中，建议继续使用 PostGIS。
在我的用例中，我选择 DuckDB 是因为其在大规模数据处理时的速度优势。我目前有 600GB 的经纬度数据存储在磁盘上的 Parquet 文件中。
如果要使用 PostGIS，我需要先将所有数据导入 Postgres 数据库。
使用DuckDB，我只需在Jupyter笔记本中直接操作，不到10秒即可完成，结果瞬间返回：(无需提前导入任何数据)
我尚未理解这种模式(且尝试过使用DuckDB)。除非您一生中仅需查询这些文件一两次，否则将它们导入Postgres并不需要太长时间，之后您可实现与DuckDB相同甚至更强大的功能。
另外，作为一个附带说明，大家都是在内存中使用DuckDB吗？因为一旦你需要跨多个会话的数据，我认为你会将DuckDB与本地数据库结合使用，所以再次，我看不出来有什么意义，但我肯定我漏掉了什么。
> 将它们导入Postgres应该不会花太久时间，然后你可以做和DuckDB一样的事情，甚至更多。
通常新数据会定期生成，需要创建一个单独的ETL过程来导入到Postgres。使用DuckDB时，不需要ETL。新的Parquet文件只需从磁盘读取即可。
> 另外，大家都是在内存中使用DuckDB吗？
DuckDB通常作为单用户使用，是的，内存使用场景是最常见的。不确定单用户需要多个会话的场景？但DuckDB支持读并发、会话隔离等功能。我相信在多个会话中支持写入串行化。
对于 Parquet 文件，由于其为只追加模式，因此“写入”用例通常较为有限。通常由另一个进程生成这些 Parquet 文件，DuckDB 仅与之配合使用。
> 通常新数据会定期生成
这一部分并不明显。在许多情况下，地理数据大多保持稳定，读取/搜索操作远多于追加操作。因此我们将其保存在数据库中(通常是PostGIS，是的)。
因此DuckDB针对非常不同的使用场景进行了优化，且其适用性并不总是显而易见
这是更简单的使用场景(静态数据、大量读取)，而DuckDB对此场景进行了绝对优化。
DuckDB还提供了一个向量化、并行化的引擎。当我运行查询时，我的32个核心在htop上都会亮起。
但DuckDB在处理静态数据时同样表现出色。
我认为关键点在于无需存储600GB输入数据的副本。
现在我好奇是否有一种方法可以实际索引外部文件(使这些查询在 600GB 数据上更快)，并且让这个索引(或多个索引)保持持久化。我可能在查看文档时漏掉了这一点……
如果数据以 Parquet 格式存储，它们在某种程度上已经索引好了。无需进一步索引。
如果它们存储在DuckDB的原生格式中(我没有使用该格式)，它支持一些最先进的索引。
https://duckdb.org/docs/stable/sql/indexes.html
不过我认为Parquet已经足够快了。
啊，谢谢。我原本打算处理数百万个(Geo)JSON文件，总容量达数千兆字节，且不复制/重复这些文件，主要通过索引实现。我之前曾使用PostgreSQL的外数据封装器进行过类似操作，对DuckDB也抱有期待。但这个问题更适合在Stack Overflow或其他论坛讨论。
首先，它没有那个糟糕的 pandas API。
是的，这是我最喜欢它的方面之一
我没有使用过 duckDB，但真正的比较对象应该是 PostGIS？它在讨论中缺席，但我认为作者暗示的就是它。
我对pandas和geopandas没有太大意见。不过我只在别无选择时才使用它，而不是因为喜欢用它作为库。听起来像是pandas(或类似库)与数据库的对比？
没错，PostGIS易于获取，而PostgreSQL的普及程度远超DuckDB。要么我没理解楼主为何认为这如此重要，要么我就是不认同。
如果你用 JavaScript，就安装 Turf。能够轻松安装空间库的概念并不新鲜。
便利性始终是个人偏好。
问问任何刚开始使用geo pandas的人，他们的体验如何，我敢肯定没有人会称它为直观和简单的。就geopandas而言，我认为它只是继承了Pandas的许多缺点(为什么用户需要理解索引才能进行基本操作，没有多核支持，类型提示非常差，等等)。
我从事地理空间应用开发，我最期待的软件是https://felt.com/。我希望他们能扩展工具集，使地图和数据源的认证/授权可由开发者控制，从而实现租户隔离和专有数据访问。他们有望彻底改变地理空间技术在消费级应用中的集成方式。
这篇文章没有意识到这些内容的利基性，而且要让人们掌握坐标系统、投影、转换等知识需要大量培训。如果可能的话，我会用Felt替换我自建的大部分映射工具，这样我就可以专注于核心地理空间流程，而不是在浏览器中显示和操作数据的代码，后者在代码行数上几乎与前者相当甚至更多。
如另一位评论者所提，文中描述的DuckDB DX与PostGIS基本相同。
作者补充：DuckDB空间功能的优势在于，投影和坐标参考系统(CRS)选项在不需要时会被隐藏。对于90%的地理空间数据使用场景，用户无需也不应了解投影或CRS细节。
是的，处理大写G的地理空间工作有许多优秀的工具。
我也喜欢Felt！Sam和团队打造了一个伟大的平台。但很多时候不需要地图；分析师只需要它作为一列数据。
PostGIS也非常出色！但启动数据库服务器来处理数据并不适合随意的使用。
DuckDB 的魅力在于它能瞬间呈现，且对数据通用型用户触手可及。
我的经验是，数据通用型用户应避免进行地理空间分析，恰恰是因为他们未能充分理解空间坐标的重要性。我见过人们以各种方式在这一任务中失败。从“我不用库来重新投影，我直接用哈弗辛函数”到“我直接用 WGS84 坐标系中的地址点与 NAD27 坐标系中的地块进行空间连接”再到“这些朝鲜导弹不构成威胁，因为根据这张使用墨卡托投影的地图，我们不在射程内。”
DuckDB很棒，但它让数据通用主义者更容易在地理空间数据上犯错，这反而成了它的缺点，而非优点。
我记得在GIS课上学过那张臭名昭著的导弹威胁地图——
https://georeferenced.wordpress.com/2014/05/22/worldmapblund…https://www.economist.com/asia/2003/05/15/correction-north-k…
我认为我们基本上在讨论同一个问题，即复杂性。
对我来说，我认为主要是前端问题阻碍了地图在消费级应用中的普及。后端地理信息其实很简单，说实话。有太多优秀的免费工具。而地图前端开发则是噩梦，我还没见过现成的解决方案。有些工具太底层，有些又太高层。我认为我们需要一个可嵌入的GIS轻量级版本，以隐藏复杂性，让应用开发者专注于自身价值，而不是让前端开发者去解决他们不理解的地图问题。
编辑：为了澄清，我认为地图功能被领导层认可(甚至可由分析师完成地理工作)与前端应用中存在更多地图工具(让领导层看到并理解地理数据的重要性)之间存在关联。这需要超越地图上的简单标记，实现广泛曝光。因此我专注于前端网页。如果表达显得零散，请见谅
一点也不零散。最后那个话题才是需要解决的重大挑战。
据我所知，DuckDB的空间功能不支持处理投影。它无法从.prj文件加载坐标参考系统(CRS)。这使得它无法用于严肃的地理空间应用。
> 要让人们掌握坐标系统、投影、变换等知识需要大量培训
这可以通过适当的椭球参考系统、计算几何实现和索引来完全避免。大多数地理空间分析应用并非地图制图性质。地图充其量只是展示层，并非数据模型，且部分用户根本不使用地图。迫使用户学习晦涩难懂的制图系统来提出关于地理空间关系的简单直观问题，正是问题所在。这本不应成为学习曲线的一部分。
我曾多次对非专业用户进行过相关实验。如果为他们提供一个完整的球面WGS84实现用于地理空间分析，它在地球上的任何地方基本上都能“正常工作”，且无需考虑地理空间范围。是的，软件实现要复杂得多，但从用户体验角度看，这种设计更优越，因为“世界”的行为方式与人们直觉中的预期基本一致，无需了解投影、变换等技术细节。坦白说，即使你了解投影和变换，结果也常常不够理想。
唯一的问题是，许多制图可视化工具包在处理全球数据模型或复杂几何形状时会出现问题。会产生大量渲染 artifacts。这可能是另一个需要解决的问题。
我倾向于同意，但遗憾的是，该领域现有的大量数据和流程并未假设地球为椭球体，且未提供坐标参考系统。最终，还有一些领域中，你明确不希望使用椭球体语义来解释数据，例如在处理城市规划时——此时地图本身就是数据模型，你肯定希望三角形的内角和等于180度。
同样，我认为遇到与这些问题相关的问题是不可避免的，如果你不熟悉细节，就会遇到巨大的障碍，因为调试需要对困难问题有深入的理解。否则，你可能不知道问题存在，而代码已经损坏。我认为这并非像抽象掉整个概念那样简单，正如我之前提到的，这属于过于高层次的抽象。我坦白说不知道正确答案，但我认为当有人破解它时，这将带来颠覆性影响
> 软件实现要复杂得多
难道大多数地理空间工具不就是做简单的几何运算吗？因此需要处理某种投影吗？
如果你能用椭球体模型进行计算，确实能得到更好的结果，而且像你说的更容易理解，但这涉及更复杂的数学。你今天能用QGIS和GDAL等工具做到这一点吗？
许多工具确实使用简单几何运算。这给非制图专业人士带来了无尽的困扰，因为他们并未预料到这一点。优秀的地理空间工具通常支持椭球体模型，但这并非默认设置，用户必须主动确保其使用该模型(许多人误以为这是默认选项)。
另一个问题是，椭球体实现经过的优化非常有限，可能是因为它们不是默认选项。因此，当人们弄清楚如何启用它们时，性能突然变得非常糟糕。现在，人们认为椭球体实现非常缓慢，而实际上他们只是使用了异常缓慢的实现。经过性能优化的椭球体实现比基于开源实现的性能要快得多。
说句公道话，你无法使用球面方法处理大多数数据。它们仅用于点数据，在实际应用中。你的空间数据本质上是以不支持球面方法的方式存储/生成的，一旦涉及多边形，更不用说栅格数据了。
是的，多边形数据的球面表示形式确实存在，但你导入的数据已经过“分割”，而逆转这一过程往往不可能，或至少非常困难。至于栅格数据，根本无法以这种方式表示。
分析使用投影正是出于这个原因。球面方法并非在绝大多数用例中都“更好”。它们仅在处理的对象全是点数据时才严格优于其他方法。
地理空间数据不仅仅是点数据集。
这是一个很好的观点。对于栅格分析来说，这确实没有意义。
但任何类型的矢量数据都可以建模在球面上，对吧？点、形状、线。我看到“更好”是因为即使是最适合的投影也会有一些小的失真。
无论如何，大多数情况都使用平面几何，因此投影是必要的，你需要理解这些原理如何运作
你可以将多边形建模在球面上，但问题是原始数据已采用笛卡尔坐标系表示。对于复杂几何形状，尤其是在跨越反子午线/极点的情况下，你实际上无法轻松地在两种表示之间转换。因此，除了点之外，尝试做其他事情在实践中是困难的，除非你从头开始以球面表示生成数据，而这种情况很少见。
这并不是一个大问题，除非你试图模拟一些3D空间轨道或物理现象。从地理信息系统(GIS)到地理模拟系统的过渡较为粗糙，但基于投影笛卡尔空间的投影和计算已足以应对许多典型问题，如距离、面积、路由等。然而，拓扑支持开始变得专业化，应用场景也更加小众。我认为要求数据库/存储层在GEOS支持范围外进行高效计算有些强人所难。此时，你可能需要将相关数据导入更高层次的应用程序。
就我个人而言，我并非指任何类型的模拟系统。这是许多运营地理空间数据模型的标准要求，而这类模型在行业中数量庞大。任何基于投影的方案都是不可行的，这会在大规模地理空间分析或需要精确度的情况下引发明显问题。高效计算仅指高效代码，开源领域并不缺乏此类实现，只是需要有人去编写。是的，如果你的数据模型在地理范围和数据规模上都较小，或许可以勉强应付，但这并不适用于所有公司。
这完全可以在数据库中实现。这就是实际操作的方式。GEOS的局限性并非软件本身的局限性，它并不是一个特别复杂的实现(据我所知，PostGIS在关键部分也没有使用它)。在某种程度上，你是在承认开源领域在这个市场部分缺乏雄心。
我不会说GEOS并不特别复杂。许多(当然不是全部)GEOS算法现在是从JTS移植过来的，而JTS的主要作者是Martin Davis(又称Dr JTS)，他目前在Crunchy Data工作，该公司提供了PostGIS扩展。因此，这条链(再次强调，主要是)是JTS -> GEOS -> {PostGIS, Shapely} -> …。Martin的工作一直处于开源GIS领域计算几何的前沿，而且已经很久了(当然，行业有自己的工具，但这不是我们讨论的重点)。
我能理解你关于全球球面几何优点的观点，尤其是从用户角度来看。但不可否认的是，几何计算在各个维度上都更慢(我忍不住想说“本质上”……)且实现起来复杂得多(只需看看编写高效、准确的球坐标r-树或r*-树有多痛苦)。这种情况短期内不会改变，因此投影工作流程可能不会消失。
你说得对，几乎任何事情都可以通过数据库函数暴露的API来实现。然而，正如他们所说……如果可以做到，就意味着应该这样做吗？我同意，拥有更复杂的多维计算会很酷，但我很少在项目中遇到需要或甚至想要这样做的场景，即使是涉及精确模拟的项目。实际上，数据库一直用于存储和查询数据，这可以非常精确。我可能是第一个滥用SQL的人，我曾用SQL编写过3D ECEF旋转代码，但那只是为了赶工期的权宜之计，而非因为这是正确的做法。我参与的所有项目中，都有外部模型或组件负责使用复杂代码完成“精确工作”，而我绝不会让这些依赖于任何数据库。
我其实很好奇，就你而言，你正在进行何种分析，使得NAD83或UTM无法提供足够的精度？这是否真的是“真实世界”的地理空间数据？如果我有一个土壤模型，那是一个非常局部的分析，如果我有一个全球气候模型，我们讨论的是公里级的网格单元。在所有这些情况下，收集的数据中内置的地理位置误差都远大于大多数合理的投影系统…
那么，你正在进行的分析是什么，需要在全球数千公里的范围内实现厘米级精度？这听起来非常有趣。我唯一见过这种情况是在进行太空飞行模拟时，误差会随着时间的推移而累积。
你尝试过https://geobase.app/吗？他们最近还发布了一篇关于DuckDB集成的文章：https://geobase.app/blog/duckdb-1-1-3
我还没有尝试过，看起来挺酷的，但似乎解决了相反的问题。我想要一个与后端无关的前端工具集，它是一个我可以根据需求定制的GIS。我不想自己实现这些工具，那太底层了。我也不希望服务管理、控制或拥有数据，那太高层了。我认为目前还没有找到这个甜蜜点。
我正准备使用Felt，结果他们取消了免费层级并大幅提高了价格。
https://atlas.co/仍然提供免费层级。功能较少，当然这取决于你的具体用例。
>如另一位评论者所提，文中描述的DuckDB DX与PostGIS基本相同。
不，它们不同。
为什么？文章缺乏细节。将空间分析与SQL结合确实很棒且自然。从关系型数据库管理系统(RDBMS)的角度来看，2D几何图形与浮点数和字符串并无本质区别——几何图形只是另一种列类型，只不过带有特殊运算符和索引。我们已经使用PostGIS、Spatialite等技术做了二十年了。
DuckDB的独特之处在于云原生格式。这是将标准地理空间功能与对象存储而非磁盘绑定在一起。因此，它不需要运行数据库进程——数据始终处于“静止”状态，并通过HTTP提供访问。我并非贬低这一成就，它确实非常方便。但请明白，这是对现有技术的重新包装，以在云IO环境中高效运行。如果说有什么创新，DuckDB的主要创新在于数据管理，而非地理空间本身。
这个论点对我来说似乎很清楚；更易于使用的工具意味着更多的用户和贡献者。但作为一个明显的领域专家，我可以理解你为什么会被标题吸引。
主要是为了澄清一点——我认为DuckDB并不代表地理空间领域的任何新事物。它代表了数据管理和数据架构的新范式。理解这种区别并非可有可无。
DuckDB 同样支持浮点数 – DuckDB 是否是浮点数据中最重要的事物？当然不是，数据类型和运算符并未改变。改变的是底层计算环境。创新就在这里。我只是希望技术作家能花两秒钟时间做出这一关键区分 – 保持精准并不难，我不知道我们通过发布故意模糊的技术文章能获得什么。
我不确定“install geospatial”与“pip install geopandas”相比，在简便性上是否真的是一个重大突破。
两者都是单行命令。
我认为关键在于duckdb的空间扩展没有传递依赖(除了libc)。它静态打包了标准的开源GIS工具套件(包括完整的坐标系统数据库)，支持多平台(包括WASM)，并提供统一的SQL接口。
(免责声明：我参与duckdb-spatial的开发 @duckdblabs)
我曾将 duckdb-spatial 用于一个业余项目，我的结论是它相较于 geopandas 的主要优势在于批量处理性能。
如果我能将空间分析简化为 SQL 并稍作优化，duckdb 就能充分利用 CPU 和内存资源快速处理数据，这是 Python 脚本难以做到的。
是的，静态链接很方便。它有助于解决 Python 环境可重复性问题。但在我看来，这并非决定性优势。
“易用性”常被忽视，虽然你可以用工具完成任务，但让用户实际使用则是门手艺和艺术。这正是开源核心与企业版产品之间的差异所在。
这比‘load extension postgis’简单得多吗？我知道geos和gdal一直有点麻烦，但我觉得Docker已经抽象化了所有这些。‘docker pull postgis’相当简单，尽管我对duckdb提供的其他功能不太熟悉。
是的。在命令行中运行‘install spatial’与配置服务器之间的差异天差地别。
Docker确实带来了巨大改进(当我最初学习PostGIS时，寻找proj目录或编译软件只为安装插件所耗费的时间曾是重大障碍)，但它仍远未达到：
“` $ duckdb D install spatial; “`
你所说的“配置服务器”是什么意思？这是一个奇怪的要求。你可以在MacBook上用一条命令安装PostGIS，或者实际上在三大主流操作系统上都用一条命令安装：“brew install postgis”、“apt-get install postgresql-postgis”和“choco install postgis-9.3”。DuckDB 是否不需要“服务器”或“计算机”？Docker 与此事有何关联？这思路非常混乱。
> DuckDB 是否不需要“服务器”
不需要，它的工作方式类似于 SQLite。
PostGIS 包含在 Postgres.app 中，这是一个适用于 Mac 的单一可执行文件。DuckDB 似乎也是适用于 Mac 的单一文件下载。我不确定您“在最初学习 PostGIS 时”的经历是否反映了当前情况。
https://postgresapp.com/
我的意思是，我喜欢DuckDB，但这感觉像是你在强推它。在我的系统中，PostGIS是通过apt install安装的，激活“插件”只需一条命令。难道“天壤之别”不就是不用从网上运行随机sh脚本来安装软件吗？
DuckDB 不需要运行服务器。我在终端中运行 DuckDB，查询 10,000 个 CSV 或 Parquet 文件，并在它们上运行 SQL，同时与存储在 SQLite、另一个使用其原生格式的 DuckDB 文件，甚至 Postgres 中的数据进行连接。
太棒了！区别在于你已经熟悉并知道如何操作
对于不熟悉的人来说，从零开始使用地理数据可能很困难。DuckDB 将一切打包成一行代码，只需一个依赖项。
https://postgresapp.com
这并不简单。我通常在笔记本中与 testcontainers 一起使用它 https://testcontainers-python.readthedocs.io/en/latest/
DuckDB 对于地理空间数据来说是个很棒的工具，但它是过去十年中最重要的吗？不同类别中有太多工具，它不会是我心中的顶尖选择。一些可能包括 QGIS、PostGIS(仍是行业标准)、ArcGIS Online(仍是行业标准)、JS 地图工具如 Mapbox(我更喜欢 DeckGL)、新数据类型如 COG、Geopackage 和 Geoparquet、摄影测量工具、3D 瓦片、核心库如 GDAL 和现在 PDAL、Shapely 等。
这些工具大多在2000年左右推出。
是的，我感觉自己老了。
问题明确指出的是“过去十年中最重要的工具”，而非“过去十年中被发明的最重要的工具”。即使按照你的定义，列表也可能缩小到一半左右，你应该清楚这一点。
我对DuckDB及其依赖的GEOS的许可问题有一些担忧。前者采用MIT许可，后者采用LGPL 2.1许可。
这导致了一些复杂的情况，例如与闭源应用程序进行静态链接时，某些构建可能会违反LGPL 2.1许可。
我来推广一个类似的项目，即我正在开发的 Polars [1] 的地理空间扩展。目前该项目尚未稳定(尽管已非常接近)，但功能已相当完善(它使用 GEOS 和 PROJ 作为后端，因此与 GeoPandas 功能相当)。
[1] https://github.com/oreilles/polars-st/
我认为这是地理空间数据处理日益简化的更广泛趋势的一部分。DuckDB 适合快速临时任务，但我发现 Polars 更易于维护。个人而言，我非常期待 Polars 未来能真正支持地理空间功能。目前，创建一个自定义 H3 插件仅需几天时间，且大幅简化了我们原有的 GeoPandas/DuckDB 代码。我们越早完全淘汰 GeoPandas，越好。
[1] https://github.com/Filimoa/polars-h3
使用 Polars 是否能比数据库更高效地存储数据？
我使用 Polars，但尚未深入研究其性能特性与 PostgreSQL 等数据库的对比。
我一直在使用 Trino/AWS Athena 进行地理空间工作。
其 API 覆盖不够完善，部分功能仍缺失，但这只是时间问题。
它真正发光的地方在于需要进行O(n²)或O(nm)类型计算时。那时，那些数百个免费的CPU核心就派上用场了！最终结果往往相当于一美元的CPU天数计算成本。
O(nm)计算的示例包括在每个列表中的点内查找最近的道路段(或更可能是该道路段及其周围的道路段)。
如果你进行大量空间索引查询，其实比 SpatiaLite 慢得多。因为 DuckDB 使用列式存储。
我真希望他们能允许 2 个连接。一个只读连接用于我的 BI 工具，一个读写连接用于 dbt/sqlmesh
我认为使用pyarrow数据集作为中间层，可以实现从一个连接到第二个连接的零拷贝读写。
DuckDB > geopandas，尤其是在处理内存外的数据时。不过，我最近放弃了导入70GB的大型多边形数据(来自CSV格式的HEX WKB)，转而使用PostGIS容器。随着DuckDB的成长，我也标志着geoparquet的出现。
在我看来，过去十年GIS软件的重大变化在于计算和存储效率的提升，贯穿整个典型技术栈。DuckDB已成为其中一部分，但也要感谢shapely、geopandas、geoparquet和GDAL的进步。这些技术之间存在大量重叠，功劳应归于各方。QGIS也很出色，但我认为将其庞大的功能集应用于90/10原则并迁移到网页端存在市场机会。
SQL Server具备地理空间功能，无需任何扩展或插件。我多年来一直愉快地使用免费Express版本的地理空间数据类型，可能已超过十年。
这是一个相当夸张的声明，坦率地说，我并不喜欢这种广告。
如果你想导入数据并进行处理，GeoPandas存在。如果你想与SQL数据库集成，PostGIS存在。
在应用程序层面，GRASS GIS、QGIS等工具向你问好。它们被广泛应用于农业行业和政府机构(至少在德国和巴西是这样)。
DBeaver(数据库客户端)内置了显示地理数据的功能。在我使用的情况下，是PostGIS的结果。我注意到DuckDB的空间函数与PostGIS的几乎完全相同。
https://dbeaver.com/docs/dbeaver/Working-with-Spatial-GIS-da…
说实话，我认为实际上是 https://www.uber.com/en-CA/blog/h3/
这让人不禁思考，YOLO 算法是否在六边形上会表现得更好。
“六边形是一个重要的选择，因为城市中的人们经常处于运动状态，而六边形可以最小化用户在城市中移动时引入的量化误差。六边形还允许我们轻松近似半径，例如在这个使用 Elasticsearch 的示例中。”
[Edit]也许 https://www.researchgate.net/publication/372766828 _YOLOv8_fo…
你能详细说明一下吗？我曾尝试在查询中使用h3，但从未在生产环境中使用过。显然，它对Uber非常有效，但我好奇你是否有其他使用经验。
数据集的规模有多大？我一直在尝试在公司中使用duckdb处理财务交易和报告数据。数据集大约是500GB的CSV文件存储在S3中，但duckdb无法处理它。
CSV是一种相当糟糕的格式，任何引擎都会在处理它时遇到困难。它基本上需要进行全表扫描才能获取任何数据。
您需要将其转换为Parquet或其他列式格式，以便引擎能够进行谓词下推和快速扫描。每个Parquet文件都会存储其包含数据的统计信息，因此引擎可以快速决定是否值得读取该文件或直接跳过。
从S3访问CSV文件是一种低效的方式。
应将其转换为Parquet格式，这样访问和分析将变得廉价且快速。
我同意。这就是我们的数据生成方式。我们不断将实时数据生成到 CSV 文件中。据我所知，无法向 Parquet 文件追加数据。
Parquet 文件本就是为追加操作设计的。只需创建新文件即可。
这对不熟悉大数据的人来说是一个新概念——传统方法通常涉及行插入操作。在大数据中，追加操作仅需创建新文件——数据库引擎会立即识别其存在。这就是为什么“select * from ‘*.parquet’”始终操作最新数据集的原因。
等等，所以我要为每条消息创建一个新文件吗？
通常小数据会进行批量处理。虽然理论上可以，但我不会为每行创建一个文件(文件数量会过多，文件系统会难以处理)。但也许你可以将一天的数据(或适合你数据的任何分区方式)批量处理并写入一个 Parquet 文件？
例如，我的数据通常按年周(年+周号)进行批量处理，因此我的目录结构如下：
这也被称为Hive目录结构。当我查询时，只需执行：
这与传统数据库处理海量数据的思维方式截然不同。它采用按文件 append-only 的方式。
500GB的CSV文件听起来并不算太大。我猜当你将其转换为Parquet格式(在DuckDB中只需一行代码，如下所示)时，最终可能只有50GB左右。
我真的很惊讶DuckDB在处理500GB数据时会出问题。这可能只相当于一周的数据量。
Parquet文件的分区可能是个问题，因为并非所有数据都按日期整齐地分区。我们有交易数据，其执行日期、清算日期和其他日期值各不相同，这些都需要进行查询。
通常情况下，500GB的数据并不会导致卡顿。我每天查询600GB的Parquet文件(相当于几TB的CSV文件？)。问题不在于数据大小，而在于数据类型。
如果按日期分区不起作用，就找另一个分区键。关键是将数据转换为Parquet格式。CSV格式效率极低。
或者启动一个内存更大的计算实例。我的实例有256GB内存。
我曾尝试在300GB TSV数据湖上运行一个Apache Spark任务(8台机器集群)。这是一个分布式集群。其中包含一个连接操作。8小时后任务超时。我意识到原因——Spark不得不对TSV文件进行多次全表扫描，这效率极低。CSV格式适用于简单读取，但一旦需要在规模上进行聚合或连接等分析操作，就会遇到巨大挑战。
DuckDB在处理CSV方面比Spark更优，但如果数据集规模庞大且格式不佳，任何引擎都会受阻。
我们也有Spark集群。后来切换到Athena。我只是不喜欢其成本结构。
基于磁盘的分区问题在于，键值难以妥善管理。
Athena 处理 CSV 文件的效果如何？我使用过 Athena，它在大规模处理 CSV 时也存在困难。
顺便说一句，我不是建议使用 Spark。我的意思是，即使 Spark 在处理大型 TSV 数据集时也无法正常工作(只需一个连接或分组操作就能严重影响查询性能)。CSV 数据存储格式本身就不适合分析。
分区是不可逆的，但设计一个合理的分区方案并不难。你只需要对某个字段进行哈希处理。即使是对某个有意义的字段进行HNV哈希，也足以满足需求。在我的一个数据集中，我按周进行分块，然后按HNV模50进行分块，因此数据结构如下：
/yearwk=202501/chunk=24/000.parquet
请大语言模型(LLM)提出分区方案，或者自己想一个。
CSV是一个错误。这里的做法是摆脱CSV。分区是次要的——这里分区只是用于对Parquet进行分块，仅此而已。你不会被任何东西束缚。
是的，在Athena上，我们处理的CSV文件要大得多。但成本实在太高了。我们还有ORC和Parquet格式的其他数据集，这些数据集我们是用EMR Spark来处理的。我真的很想尽可能地摆脱这些分布式分析引擎。
我必须考虑分区问题，Spark和Athena在按接收日期进行分区时都遇到了问题。它们扫描了太多数据。
您是否从靠近S3数据的EC2实例进行查询？CSV文件是否被分割为独立文件？该机器是否拥有500GB内存？当存在明显的I/O瓶颈时，问题并不总是出在DuckDB上……
不，EC2实例没有500GB内存。DuckDB需要这个吗？我实际上将数据从S3下载到本地EBS，但仍然卡住了。
对我来说，在TB+数据集上运行正常。也许你是在内存中而不是持久化数据库中运行，导致内存不足？https://duckdb.org/docs/stable/clients/cli/overview.html#in-…
等等，你是从 S3 将数据插入 DuckDB 吗？我只是从文件中进行选择。
不，只是从S3中读取。看看这个：https://duckdb.org/2024/07/09/memory-management.html
可能是你的终端因为尝试显示太多数据而卡住了？500GB应该没问题。
你能用clickhouse-local测试一下吗？对我来说它总是运行得更好。
不，ClickHouse因其他原因未被考虑。但我认为未来可能会重新评估它。
将空间功能直接嵌入到通用数据工具(如DuckDB)中，将如何改变参与地理空间分析的群体——以及他们选择解决的问题类型？
我对DuckDB不太了解，哪里可以获得关于它热度原因的全面概述？从命令行界面看，它似乎只是一个新的SQLite…
它本质上是一个列式SQLite，因此对于某些类型的查询速度快得多。这类查询的市场需求很大，而没有人愿意为了处理单台机器规模的任务而运行自己的Hadoop集群。
我们需要一个“别开玩笑了”的条款来应对这些荒谬的标题。别开玩笑了。
我本以为会看到示例查询，结果只得到了如何安装包的说明 🙁
嗯，我尝试做一些空间相关操作，但内容不够丰富，或者我无法弄清楚如何使用它。将空间信息加载到IPython并进行调整是常见操作，我认为SQL对用户而言并非天然门槛更低。
哎呀，又是一个采用宽松许可证的数据库。我好奇它何时会开启自己的Redis传奇。
我认为地理空间分析很重要(当然我会这么认为)，但坦白说，地理空间软件已经停滞不前很久了。每项新事物不过是对现有停滞不前的事物进行重新包装。这基本上就是这个意思？
对于地理空间分析，软件领域最重要的是不再将它(无论是明示还是暗示)与制图学挂钩。许多应用场景根本与地图无关，但工具却要求用户必须通过制图学的视角来处理一切。
当人们提出反驳标题的替代方案(如QGIS、PostGIS、GDAL等)时，我深有同感：几乎所有这些工具都诞生于21世纪初。
我完全同意你对地图的看法：大多数人无法读懂地图，它们会影响整个工作流程并使其复杂化，而且(我认为)导致了对地理空间领域的普遍低估。将数据转换为列格式意味着它可以被每个部门使用。
你能举些例子吗？
关于停滞不前？我从事地理空间分析已有20多年，令人惊讶的是，无论是功能还是能力，几乎没有什么变化。考虑到过去的时间以及人们今天使用的地理空间数据模型范围的极大扩展，我认为大多数人会期望有更多变化。
不，我的意思是这个：“许多用例根本不是基于地图的，但工具却要求用户将一切都通过制图的视角来处理。”
不。QGIS就是这样。
天啊。
作者在此。
QGIS太棒了。它真的很棒。它于2002年发布，所以我认为这个标题是安全的。
不，它一直在改进，并且仍然是十年中的佼佼者。你因为它存在就否定它吗？重新阅读你的标题，它绝对不是你认为的那个意思。
我同意。