Apache Griffin 介绍与核心概念详解

目标：介绍 Apache Griffin（eBay 开源、Apache 顶级项目）这一大数据数据质量平台的定位、三大核心对象（Measure / DQ Job / Metric）、度量功能矩阵与端到端架构，并基于 0.6.0 官方部署套件的实测给出版本现状与同类选型对比（Great Expectations、Deequ）。文中命令与回显均来自真实环境实测（Linux 服务器 + 官方 compose 部署套件，batch 模式端到端跑通 accuracy 检测）。

一、环境信息

本文所有结论与命令回显均在以下真实环境中验证取得，读者对照学习时可以此为基准。

• 操作系统：Linux（x86_64）
• Apache Griffin：0.6.0（官方代码仓 tag griffin-0.6.0 的部署套件，batch 模式）
• 部署方式：官方 compose 部署套件（部署过程详见《Apache Griffin Docker Compose 部署指南》）
• 实测服务版本：0.2.0（GET /api/v1/version 返回值，版本错位说明见 2.2 节）
• 端到端验证：本专栏《Apache Griffin 数据质量实战详解》在同一环境跑通了 accuracy 度量的完整闭环

部署完成后服务存活与版本的实测核验（Griffin Service 默认监听 38080 端口）：

curl http://localhost:38080/api/v1/version

0.2.0

💡 说明：这一行实测回显包含两个信息——其一，服务已正常监听并响应 HTTP 200；其二，返回的版本号是 0.2.0 而不是 0.6.0，这是 0.6.0 官方部署套件的真实状态（套件引用的组件包标记为 0.3.0，内部服务实际报 0.2.0），选型与使用前必须知道这一事实，详见 2.2 节。

二、软件概述

2.1 项目定位与背景

大数据场景下，"数据对不对、全不全、新不新"长期缺少一个平台级的统一答案：各业务线各自写脚本对账，规则无法沉淀、结果无法展示、调度无法统一。Apache Griffin 正是为解决该问题而生的开源数据质量平台——它由 eBay 发起开源，2016 年底进入 Apache 软件基金会孵化器，是一个面向大数据的数据质量解决方案（官方服务首页的 <title>Griffin - Data Quality Service</title> 即其自我定位，实测抓取确认）。

从官方代码仓的实测 tag 序列可以直接看出它的孵化历程：griffin-0.1.4-incubating、griffin-0.1.5-incubating、griffin-0.1.6-incubating、griffin-0.2.0-incubating、griffin-0.3.0-incubating 均带孵化（incubating）后缀，从 griffin-0.4.0 起后缀消失，即已毕业成为 Apache 顶级项目；当前最新发布 tag 为 griffin-0.6.0（实测仓库 tag 列表）。

其源码仓 master 分支根目录的模块构成（实测枚举）为 dev、griffin-doc、measure、service、ui 与 pom.xml，对应的三大组成即：measure（度量引擎，跑在 Spark 上）、service（REST 服务与调度）、ui（Web 前端）。

2.2 版本现状（0.6.0 官方部署套件实测）

选型前必须清楚 0.6.0 官方部署套件的真实组件版本。实测部署后，各组件版本与来源如下：

关键差异与如何理解这张表：官方 0.6.0 的部署配置文件自 2018 年后未随版本升级组件——组件包标记写着 0.3.0，内部 Griffin Service 实际是 0.2.0，而仓库代码本身是 0.6.0。这意味着用官方套件可以完整体验"部署 + 批量准确率检测 + 指标入库"的主线功能（本专栏实战篇已端到端验证），但不能演示 0.6.0 服务端的新增 API（例如按 id 触发作业的 POST /api/v1/jobs/trigger/:id 在实测 0.2.0 服务上返回 404，而 0.6.0 的官方接口文档里有该 API）。另从实测仓库分支列表看，社区存在 griffin-0.7.0-rc0、griffin-1.0.0-dev、griffin-2.0.0-dev 等开发分支，但均无对应发布 tag，选型时不应依赖。

三、核心架构

3.1 端到端架构与依赖组件

Griffin 是一个端到端（e2e）数据质量引擎：定义度量规则后，由服务端按调度周期发起，Spark 计算结果，指标落到存储并供查询与展示。实测环境的组件关系如下：

+--------------------------------------------------------------------------+
|                        Griffin Service (REST API + UI, 8080)              |
|     measure 定义 | job 调度(quartz) | Hive 元数据接入 | 指标查询            |
+--------+-----------------+------------------+-----------------+----------+
         | 提交度量作业      | 调度元数据        | 库表元数据        | 指标读写
+--------v-------+  +------+------+  +--------+--------+  +------+-----+
| Livy (8998)    |  | PostgreSQL  |  | Hive metastore  |  | Elasticsearch|
| Spark 作业提交  |  | 9.3 (quartz)|  | (thrift 9083)   |  | (9200)      |
+--------+-------+  +-------------+  +-----------------+  +------+-----+
         | yarn-cluster 提交                                          ^
