1. 为什么在生产环境部署元数据管理平台值得认真对待数据治理这件事做过的人都知道最难的从来不是技术本身而是让整个数据链路说得清、找得到、管得住。Apache Atlas 作为 Hadoop 生态里做元数据管理和数据血缘的核心组件1.1.0 这个版本虽然不算新但在不少企业的生产集群里依然是主力版本——原因很简单它稳定、功能够用而且和 Hive、HBase、Kafka、Spark 这些组件的集成已经打磨得比较成熟了。但问题在于Atlas 的安装文档虽然官方有可官方文档写的是能跑起来的级别离生产环境能扛住还差着十万八千里。我自己在几个不同规模的数据平台上部署过 Atlas从测试环境的三节点到生产环境的几十个节点踩过的坑可以说是五花八门。这篇文章就是把这些经验整理出来给正在或者准备在生产环境部署 Atlas 1.1.0 的同行们一个可以直接参考的方案。这篇文章适合谁看如果你已经对 Hadoop 生态有一定了解知道 Hive、HBase、Kafka 大概是干什么的现在需要把 Atlas 集成到现有集群里做元数据管理和血缘追踪那这篇内容就是写给你的。如果你是完全的新手建议先补一下 Hadoop 生态的基础知识不然有些配置项你可能会看得云里雾里。下面我会从整体架构设计开始一步步拆解生产环境部署 Atlas 1.1.0 的完整方案包括组件选型、配置细节、依赖关系处理、性能调优以及那些只有真正踩过坑才知道的注意事项。2. 生产环境部署的整体架构与方案选型2.1 核心组件拆解与依赖关系梳理Atlas 的架构不算复杂但依赖的组件不少。在动手之前你得先搞清楚它到底需要什么。Atlas 的核心组件包括Atlas Server提供 REST API 和 Web UI、Metadata Store元数据存储、Index Store全文检索索引、Kafka用于 Hook 的消息队列、HBaseAtlas 自身依赖的存储后端之一。这五个部分缺一不可而且它们之间的依赖关系是有顺序的。我见过有同事上来就先装 Atlas Server结果启动报了一堆连接错误排查了半天才发现是 Kafka 和 HBase 还没就绪。所以正确的部署顺序应该是先确保 HBase 和 Kafka 可用再配置 Atlas 的 Metadata Store 和 Index Store最后启动 Atlas Server。Metadata Store 的选择上Atlas 1.1.0 支持 HBase 和 BerkeleyDB内嵌。生产环境毫无疑问选 HBaseBerkeleyDB 只适合单机测试性能和可靠性都撑不住生产流量。Index Store 方面Atlas 1.1.0 支持 Solr 和 Elasticsearch但在这个版本里 Solr 的集成更成熟官方文档和社区案例也更多所以我建议生产环境优先选 Solr。Kafka 的角色容易被忽视。Atlas 的 Hook 机制是通过 Kafka 异步发送元数据变更消息的如果 Kafka 不稳定元数据更新就会延迟甚至丢失。生产环境一定要用独立的 Kafka 集群不要和业务 Kafka 混用否则业务流量高峰时 Atlas 的元数据同步会受影响。2.2 为什么选择 HBase Solr Kafka 这套组合有人可能会问为什么不用 MySQL 做 Metadata StoreAtlas 1.1.0 确实支持 JDBC 存储但在大规模元数据场景下关系型数据库的扩展性和写入性能会成为瓶颈。HBase 的分布式架构天然适合这种写多读少、数据量大的场景而且 Atlas 的元数据模型本身就是图状的HBase 的列式存储更适合。Solr 的选择也是类似的逻辑。Atlas 需要支持全文检索和复杂的条件查询Solr 在全文检索方面的成熟度比 Elasticsearch 在 Atlas 1.1.0 里的集成要好。我实测过两个版本Solr 的查询延迟明显更低尤其是在元数据量超过百万级之后。Kafka 的选型没什么悬念Atlas 的 Hook 机制就是基于 Kafka 的你只能用 Kafka。但要注意 Kafka 的版本兼容性Atlas 1.1.0 对 Kafka 的版本有一定要求太新的版本可能会有 API 不兼容的问题。我建议用 Kafka 0.10.x 或 0.11.x这两个版本和 Atlas 1.1.0 配合最稳定。2.3 生产环境的硬件规划与容量估算硬件规划这块很多人在测试环境跑通了就直接上生产结果发现性能完全不够。Atlas 的资源消耗主要在三块HBase 的存储、Solr 的索引、Atlas Server 的 JVM 内存。根据我的经验一个中等规模的数据平台大概 5000 张 Hive 表每天元数据变更 10 万次左右Atlas Server 至少需要 16GB 堆内存HBase 的 RegionServer 需要 32GB 内存和 500GB 以上的 SSD 存储Solr 需要 16GB 内存和 200GB 存储。这只是一个参考值具体要根据你的元数据量和变更频率来调整。容量估算有个简单的公式元数据条数 × 平均每条元数据的大小 × 副本数 × 1.5预留增长空间。比如你有 100 万条元数据每条平均 2KBHBase 默认 3 副本那就是 100万 × 2KB × 3 × 1.5 ≈ 9GB。但这只是原始数据还要算上索引和日志的空间实际规划时至少要在估算值上再乘 2。3. 核心细节解析与实操要点3.1 安装前的环境准备与依赖检查在开始安装之前有几项环境准备工作必须做扎实否则后面会各种报错。首先是JDK 版本。Atlas 1.1.0 要求 JDK 8不支持 JDK 11 及以上版本。我试过用 JDK 11 跑启动直接报反射相关的错误因为 Atlas 内部用了不少 JDK 8 特有的 API。生产环境建议用 JDK 8u201 或更高的小版本这个版本的稳定性和安全性都比较好。然后是Maven 版本。如果你是从源码编译 AtlasMaven 版本不能低于 3.3.9。我建议用 3.6.x这个版本在依赖解析和构建速度上都比较均衡。编译 Atlas 的时候有个坑它会下载大量的依赖包如果网络不稳定编译很容易中断。建议提前配置好 Maven 的镜像仓库并且把超时时间调大。HBase 和 Kafka 的连通性也要提前验证。Atlas 启动时会连接 HBase 和 Kafka如果网络不通或者权限不对启动会失败。你可以先用hbase shell和kafka-topics.sh测试一下连通性确保 Atlas 所在的节点能正常访问这两个服务。还有一个容易被忽视的点主机名和 DNS 解析。Atlas 的配置里会用到主机名如果 DNS 解析不稳定Atlas Server 启动时会卡在连接 HBase 的步骤。建议在/etc/hosts里把相关节点的主机名和 IP 映射写死避免依赖 DNS。3.2 Atlas 配置文件的关键参数详解Atlas 的配置文件主要有两个atlas-application.properties和atlas-env.sh。前者是核心配置后者是环境变量配置。atlas-application.properties里有几个参数必须根据生产环境调整atlas.graph.storage.hostnameHBase 的 ZooKeeper 地址。生产环境要写全所有 ZooKeeper 节点用逗号分隔。不要只写一个否则那个节点挂了 Atlas 就连不上 HBase 了。atlas.graph.index.search.solr.zookeeper-urlSolr 的 ZooKeeper 地址。同样要写全所有节点。Solr 在生产环境通常是以 SolrCloud 模式部署的依赖 ZooKeeper 做集群管理。atlas.kafka.bootstrap.serversKafka 的 broker 地址列表。建议写全所有 broker并且配置atlas.kafka.retries和atlas.kafka.acks参数提高消息发送的可靠性。atlas.server.http.portAtlas Server 的 HTTP 端口默认是 21000。生产环境如果有多实例部署每个实例的端口可以不同但要注意防火墙规则。atlas.rest.addressAtlas Server 的 REST 地址用于 Hook 回调。这个地址必须是所有客户端都能访问到的地址不能写 localhost。atlas-env.sh里主要调整 JVM 参数。ATLAS_SERVER_HEAP建议设置为 16G 或更高具体根据元数据量调整。ATLAS_SERVER_OPTS里可以加一些 GC 参数比如-XX:UseG1GCG1 在大堆内存场景下比 CMS 更稳定。3.3 Solr 索引的初始化与 Schema 配置Solr 的配置是 Atlas 部署里最容易出问题的环节。Atlas 1.1.0 需要 Solr 里有特定的 collection 和 schema如果 schema 不对Atlas 启动时会报索引创建失败。首先你需要创建两个 Solr collectionvertex_index和edge_index。这两个 collection 分别存储顶点和边的索引。创建命令大概是这样solrctl collection --create vertex_index -s 3 -c vertex_index -r 2 solrctl collection --create edge_index -s 3 -c edge_index -r 2这里的-s 3表示 3 个 shard-r 2表示 2 个副本。生产环境建议至少 3 个 shard 和 2 个副本保证可用性和查询性能。创建完 collection 之后需要把 Atlas 提供的 schema 文件上传到 Solr。Atlas 的安装包里有solr目录里面包含了vertex_index和edge_index的 schema 配置文件。你需要把这些文件放到 Solr 的配置目录里然后 reload collection。注意Solr 的 schema 文件修改后必须 reload collection 才能生效直接重启 Solr 是不行的。reload 命令是solrctl collection --reload vertex_index。还有一个坑Solr 的 schema 里定义了字段类型和索引方式如果元数据里有特殊字符可能会触发 schema 解析错误。我遇到过 Hive 表名里带中文的情况Solr 默认的分词器处理不了需要在 schema 里调整字段类型。生产环境如果有可能出现非英文字符建议提前在 schema 里配置好对应的分词器。3.4 Kafka Topic 的规划与创建Atlas 需要几个 Kafka topic 来传递元数据变更消息。默认情况下Atlas 会自动创建这些 topic但生产环境建议手动创建这样可以控制分区数和副本数。Atlas 1.1.0 用到的 topic 主要有ATLAS_HOOKHook 发送元数据变更消息、ATLAS_ENTITIESAtlas Server 内部使用。生产环境建议ATLAS_HOOK至少 6 个分区副本数 2 或 3。分区数决定了消息处理的并行度如果元数据变更频繁分区数太少会导致消息积压。创建 topic 的命令kafka-topics.sh --create --zookeeper zk1:2181,zk2:2181,zk3:2181 \ --topic ATLAS_HOOK --partitions 6 --replication-factor 2提示Kafka 的auto.create.topics.enable参数如果设为 trueAtlas 会自动创建 topic但自动创建的 topic 分区数和副本数都是默认值可能不满足生产要求。建议把这个参数设为 false手动管理 topic。另外Kafka 的消息保留时间也要注意。Atlas 的元数据变更消息如果保留时间太短可能会在 Atlas Server 处理之前就被清理掉。建议把log.retention.hours设为 1687 天给 Atlas 足够的处理时间。4. 实操过程与核心环节实现4.1 从源码编译 Atlas 1.1.0 的完整步骤虽然 Apache 提供了编译好的二进制包但生产环境我建议从源码编译。原因有两个一是可以确保和你的 Hadoop 版本兼容二是可以按需裁剪不需要的 Hook 模块减小部署包体积。编译步骤大概是这样# 下载源码 wget https://archive.apache.org/dist/atlas/1.1.0/apache-atlas-1.1.0-sources.tar.gz tar -xzf apache-atlas-1.1.0-sources.tar.gz cd apache-atlas-1.1.0-sources # 修改 pom.xml 里的 Hadoop 版本匹配你的集群版本 # 比如你的集群是 Hadoop 2.7.3就把 hadoop.version 改成 2.7.3 # 编译跳过测试 mvn clean package -DskipTests -Dmaven.javadoc.skiptrue编译过程大概需要 20 到 40 分钟取决于机器性能。编译完成后在distro/target目录下会生成apache-atlas-1.1.0-bin.tar.gz这就是可以部署的安装包。编译时有个坑Atlas 的源码里依赖了一些第三方库如果 Maven 仓库里没有编译会失败。建议提前配置好阿里云或华为云的 Maven 镜像并且把settings.xml里的超时时间调大。我遇到过编译到一半因为下载依赖超时而失败的情况重新编译又要从头开始很浪费时间。4.2 Atlas Server 的部署与启动流程编译完成后把安装包解压到目标目录然后开始配置。tar -xzf apache-atlas-1.1.0-bin.tar.gz -C /opt/ cd /opt/apache-atlas-1.1.0接下来配置conf/atlas-application.properties。这个文件里的配置项很多我挑几个最关键的说明# HBase 配置 atlas.graph.storage.backendhbase atlas.graph.storage.hostnamezk1:2181,zk2:2181,zk3:2181 atlas.graph.storage.hbase.tableapache_atlas_janus # Solr 配置 atlas.graph.index.search.backendsolr atlas.graph.index.search.solr.modecloud atlas.graph.index.search.solr.zookeeper-urlzk1:2181,zk2:2181,zk3:2181 atlas.graph.index.search.solr.wait-searchertrue # Kafka 配置 atlas.kafka.bootstrap.serverskafka1:9092,kafka2:9092,kafka3:9092 atlas.kafka.zookeeper.connectzk1:2181,zk2:2181,zk3:2181 atlas.kafka.auto.commit.enablefalse atlas.kafka.hook.group.idatlas # Server 配置 atlas.server.http.port21000 atlas.rest.addresshttp://atlas-host:21000配置完成后启动 Atlas Serverbin/atlas_start.py启动过程大概需要 1 到 2 分钟。启动完成后可以通过http://atlas-host:21000访问 Web UI默认用户名和密码都是admin。注意Atlas 启动时会初始化 HBase 表结构如果 HBase 里已经存在同名的表启动会报错。第一次部署时建议先确认 HBase 里没有apache_atlas_janus表如果有先删掉再启动。4.3 Hive Hook 的集成与验证Atlas 部署好之后最重要的就是集成各种 Hook让元数据能自动同步过来。Hive Hook 是最常用的配置也不复杂。首先把 Atlas 的 Hook jar 包放到 Hive 的 lib 目录下cp /opt/apache-atlas-1.1.0/hook/hive/atlas-hive-plugin-impl/*.jar $HIVE_HOME/lib/然后在 Hive 的hive-site.xml里添加 Atlas 相关配置property namehive.exec.post.hooks/name valueorg.apache.atlas.hive.hook.HiveHook/value /property property nameatlas.hook.hive.synchronous/name valuefalse/value /property配置完成后重启 HiveServer2。然后创建一个测试表看看 Atlas 里能不能查到CREATE TABLE test_atlas (id INT, name STRING) STORED AS ORC;等几秒钟在 Atlas Web UI 里搜索test_atlas如果能搜到说明 Hook 集成成功了。提示Hive Hook 默认是异步的元数据变更消息先发到 Kafka再由 Atlas Server 消费。如果 Kafka 有问题元数据不会立即出现在 Atlas 里。排查问题时可以先检查 Kafka 的ATLAS_HOOKtopic 里有没有消息。4.4 生产环境启动参数调优与验证生产环境的 Atlas Server 启动参数需要根据实际负载调整。我一般会在atlas-env.sh里设置这些参数export ATLAS_SERVER_HEAP16g export ATLAS_SERVER_OPTS-XX:UseG1GC -XX:MaxGCPauseMillis200 -XX:InitiatingHeapOccupancyPercent45 -XX:ParallelRefProcEnabled -XX:DisableExplicitGCG1GC 在大堆内存场景下比 CMS 更稳定MaxGCPauseMillis设为 200 毫秒InitiatingHeapOccupancyPercent设为 45%让 GC 更早启动避免 Full GC。启动后可以通过几个指标验证 Atlas 是否健康Web UI 能否正常访问这是最基本的。REST API 能否返回数据比如curl http://atlas-host:21000/api/atlas/types看看能不能返回类型列表。Kafka 消息是否有积压用kafka-consumer-groups.sh查看ATLAS_HOOK的消费延迟。HBase 和 Solr 的连接是否正常查看 Atlas 的日志确认没有连接错误。我一般还会做一个压力测试批量创建几百张 Hive 表观察 Atlas 的响应时间和 Kafka 的消息积压情况。如果消息积压严重说明 Atlas Server 的处理能力不够需要增加实例或者调大 Kafka 分区数。5. 常见问题与排查技巧实录5.1 启动失败类问题的排查思路Atlas 启动失败是最常见的问题原因五花八门。我整理了一个排查顺序按这个顺序查基本能定位到问题。第一步看日志。Atlas 的日志在logs/atlas-application.log启动失败的原因通常会在这里体现。重点看ERROR和Exception关键字。第二步检查 HBase 连接。如果日志里有Connection refused或NoRouteToHost说明 Atlas 连不上 HBase。检查atlas.graph.storage.hostname配置是否正确以及网络是否通。第三步检查 Solr 连接。如果日志里有SolrException说明 Solr 配置有问题。检查 collection 是否创建成功schema 是否正确。第四步检查 Kafka 连接。如果日志里有KafkaException说明 Kafka 配置有问题。检查atlas.kafka.bootstrap.servers是否正确以及 Kafka 是否正常运行。第五步检查端口占用。如果日志里有BindException说明端口被占用了。用netstat -tlnp | grep 21000看看是谁占用了端口。下面是一个常见问题速查表问题现象可能原因解决方法启动卡在初始化 HBaseHBase 连接超时检查 ZooKeeper 地址和网络启动报 Solr schema 错误schema 文件不匹配重新上传 schema 并 reload collectionWeb UI 打不开端口被占用或防火墙拦截检查端口和防火墙规则Hook 消息不消费Kafka topic 不存在或分区数不够手动创建 topic 并调整分区数元数据搜索不到Solr 索引未更新检查 Solr 的 wait-searcher 配置5.2 元数据同步延迟的优化经验元数据同步延迟是生产环境最常见的问题之一。表现是在 Hive 里创建了表但 Atlas 里要等很久才能搜到。这个问题的根源通常在 Kafka 或者 Atlas Server 的处理能力上。我遇到过几种情况情况一Kafka 消息积压。用kafka-consumer-groups.sh --describe --group atlas查看消费延迟。如果 lag 很大说明 Atlas Server 消费不过来。解决办法是增加 Kafka 分区数同时增加 Atlas Server 实例。情况二Atlas Server GC 频繁。如果 Atlas Server 的 GC 日志显示 Full GC 频繁说明堆内存不够。解决办法是调大ATLAS_SERVER_HEAP或者优化 GC 参数。情况三Solr 索引慢。如果 Solr 的索引更新慢元数据虽然写入了 HBase但搜索不到。解决办法是增加 Solr 的 shard 数或者优化 schema 配置。我一般会设置一个监控告警当 Kafka 的 lag 超过 10000 时触发告警这样可以在问题变严重之前介入处理。5.3 生产环境踩过的坑与避坑指南说几个我实际踩过的坑希望能帮你省点时间。坑一HBase 表预分区不合理。Atlas 的 HBase 表默认没有预分区数据量大之后会出现热点写入。解决办法是在创建表时预分区比如按vertex_id的哈希值分 16 个区。这个操作需要在 Atlas 第一次启动之前做启动之后再改就很麻烦了。坑二Solr 的 schema 字段类型不对。Atlas 的元数据里有不少长文本字段如果 schema 里把这些字段定义成string类型Solr 会做分词导致搜索时匹配不准确。正确的做法是把这些字段定义成text_general或者自定义字段类型。坑三Kafka 的auto.commit.enable配置错误。Atlas 的 Kafka 消费者默认是自动提交 offset 的如果 Atlas Server 处理消息失败offset 已经提交了消息就丢了。生产环境一定要把atlas.kafka.auto.commit.enable设为 false让 Atlas 手动提交 offset。坑四Hook 的同步模式选错。Hive Hook 有同步和异步两种模式。同步模式下Hive 操作会等 Atlas 处理完才返回影响 Hive 的性能。异步模式下Hive 操作立即返回元数据通过 Kafka 异步同步。生产环境建议用异步模式但要注意 Kafka 的可靠性。坑五Atlas Server 单点部署。生产环境一定要部署多个 Atlas Server 实例通过负载均衡对外提供服务。单实例一旦挂了整个元数据管理就瘫痪了。多实例部署时要注意atlas.rest.address的配置每个实例的地址要能被其他实例访问到。6. 生产环境运维与监控要点6.1 日常巡检与关键指标监控Atlas 上线之后日常巡检不能少。我一般会关注这几个指标JVM 指标堆内存使用率、GC 频率和耗时。如果堆内存使用率长期超过 80%或者 Full GC 频率超过每天 10 次就需要考虑扩容了。Kafka 消费延迟ATLAS_HOOKtopic 的 lag 值。如果 lag 持续增长说明 Atlas Server 处理能力不足。HBase 读写延迟Atlas 的元数据读写都依赖 HBase如果 HBase 的读写延迟升高Atlas 的响应时间也会变长。Solr 查询延迟Atlas 的搜索功能依赖 Solr如果 Solr 查询延迟超过 1 秒用户体验会明显下降。REST API 响应时间Atlas 的 REST API 是外部系统集成的入口响应时间超过 2 秒就需要排查了。这些指标可以通过 Prometheus Grafana 做可视化监控Atlas 1.1.0 本身没有内置的 metrics 接口但可以通过 JMX 导出。6.2 备份与恢复策略Atlas 的元数据是核心资产备份策略必须做好。Atlas 的元数据主要存在 HBase 和 Solr 里备份也主要针对这两个。HBase 备份可以用 HBase 的 snapshot 功能定期对apache_atlas_janus表做 snapshot。snapshot 是增量的对性能影响小。恢复时直接从 snapshot 恢复。Solr 备份Solr 的索引可以从 HBase 重建所以不是必须备份。但如果元数据量很大重建索引需要很长时间建议也定期备份 Solr 的索引数据。配置文件备份atlas-application.properties和atlas-env.sh这些配置文件也要备份最好放到版本控制里方便追踪变更。我一般会设置每天凌晨做一次 HBase snapshot保留最近 7 天的 snapshot。每个月做一次全量备份归档到对象存储里。6.3 版本升级与扩展性考虑Atlas 1.1.0 虽然稳定但后续如果需要升级到更高版本有一些注意事项。升级前先备份HBase 的 snapshot 和 Solr 的索引都要备份配置文件也要备份。检查兼容性新版本的 Atlas 可能对 HBase 和 Solr 的版本有不同要求升级前要确认。灰度升级生产环境不要一次性全量升级先升级一个实例验证没问题再升级其他实例。回滚方案升级前要准备好回滚方案万一升级失败能快速恢复到旧版本。扩展性方面Atlas 的瓶颈主要在 HBase 和 Solr。如果元数据量持续增长HBase 可以通过增加 RegionServer 来扩展Solr 可以通过增加 shard 来扩展。Atlas Server 本身是无状态的可以通过增加实例来提升处理能力。我个人在实际运维中的体会是Atlas 的稳定性很大程度上取决于 HBase 和 Kafka 的稳定性。把这两个基础组件运维好Atlas 本身其实很少出问题。另外监控一定要做在前面不要等用户反馈搜不到表了才去排查那时候可能已经积压了几十万条消息了。提前设置好告警阈值把问题扼杀在萌芽阶段这才是生产环境运维的正确姿势。
