2. 核心细节解析与实操要点2.1 认识三大常用API的数据结构NASA公开API的返回格式绝大多数是JSON但不同接口的字段结构差异很大这是新手最容易踩坑的地方。以我项目里用到的三个为例APOD每日天文一图返回字段相对简单核心字段有date、explanation、hdurl、media_type、title。其中media_type有image和video两种如果直接全部按图片处理脚本跑一半就会报错。需要先根据media_type做分支处理。Mars Rover Photos火星车照片返回结构是嵌套的根节点是photos数组每个元素里又嵌套rover对象和camera对象。rover里还有max_date、total_photos这些元信息处理时要小心层级。NeoWS近地天体返回结构最复杂根节点是near_earth_objects它是一个键为日期字符串的字典不是数组。如果不先弄清楚这一点直接用pd.DataFrame(data)会得到一堆乱码。数据结构决定了后面的处理逻辑建议动手写代码前先用浏览器打开接口地址把返回的JSON粘贴到格式化工具里看一遍心里有数再开发。这一步花十分钟后面能省两小时。接口名称根节点类型嵌套层级容易踩的坑APOD单对象无嵌套图片/视频类型混合Mars Rover数组两层嵌套rover和camera对象各自有元数据NeoWS字典键为日期字符串直接转DataFrame会错乱2.2 参数构造与请求频率控制NASA API的请求参数大部分通过URL的query string传递比如火星车照片接口必须传earth_date或sol其中一个不传就直接报400错误。日期格式必须是YYYY-MM-DD这是硬性规定Python的datetime对象需要先调用strftime转换。速率限制方面没有API key的匿名请求通常限制在每小时30次左右申请了key之后提高到每小时50次。对批量数据抓取来说这个配额很快就用完所以代码里必须加上暂停控制。我用的是简单的time.sleep(1)每请求一次停一秒确保不触发封禁。实测稳得很从来没被限流过。选什么样的earth_date也是个学问。火星车的max_date不是今天而是地球上的某一天因为火星和地球的历法不一样。我一开始直接用当天的日期去查返回空数组排查了半天才发现要先用查询接口拿max_date。这个细节文档里没写明白但实际开发中非常重要。2.3 环境配置与安全存放密钥请求头里带着API key是最常见的做法——我这里说“最常见”并不代表推荐更稳妥的方式是放在设置文件或环境变量里然后用代码读取而不是直接硬编码在脚本里。但为了演示简洁代码示例里通常直接写在URL参数中实际部署到服务器时要改成从环境变量读取。一个更安全的做法是把密钥放进.env文件里用python-dotenv加载到当前进程的环境变量中。这样脚本提交到代码仓库时.env不会跟着上传密钥就不会泄露。某开发者就吃过这个亏把API key直接写进了代码并推到了公共仓库几分钟后就被爬虫抓走刷爆了配额只好重新申请。不要觉得这种事离自己很远工具性的小项目也要养成好习惯。3. 实操过程与核心环节实现3.1 初始化项目与依赖安装项目结构按标准Python工程的套路来组织nasa_api_project/ ├── config.py # 配置文件存放API key和相关参数 ├── fetch_apod.py # 抓取APOD数据 ├── fetch_mars.py # 抓取火星车照片数据 ├── fetch_neows.py # 抓取近地天体数据 ├── process_data.py # 数据处理模块 ├── requirements.txt # 依赖清单 └── data/ # 存放获取的原始数据依赖方面requests库是核心pandas做二次加工python-dotenv管理密钥。执行以下命令安装pip install requests pandas python-dotenv如果是在国内网络环境下安装先把pip源换成国内镜像站速度会快很多。实测下来这个组合能覆盖绝大多数需求够用了。3.2 获取并保存APOD每日天文数据APOD接口最简单适合热身。核心代码逻辑是这样的import requests import os from datetime import datetime API_KEY os.environ.get(NASA_API_KEY) URL https://api.nasa.gov/planetary/apod def fetch_apod(dateNone): params {api_key: API_KEY} if date: params[date] date.strftime(%Y-%m-%d) resp requests.get(URL, paramsparams, timeout10) resp.raise_for_status() return resp.json() # 获取今日数据 apod_data fetch_apod() print(apod_data[title]) print(apod_data[media_type])这段代码里有两个细节值得注意。第一是timeout10不设置超时的话万一NASA接口抽风脚本会一直挂在那边不返回白白浪费配额。第二是raise_for_status()它会自动检查HTTP状态码非200状态直接抛异常省去了手动判断的麻烦。保存到本地时我一般会把JSON原始文件和数据清洗后的结果分开存放。原始文件用日期命名方便回溯import json from pathlib import Path Path(data/raw).mkdir(parentsTrue, exist_okTrue) raw_path Path(data/raw) / fapod_{date}.json with open(raw_path, w, encodingutf-8) as f: json.dump(apod_data, f, ensure_asciiFalse, indent2)有些小伙伴喜欢把数据塞进SQLite这个思路没问题但前期探索阶段还是以JSON文件为主结构灵活排查问题方便。等后续跑通了再迁移到正式存储系统也不迟。3.3 批量抓取火星车照片数据火星车接口比APOD复杂一个量级需要同时处理日期遍历和数据结构嵌套。下面这段代码是核心逻辑我加了详细的注释import requests import pandas as pd from datetime import datetime, timedelta def fetch_mars_photos(earth_date): url https://api.nasa.gov/mars-photos/api/v1/rovers/curiosity/photos params { earth_date: earth_date, api_key: API_KEY, } resp requests.get(url, paramsparams, timeout10) if resp.status_code 200: return resp.json().get(photos, []) return [] # 连续抓取7天数据 start_date datetime(2024, 6, 1) for i in range(7): date_str (start_date timedelta(daysi)).strftime(%Y-%m-%d) photos fetch_mars_photos(date_str) print(f{date_str}: {len(photos)} photos) time.sleep(1)这里我特意用get(photos, [])而不是data[photos]是因为有些日期火星车没拍照接口返回的JSON里没有photos键用get方法就不会抛出KeyError。一个简单的容错处理能让脚本稳定性提升很多。抓下来的数据是嵌套结构直接用pd.DataFrame(photos)会产生一堆字典列不便于分析。需要做一层扁平化处理把嵌套的camera和rover字段提取出来def flatten_photos(photos): records [] for p in photos: records.append({ id: p[id], sol: p[sol], camera_name: p[camera][name], camera_full_name: p[camera][full_name], img_src: p[img_src], earth_date: p[earth_date], rover_name: p[rover][name], rover_status: p[rover][status], }) return pd.DataFrame(records)扁平化处理之后的数据结构清晰多了后续存CSV、做图表都顺手。这里建议不要直接把所有字段一股脑塞进DataFrame而是按分析需求挑出需要的列减少数据冗余。3.4 近地天体数据的清洗与统计近地天体数据是三个接口中最难处理的。接口返回的near_earth_objects是一个以日期为键的字典需要先转成列表格式再处理。我的代码如下def process_neows(data): all_objects [] for date, objects in data[near_earth_objects].items(): for obj in objects: all_objects.append({ date: date, name: obj[name], diameter_min: obj[estimated_diameter][meters][estimated_diameter_min], diameter_max: obj[estimated_diameter][meters][estimated_diameter_max], is_hazardous: obj[is_potentially_hazardous_asteroid], velocity_kmh: obj[close_approach_data][0][relative_velocity][kilometers_per_hour], miss_distance_km: obj[close_approach_data][0][miss_distance][kilometers], }) return pd.DataFrame(all_objects)这段代码里面有几个坑。is_potentially_hazardous_asteroid是个布尔值直接转NumPy的bool类型后存入CSV会变成True/False后续读出来做条件筛选没问题。close_approach_data是个列表即使只有一个元素也得用下标访问因为未来可能返回多条数据——代码的健壮性要在这种地方下功夫。处理完毕后做个简单的统计df process_neows(data) potentially_hazardous df[df[is_hazardous] True] print(f当天共记录 {len(df)} 颗近地天体) print(f其中潜在危险天体 {len(potentially_hazardous)} 颗)如果做连续一周的数据抓取可以把每天的结果累积起来然后用pd.concat合并成一个大表做更长时间维度的趋势分析。这是后续扩展的方向但起步阶段先把单日的数据处理跑通更重要。4. 常见问题与排查技巧实录4.1 三个非常容易踩的坑问题一日期格式不正确导致400错误NASA的日期参数严格遵循YYYY-MM-DD格式传2024/6/1或2024-6-1都会报错。解决方法是统一用datetime.strftime(%Y-%m-%d)生成日期字符串。这个错误很容易排查因为返回的状态码和错误信息都很明确但新手往往被一堆HTML格式的错误信息吓到以为是网络问题。问题二请求频率过高触发速率限制不带API key的匿名请求每小时只有30次配额用Python写循环抓数据非常容易超。触发限流后接口返回429状态码解决方法是加上time.sleep(1)把请求间隔控制在1秒以上。如果想更稳妥可以做一个简单的重试机制遇到429等10秒再重试一次。实测下来配合API key和1秒间隔完全够用。问题三JSON结构判断错误导致处理结果异常NeoWS的根节点是字典不是数组Mars Rover的数据有多层嵌套不弄清楚结构直接硬编码处理会得到错误结果。解决方案是先做数据探查把原始JSON打印出来看一遍再动代码。4.2 排查思路与工具推荐调试这类接口时我习惯先用浏览器的开发者工具或者Postman直接发一个请求确认数据结构和返回内容再回过来写Python代码。这样能快速区分是接口问题还是代码问题。遇到比较棘手的JSON结构解析问题可以用json.dumps(data, indent2, ensure_asciiFalse)把数据打印出来格式化后的层级一目了然。不要直接打印整个JSON字符串会把终端刷屏先打印前几个元素了解结构就够了。4.3 批量抓取策略与数据保全建议做批量抓取时建议每抓一条就立刻保存一条不要攒在内存里最后统一写盘。原因是中途网络波动或程序崩溃都可能导致数据丢失前功尽弃。用json.dump边抓边写即使中断了已经保存的数据不会丢。另外一个建议是保存下来的原始数据不要删留一份备份。后续处理代码升级了用同样的原始数据可以重新跑一遍对比新旧结果差异。数据处理里这是很基本的工作习惯。5. 从数据到价值的进阶路径5.1 从简单的数据预览到多维度分析拿到基础数据之后能干的事情其实比自己想得多。APOD数据可以做成一个个人主页的每日背景图自动更新火星车照片数据可以统计不同相机类型的拍摄频率结合sol火星日做时间序列分析近地天体数据可以分析危险天体的直径分布和接近速度。这些都是很好的练手方向。当时我就用近地天体数据做了一个简单的分析统计每月的近地天体数量和潜在危险天体占比。基于pandas的resample功能按月聚合配合matplotlib画折线图很直观就能看出某些月份的近地天体数量明显偏多。虽然这只是基础统计不是严格的天文学研究但作为数据科学练手项目足够有意思了。5.2 把数据处理函数封装成可复用模块项目跑通后代码会越来越长。这时候就要开始做模块化封装把请求逻辑、清洗逻辑、存储逻辑拆分到不同文件里。具体来说请求模块统一管理API密钥、超时时间、重试策略清洗模块负责把原始JSON转成规整的DataFrame存储模块决定写CSV、写JSON还是写数据库这样各层之间解耦后面哪怕更换接口版本也只需要改对应模块不会牵一发动全身。这个习惯越早养成越好等到代码写了几千行再重构成本就高了。6. 个人踩坑复盘与体验总结整个项目做下来我最大的体会是公开数据的价值不在于数据本身而在于怎么处理、怎么挖掘、怎么呈现。NASA接口返回的原始JSON只是半成品把它变成能用的表格、好看的图表、有说服力的分析结论这才是工程师的工作。有个小教训值得一提最开始我做火星车数据可视化时没有仔细筛选img_src的有效性直接把所有照片链接拿来下载结果其中相当一部分链接返回404。后来加了状态码检查才把这个问题解决。这件事提醒我公开数据的质量是参差不齐的作为处理方必须自己做好数据校验。如果后续想继续深入可以考虑这几个方向做一个自动每日抓取的定时任务把数据存到SQLite里做长期积累或者用FastAPI把分析结果封装成接口供其他小程序调用。NASA的数据源更新稳定接口开放且文档完善是练手公开数据处理的绝佳起点。希望这篇文章能帮助更多人少走弯路顺利跑通自己的第一个NASA数据项目。 
长河君 · 2026/10/22 13:42:17 · 阅读 1.2k NASA公开API数据抓取实战：三大接口JSON解析与清洗
2. 核心细节解析与实操要点2.1 认识三大常用API的数据结构NASA公开API的返回格式绝大多数是JSON但不同接口的字段结构差异很大这是新手最容易踩坑的地方。以我项目里用到的三个为例APOD每日天文一图返回字段相对简单核心字段有date、explanation、hdurl、media_type、title。其中media_type有image和video两种如果直接全部按图片处理脚本跑一半就会报错。需要先根据media_type做分支处理。Mars Rover Photos火星车照片返回结构是嵌套的根节点是photos数组每个元素里又嵌套rover对象和camera对象。rover里还有max_date、total_photos这些元信息处理时要小心层级。NeoWS近地天体返回结构最复杂根节点是near_earth_objects它是一个键为日期字符串的字典不是数组。如果不先弄清楚这一点直接用pd.DataFrame(data)会得到一堆乱码。数据结构决定了后面的处理逻辑建议动手写代码前先用浏览器打开接口地址把返回的JSON粘贴到格式化工具里看一遍心里有数再开发。这一步花十分钟后面能省两小时。接口名称根节点类型嵌套层级容易踩的坑APOD单对象无嵌套图片/视频类型混合Mars Rover数组两层嵌套rover和camera对象各自有元数据NeoWS字典键为日期字符串直接转DataFrame会错乱2.2 参数构造与请求频率控制NASA API的请求参数大部分通过URL的query string传递比如火星车照片接口必须传earth_date或sol其中一个不传就直接报400错误。日期格式必须是YYYY-MM-DD这是硬性规定Python的datetime对象需要先调用strftime转换。速率限制方面没有API key的匿名请求通常限制在每小时30次左右申请了key之后提高到每小时50次。对批量数据抓取来说这个配额很快就用完所以代码里必须加上暂停控制。我用的是简单的time.sleep(1)每请求一次停一秒确保不触发封禁。实测稳得很从来没被限流过。选什么样的earth_date也是个学问。火星车的max_date不是今天而是地球上的某一天因为火星和地球的历法不一样。我一开始直接用当天的日期去查返回空数组排查了半天才发现要先用查询接口拿max_date。这个细节文档里没写明白但实际开发中非常重要。2.3 环境配置与安全存放密钥请求头里带着API key是最常见的做法——我这里说“最常见”并不代表推荐更稳妥的方式是放在设置文件或环境变量里然后用代码读取而不是直接硬编码在脚本里。但为了演示简洁代码示例里通常直接写在URL参数中实际部署到服务器时要改成从环境变量读取。一个更安全的做法是把密钥放进.env文件里用python-dotenv加载到当前进程的环境变量中。这样脚本提交到代码仓库时.env不会跟着上传密钥就不会泄露。某开发者就吃过这个亏把API key直接写进了代码并推到了公共仓库几分钟后就被爬虫抓走刷爆了配额只好重新申请。不要觉得这种事离自己很远工具性的小项目也要养成好习惯。3. 实操过程与核心环节实现3.1 初始化项目与依赖安装项目结构按标准Python工程的套路来组织nasa_api_project/ ├── config.py # 配置文件存放API key和相关参数 ├── fetch_apod.py # 抓取APOD数据 ├── fetch_mars.py # 抓取火星车照片数据 ├── fetch_neows.py # 抓取近地天体数据 ├── process_data.py # 数据处理模块 ├── requirements.txt # 依赖清单 └── data/ # 存放获取的原始数据依赖方面requests库是核心pandas做二次加工python-dotenv管理密钥。执行以下命令安装pip install requests pandas python-dotenv如果是在国内网络环境下安装先把pip源换成国内镜像站速度会快很多。实测下来这个组合能覆盖绝大多数需求够用了。3.2 获取并保存APOD每日天文数据APOD接口最简单适合热身。核心代码逻辑是这样的import requests import os from datetime import datetime API_KEY os.environ.get(NASA_API_KEY) URL https://api.nasa.gov/planetary/apod def fetch_apod(dateNone): params {api_key: API_KEY} if date: params[date] date.strftime(%Y-%m-%d) resp requests.get(URL, paramsparams, timeout10) resp.raise_for_status() return resp.json() # 获取今日数据 apod_data fetch_apod() print(apod_data[title]) print(apod_data[media_type])这段代码里有两个细节值得注意。第一是timeout10不设置超时的话万一NASA接口抽风脚本会一直挂在那边不返回白白浪费配额。第二是raise_for_status()它会自动检查HTTP状态码非200状态直接抛异常省去了手动判断的麻烦。保存到本地时我一般会把JSON原始文件和数据清洗后的结果分开存放。原始文件用日期命名方便回溯import json from pathlib import Path Path(data/raw).mkdir(parentsTrue, exist_okTrue) raw_path Path(data/raw) / fapod_{date}.json with open(raw_path, w, encodingutf-8) as f: json.dump(apod_data, f, ensure_asciiFalse, indent2)有些小伙伴喜欢把数据塞进SQLite这个思路没问题但前期探索阶段还是以JSON文件为主结构灵活排查问题方便。等后续跑通了再迁移到正式存储系统也不迟。3.3 批量抓取火星车照片数据火星车接口比APOD复杂一个量级需要同时处理日期遍历和数据结构嵌套。下面这段代码是核心逻辑我加了详细的注释import requests import pandas as pd from datetime import datetime, timedelta def fetch_mars_photos(earth_date): url https://api.nasa.gov/mars-photos/api/v1/rovers/curiosity/photos params { earth_date: earth_date, api_key: API_KEY, } resp requests.get(url, paramsparams, timeout10) if resp.status_code 200: return resp.json().get(photos, []) return [] # 连续抓取7天数据 start_date datetime(2024, 6, 1) for i in range(7): date_str (start_date timedelta(daysi)).strftime(%Y-%m-%d) photos fetch_mars_photos(date_str) print(f{date_str}: {len(photos)} photos) time.sleep(1)这里我特意用get(photos, [])而不是data[photos]是因为有些日期火星车没拍照接口返回的JSON里没有photos键用get方法就不会抛出KeyError。一个简单的容错处理能让脚本稳定性提升很多。抓下来的数据是嵌套结构直接用pd.DataFrame(photos)会产生一堆字典列不便于分析。需要做一层扁平化处理把嵌套的camera和rover字段提取出来def flatten_photos(photos): records [] for p in photos: records.append({ id: p[id], sol: p[sol], camera_name: p[camera][name], camera_full_name: p[camera][full_name], img_src: p[img_src], earth_date: p[earth_date], rover_name: p[rover][name], rover_status: p[rover][status], }) return pd.DataFrame(records)扁平化处理之后的数据结构清晰多了后续存CSV、做图表都顺手。这里建议不要直接把所有字段一股脑塞进DataFrame而是按分析需求挑出需要的列减少数据冗余。3.4 近地天体数据的清洗与统计近地天体数据是三个接口中最难处理的。接口返回的near_earth_objects是一个以日期为键的字典需要先转成列表格式再处理。我的代码如下def process_neows(data): all_objects [] for date, objects in data[near_earth_objects].items(): for obj in objects: all_objects.append({ date: date, name: obj[name], diameter_min: obj[estimated_diameter][meters][estimated_diameter_min], diameter_max: obj[estimated_diameter][meters][estimated_diameter_max], is_hazardous: obj[is_potentially_hazardous_asteroid], velocity_kmh: obj[close_approach_data][0][relative_velocity][kilometers_per_hour], miss_distance_km: obj[close_approach_data][0][miss_distance][kilometers], }) return pd.DataFrame(all_objects)这段代码里面有几个坑。is_potentially_hazardous_asteroid是个布尔值直接转NumPy的bool类型后存入CSV会变成True/False后续读出来做条件筛选没问题。close_approach_data是个列表即使只有一个元素也得用下标访问因为未来可能返回多条数据——代码的健壮性要在这种地方下功夫。处理完毕后做个简单的统计df process_neows(data) potentially_hazardous df[df[is_hazardous] True] print(f当天共记录 {len(df)} 颗近地天体) print(f其中潜在危险天体 {len(potentially_hazardous)} 颗)如果做连续一周的数据抓取可以把每天的结果累积起来然后用pd.concat合并成一个大表做更长时间维度的趋势分析。这是后续扩展的方向但起步阶段先把单日的数据处理跑通更重要。4. 常见问题与排查技巧实录4.1 三个非常容易踩的坑问题一日期格式不正确导致400错误NASA的日期参数严格遵循YYYY-MM-DD格式传2024/6/1或2024-6-1都会报错。解决方法是统一用datetime.strftime(%Y-%m-%d)生成日期字符串。这个错误很容易排查因为返回的状态码和错误信息都很明确但新手往往被一堆HTML格式的错误信息吓到以为是网络问题。问题二请求频率过高触发速率限制不带API key的匿名请求每小时只有30次配额用Python写循环抓数据非常容易超。触发限流后接口返回429状态码解决方法是加上time.sleep(1)把请求间隔控制在1秒以上。如果想更稳妥可以做一个简单的重试机制遇到429等10秒再重试一次。实测下来配合API key和1秒间隔完全够用。问题三JSON结构判断错误导致处理结果异常NeoWS的根节点是字典不是数组Mars Rover的数据有多层嵌套不弄清楚结构直接硬编码处理会得到错误结果。解决方案是先做数据探查把原始JSON打印出来看一遍再动代码。4.2 排查思路与工具推荐调试这类接口时我习惯先用浏览器的开发者工具或者Postman直接发一个请求确认数据结构和返回内容再回过来写Python代码。这样能快速区分是接口问题还是代码问题。遇到比较棘手的JSON结构解析问题可以用json.dumps(data, indent2, ensure_asciiFalse)把数据打印出来格式化后的层级一目了然。不要直接打印整个JSON字符串会把终端刷屏先打印前几个元素了解结构就够了。4.3 批量抓取策略与数据保全建议做批量抓取时建议每抓一条就立刻保存一条不要攒在内存里最后统一写盘。原因是中途网络波动或程序崩溃都可能导致数据丢失前功尽弃。用json.dump边抓边写即使中断了已经保存的数据不会丢。另外一个建议是保存下来的原始数据不要删留一份备份。后续处理代码升级了用同样的原始数据可以重新跑一遍对比新旧结果差异。数据处理里这是很基本的工作习惯。5. 从数据到价值的进阶路径5.1 从简单的数据预览到多维度分析拿到基础数据之后能干的事情其实比自己想得多。APOD数据可以做成一个个人主页的每日背景图自动更新火星车照片数据可以统计不同相机类型的拍摄频率结合sol火星日做时间序列分析近地天体数据可以分析危险天体的直径分布和接近速度。这些都是很好的练手方向。当时我就用近地天体数据做了一个简单的分析统计每月的近地天体数量和潜在危险天体占比。基于pandas的resample功能按月聚合配合matplotlib画折线图很直观就能看出某些月份的近地天体数量明显偏多。虽然这只是基础统计不是严格的天文学研究但作为数据科学练手项目足够有意思了。5.2 把数据处理函数封装成可复用模块项目跑通后代码会越来越长。这时候就要开始做模块化封装把请求逻辑、清洗逻辑、存储逻辑拆分到不同文件里。具体来说请求模块统一管理API密钥、超时时间、重试策略清洗模块负责把原始JSON转成规整的DataFrame存储模块决定写CSV、写JSON还是写数据库这样各层之间解耦后面哪怕更换接口版本也只需要改对应模块不会牵一发动全身。这个习惯越早养成越好等到代码写了几千行再重构成本就高了。6. 个人踩坑复盘与体验总结整个项目做下来我最大的体会是公开数据的价值不在于数据本身而在于怎么处理、怎么挖掘、怎么呈现。NASA接口返回的原始JSON只是半成品把它变成能用的表格、好看的图表、有说服力的分析结论这才是工程师的工作。有个小教训值得一提最开始我做火星车数据可视化时没有仔细筛选img_src的有效性直接把所有照片链接拿来下载结果其中相当一部分链接返回404。后来加了状态码检查才把这个问题解决。这件事提醒我公开数据的质量是参差不齐的作为处理方必须自己做好数据校验。如果后续想继续深入可以考虑这几个方向做一个自动每日抓取的定时任务把数据存到SQLite里做长期积累或者用FastAPI把分析结果封装成接口供其他小程序调用。NASA的数据源更新稳定接口开放且文档完善是练手公开数据处理的绝佳起点。希望这篇文章能帮助更多人少走弯路顺利跑通自己的第一个NASA数据项目。