元数据管理与数据治理平台：Apache Atlas 容错与高可用选项 Fault Tolerance and High Availability Options

文中内容仅限技术学习与代码实践参考，市场存在不确定性，技术分析需谨慎验证，不构成任何投资建议。

Apache Atlas 框架是一套可扩展的核心基础治理服务，使企业能够有效、高效地满足 Hadoop 中的合规性要求，并支持与整个企业数据生态系统集成。这将通过使用规范和取证模型，以及技术和运营审计以及由业务分类元数据丰富的沿袭，在 Hadoop 中提供真正的可视性。它还使任何元数据使用者能够互操作，而无需彼此独立的接口——元数据存储是通用的。通过利用 Apache Ranger 来维护元数据的准确性，以防止在运行时对数据进行未经授权的访问。安全性基于角色 (RBAC) 和属性 (ABAC)。

容错与高可用选项

Fault Tolerance and High Availability Options

简介

Apache Atlas 与多种系统交互，以向数据管理员提供元数据管理和数据血缘功能。通过恰当选择和配置这些依赖，Atlas 可以实现高度的服务可用性。本文档描述了 Atlas 对高可用的支持现状，包括其能力与当前限制，以及达到该高可用级别所需的配置。

架构页面 概述了构成 Atlas 的各个组件。下文提到的各组件选项以上述页面为背景，建议先阅读该页面再继续阅读本文。

Atlas Web Service

目前，Atlas Web Service 存在一个限制：同一时刻只能有一个 active 实例。在 Atlas 的早期版本中，可以部署一个 backup 实例并保持其可用，但需要手动 failover 才能使该 backup 实例变为 active。

从本版本开始，Atlas 支持以 active/passive 配置方式运行多个 Atlas Web Service 实例，并具备自动 failover 能力。这意味着用户可以在不同物理主机上同时部署并启动多个 Atlas Web Service 实例。其中一个实例会被自动选为 ‘active’ 实例以处理用户请求，其余实例则自动被视为 ‘passive’。如果 ‘active’ 实例因故意停止或意外故障而不可用，其他实例中的一个会被自动选举为新的 ‘active’ 实例并开始处理用户请求。

‘active’ 实例是唯一能够正确响应用户请求的实例，它可以创建、删除、修改或查询元数据对象。‘passive’ 实例会接受用户请求，但会通过 HTTP redirect 将其重定向到当前已知的 ‘active’ 实例。具体而言，passive 实例本身不会响应任何对元数据对象的查询。然而，所有实例（无论 active 还是 passive）都会响应返回该实例信息的管理类请求。

当配置为高可用模式时，用户可获得以下运维收益：

• 维护期间服务不中断：如果 Atlas Web Service 的 active 实例需要下线维护，另一实例会自动变为 active 并继续处理请求。
• 意外故障时服务不中断：如果 Atlas Web Service 的 active 实例因软件或硬件错误而故障，另一实例会自动变为 active 并继续处理请求。

以下各小节将描述为 Atlas Web Service 搭建高可用所需的步骤，并说明如何设计部署和客户端以利用该能力，最后给出底层实现的部分细节。

在 Atlas 中启用高可用特性

配置高可用特性前必须满足以下前提条件：

• 在集群机器上安装 Apache Zookeeper（生产环境建议至少 3 台服务器）。
• 选择 2 台或更多物理机来运行 Atlas Web Service 实例，这些机器构成 Atlas 的 ‘server ensemble’。

要在 Atlas 中启用高可用，需要在 atlas-application.properties 文件中定义若干配置项。虽然完整的配置项列表见 配置页面，本节列出主要选项：

• 高可用是 Atlas 的可选特性，需将配置项 atlas.server.ha.enabled 设为 true 以启用。

• 接下来，为每台选定的物理机定义唯一标识符，可为简单字符串如 id1、id2 等，必须唯一且不含逗号。

• 将这些标识符以逗号分隔作为选项 atlas.server.ids 的值。

• 对每台物理机，将 IP 地址/主机名和端口作为配置 atlas.server.address.id 的值，其中 id 为该物理机的标识符字符串。 例如，若选择两台主机 host1.company.com 和 host2.company.com，可如下配置：

atlas.server.ids=id1,id2
atlas.server.address.id1=host1.company.com:21000
atlas.server.address.id2=host2.company.com:21000

• 定义 Atlas 高可用特性将使用的 Zookeeper quorum：

atlas.server.ha.zookeeper.connect=zk1.company.com:2181,zk2.company.com:2181,zk3.company.com:2181

