Nutrola开放食品营养数据集：500K+食品可供下载
下载Nutrola的开放食品营养数据集，包含500K+经过验证的条目，包括卡路里、宏量营养素、微量营养素和份量信息。以CSV和JSON格式提供，适用于研究、开发和教育。
优质的营养数据难以获取。研究人员花费数周时间清理政府数据库，开发者编写的爬虫每月都可能失效，撰写论文的学生只能依赖小而过时的样本，因为从头组建一个全面的数据集在学术时间表上并不现实。
我们构建了Nutrola的食品数据库，以支持我们的卡路里追踪应用。在过去三年中，我们投入了大量精力，确保这些数据准确、全面且结构良好。今天，我们将这个数据库的一个经过筛选的子集作为开放数据集发布：超过500,000个经过验证的食品条目，免费提供CSV和JSON格式下载。
本文将介绍有关该数据集的所有信息——内容、下载方式、数据结构、许可协议、质量方法论，以及它与其他公开可用的营养数据源的比较。
数据集包含的内容
Nutrola开放食品营养数据集包含超过500,000个食品条目，涵盖生鲜食材、普通食品、品牌消费品和常见餐厅菜品。每个条目都经过我们多层次的质量控制流程验证，具体流程在我们关于如何构建食品数据库的文章中有详细描述。
每个食品条目包括以下数据点：
- 食品名称 — 食品项目的常用名称（英文），适用时包含品牌名称
- 卡路里 — 每100克和每份的能量含量（千卡）
- 宏量营养素 — 蛋白质、总脂肪、饱和脂肪、反式脂肪、总碳水化合物、膳食纤维、总糖和添加糖，单位为克
- 微量营养素 — 包括30多种维生素和矿物质，如维生素A、维生素C、维生素D、维生素E、维生素K、硫胺素、核黄素、烟酸、维生素B6、叶酸、维生素B12、钙、铁、镁、磷、钾、钠、锌、铜、锰、硒等
- 份量信息 — 标准份量描述（例如，“1个中等苹果”，“1杯熟食”），份量重量（克），以及每种食品最多三种替代份量
- 食品类别 — 使用我们内部分类法的层级分类（例如，乳制品 > 奶酪 > 硬奶酪）
- 原产国 — 食品产品主要销售的国家或地区，或成分常见消费的地方
- 条形码（如适用） — 品牌产品的UPC或EAN代码
- 数据来源标签 — 说明条目来源的标签，表明该条目是来自政府数据库、制造商数据、实验室分析，还是我们内部验证团队的结果
示例数据
以下是数据集中一些条目的选取，以便让您了解其结构和细节：
| food_id | food_name | category | country | calories_per_100g | protein_g | fat_g | carbs_g | fiber_g | serving_desc | serving_g |
|---|---|---|---|---|---|---|---|---|---|---|
| NF-001247 | 生鸡胸肉，生，去皮 | 家禽 > 鸡肉 | 美国 | 120 | 22.5 | 2.6 | 0.0 | 0.0 | 1块（174克） | 174 |
| NF-008391 | Fage Total 0% 希腊酸奶 | 乳制品 > 酸奶 > 希腊酸奶 | 希腊 | 54 | 10.3 | 0.0 | 3.0 | 0.0 | 1个容器（150克） | 150 |
| NF-014205 | 白色巴斯马蒂米，熟 | 谷物 > 米 | 印度 | 130 | 2.7 | 0.3 | 28.2 | 0.4 | 1杯（158克） | 158 |
| NF-022876 | 哈斯鳄梨，生 | 水果 > 热带 | 墨西哥 | 160 | 2.0 | 14.7 | 8.5 | 6.7 | 1/2个鳄梨（68克） | 68 |
| NF-031560 | Barilla通心粉，干 | 意大利面 > 干 | 意大利 | 359 | 12.5 | 2.0 | 71.2 | 3.0 | 2盎司（56克） | 56 |
| NF-045892 | 泡菜，传统大白菜 | 蔬菜 > 发酵 | 韩国 | 15 | 1.1 | 0.5 | 2.4 | 1.6 | 1/2杯（75克） | 75 |
| NF-053714 | 大西洋鲑鱼，生，养殖 | 鱼 > 鲑鱼 | 挪威 | 208 | 20.4 | 13.4 | 0.0 | 0.0 | 1片（113克） | 113 |
| NF-067283 | 鹰嘴豆，罐装，沥干 | 豆类 > 豆 | 美国 | 119 | 6.3 | 2.0 | 18.2 | 5.4 | 1/2杯（120克） | 120 |
完整的数据集还包括更多微量营养素、替代份量、条形码数据和来源标签的列。上表展示了核心营养信息字段。
数据格式
数据集提供两种格式：
CSV
CSV文件使用UTF-8编码，采用逗号分隔。第一行包含列标题。包含逗号的字段用双引号括起来。空值表示为空字段。
CSV格式非常适合Excel和Google Sheets等电子表格工具、R和SPSS等统计软件，以及使用命令行工具如csvkit或xsv进行快速数据探索。
文件：nutrola-open-food-dataset-v3.csv（未压缩约210 MB，压缩后约48 MB）
JSON
JSON文件包含一个对象数组，每个食品条目一个对象。嵌套对象用于结构化字段，如份量信息（包含描述、克重和适用时的毫升等值）和微量营养素概况。
JSON格式更适合应用开发、数据库导入以及需要保留份量和营养组层级结构的工作流程。
文件：nutrola-open-food-dataset-v3.json（未压缩约340 MB，压缩后约62 MB）
两个文件也提供gzip压缩档案，以减少下载时间。
数据结构
以下是数据集中每个字段的完整结构及描述：
| 字段名称 | 类型 | 描述 |
|---|---|---|
food_id |
字符串 | Nutrola食品条目的唯一标识符（格式：NF-XXXXXX） |
food_name |
字符串 | 食品的常用名称，包括品牌（如适用） |
category_l1 |
字符串 | 顶级食品类别（例如，乳制品、谷物、水果） |
category_l2 |
字符串 | 第二级类别（例如，奶酪、米、热带） |
category_l3 |
字符串 | 第三级类别（如适用）（例如，硬奶酪、棕米） |
country |
字符串 | 表示主要市场的ISO 3166-1 alpha-2国家代码 |
brand |
字符串 | 品牌名称；通用食品为null |
barcode |
字符串 | UPC/EAN条形码；如不适用则为null |
calories_per_100g |
浮点数 | 每100克的能量（千卡） |
protein_g |
浮点数 | 每100克的蛋白质（克） |
fat_total_g |
浮点数 | 每100克的总脂肪（克） |
fat_saturated_g |
浮点数 | 每100克的饱和脂肪（克） |
fat_trans_g |
浮点数 | 每100克的反式脂肪（克） |
carbs_total_g |
浮点数 | 每100克的总碳水化合物（克） |
fiber_g |
浮点数 | 每100克的膳食纤维（克） |
sugars_total_g |
浮点数 | 每100克的总糖（克） |
sugars_added_g |
浮点数 | 每100克的添加糖（克） |
sodium_mg |
浮点数 | 每100克的钠（毫克） |
cholesterol_mg |
浮点数 | 每100克的胆固醇（毫克） |
vitamin_a_mcg |
浮点数 | 每100克的维生素A（微克RAE） |
vitamin_c_mg |
浮点数 | 每100克的维生素C（毫克） |
vitamin_d_mcg |
浮点数 | 每100克的维生素D（微克） |
calcium_mg |
浮点数 | 每100克的钙（毫克） |
iron_mg |
浮点数 | 每100克的铁（毫克） |
potassium_mg |
浮点数 | 每100克的钾（毫克） |
magnesium_mg |
浮点数 | 每100克的镁（毫克） |
zinc_mg |
浮点数 | 每100克的锌（毫克） |
phosphorus_mg |
浮点数 | 每100克的磷（毫克） |
selenium_mcg |
浮点数 | 每100克的硒（微克） |
vitamin_b6_mg |
浮点数 | 每100克的维生素B6（毫克） |
vitamin_b12_mcg |
浮点数 | 每100克的维生素B12（微克） |
folate_mcg |
浮点数 | 每100克的叶酸（微克DFE） |
vitamin_e_mg |
浮点数 | 每100克的维生素E（毫克） |
vitamin_k_mcg |
浮点数 | 每100克的维生素K（微克） |
thiamin_mg |
浮点数 | 每100克的硫胺素（B1）（毫克） |
riboflavin_mg |
浮点数 | 每100克的核黄素（B2）（毫克） |
niacin_mg |
浮点数 | 每100克的烟酸（B3）（毫克） |
copper_mg |
浮点数 | 每100克的铜（毫克） |
manganese_mg |
浮点数 | 每100克的锰（毫克） |
serving_1_desc |
字符串 | 主要份量描述（例如，“1杯熟食”） |
serving_1_g |
浮点数 | 主要份量重量（克） |
serving_2_desc |
字符串 | 替代份量描述；如无则为null |
serving_2_g |
浮点数 | 替代份量重量（克） |
serving_3_desc |
字符串 | 第二替代份量描述；如无则为null |
serving_3_g |
浮点数 | 第二替代份量重量（克） |
data_source |
字符串 | 来源标签：“government”、“manufacturer”、“laboratory”或“verified_community” |
last_verified |
字符串 | 条目最后验证的ISO 8601日期（YYYY-MM-DD） |
dataset_version |
字符串 | 数据集版本标识符（例如，“v3.0”） |
所有营养值均以每100克为单位，以便进行一致的比较。要计算每份的营养成分，将每100克的值乘以份量重量（克），然后除以100。
如何下载
数据集托管在我们的公共GitHub仓库中：
github.com/nutrola/open-food-nutrition-dataset
您可以直接从GitHub发布页面下载文件，或克隆该仓库：
git clone https://github.com/nutrola/open-food-nutrition-dataset.git
对于压缩版本：
# 下载CSV（gzip压缩）
wget https://github.com/nutrola/open-food-nutrition-dataset/releases/latest/download/nutrola-open-food-dataset-v3.csv.gz
# 下载JSON（gzip压缩）
wget https://github.com/nutrola/open-food-nutrition-dataset/releases/latest/download/nutrola-open-food-dataset-v3.json.gz
该仓库还包含：
- 详细的
README.md，提供快速入门说明 CHANGELOG.md，记录数据集版本之间的变化scripts/目录，包含用于加载、过滤和分析数据的Python和R示例脚本schema/目录，包含JSON Schema和CSV方言定义
如果您需要包含300万+条目的完整数据库，并希望获得实时更新而非定期快照，请参见我们的营养数据API，以获取开发者访问权限。
用例
学术研究
营养研究人员可以使用该数据集进行饮食模式分析、流行病学建模和营养密度研究，而无需花费数周时间清理和合并政府数据文件。层级分类系统使按食品组过滤变得简单，国家字段则便于跨文化比较。
使用该数据集发表的研究应引用为：Nutrola开放食品营养数据集，v3.0（2026）。可在github.com/nutrola/open-food-nutrition-dataset获取。根据CC BY-SA 4.0许可发布。
应用开发
开发健康、健身或食品相关应用的开发者可以将该数据集用作本地食品数据库。统一的结构和份量数据意味着您可以在不依赖实时API连接的情况下构建功能齐全的食品记录功能。这对于离线优先的移动应用、原型设计和黑客马拉松项目尤其有用。
CSV格式可以直接加载到SQLite、PostgreSQL或任何关系数据库中。JSON格式则可以干净地映射到MongoDB或Firestore等文档存储中。
数据科学与机器学习
该数据集非常适合用于与食品和营养相关的机器学习模型的训练和评估。常见应用包括：
- 食品分类模型 — 使用类别层级作为训练标签，构建分类器，从名称或营养概况中预测食品类别
- 营养估算 — 训练回归模型，根据部分信息（例如，从蛋白质、脂肪和碳水化合物比例估算卡路里）预测卡路里或宏量营养素含量
- 推荐系统 — 构建食品推荐引擎，建议营养相似的替代品
- 异常检测 — 识别不寻常的营养概况，可能表明其他数据集中存在数据质量问题
教育
营养科学的学生和教育工作者可以将该数据集用于课程作业、实验和作业。数据的广度——涵盖来自数十个国家的食品，涵盖每个主要食品组——使其在教授宏量营养素比例、微量营养素密度以及营养概况如何因菜系和食品加工水平而异等概念时非常有用。
公共健康与政策
公共健康组织可以利用这些数据分析特定食品类别或市场的营养状况。国家字段允许按地区过滤，而品牌字段则便于分析品牌与通用食品的营养质量。
数据质量方法论
发布开放数据集毫无意义，如果数据不可信。以下是我们如何确保此次发布的500,000+条目质量的方法。
多来源验证
数据集中的每个条目都经过至少两个独立来源的验证。我们的主要数据来源包括：
- 政府营养数据库 — USDA FoodData Central（美国）、CoFID（英国）、NUTTAB（澳大利亚）、CNF（加拿大）及20多个国家的等效数据库
- 制造商提供的数据 — 通过我们的品牌合作计划，食品制造商直接提交的营养成分标签
- 实验室分析 — 我们团队对高流量食品进行的独立实验室测试，当来源数据存在冲突或过时时使用
- 经过验证的社区提交 — 用户提交的条目经过我们的三步验证流程（自动交叉引用、专家审核和统计异常检测）
自动质量检查
每个条目在进入数据集之前都会经过一系列自动检查：
- 能量平衡验证 — 卡路里含量与Atwater计算（4 kcal/g蛋白质 + 9 kcal/g脂肪 + 4 kcal/g碳水化合物）进行交叉检查。声明的卡路里与计算值偏差超过10%的条目会被标记为手动审核。
- 范围检查 — 每个营养值都与食品类别的生理合理范围进行验证。声称0克脂肪的奶酪条目或声称50克蛋白质的水果条目会立即被标记。
- 交叉条目一致性 — 相似食品进行统计比较。如果新的鸡胸肉条目的值与现有鸡胸肉条目的集群显著不同，则会被保留审核。
- 份量验证 — 份量重量与已知标准份量进行检查。声称重达500克的“1个中等苹果”不会通过。
人工审核
由自动检查标记的条目将经过我们的数据团队的人工审核，该团队包括具有资质的营养师和食品科学家。大约12%的条目在批准之前需要某种形式的人工修正。
持续维护
该数据集不是一次性发布的。我们会定期重新验证条目，优先考虑高流量食品（Nutrola用户最常记录的食品）和其来源数据已更新的条目。当食品制造商重新配方时，我们通过条形码监控系统捕捉到变化，并相应更新条目。
更新频率
我们每季度发布新版本的开放数据集。每次发布包括：
- 自上一个版本以来新增的食品条目
- 识别出的现有条目的更正
- 对重新配方产品的更新营养数据
- 在新来源数据可用时扩展的微量营养素覆盖
当前版本为v3.0，于2026年3月发布。版本历史和变更日志可在GitHub仓库中找到。
如果您需要比季度更新更频繁的数据，我们的营养数据API在48小时内反映更改。
许可
Nutrola开放食品营养数据集根据**知识共享署名-相同方式共享4.0国际版（CC BY-SA 4.0）**许可发布。
这意味着您可以自由地：
- 分享 — 在任何媒介或格式中复制和再分发数据集
- 改编 — 重新混合、转变和基于数据集进行构建，任何目的均可，包括商业用途
在以下条款下：
- 署名 — 您必须给予Nutrola适当的信用，提供许可链接，并指明是否进行了更改
- 相同方式共享 — 如果您重新混合、转变或基于数据集进行构建，您必须在相同的CC BY-SA 4.0许可下分发您的贡献
我们选择CC BY-SA 4.0，因为它在开放性和确保改进回馈社区之间找到了合适的平衡。如果您构建了更好的数据版本，该许可确保您的改进也能对其他人开放。
与其他数据集的比较
目前有几个公开可用的营养数据集。以下是Nutrola开放食品营养数据集与两个最广泛使用的替代数据集的比较。
vs. USDA FoodData Central
USDA FoodData Central是美国营养数据的金标准。它内容详尽、文档齐全，并得到实验室分析的支持。然而，它有一些Nutrola数据集所解决的局限性：
| 维度 | USDA FoodData Central | Nutrola开放数据集 |
|---|---|---|
| 总条目 | ~400,000（基础、SR遗留、品牌合并） | 500,000+ |
| 地理覆盖 | 主要是美国 | 47个国家 |
| 品牌产品 | 仅限美国品牌，通常过时 | 国际品牌，季度验证 |
| 数据格式 | 多种不兼容的文件格式，复杂的关系结构 | 单一CSV或JSON文件，扁平结构 |
| 份量信息 | 在子数据库中不一致 | 标准化格式，每种食品最多3个份量 |
| 易用性 | 需要大量数据工程来合并子数据库 | 下载一个文件即可开始工作 |
| 更新频率 | 根据子数据库而异（某些每年更新） | 每季度更新 |
如果您的工作专注于美国食品，并且需要最深入的营养概况（USDA覆盖150多种营养素），FoodData Central是更好的选择。如果您需要国际覆盖、一致的格式，并且希望数据集开箱即用，Nutrola数据集则是更强的选择。
这两个数据集是互补的。许多研究人员使用USDA基础数据进行详细的美国营养分析，并用Nutrola数据补充国际覆盖和品牌产品。
vs. Open Food Facts
Open Food Facts是一个众包数据库，拥有超过300万条目。它在规模上令人印象深刻，涵盖多个国家的产品。然而，其众包性质带来了数据质量挑战：
| 维度 | Open Food Facts | Nutrola开放数据集 |
|---|---|---|
| 总条目 | 3M+ | 500,000+ |
| 数据质量 | 变量 — 众包，带有自动检查 | 验证 — 多来源，人工审核 |
| 完整性 | 许多条目缺少宏/微数据 | 所有条目都有完整的宏数据；90%+有完整的微量营养素概况 |
| 份量信息 | 不一致，常常缺失 | 标准化，始终存在 |
| 分类法 | 众包标签，不一致 | 层级、策划分类法 |
| 营养覆盖 | 每个条目的差异很大 | 所有条目一致覆盖40+种营养素 |
| 数据格式 | MongoDB转储，复杂的嵌套JSON | 清晰的CSV和JSON |
| 许可 | 开放数据库许可（ODbL） | CC BY-SA 4.0 |
Open Food Facts在广度上表现出色——如果您需要通过条形码查找特定的冷门产品，他们可能会有。而Nutrola数据集在深度和一致性上表现更佳——每个条目都符合相同的质量标准，使其在定量分析中更可靠，数据缺口或错误可能会扭曲结果。
如果您正在构建条形码扫描应用并需要最大产品覆盖，Open Food Facts是一个不错的起点。如果您正在训练机器学习模型、进行统计研究或构建对营养准确性要求高的应用，Nutrola数据集的验证数据将为您提供更坚实的基础。
开始使用
下载数据集后，以下是一个在Python中加载和探索数据的快速示例：
import pandas as pd
# 加载数据集
df = pd.read_csv("nutrola-open-food-dataset-v3.csv")
# 基本概述
print(f"总条目数: {len(df):,}")
print(f"覆盖国家: {df['country'].nunique()}")
print(f"食品类别（L1）: {df['category_l1'].nunique()}")
# 查找高蛋白、低卡路里的食品
high_protein = df[
(df["protein_g"] > 20) &
(df["calories_per_100g"] < 150)
].sort_values("protein_g", ascending=False)
print(high_protein[["food_name", "calories_per_100g", "protein_g"]].head(10))
# 分析食品类别的平均宏量营养素
category_macros = df.groupby("category_l1").agg({
"calories_per_100g": "mean",
"protein_g": "mean",
"fat_total_g": "mean",
"carbs_total_g": "mean"
}).round(1)
print(category_macros.sort_values("calories_per_100g", ascending=False))
更多示例——包括R脚本、SQL导入指南和Jupyter笔记本——可在GitHub仓库的scripts/目录中找到。
常见问题
数据集真的可以免费使用吗？
是的。Nutrola开放食品营养数据集根据CC BY-SA 4.0许可发布，允许商业和非商业使用。唯一的要求是您必须将Nutrola作为来源进行适当的信用，并且任何您分发的衍生数据集都必须使用相同的许可。下载文件不需要API密钥、使用限制或注册。
数据集的更新频率如何？
我们每季度发布新版本。每次发布都会添加新食品条目，纠正自上一个版本以来识别的错误，并更新重新配方产品的条目。GitHub仓库的发布页面有完整的版本历史，您可以关注该仓库，以便在发布新版本时收到通知。
我可以使用该数据集构建商业应用吗？
可以。CC BY-SA 4.0许可明确允许商业使用。您可以在付费应用、SaaS产品或任何其他商业环境中使用这些数据。您必须在应用或文档中包含对Nutrola的署名，如果您分发修改后的数据集本身，修改后的版本也必须根据CC BY-SA 4.0许可发布。在您的应用中使用数据（而不重新分发原始数据集）不会触发相同方式共享的要求。
为什么只有500K条目，而Nutrola的完整数据库有300万+？
开放数据集包含我们可以在没有限制的情况下发布的条目。我们的完整数据库包括来自专有来源的数据——直接制造商合作、许可的实验室数据和其他有合同限制的来源。开放数据集中500K条目来自政府数据库、我们自己的实验室分析以及同意开放许可的社区提交。如果您需要访问完整数据库，我们的营养数据API提供了不同的商业条款。
如果我发现数据集中的错误该怎么办？
在GitHub仓库上打开一个问题，提供受影响条目的food_id和错误描述。如果您有来源链接（例如，显示不同营养成分的制造商网站），请包含在内。我们的数据团队每周审核报告的问题，确认的更正将在下一个季度发布中包含。对于紧急更正，我们可能会在季度更新之间推送补丁发布。
这与Nutrola营养数据API有什么关系？
开放数据集是我们数据库的一个经过策划的静态季度快照。API提供对完整的300万+条目数据库的实时访问，具有搜索、过滤、条形码查找和其他功能。可以将开放数据集视为离线或批量使用的基础，而API则是需要实时数据的生产应用的解决方案。许多开发者从开放数据集开始进行原型设计，随后在生产时迁移到API。
