4. 环境搭建总览：工程分析平台的技术栈选型
构建一个面向生产环境的血缘链路分析平台，技术栈选型直接决定了系统的扩展性、查询性能与运维成本。本章从数据采集、元数据存储、血缘计算、图查询到应用层，给出经过大规模实践验证的推荐组合，并对比各组件在血缘场景中的核心职责。
4.1 技术栈全景
工程分析平台采用分层解耦架构，每一层聚焦单一职责，通过标准接口（REST API / JDBC / Spark DataSource）进行通信。下表列出各层选型及版本基线：
| 架构层 | 推荐组件 | 版本基线 | 核心职责 |
|---|---|---|---|
| 数据采集与 ETL | Apache Spark 3.4+ | Scala 2.12 / Python 3.9 | 解析 SQL 执行计划、提取输入输出表与字段级依赖 |
| 元数据存储 | Apache Atlas 2.3+ | HBase 2.4 / Solr 8.11 | 管理表、字段、ETL 流程等元数据实体及关系 |
| 图数据库 | Neo4j 5.15+ (Community) | APOC / GDS 插件 | 存储血缘图结构、支持多跳溯源与影响分析 |
| 后端服务 | Java 17 + Spring Boot 3.x | Gradle 8.x / Maven 3.9 | 提供 REST API、权限控制、异步任务调度 |
| 前端展示 | Vue 3 + D3.js / Cytoscape.js | Node 18+ | 血缘图可视化、搜索、交互式下钻 |
| 调度与编排 | Apache Airflow 2.8+ | Python 3.9 | 定时触发血缘采集任务、监控执行状态 |
选型原则： 血缘链路分析对写入吞吐（元数据变更频繁）和多跳查询延迟（深度 > 5 层）要求极高。Neo4j 在 10 亿节点规模下仍能保持 200ms 以内的 6 跳查询，这是关系型数据库无法替代的。
4.2 核心组件选型详解
4.2.1 计算引擎：Spark 与 Python 的协作
血缘解析的核心计算落在 Spark 上，原因有三：
- SQL 解析能力： Spark 的 Catalyst Optimizer 可直接输出逻辑计划（LogicalPlan），从中提取 Input/Output 表、投影列、过滤条件。
- 多语言支持： 使用 Scala 编写解析插件，Python（PySpark）仅用于轻量级预处理和结果回写，降低团队维护成本。
- 批流一体： 同一套解析逻辑可同时覆盖离线 Hive 表和实时 Kafka 流表。
// Spark 血缘解析核心片段（Scala）
val plan = spark.sessionState.executePlan(df.queryExecution.logical)
val lineage = LineageExtractor.extract(plan)
// lineage 包含：sourceTables, targetTables, fieldMappings
lineage.writeToAtlas(atlasClient)
4.2.2 元数据中心：Atlas 的实体模型
Atlas 提供开箱即用的 Hive、Kafka、Spark 等桥接器（Bridge），自动捕获表创建、字段变更、ETL 执行等事件。在血缘场景中，我们主要使用以下实体类型：
| Atlas 实体类型 | 映射血缘元素 | 关键属性 |
|---|---|---|
| hive_table | 源表 / 目标表 | qualifiedName, db, owner, createTime |
| hive_column | 字段级血缘节点 | name, type, comment, statistics |
| spark_process | ETL 作业（血缘边） | inputs, outputs, queryText, startTime |
| spark_process_execution | 作业运行实例 | status, duration, logPath |
注意： Atlas 默认使用 Solr 作为全文索引，当实体数超过 500 万时，建议将 Solr 切换为 Elasticsearch 7.x 或启用 Atlas 的 JanusGraph 后端，否则字段级搜索延迟会超过 5 秒。
4.2.3 图数据库：Neo4j 的建模策略
Neo4j 存储从 Atlas 同步过来的血缘关系，采用以下标签（Label）设计：
- Table：表节点，属性包括 name、database、project、lastRefreshTime。
- Column：字段节点，属性包括 name、dataType、nullable。
- ETLJob：作业节点，属性包括 jobName、cronExpr、owner。
- 关系类型：
:PRODUCES（作业产出表）、:CONSUMES（作业消费表）、:LINEAGE（字段级依赖）。
// Cypher 查询示例：查找某字段的上游 5 层
MATCH (c:Column {name: 'order_amount'})<-[:LINEAGE*1..5]-(upstream:Column)
RETURN upstream.name, upstream.tableName
LIMIT 100
4.3 技术栈集成架构图
下图展示各组件之间的数据流与调用关系：
4.4 环境搭建清单
以下为最小可用环境所需的组件与资源建议：
| 组件 | 部署方式 | 最低配置 | 生产建议 |
|---|---|---|---|
| Spark (YARN 模式) | Docker Compose / 物理机 | 4C 16G × 2 节点 | 8C 32G × 5 节点 |
| Atlas + HBase + Solr | Docker Compose | 4C 8G × 3 节点 | 8C 16G × 5 节点 |
| Neo4j | Docker 单机 / 集群 | 2C 4G (社区版) | 8C 32G (企业版集群) |
| Java 后端 | JAR 包 / Docker | 2C 4G | 4C 8G × 2 节点 (HA) |
| Airflow | Docker Compose | 2C 4G | 4C 8G + Celery 执行器 |
快速启动建议： 使用
docker-compose 一键拉起 Atlas + Neo4j + 后端开发环境，参考项目根目录下的 docker/dev.yml。首次启动后，执行 python scripts/seed_metadata.py 导入示例元数据，即可通过 http://localhost:8080 查看血缘图。
4.5 选型避坑指南
- 不要用 MySQL 存储血缘图： 超过 3 层 JOIN 查询延迟指数级上升，且无法支持路径分析。
- Atlas 与 Neo4j 的数据同步： 不要直接修改 Neo4j 数据，应通过 Atlas 的 Hook 或 Kafka 通知触发增量同步，否则元数据会不一致。
- Spark 版本兼容： 使用 Spark 3.4+ 时，Atlas 的 Spark Bridge 需要手动编译，官方包仅支持到 3.2。建议使用社区维护的
apache-atlas-spark-lineage分支。 - Neo4j 索引： 对
Column.name和Table.name创建 BTREE 索引，否则全表扫描会导致 API 超时。