大学生数据库实践课：航空网络分析

本期播客

大学生数据库实践课：航空网络分析

同学们好，欢迎继续学习《大学生数据库实践课》。在 19.1 讲中，我们感受了社交网络的“人情冷暖”，今天 19.2 讲我们把目光投向更加宏大的航空物流网络。

航空数据分析是典型的高维关联分析场景。全国数千个机场、数万次航班、数百万个座位，如何从中精准找出中转方案？如何通过复杂的预订链路分析定价策略？如果还用传统 SQL 那种“套娃式”的 Join，不仅性能拉跨，代码也会写得像面条一样乱。

今天，我们就用 DuckPGQ 来一场航空数据的“图式手术”。

一、 为什么航空大脑需要“图模型”？

在航空领域，数据天然就是点和边：

• 顶点（Nodes） ：机场是点，座位是点，机票也是点。
• 边（Edges） ：航线（Route）是连接机场的边，预订（Bookings）是连接乘客与座位的边。

痛点：如果你要查“从乌鲁木齐（UKX）到圣彼得堡（CNN）的所有最短中转路径”，传统 SQL 需要手动模拟 1 跳、2 跳、3 跳……而图数据库只需要一个路径量词。

二、 核心案例：从代码到业务洞察

本课我带大家重点拆解两个核心查询：

1. 自动导航：最短路径搜索

MATCH o = ANY SHORTEST (a:airports_data WHERE a.airport_code = 'UKX')  
      -[fr:route]->*  
      (a2:airports_data WHERE a2.airport_code = 'CNN')  

• 德哥点评：这个 -[fr:route]->* 里的 * 是精髓，它告诉数据库：“不管中间换乘几次，给我把路找出来！”底层会自动跑 Dijkstra 或 BFS 算法。在航班延误、航司需要紧急为旅客寻找备选方案时，这个功能就是救命稻草。

2. 精准营销：寻找“黄金座位”

MATCH (b:bookings)-[bt:bookings_tickets]->(t:tickets)-[bp:boarding_passes]->(s:seats)  
SELECTround(avg(total_amount), 2) avg_amount, seat_no ...  

• 德哥点评：这行代码串联了“预订->机票->登机牌->座位”一长串业务链条。通过这个模式匹配，我们能瞬间算出哪个位置最挣钱（比如某些特定机型的应急出口位或前排位）。这种“链式思维”比写四五个 JOIN 要直观得多。

三、 德哥给大学生的“课后三问”

通过这三个问题，看看你是否真正掌握了图数据库的思维：

1. 【思维转换】：既然 SQL 也能做路径查询（虽然很难），为什么我们要费劲折腾出一套 SQL:PGQ 标准？提示：从代码的可读性和底层的执行性能（指针跳转 vs 哈希连接）去思考。
2. 【语法进阶】：在上面的座位分析中，MATCH (b)-[bt]->(t)-[bp]->(s) 是单向的。如果我们要查“哪些乘客经常坐在一起”，你会如何利用“座位”这个公共节点，写出一个类似“V型”或“闭环”的匹配模式？
3. 【实战扩展】：航空图中如果加入了“时间”属性（比如前一班落地和下一班起飞必须间隔 2 小时），图查询还能像现在这么简单吗？这涉及到了图数据库中非常高级的路径约束问题。

四、 德哥寄语：图数据库是解决复杂关系的“终极武器”

1. 别把图当成新工具，要当成新视界：学会把现实世界的业务（供应链、航空网、反洗钱）抽象成点和边。
2. SQL 永不过时：DuckPGQ 的伟大之处在于它没有抛弃 SQL。你可以在 GRAPH_TABLE 里做图搜索，在外面继续用 GROUP BY 做统计，这是 混合负载（HTAP） 的趋势。
3. 动手才是真理：文章里给出的 ATTACH 链接是真实的，同学们一定要在自己的 DuckDB 里跑一遍，感受一下秒级出结果的快感。

下一讲预告：我们将进入最硬核的部分——《金融反欺诈：如何利用图计算抓捕洗钱团伙》。

如果你在练习时遇到报错，或者对“相邻座位乘客”的 SQL 怎么写感兴趣，欢迎在评论区留言。公益是一辈子的事，学习也是。

详细教程, 点击「阅读原文」