+--------v----------------------------+                                |
| Spark measure 引擎（yarn 上执行）      |--- 指标写入(Elasticsearch) -----+
| 读取 Hive/HDFS 源表与目标表按规则计算  |--- 指标备份落盘(HDFS)
+-------------------------------------+

各依赖组件的角色与实测端口汇总：

💡 说明：这套"一个 all-in-one 主服务 + 一个 Elasticsearch"的两节点形态是官方 batch 套件的默认布局——Spark、Hadoop、Hive、Livy、调度器全部集成在主服务节点内，Elasticsearch 独立部署承接指标。理解这一点有助于评估生产化改造点：生产上通常将计算引擎、调度库、指标存储各自独立成集群。

3.2 三大核心对象：Measure / DQ Job / Metric

Griffin 的领域模型围绕三个对象展开，全部通过 REST API 操作，实测对象与 API 对应关系如下：

三者关系是一条单向流水线：Measure 定义"检查什么"，DQ Job 决定"何时检查、检查哪段时间的数据"，Metric 是"检查结果"。Measure 一旦创建即静态存在；Job 按 cron 周期触发，每轮调度生成一个 job instance（执行实例）；Metric 随每轮执行追加写入。完整的创建、排障与结果核验操作见《Apache Griffin 数据质量实战详解》。

3.3 调度与触发机制

DQ Job 的调度由内嵌 quartz 实现，调度元数据落在 PostgreSQL 的 quartz 库（实测连接日志确认）；作业创建时指定 cron 表达式与时区（实测示例 0 0/4 * * * ? + GMT+8:00）。

每轮触发前还有一道"数据就绪检查"（predicate）：实测生效的实现是 FileExistPredicator，对应度量定义中的 file.exist 谓词——按分区模板（如 /dt=#YYYYMMdd#/hour=#HH#/_DONE）探测 HDFS 上是否已有 _DONE 就绪标志文件，检查未通过则本轮实例标记 NOT_FOUND 等下一轮，不会空跑 Spark 作业。就绪检查的节奏由作业的 predicate.config（如每 1 分钟检查一次、最多重复 2 次）控制。

💡 技术拓展：作业的"手动触发"在不同版本间存在 API 差异，使用前需先核对自己服务端的版本——

触发方式	机制	实测结果
cron 自动调度	quartz 按 cron.expression 周期触发，到达就绪检查后启动	实测可用，0.2.0 服务上为主路径
POST /api/v1/jobs/trigger/:id	按 id 手动触发一轮执行	0.2.0 实测返回 404（该版本无此端点）；0.6.0 官方接口文档与 postman 集合中存在

本文实测环境服务版本为 0.2.0，实际采用 cron 自动调度；若你的服务版本较新，可优先用手动触发 API 做首次验证，再交给 cron 周期调度。

四、功能特性

4.1 度量类型矩阵

Griffin 内置多种数据质量度量类型（dq.type），0.6.0 官方能力矩阵与实测状态如下：

关键差异与选型提示：准确率是实测完整跑通的类型，适合作为上手与验证部署的第一选择；完整性与画像属于批量统计类，规则结构与准确率同源（evaluate.rule.rules 下换 dq.type）；时效性依赖流处理形态。dq.type 取值以你所用版本的官方文档为准，0.2.0 服务实测可正常接受 ACCURACY 类型定义并返回 201。

💡 技术拓展：度量结果的持久化位置（sink）不止一种，创建 Measure 时可声明——

sink	原理/特点	适用场景
ELASTICSEARCH	指标写入 ES 索引，支持检索与 UI 图表聚合	平台查询、UI 展示（默认主路径）
HDFS	指标以文件形式备份落盘到 HDFS	长期留存、供离线二次分析

本文实测环境创建 Measure 时服务端自动挂载了两个 sink（返回 "sinks":["ELASTICSEARCH","HDFS"]），即指标同时写 ES 与 HDFS，无需手动选择；生产若只保留 ES，需评估留存周期与备份策略。

4.2 批处理与流处理两种形态

官方部署套件提供两套形态，实测配置差异如下：

关键差异在于数据到达模型：批形态依赖"分区就绪 + 就绪谓词检查"的拉模式，流形态则持续消费 Kafka 主题的推模式。两者可并存部署，生产上通常批流各建一套度量定义。本专栏的实测与实战篇均基于 batch 形态。

4.3 指标持久化与查询

指标按"度量名 + 时间戳"追加写入，实测产出的指标既可通过 ES 直接检索，也可经 Service API 聚合查询。实测的两种查询回显如下（含义解读见实战篇）：

curl "http://localhost:39200/griffin/accuracy/_search?pretty&filter_path=hits.hits._source" \
   -d '{"query":{"match_all":{}},"sort":[{"tmst":{"order":"asc"}}],"size":3}'

{"hits":{"hits":[{"_source":{"name":"accuracy_job_exp3","tmst":1791987600000,
  "value":{"total":125000,"miss":502,"matched":124498}}}]}}

curl http://localhost:38080/api/v1/metrics

