3、DEX数据抓取：Uniswap V2/V3子图查询、PancakeSwap数据接口、SushiSwap数据获取、DEX聚合器（1inch）数据源
做DeFi量化，第一步就是搞定数据。没有数据，策略就是空中楼阁。
我个人习惯把DEX数据分成两类：链上原始数据和子图索引数据。链上数据太原始，解析起来费劲。子图（The Graph）才是我们量化工程师的利器。说白了，它帮你把链上事件整理成了SQL一样的数据库，你直接查就行。
核心观点： 别自己解析交易日志，用子图。效率差十倍。
3.1 Uniswap V2 子图查询
Uniswap V2 的子图是最成熟的。我最早做套利策略时，就是靠它抓的池子数据。
它的查询端点很固定。主网地址是：https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
你想想看，一个简单的查询就能拿到所有交易对和流动性。我贴一个我常用的示例：
{
pairs(first: 10, orderBy: reserveUSD, orderDirection: desc) {
id
token0 { symbol }
token1 { symbol }
reserve0
reserve1
volumeUSD
totalSupply
}
}这个查询返回了按美元流动性排名的前10个池子。嗯，这里要注意：reserveUSD 是子图计算出来的近似值，不是精确的链上数据。做高频策略时，别直接拿它当价格依据。
我的经验： 我曾经在V2上抓过一笔异常交易，发现子图数据有15秒的延迟。所以做套利时，我建议你同时监听链上事件做补充。
3.2 Uniswap V3 子图查询
V3 比 V2 复杂得多。引入了 ticks 和 范围订单。子图结构也变了。
V3 主网端点：https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v3
我个人觉得 V3 最核心的是 ticks 表。它记录了每个价格区间的流动性分布。做流动性挖矿策略时，这个数据是命根子。
{
pool(id: "0x8ad599c3a0ff1de082011efddc58f1908eb6e6d8") {
tick
sqrtPrice
liquidity
ticks(first: 5, orderBy: tickIdx, orderDirection: asc) {
tickIdx
liquidityNet
liquidityGross
}
}
}这个查询返回了 USDC/ETH 0.3% 池子的当前 tick 和附近5个 tick 的流动性。为什么重要？因为你可以算出当前价格附近有多少深度，滑点有多大。
避坑指南： 我曾经在V3上抓 tick 数据时，发现 liquidityNet 是累加值，不是绝对值。如果你要算某个区间的总流动性，得自己累加。别直接拿来用。
3.3 PancakeSwap 数据接口
PancakeSwap 跑在 BSC 上，子图地址不一样。它的数据结构和 Uniswap V2 几乎一样，毕竟 Fork 的嘛。
BSC 主网端点：https://api.thegraph.com/subgraphs/name/pancakeswap/pairs
我建议你直接用和 Uniswap V2 一样的查询语句，改一下端点就行。但有个坑：PancakeSwap 的 volumeUSD 有时候不准，因为 BSC 上的稳定币价格波动大。
{
pairs(first: 5, where: {volumeUSD_gt: "1000000"}) {
id
token0 { symbol }
token1 { symbol }
reserve0
reserve1
volumeUSD
}
}这个查询只返回日交易量超过100万美元的池子。做跨链套利时，我经常用这个过滤掉流动性差的池子。
小技巧： 我习惯在 PancakeSwap 上同时查 hourlySnapshot 表，拿小时级数据做波动率分析。比日数据敏感得多。
3.4 SushiSwap 数据获取
SushiSwap 也是 Fork 的 Uniswap V2，但它在多链部署。主网、Arbitrum、Polygon 都有。
主网端点：https://api.thegraph.com/subgraphs/name/sushiswap/exchange
我个人觉得 SushiSwap 的亮点是它的 liquidityPositions 表。你可以查到某个地址在哪些池子里有流动性。做跟单策略时很有用。
{
liquidityPositions(where: {user: "0x你的地址"}) {
pair {
id
token0 { symbol }
token1 { symbol }
}
liquidityTokenBalance
}
}这个查询返回了某个地址在所有 SushiSwap 池子里的 LP 持仓。嗯，这里要注意：liquidityTokenBalance 是 LP Token 的数量，不是美元价值。你得自己乘上价格。
避坑指南： 我曾经在 Arbitrum 上抓 SushiSwap 数据，发现子图同步速度比主网慢很多。做高频策略时，建议用 RPC 直接读合约状态。
3.5 DEX聚合器（1inch）数据源
1inch 不是 DEX，它是聚合器。它把多个 DEX 的流动性汇总起来，给你最优报价。
1inch 提供了 REST API，不是子图。端点：https://api.1inch.io/v5.0/1/quote
你想想看，如果你要查某个交易对在所有 DEX 上的最优价格，用 1inch 的 API 最方便。它帮你算好了滑点和 gas。
GET /v5.0/1/quote?fromTokenAddress=0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE&toTokenAddress=0xdAC17F958D2ee523a2206206994597C13D831ec7&amount=1000000000000000000这个请求查的是用1个ETH换USDT的最优报价。返回结果里包含了 toTokenAmount、estimatedGas、protocols 字段。其中 protocols 告诉你这个报价来自哪个 DEX。
核心观点： 1inch 的数据适合做价格发现和路由优化。但别用它做历史回测，因为它只给实时报价，没有历史数据。
我个人习惯把 1inch 的报价和子图数据结合起来用。子图拿历史流动性，1inch 拿实时最优价。两者互补，策略才稳。
我的经验： 我曾经在 1inch 上发现一个 bug：当交易量特别大时，它的报价会忽略某些小 DEX 的流动性。所以做鲸鱼策略时，我建议你同时查几个 DEX 的深度。
知识体系结构图
下面这张图帮你理清 DEX 数据抓取的整体脉络。从数据源到应用层，一目了然。
这张图展示了从数据源到最终应用的完整链路。你抓数据时，先确定用哪个 DEX，再选接口类型，最后落到具体场景。我个人习惯把子图查询和 RPC 直连结合起来用，一个拿历史，一个拿实时。
总结一下： Uniswap V2/V3 用子图，PancakeSwap 和 SushiSwap 同理，1inch 用 REST API。记住每个平台的端点地址和核心表结构，数据抓取就完成了一半。
公众号:蓝海数据掘金营，微信deep3321