• 可查阅高可用特性的其他配置项，并在 atlas-application.properties 文件中按需设置。
• 生产环境中，Atlas 所依赖的组件也必须以高可用模式部署，后续章节将详细说明，请按其指导进行配置。
• 在选定的物理机上安装 Atlas 软件。
• 将上述步骤创建的 atlas-application.properties 文件复制到所有机器的配置目录。
• 启动依赖组件。
• 启动每个 Atlas Web Service 实例。

验证高可用是否生效，可在安装 Atlas Web Service 的每台实例上运行以下脚本：

$ATLAS_HOME/bin/atlas_admin.py -status

该脚本可能返回以下值之一：

• ACTIVE：该实例为 active，可响应用户请求。
• PASSIVE：该实例为 PASSIVE，会将收到的任何用户请求重定向到当前 active 实例。
• BECOMING_ACTIVE：服务器正在变为 ACTIVE 实例，此状态下无法处理任何元数据用户请求。
• BECOMING_PASSIVE：服务器正在变为 PASSIVE 实例，此状态下无法处理任何元数据用户请求。

在正常运行情况下，只有其中一个实例应返回 ACTIVE，其余均返回 PASSIVE。

配置客户端以使用高可用特性

Atlas Web Service 可通过以下两种方式访问：

• 使用 Atlas Web UI：基于浏览器的客户端，可查询 Atlas 存储的元数据。
• 使用 Atlas REST API：由于 Atlas 暴露 RESTful API，可使用任何标准 REST 客户端，包括其他应用中的库。Atlas 自带名为 AtlasClient 的客户端，可作为构建 REST 客户端访问的示例。

为在客户端利用高可用特性，有两种可选方案：

使用中间代理

实现 Atlas 高可用访问的最简方案是安装并配置具备根据状态透明切换服务能力的中间代理。其中一个代理方案是 HAProxy。

以下示例 HAProxy 配置可供参考。注意，这仅为演示，并非推荐的生产配置，生产配置请参考 HAProxy 官方文档。

frontend atlas_fe
bind *:41000
default_backend atlas_be
backend atlas_be
mode http
option httpchk get /api/atlas/admin/status
http-check expect string ACTIVE
balance roundrobin
server host1_21000 host1:21000 check
server host2_21000 host2:21000 check backup
listen atlas
bind localhost:42000

上述配置将 HAProxy 绑定到 41000 端口以接收客户端连接，然后根据 HTTP 状态检查将连接路由到 host1 或 host2。状态检查通过向 REST URL /api/atlas/admin/status 发送 HTTP GET 完成，仅当 HTTP 响应包含字符串 ACTIVE 时视为成功。

使用自动发现 active 实例

若不想部署并维护独立代理，另一个利用高可用特性的方案是构建具备状态检测和重试操作能力的客户端应用。在此场景下，客户端启动时可携带组成 ensemble 的所有 Atlas Web Service 实例的 URL。客户端随后对每个 URL 调用 REST URL /api/atlas/admin/status 以确定哪个为 active 实例。Active 实例的响应形如 {Status:ACTIVE}。此外，当客户端在操作过程中遇到任何异常时，应再次确定剩余 URL 中哪个为 active 并重试操作。

Atlas 自带的 AtlasClient 类可作为示例客户端库，展示如何与 ensemble 协作并选择正确的 Active 服务器实例。

Atlas 提供的工具如 quick_start.py 和 import-hive.sh 可配置为运行时使用多个服务器 URL。当以该模式启动时，AtlasClient 会自动选择并与当前 active 实例协作。若中间部署了代理，则运行 quick_start.py 或 import-hive.sh 时可使用代理地址。

Atlas 高可用实现细节

Atlas 高可用工作由主 JIRA ATLAS-510 跟踪。其下的 JIRA 详细记录了高可用特性的实现方式。高层来看，可归纳如下：

• Active 实例的自动选择以及向新 Active 实例的自动 failover 均通过 leader 选举算法完成。
• leader 选举使用 Apache Curator 的 Leader Latch Recipe。
• Active 实例是唯一初始化、修改或读取后端存储状态以保持其一致性的实例。
• 此外，当某个实例被选举为 Active 时，它会从后端存储刷新所有缓存信息以获得最新数据。
• servlet 过滤器确保只有 active 实例处理用户请求。若 passive 实例收到这些请求，会自动将其重定向到当前 active 实例。

Metadata Store

如上所述，Atlas 使用 JanusGraph 存储其管理的元数据。默认情况下，Atlas 将独立的 HBase 实例作为 JanusGraph 的后端存储。要为元数据存储提供 HA，建议配置 Atlas 使用分布式 HBase 作为 JanusGraph 的后端存储。这样即可利用 HBase 提供的 HA 保证。要将 Atlas 配置为使用 HA 模式的 HBase，请执行以下步骤：

