在使用TBDS 大数据平台之前，请您详细阅读并了解以下使⽤限制：
- 新建集群为保证集群网络安全和稳定，集群将放置在同一网络环境中，请勿随意变更已有集群或节点的网络，避免造成集群⽹络不互通。
- 请根据业务需要提前规划节点的存储空间，并及时扩充存储节点，避免因存储空间不足造成数据及节点运行风险。
- 使用TBDS 大数据平台时，请避免直接操作主机或容器，如关机、重启、网络切换、安全组调整等，以防集群异常。推荐在 TBDS 大数据管理平台内完成所有必要的集群维护操作。
- 在创建集群时，TBDS 大数据平台提供了满足通用场景的组件初始化参数，在使用组件服务前，建议您检查并微调相关组件参数以确保匹配您的业务场景。如需相关组件初始化指南，可以联系技术支持人员获取。
- 请您妥善保管TBDS 大数据平台集群的主机登录密码。
禁止操作
在使用及维护 TBDS 大数据平台集群时，一些非预期的操作可能会导致集群不可用或不稳定，在控制台执行部分操作前会有相应的风险提示，本节列举了⼀些禁止及高危操作：
| 操作 | 操作风险 |
| 使用开源版本/低版本TBDS 的客户端/未经确认的第三方工具进行组件操作 | 使用非配套版本的客户端进行操作容易导致：集群隐蔽性故障、元数据不一致、数据丢失与损坏等 |
| 在 TBDS 集群节点中修改节点内网 IP | 节点通信异常、集群不可用 |
| 在集群运行中修改 TBDS 集群节点的访问白名单 | 节点通信异常、组件服务不可用 |
| 删除节点上已有进程/应用程序/文件 | 集群/组件服务不可用 |
| 删除或者修改/etc 目录下的 hosts 文件 | 集群关联不到节点上的服务，导致服务异常 |
| 删除或者修改 HDFS 元数据文件 edit log | 导致 HDFS 集群不可用 |
| 手动修改 Hive 元数据库的数据 | Hive 数据解析错误，服务异常 |
| 删除 ZooKeeper 相关数据目录 | 相关依赖组件无法运行 |
高危操作
| 操作 | 操作风险 | 操作建议 |
| 对 TBDS 集群节点进行关机、重启 | 重启、关机导致服务不可用 | 确认操作必要性，并详细评估相关操作风险 |
| 对 TBDS 集群节点挂载磁盘 | TBDS 集群节点无法识别和初始化，导致磁盘不可用 | 建议在技术人员指导下进行 |
| 对 TBDS 集群节点卸载磁盘 | 会导致数据丢失或集群不可用 | 建议在技术人员指导下进行 |
| 直接在 TBDS 集群节点上修改组件配置文件的参数 | 服务重启后，导致修改的参数被覆盖 | 通过 TBDS 大数据管理平台上修改参数配置，特殊情况请在技术支持人员指导下进行 |
| 删除或者修改/etc目录下的resolv.conf 文件 | 集群关联不到节点上的服务，导致服务异常 | 确认操作必要性，并在技术指导下进行 |
| 修改 MetaDB 密码 | TBDS 集群依赖 MetaDB 中配置 的密码，修改后导致Hive/Ranger 等服务不可用 | 在TBDS 大数据管理平台同步修改配置，并在技术人员指导下进行 |
| 修改 MetaDB 浮动 IP | TBDS 集群依赖 MetaDB 中配置的 IP，修改后导致 Hive/Ranger等服务不可用 | 在TBDS 大数据管理平台同步修改配置，并在技术人员指导下进行 |
| 修改 MetaDB 安全组 | 导致 MetaDB 与集群通信受阻，Hive/Ranger 等服务不可用 | 在技术人员指导下进行 |
高可用说明
TE组件高可用：
| 故障场景 | 高可用说明 | 限制说明 |
| HDFS namenode-active节点失效 | Standby节点自动转换状态到active | 自动切换存在分钟级恢复，原active节点恢复后, 状态为standby |
| HDFS namenode-standby节点失效 | Standby节点失效后, active节点不受影响 | 原standby节点恢复后, 状态为standby |
| HDFS任意一台DataNode失效 | DataNode失效后, 功能正常 | DataNode恢复后, datanode重新加入集群 |
| HDFS-任意一个journal node失效 | 使用quorum机制，任意节点失效功能不受影响 | 不受影响 |
| Hive- HiveMetaStore/ HiveServer2/ HiveWebHCat任意一个失效 | 采用ActiveActive模式，相关功能不受影响 | 相关组件不受影响 |
| HBase- HMaster active节点失效 | active节点失效后, standby节点转换状态到active, 功能正常 | 自动切换存在分钟级恢复，原active节点恢复后, 状态为standby |
| HBase- HMaster standby节点失效 | Standby节点失效后, active节点不受影响 | 原standby节点恢复后, 状态为standby |
| HBase- HBaseThrift | 采用ActiveActive模式，相关功能不受影响 | 不受影响 |
| HBase-RegionServer其中一台失效 | 相关功能不受影响 | 不受影响 |
| Trino/Presto-Coordinator/Worker其中一台失效 | 采用ActiveActive模式，相关功能不受影响 | 相关组件不受影响 |
| Impala-Daemon任意一个失效 | Daemon无状态服务，任意一个impalad失效不影响功能 | 不受影响 |
| Impala-catalog/ statestore | 非关键服务无高可用 | 需要监控异常手工启动，不影响业务流程， |
| YARN-ResourceManager 任意一节点失效 | active/standby模式，当active节点失效，standby节点转换状态到active, standby节点失效后, active节点不受影响 | 原active节点恢复后, 状态为standby；原standby节点恢复后, 状态为standby；恢复时间分钟级 |
| YARN- NodeManager任意一节点失效 | 不受影响 | 不受影响 |
| Kafka其中一个broker失效 | 一个broker上存在partition leader ，停止这个broker，这个partition所在的topic可以被正常使用. | 不受影响 |
TM管控平台高可用：
| 故障场景 | 高可用说明 | 限制说明 |
| POD故障-双活服务 tm-woodpecker-taskcenter,tm-darwintaskcenter,tm-woodpecker-ems,tm-grafana,tm-platform,logstash,tm-web | 服务pod挂掉会自动拉起或者漂移恢复，过程中不影响服务的正常使用。 | 因资源节点问题导致不能拉起恢复但是至少保有一个实例可用，服务仍然可以正常使用。 |
| POD故障-主备服务 tm-emrcc,tm-woodpecker-server,tm-woodpecker-cmdserver,tm-woodpecker-native | 主备模式下，当主机pod挂掉后，首先备机升级为主机运行任务。服务pod挂掉会自动拉起或者漂移恢复，过程中不影响服务的正常使用。 | 因资源节点问题导致不能拉起恢复但是至少保有一个实例可用，服务仍然可以正常使用。 |
| POD故障-agent类服务 woodpecker-agent,woodpecker-bootstrap,woodpecker-ems-agent,Filebeat | 服务挂掉后能够自动拉起 | 可以自动恢复，影响分钟级 |
| 硬件故障-单节点 | 同一组件的两个pod不会部署在同一节点上；当任意worker节点挂了，此节点上对应的pod会迁移至随机的其他worker节点上 | 可以自动恢复，不影响服务正常使用。 |
| 组件更新 | 采用滚动更新，新建2个pod，完成后再依次销毁旧pod | 不影响业务 |
网络丢包场景下：组件目前机制在非断网状态下不会进行主备切换的，但业务可能会受损，建议由上层业务平台进行监控。
规格限制
TBDS建议规格限制如下：
| 类型 | 指标名称 | 规格 | 说明 |
| 账号/租户 | 最大主账号数 | 20 | |
| 单主账号下的最大用户数 | 5000 | ||
| 单主账号下的最大用户组数 | 300 | ||
| 用户关联的最大用户组数 | 50 | ||
| 集群 | 系统最大节点数 | 5000 | 通用X86/ARM服务器 |
| HDFS | 单NameNode最大文件数 | 3亿 | |
| NameNode的最大连接数 | 3000 | ||
| 单DataNode最大block数 | 500万 | ||
| 单个DataNode磁盘最多block数 | 50万 | ||
| 单个目录下最多文件目录数 | 100万 | ||
| 文件路径最大长度 | 8000 | ||
| HBase | 单个RegionServer实例的Region数量 | 2000 | 单RS实例支持的最大Region数 |
| 单个RegionServer支持的活跃Region数量 | 200 | 单RS实例支持的最大活跃Region数 | |
| Hive | 最大分区数量 | 1亿 | 单个Hive服务建议最大分区个数 |
| 单HiveServer最大并发数 | 500 | 单个HiveServer实例支持的最大并发数 | |
| Elasticsearch | 单Elasticsearch实例最大内存配置 | 31GB | |
| 单shard支持的记录数 | 4亿 | ||
| ZooKeeper | 最大znode数 | 400000 | |
| 单个znode大小 | 4M | ||
| Ranger | Ranger策略数 | 100万 |