1. 项目背景与整体设计思路Apache Atlas 在数据治理领域算是一个绕不开的存在尤其是当你的数据平台里同时跑着 Hive、HBase、Kafka、Spark 这一堆组件的时候元数据管理很快就会变成一团乱麻。表是谁建的、字段含义是什么、血缘关系怎么流转、敏感数据有没有被标记这些问题如果没有一个统一的元数据服务来兜底后面做数据资产盘点或者合规审计的时候基本就是灾难现场。Atlas 1.1.0 这个版本虽然不算新但在不少存量生产集群里依然在跑原因也很简单——稳定、依赖清晰、功能够用。我这次要聊的就是怎么把它稳稳当当地装到生产环境里不是那种装完能跑就行的 Demo 级别而是要考虑后续扩展、高可用和运维便利性的正经部署方案。先说清楚这个方案适合谁看。如果你只是想在本地虚拟机上跑个 Atlas 看看界面长什么样那官方 Quick Start 就够了没必要往下看。但如果你面对的是一个已经有几十个节点、上面跑着 Hive 数仓和 Kafka 消息队列的生产集群需要把 Atlas 集成进去做元数据采集和血缘分析那这套方案就是给你准备的。核心思路其实不复杂Atlas 本身是一个 Java 应用底层依赖 HBase 做存储、Solr 做索引、Kafka 做消息通知把这四个东西的版本对齐、配置打通剩下的就是调优和验证。但魔鬼全在细节里版本错一个、ZK 端口写错一个、Solr 的 collection 没建对都会让你在启动阶段卡到怀疑人生。我选择 Atlas 1.1.0 搭配 HBase 1.1.x、Solr 5.5.x、Kafka 0.10.x 这个组合不是随便拍的。Atlas 1.1.0 的官方文档里明确写了它依赖的 HBase 是 1.1.2 版本Solr 是 5.5.1Kafka 是 0.10.0.1。你当然可以用更高版本的组件去试但生产环境里最忌讳的就是“我觉得应该可以”版本兼容性这种东西官方验证过的组合永远是最省心的。HBase 1.1.x 系列在稳定性上已经经过大量集群验证Solr 5.5.x 的 SolrCloud 模式也足够成熟Kafka 0.10.x 虽然现在看有点老但 Atlas 1.1.0 的消息序列化格式就是按这个版本写的换新版本反而容易出序列化不兼容的问题。整个部署架构我采用的是分布式模式不是单机伪分布式。原因很直接生产环境要考虑单点故障。Atlas 本身可以部署多个实例通过 Kafka 做消息队列解耦HBase 和 Solr 各自做集群这样任何一个 Atlas 实例挂掉都不影响元数据采集的连续性。具体来说我规划了三台 Atlas 服务器做负载均衡HBase 用三台 RegionServer 加两台 Master 的架构Solr 用三台节点组 SolrCloudKafka 用三台 Broker 加三台 Zookeeper。这个规模不算大但足够支撑中等规模数据平台的元数据量后续要扩容也方便。注意Atlas 的元数据存储强依赖 HBase索引强依赖 Solr消息通知强依赖 Kafka。这三个组件任何一个出问题Atlas 都会处于不可用状态。所以生产环境里这三个组件本身也必须是高可用架构不能有单点。还有一个容易被忽略的点是 Zookeeper。HBase 和 Kafka 都需要 ZK你可以共用一套 ZK 集群也可以分开部署。我建议分开因为 HBase 的 ZK 负载和 Kafka 的 ZK 负载特性不一样混在一起容易互相影响。如果资源实在紧张至少要把 ZK 的 chroot 路径区分开避免节点数据混乱。这个坑我在早期项目里踩过HBase 的 ZK 节点被 Kafka 的临时节点挤掉导致 HBase Master 频繁切换排查了大半天才定位到是 ZK 共用的问题。2. 环境准备与核心依赖安装2.1 操作系统与基础环境配置生产环境我选的是 CentOS 7.6这个版本在内核参数和系统库兼容性上比较省心。不建议用 CentOS 8 或者 Ubuntu 最新版因为 Atlas 1.1.0 依赖的一些原生库在这些新系统上可能会有 glibc 版本冲突。安装之前先把基础环境统一一遍包括主机名解析、时间同步、文件句柄数、防火墙规则这些。主机名解析这块每台机器都要在/etc/hosts里写清楚所有节点的映射关系。别偷懒只用 DNS生产环境里 DNS 偶尔抽风的时候HBase 和 Kafka 之间的通信会莫名其妙断掉排查起来非常痛苦。时间同步用 chronyd 或者 ntpd 都行关键是所有节点的时间差不能超过 30 秒否则 Kafka 的消息时间戳会乱Atlas 的血缘关系时间线也会错乱。文件句柄数要调到至少 65535HBase 和 Solr 在高负载下会打开大量文件句柄默认的 1024 根本不够用。修改/etc/security/limits.conf加上* soft nofile 65535和* hard nofile 65535然后确认/etc/security/limits.d/目录下没有覆盖这个配置的文件。这个细节很小但 HBase RegionServer 因为句柄数不够而挂掉的情况我见过不止一次。防火墙方面生产环境通常不会直接关掉而是按端口开放。需要开放的端口包括HBase 的 16000、16010、16020、16030Solr 的 8983Kafka 的 9092Zookeeper 的 2181、2888、3888Atlas 的 21000。如果用了 Kerberos还要开放 88 和 749。这些端口在部署前就要确认互通别等到启动的时候才发现连不上。2.2 JDK 版本选择与安装Atlas 1.1.0 对 JDK 版本有明确要求必须是 JDK 8不支持 JDK 11 及以上。我推荐用 Oracle JDK 8u201 或者 OpenJDK 8u212 这两个版本它们在稳定性和兼容性上表现最好。安装方式我习惯用 tar 包手动解压不用 yum 安装因为 yum 安装的 JDK 路径不固定后面配置 JAVA_HOME 的时候容易出问题。安装步骤很简单把 tar 包解压到/usr/local/目录下然后重命名成jdk1.8接着在/etc/profile.d/下新建一个java.sh文件写入export JAVA_HOME/usr/local/jdk1.8和export PATH$JAVA_HOME/bin:$PATH。最后source /etc/profile让配置生效用java -version确认版本正确。提示所有节点都要装 JDK而且路径必须完全一致。Atlas 在启动时会通过 SSH 或者脚本调用其他节点的 Java 进程如果路径不一致会出现“Java not found”的错误但报错信息不会直接告诉你路径问题只会说连接失败。2.3 HBase 1.1.x 集群部署要点HBase 的部署我单独拿出来说因为它是 Atlas 的存储底座配置不对后面全白搭。我用的版本是 HBase 1.1.2和 Atlas 1.1.0 官方文档完全对齐。安装包从 Apache 归档站下载解压到/usr/local/hbase。hbase-site.xml里有几个关键配置必须改。hbase.rootdir要指向 HDFS 的路径比如hdfs://nameservice1/hbase注意这里要用 HDFS 的 nameservice 而不是具体 namenode 地址否则 HA 切换后 HBase 会找不到数据。hbase.cluster.distributed设为 truehbase.zookeeper.quorum写 ZK 集群的地址列表hbase.zookeeper.property.dataDir指向 ZK 的数据目录。还有一个容易被忽略的参数是hbase.regionserver.handler.count默认是 30生产环境建议调到 100 以上。Atlas 在批量写入元数据的时候会并发创建大量连接handler 数不够会导致请求排队严重的时候会超时。我一般设成 120配合hbase.hregion.max.filesize设成 5G这样 region 不会太碎也不会太大导致 compaction 压力过高。HBase 的 Master 和 RegionServer 启动后用hbase shell进去执行status命令确认3 servers之类的输出说明集群正常。然后建一个 Atlas 专用的 namespace比如create_namespace atlas后面 Atlas 初始化的时候会自动在这个 namespace 下建表。如果不提前建 namespaceAtlas 初始化会报权限错误虽然也能跑但日志里会有一堆警告。2.4 Solr 5.5.x 集群部署要点Solr 我用的是 5.5.1 版本部署成 SolrCloud 模式。SolrCloud 依赖 Zookeeper 做集群协调所以要先确保 ZK 集群可用。安装包解压到/usr/local/solr然后修改bin/solr.in.sh文件设置ZK_HOST为 ZK 集群地址SOLR_HEAP设成 4G 以上生产环境元数据索引量大的话建议 8G。启动 Solr 的时候用bin/solr start -c -z zk1:2181,zk2:2181,zk3:2181-c表示 Cloud 模式。启动后要创建两个 collection一个是vertex_index一个是edge_index这两个是 Atlas 用来存图索引的。创建命令是bin/solr create -c vertex_index -d /usr/local/solr/server/solr/configsets/basic_configs -shards 3 -replicationFactor 2edge_index同理。注意collection 的 shards 和 replicationFactor 要根据你的节点数来定。3 个 Solr 节点的话shards 设 3、replicationFactor 设 2 比较合理既保证了数据分散又有副本冗余。如果节点少shards 设 1 也行但生产环境不建议。Solr 的 schema 文件 Atlas 会自己上传不需要手动改。但有一个参数要提前调就是autoSoftCommit的间隔默认是 1 秒生产环境可以放宽到 5 秒减少 commit 频率提升写入吞吐。在solrconfig.xml里找到autoSoftCommit标签把maxTime改成 5000。2.5 Kafka 0.10.x 集群部署要点Kafka 用 0.10.0.1 版本部署三节点集群。server.properties里重点改这几个broker.id每个节点唯一listeners设成PLAINTEXT://hostname:9092log.dirs指向数据盘目录zookeeper.connect写 ZK 集群地址加一个 chroot 路径比如/kafkadefault.replication.factor设 3min.insync.replicas设 2。Atlas 会用到一个叫ATLAS_HOOK的 topic 和一个叫ATLAS_ENTITIES的 topic。这两个 topic 可以提前建好也可以让 Atlas 自动创建。我建议提前建因为自动创建的时候分区数和副本数可能不符合预期。建 topic 的命令是bin/kafka-topics.sh --create --topic ATLAS_HOOK --partitions 6 --replication-factor 3 --zookeeper zk1:2181/kafkaATLAS_ENTITIES同理。Kafka 的log.retention.hours建议设成 168 小时也就是 7 天给 Atlas 的消息消费留足缓冲时间。如果 Atlas 因为维护停机超过这个时间消息被清理了那部分元数据变更就丢了只能重新全量采集。这个参数根据你的维护窗口来定但至少 72 小时是底线。3. Atlas 核心配置与实操部署3.1 Atlas 安装包编译与解压Atlas 1.1.0 的官方二进制包在 Apache 归档站可以下载到但我不建议直接用二进制包因为里面的一些依赖 jar 包版本可能和你环境里的不一致。我习惯从源码编译这样能确保所有依赖都对齐。源码包下载后用 Maven 编译命令是mvn clean package -DskipTests -Dmaven.javadoc.skiptrue。编译过程大概需要 15 到 20 分钟取决于机器性能。编译完成后在distro/target/目录下会生成apache-atlas-1.1.0-bin.tar.gz这个就是我们要的安装包。解压到/usr/local/atlas目录结构里conf放配置文件bin放启动脚本server放 web 应用hook放各种采集钩子。提示编译的时候如果遇到OutOfMemoryError把 Maven 的MAVEN_OPTS设成-Xmx2g再试。Atlas 的编译过程比较吃内存默认的 512M 不够用。3.2 atlas-env.sh 关键参数配置conf/atlas-env.sh是 Atlas 的环境变量文件里面有几个参数必须改。export JAVA_HOME/usr/local/jdk1.8指向 JDK 路径。export ATLAS_SERVER_HEAP -Xms4g -Xmx4g -Xmn2g 设置 JVM 堆内存生产环境建议 8G 起步如果元数据量特别大16G 也不过分。export ATLAS_SERVER_OPTS里加上 GC 参数我一般用-XX:UseG1GC -XX:MaxGCPauseMillis200G1 在 Atlas 这种大堆场景下表现比 CMS 好。还有一个参数是export ATLAS_HOME_DIR/usr/local/atlas这个必须设对否则启动脚本找不到配置文件。export MANAGE_LOCAL_HBASEfalse和export MANAGE_LOCAL_SOLRfalse因为我们用的是外部集群不是 Atlas 自带的嵌入式版本。3.3 atlas-application.properties 核心配置这个文件是 Atlas 的核心配置内容比较多我挑最关键的几项说。atlas.graph.storage.backendhbase指定存储后端。atlas.graph.storage.hostnamezk1,zk2,zk3写 ZK 地址注意这里写的是 ZK 不是 HBase MasterAtlas 通过 ZK 发现 HBase 集群。atlas.graph.storage.hbase.tableatlas_janus是 HBase 表名可以自定义但建议保持默认。atlas.graph.index.search.backendsolr指定索引后端。atlas.graph.index.search.solr.modecloud表示 SolrCloud 模式。atlas.graph.index.search.solr.zookeeper-urlzk1:2181,zk2:2181,zk3:2181写 ZK 地址。atlas.graph.index.search.solr.wait-searchertrue这个参数建议设 true保证索引写入后立即可查否则血缘查询可能会有延迟。Kafka 相关配置在atlas.notification.embeddedfalse表示用外部 Kafka。atlas.kafka.zookeeper.connectzk1:2181,zk2:2181,zk3:2181/kafka写 ZK 地址加 chroot。atlas.kafka.bootstrap.serverskafka1:9092,kafka2:9092,kafka3:9092写 Broker 地址。atlas.kafka.data/data/atlas/kafka是本地缓存目录确保这个目录存在且有写权限。注意atlas.kafka.zookeeper.connect和atlas.kafka.bootstrap.servers这两个配置容易搞混。前者是给旧版消费者用的后者是给新版生产者用的。Atlas 1.1.0 两个都会用到所以都要配。3.4 初始化 Atlas 元数据存储配置改完之后先别急着启动 Atlas 服务要先初始化 HBase 表和 Solr 索引。执行bin/atlas_start.py --init或者直接跑bin/atlas_start.py加上-i参数。这个脚本会连接 HBase 创建atlas_janus表连接 Solr 创建vertex_index和edge_index的 schema。初始化过程中如果卡住大概率是 HBase 或 Solr 连接有问题。先检查atlas-application.properties里的地址对不对然后用hbase shell和curl solr分别测试连通性。初始化成功后HBase 里应该能看到atlas_janus表Solr 的 admin 界面里应该能看到两个 collection 的状态是 active。3.5 启动 Atlas 服务与验证初始化完成后用bin/atlas_start.py启动 Atlas。启动日志在logs/atlas.log重点看有没有Atlas Server started之类的字样。启动过程大概需要 30 到 60 秒如果超过 2 分钟还没起来去日志里找ERROR或Exception。启动成功后浏览器访问http://atlas-host:21000默认用户名密码是admin/admin。登录进去后先看 Dashboard 页面确认 HBase 和 Solr 的状态都是绿色。然后点 Search 标签随便搜一个类型比如hive_table如果能看到结果哪怕是空的说明索引正常。再验证 Kafka 通知用bin/kafka-console-consumer.sh --topic ATLAS_HOOK --bootstrap-server kafka1:9092 --from-beginning消费一下看看有没有消息。如果 Atlas 启动后没有任何消息可能是 hook 还没配置这个后面再说。4. 常见问题排查与避坑经验4.1 启动阶段常见报错与解决问题一HBase 连接超时。报错信息通常是org.apache.hadoop.hbase.ZooKeeperConnectionException。先检查atlas-application.properties里的atlas.graph.storage.hostname是不是 ZK 地址不是 HBase Master 地址。然后确认 ZK 集群里 HBase 的 znode 是否存在用zkCli.sh连上 ZK执行ls /hbase如果为空说明 HBase 没注册到 ZK检查 HBase 的hbase-site.xml里hbase.zookeeper.quorum配置。问题二Solr collection 不存在。报错信息是Collection not found: vertex_index。这是因为初始化的时候 Solr collection 没建成功。手动用bin/solr create命令建一下注意 configset 要用 Atlas 提供的在atlas/conf/solr/目录下。建完之后重启 Atlas。问题三Kafka 消息发送失败。报错信息是Failed to send message to topic ATLAS_HOOK。检查 Kafka 的advertised.listeners配置这个必须写主机名或者 IP不能写 localhost。如果写 localhostAtlas 连上 Kafka 后拿到的是 localhost 地址然后尝试连自己的 localhost当然连不上。4.2 运行阶段性能问题调优Atlas 运行一段时间后最常见的性能问题是查询变慢。原因通常是 Solr 索引膨胀或者 HBase 热点。Solr 这边可以定期做 optimize命令是curl http://solr-host:8983/solr/vertex_index/update?optimizetrue但生产环境别频繁做一周一次就够了。HBase 这边看 RegionServer 的负载如果某个 RegionServer 的请求量明显高于其他说明 rowkey 设计有热点。Atlas 的 rowkey 是哈希过的一般不会有严重热点但如果元数据量特别大可以考虑预分区。JVM GC 也是重点。用jstat -gcutil pid 1000观察 GC 频率如果 Full GC 超过 1 秒一次说明堆内存不够或者有内存泄漏。Atlas 1.1.0 在大量血缘关系写入时确实会有内存增长建议堆内存至少 8G并且开启 G1GC 的-XX:HeapDumpOnOutOfMemoryError方便出问题时分析。4.3 元数据采集 Hook 配置要点Atlas 本身只是个元数据服务数据要靠 Hook 采集进来。Hive Hook 是最常用的配置方式是在 Hive 的hive-site.xml里加上hive.exec.post.hooksorg.apache.atlas.hive.hook.HiveHook然后把 Atlas 的 hook jar 包放到 Hive 的 lib 目录下。Kafka Hook 类似在 Kafka 的server.properties里加kafka.producer.interceptors配置。提示Hook 配置完后要重启对应的服务才能生效。Hive 重启后执行一条create table语句然后去 Atlas 界面搜这个表名如果能搜到说明 Hook 正常工作。如果搜不到检查 Hive 的日志里有没有AtlasHook相关的报错。4.4 常见问题速查表问题现象可能原因排查方法解决方案Atlas 启动卡在初始化HBase 表创建失败检查 HBase 日志和 ZK 连接确认 HBase 集群正常手动建表界面能打开但搜索无结果Solr 索引未创建检查 Solr collection 状态手动创建 collection 并重启血缘关系不更新Kafka 消息未消费消费 ATLAS_HOOK topic 看有无消息检查 Kafka 配置和 Hook 配置查询超时Solr 索引过大或 HBase 慢看 Solr 和 HBase 监控指标优化索引扩容 HBase内存溢出堆内存不足看 GC 日志和 heap dump增大堆内存检查泄漏5. 生产环境运维与扩展建议5.1 监控指标与告警配置生产环境跑起来只是第一步后面能不能稳住全靠监控。Atlas 本身暴露了 JMX 指标可以用 Prometheus 的 JMX Exporter 采集。重点关注的指标包括AtlasRequestCount请求量、AtlasRequestLatency请求延迟、AtlasNotificationCount通知数量。HBase 和 Solr 的监控用它们自带的 metrics 体系HBase 看 RegionServer 的requestCount和compactionQueueSizeSolr 看queryResultCache的命中率和updateHandler的提交延迟。告警阈值我一般这么设Atlas 请求延迟超过 2 秒告警HBase compaction 队列超过 100 告警Solr 查询缓存命中率低于 50% 告警。这些阈值不是绝对的要根据你的实际负载调整。关键是先跑一段时间收集基线数据然后再定阈值别一上来就拍脑袋。5.2 备份与恢复策略Atlas 的元数据存在 HBase 里所以备份 Atlas 本质上就是备份 HBase 表。可以用 HBase 的 snapshot 功能定期对atlas_janus表做 snapshot然后把 snapshot 导出到另一个 HDFS 路径或者对象存储。恢复的时候用clone_snapshot或者restore_snapshot。Solr 的索引理论上可以从 HBase 重建所以不是必须备份。但如果索引特别大重建一次要几个小时那还是备份一下比较省事。Solr 的备份用curl http://solr-host:8983/solr/vertex_index/replication?commandbackup备份文件在 Solr 的数据目录下。注意HBase snapshot 不会自动清理做多了会占大量 HDFS 空间。建议设个生命周期策略比如保留最近 7 天的 snapshot旧的自动删除。5.3 后续扩展方向Atlas 1.1.0 虽然稳定但功能上确实有些局限。后续如果要做更复杂的血缘分析可以考虑升级到 Atlas 2.x 版本2.x 在性能和功能上都有明显提升。但升级不是无痛的2.x 的存储结构有变化需要做数据迁移。如果暂时不想升级可以在现有基础上扩展比如自己写 Hook 采集更多类型的元数据或者对接第三方的数据质量平台。还有一个扩展方向是集成 Ranger 做权限控制。Atlas 本身有简单的权限模型但生产环境通常需要更细粒度的控制。Ranger 可以和 Atlas 集成实现基于标签的权限管理这个在数据安全合规场景下很有用。5.4 个人实操体会这套方案我在几个不同规模的生产环境里都部署过最大的感受就是“配置要细验证要早”。Atlas 的配置文件有几百个参数大部分用默认值就行但关键的那十几个必须根据环境调对。我习惯在部署前先列一个配置清单每改一项就打个勾部署完再对着清单检查一遍这样能避免很多低级错误。另外就是日志一定要看。Atlas 的日志级别默认是 INFO启动阶段建议临时调到 DEBUG能看到更多细节。等稳定运行后再调回 INFO避免日志量过大。HBase 和 Solr 的日志也要看很多问题表面上是 Atlas 报错根因其实在 HBase 或 Solr 那边。最后说一个小的技巧Atlas 的启动脚本atlas_start.py其实是个 Python 脚本里面调用了atlas-server-start.sh。如果你需要自定义启动参数可以直接改atlas-server-start.sh但改之前先备份因为升级的时候会被覆盖。我一般把自定义参数写在atlas-env.sh里这样升级不影响。