• 选择一个已以 HA 模式部署的现有 HBase 集群供 Atlas 配置（或）以 HA 模式 部署新的 HBase 集群。
  • 若专为 Atlas 部署 HBase，请遵循 安装步骤 中列出的 HBase 部署指南。
• 建议集群中使用多个 HBase master（至少 2 个）部署在不同物理机上，并使用 Zookeeper 进行协调以提供冗余和高可用。
  • 参考 配置页面 了解在 atlas.properties 中配置 Atlas 与 HBase 的选项。

Index Store

如上所述，Atlas 通过 JanusGraph 为元数据建立索引以支持全文搜索查询。要为索引存储提供 HA，建议配置 Atlas 使用 Solr 或 Elasticsearch 作为 JanusGraph 的后端索引存储。

Solr

要将 Atlas 配置为使用 HA 模式的 Solr，请执行以下步骤：

• 选择一个已以 HA 模式部署的现有 SolrCloud 集群供 Atlas 配置（或）部署新的 SolrCloud 集群。
  • 确保 Solr 至少在 2 台物理机上运行以实现冗余，每台主机运行一个 Solr 节点。
  • 建议将副本数设为至少 2 以实现冗余。
• 按 安装步骤 所述创建 Atlas 所需的 SolrCloud 集合。
• 参考 配置页面 了解在 atlas.properties 中配置 Atlas 与 Solr 的选项。

Elasticsearch（技术预览）

要将 Atlas 配置为使用 HA 模式的 Elasticsearch，请执行以下步骤：

• 选择一个已部署的现有 Elasticsearch 集群（或）部署新的 Elasticsearch 集群。
  • 确保 Elasticsearch 至少在五台物理机上运行以实现冗余。
  • 建议副本数为 3。
• 参考 配置页面 了解在 atlas.properties 中配置 Atlas 与 Elasticsearch 的选项。

Notification Server

来自 Hooks 的元数据通知事件通过写入名为 ATLAS_HOOK 的 Kafka topic 发送给 Atlas。类似地，Atlas 向 Ranger 等其他集成组件发送的事件写入名为 ATLAS_ENTITIES 的 Kafka topic。由于 Kafka 会持久化这些消息，即使消费者宕机，事件也不会丢失，因为事件已被发送。此外，建议 Kafka 也配置容错以提供更高可用性保证。要将 Atlas 配置为使用 HA 模式的 Kafka，请执行以下步骤：

• 选择一个已以 HA 模式部署的现有 Kafka 集群供 Atlas 配置（或）部署新的 Kafka 集群。

• 建议集群中在不同物理机上部署多个 Kafka broker，并使用 Zookeeper 进行协调以提供冗余和高可用。

  • 至少部署 2 台物理机以实现冗余，每台主机运行一个 Kafka broker。

• 为 Atlas 使用创建 Kafka topic：

  • ATLAS topic 的分区数应设为 1（numPartitions）。
  • 决定 Kafka topic 的副本数：设为至少 2 以实现冗余。
  • 运行以下命令：

$KAFKA_HOME/bin/kafka-topics.sh –create –zookeeper <zookeeper 主机:端口列表> –topic ATLAS_HOOK –replication-factor <副本数> –partitions 1
$KAFKA_HOME/bin/kafka-topics.sh –create –zookeeper <zookeeper 主机:端口列表> –topic ATLAS_ENTITIES –replication-factor <副本数> –partitions 1
其中 KAFKA_HOME 指向 Kafka 安装目录。

• 在 atlas-application.properties 中设置以下配置：

atlas.notification.embedded=false
atlas.kafka.zookeeper.connect=<Kafka 所用 Zookeeper quorum 的逗号分隔服务器列表>
atlas.kafka.bootstrap.servers=<Kafka broker 端点的逗号分隔 host:port 列表> – 至少给出 2 个以实现冗余。

已知问题

• 如果托管 Atlas 表的 HBase region server 宕机，在它们恢复之前 Atlas 将无法从 HBase 存储或检索元数据。

风险提示与免责声明 本文内容基于公开信息研究整理，不构成任何形式的投资建议。历史表现不应作为未来收益保证，市场存在不可预见的波动风险。投资者需结合自身财务状况及风险承受能力独立决策，并自行承担交易结果。作者及发布方不对任何依据本文操作导致的损失承担法律责任。市场有风险，投资须谨慎。