{"accuracy_measure":[{"name":"accuracy_job_exp3","type":"ACCURACY","owner":"test",
  "metricValues":[{"name":"accuracy_job_exp3","tmst":1791987600000,
  "value":{"total":125000,"miss":502,"matched":124498}}]}]}

💡 说明：ES 侧的 tmst 是毫秒时间戳，value 内的 total/miss/matched 即准确率三元组；Service API 则按"度量名 → 指标序列"两级组织，天然适合做趋势图。指标写入的完整链路与排障见《Apache Griffin 数据质量实战详解》。

五、适用场景与限制

5.1 适用场景

结合定位与实测表现，Griffin 适合以下场景：

1. 数仓定期质量对账：源表/目标表逐日逐小时分区比对（准确率/完整性），cron 调度 + 分区就绪检查天然贴合 T+1 与小时级数仓；
2. 数据湖/多引擎写入后的质量看门：指标统一落 ES，配合 UI 形成质量大盘；
3. 流数据质量监控：Kafka 数据源的流式准确率与画像（streaming 形态）；
4. 需要平台化沉淀质量规则的组织：度量定义、调度、指标查询全走 REST API，便于与内部平台集成。

5.2 当前限制（实测确认）

1. 版本错位是硬事实：0.6.0 官方部署套件内实际运行的是 0.2.0 服务（详见 2.2 节），0.6.0 文档中的新增 API（如 trigger）在该套件上不可用，二次开发前必须先 GET /api/v1/version 核对；
2. 官方示例与 demo 数据存在脱节：官方接口示例中就绪谓词的数据路径与套件内置 demo 数据的真实 HDFS 布局不一致，照抄会导致作业永远卡在 NOT_FOUND（根因与修复见实战篇排障章节）；
3. 组件栈偏旧：套件内 Hadoop 2.6.5、ES 5.5.2、PostgreSQL 9.3 等均为 2018 年前后的版本，生产化需自行升级替换；
4. 单指标索引：默认所有准确率指标写入同一个 griffin 索引（实测 5 主分片 1 副本，单节点下 health 为 yellow 属正常），长期高频率写入需自行规划索引滚动。

⚠️ 注意：Griffin 是"度量平台"而非数据修复工具——它只产出质量指标并告警呈现，不负责修复数据；发现质量问题后的数据订正仍需回到数据加工链路处理。

六、同类选型对比

6.1 定位澄清

数据质量工具大致分三层：规则即代码的断言库（嵌进数据管道）、Spark 原生质量库（随计算作业运行）、平台化质量系统（独立服务 + 调度 + 指标存储 + UI）。Griffin 属于第三层。选型先问：质量检查是"管道内的一次断言"，还是"平台级的持续度量与看板"。

6.2 技术拓展：三类方案一屏对比

💡 技术拓展：常见数据质量方案横向对比——

方案	语言/形态	原理与特点	适用场景与取舍
Great Expectations	Python 库	以"期望（Expectation）"描述数据断言，文档化好，与 pandas/Spark 集成	Python 为主的管道内即时校验；无独立调度与 UI，需自建
Deequ	Scala/Spark 库	基于 Spark 的数据分析器自动计算质量指标，可定义约束与告警	已有 Spark 作业想内嵌质量检查；偏库形态，需自建调度与存储
Apache Griffin	Java/Scala 平台	端到端平台：REST 定义度量、quartz 调度、Spark 执行、ES 指标存储、自带 UI	需要独立于业务管道的统一质量平台；组件栈偏重（Spark/Hadoop/Hive 生态）

本文主题即 Griffin：当目标是"组织级、持续调度、有看板"的数据质量平台时它是对口方案；若只是管道内的轻量断言，Great Expectations/Deequ 更轻。三者实践中可组合：管道内用断言库做即时拦截，平台层用 Griffin 做周期对账。

6.3 选型建议

• 需要平台化的周期质量对账与质量看板：选 Griffin（本篇与部署、实战两篇构成完整上手路径）；
• 数据管道是 Python 栈且只做即时断言：优先 Great Expectations；
• 已有 Spark 批作业、希望在作业内输出质量指标：优先 Deequ；
• 已采用 Griffin 但组件老化：参考实战篇的 API 面做自研改造时，保留其"Measure/Job/Metric"领域模型迁移成本最低。

七、参考链接

• Apache Griffin 官网：https://griffin.apache.org/
• 官方代码仓库：https://github.com/apache/griffin
• 0.6.0 发布 tag：https://github.com/apache/griffin/tree/griffin-0.6.0
• 官方部署套件与部署指南：位于 0.6.0 tag 的 griffin-doc 目录下（compose 编排文件与官方指南，获取命令与文件内容见《Apache Griffin Docker Compose 部署指南》第四、五章）
• 官方 REST 接口 postman 集合：https://github.com/apache/griffin/tree/griffin-0.6.0/griffin-doc/service/postman
• 本专栏配套文档：《Apache Griffin Docker Compose 部署指南》《Apache Griffin 数据质量实战详解》