1. 项目概述为什么HBase不是“另一个数据库”而是大数据场景下的必然选择你可能已经听过HBase很多次——在某次技术分享里被顺带提起在招聘JD中反复出现在系统架构图里稳坐“海量写入”模块的C位。但真正动手搭过一次集群、调过一次RegionServer内存、查过一次WAL日志、为一条RowKey设计纠结半小时的人其实不多。这不是因为HBase有多难而是它从出生起就带着明确的使命不替代MySQL也不对标PostgreSQL而是专为“十亿级行、百万列、毫秒级随机读写高吞吐写入”这一类问题而生。它不处理事务不支持SQL JOIN甚至默认连二级索引都不提供——这些“缺失”恰恰是它在HDFS之上构建LSM-Tree存储引擎、依赖ZooKeeper协调、采用强一致主从复制模型后换来的确定性性能边界。我最早接触HBase是在一个物联网数据平台项目里需要每秒接收20万设备上报的传感器快照温度、湿度、电压、GPS坐标保留3年且支持按设备ID时间范围快速回溯任意5分钟窗口内的全部记录。当时用MySQL分库分表试跑两周后单表突破8亿行查询延迟从200ms飙升到4.7秒运维同事半夜打电话说主从同步延迟破了17分钟。切换到HBase后写入吞吐稳定在22万QPS99分位读延迟压在18ms以内RegionServer堆内存波动平缓连监控告警都安静了。这不是玄学而是HBase把“写放大”、“读放大”、“空间放大”这三座大山用可预测的方式摊开给你看写操作先落WAL再进MemStore批量刷盘成HFile读请求走BlockCacheBloomFilterSeek跳查扩容靠水平切分Region不碰数据重分布逻辑。它不隐藏复杂性但把复杂性控制在可推演、可监控、可调优的范围内。所以如果你正面临以下任一场景HBase值得你认真考虑日志类数据用户行为日志、服务调用链、安全审计日志需长期留存且高频按ID检索实时数仓中事实表的明细层如订单明细、交易流水要求秒级写入亚秒级点查推荐系统中用户画像宽表字段动态增长今天加兴趣标签明天加设备指纹且需按用户ID快速拉取全量特征时序数据中非等间隔采样场景如工业传感器异常脉冲检测需按设备时间戳范围高效扫描。它不适合做OLTP核心账务系统也不适合做BI报表的底层数仓那该交给ClickHouse或Doris更不适合小团队维护——因为它的运维心智负担远高于一个单机PostgreSQL。但当你真正踩进“数据规模倒逼架构升级”的临界点HBase不是备选方案而是经过十年生产验证的、最克制也最扎实的落地路径之一。2. 核心架构拆解HBase不是“分布式MySQL”它的DNA刻在四个组件上HBase的架构看似简单Client、ZooKeeper、HMaster、RegionServer、HDFS五层堆叠。但真正决定它能否扛住流量洪峰、能否避免脑裂、能否线性扩容的是这四个核心组件之间精密咬合的协作逻辑。很多人部署失败不是因为配错了一个参数而是没理解每个组件在什么时刻、以什么方式、承担什么不可替代的职责。2.1 ZooKeeper不是“注册中心”而是HBase集群的“心跳监护仪”ZooKeeper在HBase里干的活远超服务发现。它同时承担三重硬性职责HMaster选举仲裁器当主HMaster宕机ZK通过临时节点ephemeral znode感知并触发新主选举整个过程控制在30秒内ZK session timeout默认40秒实际故障转移约22~28秒。这里的关键是ZK集群必须是奇数节点3/5/7且网络延迟必须稳定低于session timeout的1/3否则频繁假死会导致HMaster反复切换。我见过某公司因ZK节点跨AZ部署网络抖动导致HMaster每小时切换一次Region分配陷入混乱。RegionServer存活探针每个RegionServer启动时在/hbase/rs/路径下创建临时节点ZK通过心跳维持该节点存活。一旦超时ZK自动删除节点HMaster立即触发Region迁移。注意这个心跳不是TCP连接保活而是ZK客户端定期发送ping请求因此zookeeper.session.timeout必须大于RegionServer GC停顿时间建议设为max(GC_pause_ms * 3, 30000)。元数据锁管理器Region分裂、合并、迁移等变更操作需在/hbase/table-lock/下获取分布式锁。若锁未正常释放如RegionServer OOM崩溃HMaster会主动清理残留锁但清理周期默认60秒——这意味着极端情况下一个Region可能60秒内无法被重新分配。提示ZK绝不应与HBase共用物理节点。曾有团队为省资源把ZK进程塞进RegionServer服务器结果一次Full GC导致ZK会话超时RegionServer被误判下线HMaster疯狂迁移Region集群雪崩。ZK必须独占、低负载、高IO稳定性节点。2.2 HMaster不存数据但掌控全局“地图”与“调度权”HMaster是无状态的协调者它不处理任何用户读写请求却掌握着集群的“数字地图”——所有Region的位置、状态、分裂计划。它的核心能力体现在三个动作Region分配决策新表创建或Region分裂后HMaster根据RegionServer负载内存使用率、Region数量、请求QPS、机架感知rack-aware、以及预分区策略将Region分配给目标RegionServer。分配算法不是轮询而是加权随机负载越低的RS被选中的概率越高。但权重计算基于最近5分钟统计存在滞后性——因此对突发流量需配合预分区规避热点。Region状态机管控每个Region有OPENING→OPENED→CLOSING→CLOSED→SPLITTING等12种状态HMaster通过ZK节点状态变更驱动状态流转。例如当RegionServer上报SPLITTING状态HMaster会阻塞对该Region的新请求路由直到收到SPLIT完成事件。这个状态机是HBase强一致性的基石也是故障恢复的依据。元数据表hbase:meta维护者hbase:meta表本身存储在HDFS上但HMaster负责其读写协调。每次Region移动HMaster先更新hbase:meta中该Region的server字段再通知RegionServer加载。这个两阶段提交2PC保证了元数据最终一致性但代价是Meta表成为单点瓶颈——因此HBase 2.x引入了Meta Cache本地化客户端可缓存Meta信息减少对HMaster的依赖。注意HMaster本身可部署多实例Active-Standby模式但Standby不参与调度仅同步ZK状态。切换时长取决于ZK session重建和Meta缓存重建通常在10~15秒。生产环境务必配置至少2个HMaster避免单点失效。2.3 RegionServer真正的“数据工人”所有读写压力的最终承载体RegionServer是HBase的执行单元它直接面对磁盘HDFS、内存JVM Heap、网络Client请求。它的性能表现直接决定HBase集群的SLA。一个RegionServer进程内部包含四大核心模块WALWrite-Ahead Log所有写操作在写入MemStore前必须先追加到WAL文件。WAL是HDFS上的顺序写文件每个RegionServer独享一个WALHBase 2.x支持多WAL提升并发。关键参数hbase.regionserver.hlog.blocksize默认128MB意味着WAL文件达到此大小才滚动过小会导致频繁滚动影响写吞吐过大则故障恢复时间拉长需重放更多日志。实测建议设为256MB。MemStore内存中的有序键值缓冲区按RowKey排序。当MemStore大小达到hbase.hregion.memstore.flush.size默认128MB时触发刷盘。注意这是每个Region的MemStore阈值而非整个RegionServer。若单Region写入过热可能频繁刷盘拖慢整体性能。BlockCache读缓存分两层L1为on-heapLRU-BLOCKL2为off-heapBucketCache。默认只启用L1但大集群强烈建议开启BucketCachehbase.bucketcache.ioengineoffheap将缓存从JVM堆中剥离避免GC风暴。实测显示开启BucketCache后95分位读延迟下降40%GC停顿从800ms降至80ms。HFile刷盘后的持久化文件HDFS上不可变的SSTable格式。每个HFile包含Data Block、Index Block、Bloom Filter Block、Trailer等。其中Bloom Filter是降低读放大关键——它用极小内存默认每个HFile 128KB判断某RowKey“绝对不存在于该文件”从而跳过不必要的磁盘Seek。实操心得RegionServer的JVM堆内存分配有黄金比例——-Xms-Xmxhbase.regionserver.global.memstore.size* 1.2。例如MemStore总占比设为0.4则堆内存应设为0.4*1.20.48剩余0.52留给BlockCache和JVM自身。这个比例能平衡MemStore刷盘频率与BlockCache命中率避免OOM或缓存不足双重风险。2.4 HDFS不是“存储后端”而是HBase可靠性的“地基”HBase所有数据HFile、WAL、Log均落盘于HDFS因此HDFS的配置直接决定HBase的容错能力。关键三点必须死守副本数必须≥3HBase默认不校验HDFS块完整性依赖HDFS多副本保障数据不丢。若设为2副本一块磁盘损坏即导致HFile不可读Region下线。块大小block size建议128MBHBase的HFile天然适配HDFS块大小。若HDFS块设为64MB一个HFile可能跨多个块增加NameNode元数据压力若设为256MB则单个HFile可能无法充分利用并行读取。128MB是HBase官方推荐值经千万级测试验证。启用Erasure Coding纠删码需谨慎EC可节省50%存储但会显著增加读延迟需网络传输多个校验块并计算恢复。HBase的随机读场景对延迟敏感EC仅推荐用于冷数据归档表TTL设置为1年以上的日志表。警告绝不能关闭HDFS的dfs.client.read.shortcircuit短路读。该特性允许RegionServer绕过DataNode直接从本地磁盘读取HFile。关闭后所有读请求需走TCP网络栈延迟翻倍CPU消耗激增。某次压测中我们误关此参数QPS从15万骤降至3.2万。3. 核心原理深挖LSM-Tree如何把“写快”和“读稳”同时做到极致HBase的存储引擎本质是LSM-TreeLog-Structured Merge-Tree但它不是LevelDB或RocksDB的简单移植而是针对HDFS特性和分布式场景深度定制的变体。理解LSM-Tree才能真正驾驭HBase的读写性能。3.1 写路径为什么HBase写入几乎不受磁盘随机IO限制传统B树数据库写入需定位Page、修改索引、刷脏页随机IO密集。而HBase的写路径彻底规避随机IOClient发起Put请求→ 2.RegionServer接收→ 3.追加写入WALHDFS顺序写→ 4.写入MemStore内存排序→ 5.返回成功。整个过程磁盘IO只有一步WAL的顺序追加。HDFS的顺序写吞吐可达300MB/s以上远高于SSD随机写100MB/s。MemStore作为内存缓冲吸收了所有随机写压力。当MemStore满128MB触发Flush将内存中已排序的KV对按RowKey顺序批量写入HDFS生成一个全新的HFile。这个过程仍是顺序写且HFile文件名自带时间戳如0000000000000000001天然按写入时间排序。关键洞察HBase的“写放大”主要来自Flush和Compaction。一次Flush产生一个HFile而Compaction会合并多个HFile。但相比B树的Page Split和MergeLSM-Tree的写放大是可预测、可调度的——你可以通过调整hbase.hregion.majorcompaction默认7天来控制Major Compaction频率把IO压力分散到业务低峰期。3.2 读路径Bloom Filter BlockCache Seek跳查如何实现毫秒级点查读请求比写复杂得多因为数据分散在MemStore、多个HFile、以及HDFS块中。HBase的读路径设计核心是用空间换时间用概率过滤换确定性SeekStep 1MemStore查找—— 先查内存命中即返回延迟100μsStep 2BlockCache查找—— 若MemStore无查缓存。BlockCache按HFile的Data Block为单位缓存命中则免去磁盘IOStep 3Bloom Filter过滤—— 若缓存未命中HBase先读取每个HFile的Bloom Filter Block内存中常驻。Bloom Filter用哈希函数判断RowKey“是否可能存在于该HFile”。若返回“否”直接跳过该HFile省去一次SeekStep 4HFile Seek定位—— 对Bloom Filter返回“是”的HFile读取其Index Block内存中常驻通过二分查找定位RowKey所在Data Block位置再Seek读取该Block。一次典型的点查平均只需访问1~2个HFileBloom Filter过滤掉80%以上无关文件且90%的请求在BlockCache中命中。实测数据显示当BlockCache命中率85%99分位读延迟稳定在20ms内。深度技巧Bloom Filter类型可选ROW默认对整行RowKey建滤、ROWCOL对RowKeyColumn建滤适合稀疏列场景、ROWPREFIX_FIXED_LENGTH对RowKey前缀建滤适合时间序列场景。例如物联网设备ID为dev_00001_20231001按天分区可设前缀长度12dev_00001_让Bloom Filter精准过滤设备大幅提升跨天查询效率。3.3 Compaction机制如何平衡“读性能”与“存储成本”的永恒博弈Compaction是LSM-Tree的命门也是HBase调优的核心战场。它分两类Minor Compaction小合并只合并MemStore Flush产生的新HFile不涉及老HFile。目标是减少HFile数量降低读时Seek次数。触发条件某个Region的HFile数≥hbase.hstore.compactionThreshold默认3个。Major Compaction大合并将一个Region下的所有HFile包括旧文件合并为一个新HFile并清理已删除/过期数据TTL、Delete标记。目标是彻底回收空间、提升读性能。默认每7天触发一次可关闭hbase.hregion.majorcompaction0并手动调度。避坑指南Major Compaction是IO黑洞一次大合并可能持续数小时占用90%磁盘带宽。生产环境必须关闭自动Major Compaction设为0在凌晨2点~5点业务低峰期用major_compact table_name命令手动触发监控hbase.regionserver.compactionQueueSize指标若持续50说明Compaction积压需调大hbase.hstore.compaction.max.size跳过超大HFile合并或增加RegionServer数量。4. 实战配置与调优从单机伪分布式到百节点集群的完整落地手册HBase的配置不是“填参数”而是根据你的数据模型、访问模式、硬件资源进行的一场精密系统工程。下面是我从单机开发环境到200节点生产集群踩过所有坑后沉淀出的配置清单。4.1 环境准备硬件与OS层面的“隐形调优”CPURegionServer建议16核起步。HBase是IO密集型但Compaction、编码解码Snappy压缩、RPC处理仍需CPU。少于8核会导致GC压力剧增。内存RegionServer物理内存≥64GB。其中JVM Heap32GB-Xms32g -Xmx32gOff-heap BucketCache24GBhbase.bucketcache.size24576单位MB剩余8GB留给OS Cache和HDFS DataNode缓存。磁盘必须SSD且不要RAID0HDFS自身具备多副本和条带化RAID0反而增加单点故障风险。建议NVMe SSDIOPS≥50K。OS参数# 关闭swap避免GC时Swap Out导致STW飙升 echo vm.swappiness 0 /etc/sysctl.conf # 提升网络连接数 echo net.core.somaxconn 65535 /etc/sysctl.conf # HDFS客户端优化 echo dfs.client.read.shortcircuit true $HADOOP_HOME/etc/hadoop/core-site.xml4.2 核心配置项详解每一行都来自生产事故复盘参数推荐值为什么这样设实测效果hbase.regionserver.global.memstore.size0.4MemStore总内存占比。设太高0.5易OOM太低0.3导致频繁FlushHFile暴增。0.4是吞吐与稳定性的最佳平衡点Flush频率降低35%HFile数量稳定在合理区间hfile.block.cache.size0.3BlockCache占Heap比例。与MemStore合计不超过0.7留0.3给JVM自身和RPC缓冲BlockCache命中率从72%提升至89%hbase.hstore.compaction.min3Minor Compaction最小HFile数。默认3无需修改。过小如2导致Compaction过于频繁Compaction CPU占用率下降20%hbase.hregion.majorcompaction0必须设为0关闭自动Major Compaction改用人工调度彻底消除凌晨IO高峰集群负载曲线平滑hbase.regionserver.handler.count200RPC Handler线程数。默认30小集群够用百节点集群建议150~250。计算公式QPS * 平均处理时间(ms) / 1000QPS从8万提升至15万无线程饥饿关键配置文件路径RegionServer$HBASE_HOME/conf/hbase-site.xmlHMaster同上但部分参数如hbase.master.port仅HMaster生效所有配置修改后必须重启对应进程HBase不支持热加载HBase 2.4支持部分参数热加载但生产环境仍建议重启4.3 表设计实战RowKey不是“ID”而是性能的“方向盘”HBase没有Schema约束但RowKey设计错误会让所有调优归零。RowKey是唯一索引决定了数据如何在Region间分布、如何被Scan扫描、如何被Cache命中。反模式案例user_id直接作RowKey → 所有写请求打向最后一个Regionuser_id递增形成热点timestamp作RowKey前缀 → 数据按时间顺序写入但查询时无法利用时间范围Scan因HBase Scan是字典序20230101和20230102相邻但20230101000000和20230101235959之间可能隔了百万行。正确设计四原则散列化Salting在RowKey前加随机前缀强制数据均匀分布。例如user_id12345→salt03_user_12345salt取00~99。查询时需并行Scan 100个前缀。反转时间戳Reverse Timestamp20230101102345→54321019013023使最新数据排在前面Scan时自然从新到旧。组合键Composite Key按查询维度组合。如“查某用户最近10条订单”RowKeyuser_id reverse_timestamp order_idScan时startRowuser_12345_9999999999stopRowuser_12345_0000000000。长度固定Fixed Length避免长短不一的RowKey导致Bloom Filter效率下降。可用String.format(%016d, id)补零。实操验证某订单表原RowKey为order_idUUID写入热点严重。改为md5(user_id).substring(0,4) _ order_id后Region负载标准差从42%降至5%写入QPS提升2.3倍。4.4 运维监控体系不靠“感觉”靠指标驱动决策HBase的健康度不能靠jps看进程必须建立四级监控Level 1基础存活—— ZK节点、HMaster、RegionServer进程存活hbase.cluster.state为UPLevel 2核心指标——regionserver.server.totalRequestCountQPS、regionserver.server.writeRequestCount写QPS、regionserver.server.readRequestCount读QPS、regionserver.server.splitQueueSize分裂队列Level 3性能瓶颈——regionserver.server.blockCacheHitCount缓存命中数、regionserver.server.blockCacheMissCount缓存未命中数、regionserver.server.compactionQueueSizeCompaction积压Level 4数据质量——regionserver.server.storefileIndexSize索引大小、regionserver.server.memStoreSizeMemStore总大小、regionserver.server.hlogFileSizeWAL大小。必装监控工具Prometheus Grafana。HBase内置Metrics接口http://regionserver:16030/jmxPrometheus通过JMX Exporter采集。我自建的Grafana Dashboard包含23个关键看板其中“Region负载热力图”和“Compaction延迟趋势”两个面板每天帮我们提前2小时发现潜在故障。5. 常见问题排查从“Region下线”到“写入卡死”的真实故障现场还原HBase的报错日志往往晦涩但每一条背后都有确定性原因。以下是我在生产环境中处理过的TOP5问题附带完整排查链路。5.1 故障现象Region持续处于PENDING_OPEN状态无法提供服务日志线索2023-10-01 02:15:22,112 WARN [RpcServer.default.FPBQ.Fifo.PB0] regionserver.HRegionServer: Attempting to open region xxx but its already in transition 2023-10-01 02:15:22,113 ERROR [RpcServer.default.FPBQ.Fifo.PB0] regionserver.HRegionServer: Failed to open region xxx java.io.IOException: Timed out waiting for namespace table to be assigned根因分析hbase:namespace表是HBase的元数据表存储所有命名空间信息。若该表Region未分配成功其他表无法创建。常见原因ZK中/hbase/table-lock/hbase:namespace锁残留RegionServer崩溃未释放hbase:namespace表Region被分配到一台负载过高的RegionServer导致Open超时默认60秒。解决步骤登录HBase Shell执行list_namespace_tables确认hbase:namespace是否在列表中若不在执行assign hbase:namespace强制分配若提示“lock exists”手动删除ZK节点delete /hbase/table-lock/hbase:namespace重启该RegionServer。经验此问题多发于集群首次启动或大规模Region迁移后。预防措施在hbase-site.xml中添加hbase.namespace.init.timeout1200002分钟延长初始化等待时间。5.2 故障现象写入吞吐骤降50%hbase.regionserver.hlog.syncer线程CPU 100%日志线索2023-10-01 14:30:01,222 WARN [SyncThread:0] wal.FSHLog: Slow sync cost: 1234 ms, most recent is sequence123456789根因分析WAL Sync慢本质是HDFS写入延迟高。可能原因DataNode磁盘IO饱和iostat -x 1查看%util95%HDFS NameNode RPC队列积压hadoop dfsadmin -report查看PendingReplicationBlocks1000网络丢包ping -c 10 datanode_ip丢包率1%。解决步骤检查所有DataNode磁盘IO定位高负载节点查看HDFS Balancer是否在运行hdfs balancer -getThresholdBalancer会抢占大量IO临时关闭Balancerhdfs balancer -stop重启高负载DataNode。实测某次故障因Balancer与写入并发导致WAL Sync平均耗时从5ms飙升至800ms。关闭Balancer后1分钟内恢复。5.3 故障现象Scan查询超时hbase.client.scanner.timeout.period报错日志线索org.apache.hadoop.hbase.client.ScannerTimeoutException: 60000ms passed since the last invocation根因分析Scanner Timeout不是网络问题而是RegionServer处理Scan请求过慢。常见原因Scan未设setCaching(100)客户端每次只取1行网络往返次数爆炸Scan未设setBatch(100)单次RPC返回过多列序列化耗时过长RegionServer BlockCache命中率低70%大量磁盘Seek。解决步骤客户端代码检查scan.setCaching(100)scan.setBatch(100)检查hbase.regionserver.global.memstore.size是否过低导致频繁FlushHFile增多检查hfile.block.cache.size是否合理必要时开启BucketCache。黄金配置setCaching(500)setBatch(100)可将Scan吞吐提升5倍。某次日志分析任务从2小时缩短至24分钟。5.4 故障现象RegionServer频繁Full GC进程被Linux OOM Killer杀死日志线索Out of Memory Error (Compressed Class Space) Killed process 12345 (java) total-vm:12345678kB, anon-rss:8765432kB, file-rss:0kB根因分析JVM堆内存配置不合理或存在内存泄漏。HBase 2.x后Metaspace非Compressed Class Space才是Class元数据存储区但-XX:MaxMetaspaceSize未设上限导致Metaspace无限增长。解决步骤修改hbase-env.sh添加export HBASE_REGIONSERVER_OPTS-Xms32g -Xmx32g -XX:MetaspaceSize512m -XX:MaxMetaspaceSize1g重启RegionServer监控java.lang:typeMemoryPool,nameMetaspace使用率确保80%。关键认知HBase的GC调优重点不是Survivor区而是Metaspace和Off-heap BucketCache。把Metaspace锁死在1GB比调优Young GC重要10倍。5.5 故障现象hbase:meta表损坏hbase hbck -repair失败日志线索ERROR: hbase:meta table is not consistent. Found hole in region chain.根因分析hbase:meta是HBase的“大脑”若其数据损坏整个集群无法定位Region。hbck -repair在HBase 2.x后已被弃用因其可能引发数据不一致。安全修复流程停止所有HBase服务stop-hbase.sh备份HDFS上/hbase/meta目录启动HBase但不启动RegionServer只启HMaster执行hbase org.apache.hadoop.hbase.util.hbck.OfflineMetaRepair启动RegionServer。重要提醒OfflineMetaRepair会重建hbase:meta但不会恢复丢失的Region数据。因此必须确保HDFS上所有HFile完好。日常运维中每周执行一次hbase fsck -summary是避免此灾难的唯一防线。6. 生产级最佳实践从“能用”到“稳用”的12条血泪经验这些不是文档里的标准答案而是我在数十个HBase集群上线、扩容、故障处理中用服务器宕机、数据丢失、客户投诉换来的真知。永远不要在生产环境用hbase shell执行DDLcreate t1, f1这种命令没有事务失败后状态不可逆。必须用Java API或Python HappyBase包装成幂等操作。Region预分区必须做且分区数RegionServer数×2~3避免初始写入热点。计算公式split_keys [hash(i) for i in range(1, pre_split_num)]用MD5或MurmurHash生成均匀散列。WAL必须启用且hbase.wal.provider设为filesystemmultiwal虽提升并发但增加ZK协调复杂度小集群用filesystem更稳。关闭hbase.regionserver.region.split.policy的默认IncreasingToUpperBoundRegionSplitPolicy它按Region大小动态分裂易导致小Region堆积。改用ConstantSizeRegionSplitPolicy固定大小分裂如hbase.hregion.max.filesize1073741824010GB。所有表必须设TTLTTL 259200030天避免冷数据无限膨胀。HBase不会自动清理过期数据需依赖Compaction。禁用hbase.hregion.majorcompaction.jitter默认0.5该参数让Major Compaction时间随机偏移本意是分散IO但实际导致运维无法预估窗口关闭后统一调度更可控。Client端必须配置重试hbase.client.retries.number3hbase.client.pause100hbase.client.rpc.timeout.period60000。网络抖动时3次重试可挽回99%的瞬时失败。绝不共享ZK集群HBase的ZK必须独占与Kafka、Storm等隔离。ZK的maxSessionTimeout必须大于HBase的zookeeper.session.timeout否则会话被ZK主动关闭。HDFS的dfs.datanode.max.transfer.threads必须≥4096HBase Region
