1. 项目概述：在CDH 6.1.0生态中集成Kylin的现实意义与典型误区

“CDH6.1.0后安装Kylin（麒麟）”这个标题看似是一条技术操作指令，实则指向一个在企业级大数据平台演进过程中反复出现、却常被低估复杂度的关键集成场景。我接触过二十多个基于Cloudera Distribution for Hadoop（CDH）构建数仓的项目，其中超过七成在CDH升级至6.1.0版本后，都曾计划引入Apache Kylin作为OLAP加速引擎——不是因为Kylin有多新潮，而是因为CDH 6.1.0本身标志着Hadoop生态的一次重大分水岭：它正式终止对MapReduce v1的支持，全面转向YARN资源调度；同时Hive升级至2.1.1，引入了LLAP（Live Long and Process）执行模式；HBase也同步升级至2.1.0，底层协处理器机制发生重构。这些变化，表面看是组件版本号的递增，实则彻底改写了Kylin赖以运行的底层契约。

很多团队在启动这个项目时，第一反应是“照着官网文档走一遍”，结果在第三步就卡住：Kylin Web UI打不开，或者构建Cube时提示“ClassNotFound: org.apache.hive.service.cli.thrift.ThriftCLIService”。这不是配置写错了，而是根本性误判——他们把Kylin当成一个独立应用来部署，而忽略了CDH 6.1.0已将HiveServer2、HBase Master、ZooKeeper等服务深度耦合进Cloudera Manager（CM）的统一管控体系。Kylin必须成为CM管理下的一个“合规公民”，而非游离于体系外的“独立进程”。我曾帮某金融客户排查一个持续两周未解决的Kylin构建失败问题，最终发现根源在于CM中Hive服务的“高级配置代码段”里，有一行被手动注释掉的hive.server2.use.SSL=false，而Kylin的JDBC连接器默认启用SSL握手，导致连接超时被静默丢弃。这种细节，在Kylin官方文档里不会提，在CDH手册里也藏在“安全配置最佳实践”的附录第17页。

所以，“CDH6.1.0后安装Kylin”真正的核心，不是“怎么装”，而是“怎么融”——如何让Kylin的元数据层、计算层、存储层，与CDH 6.1.0的Hive Metastore、YARN队列策略、HBase命名空间、Kerberos认证票据生命周期这四根主干神经精准咬合。它适合三类人深度参考：一是正在规划CDH平台能力升级的数据平台工程师，你需要预判Kylin接入对现有YARN队列配额的影响；二是负责OLAP查询性能优化的BI开发人员，你必须理解Kylin Cube构建过程如何复用CDH中已有的Hive表统计信息；三是运维团队的技术骨干，你得掌握Kylin服务在CM中的健康检查项、日志归集路径和JVM参数调优的黄金组合。这不是一次简单的软件安装，而是一次跨组件、跨角色、跨生命周期的系统级对齐。

2. 整体架构设计与方案选型逻辑：为什么必须放弃“独立部署”思维

2.1 CDH 6.1.0的架构刚性约束

CDH 6.1.0不是Hadoop组件的简单打包，而是一个经过严格验证、具备强一致性保障的发行版。它的核心约束体现在三个不可绕过的“刚性层”：

• 服务注册层：所有组件（HDFS、YARN、Hive、HBase）必须通过Cloudera Manager Agent向CM Server注册其运行状态、端口、进程ID及健康检查脚本。Kylin若以standalone模式运行，其Web服务端口（7070）、Query服务端口（7071）、Job服务端口（7072）将无法被CM识别，导致告警风暴——CM会持续报告“Kylin服务未运行”，即使Kylin本身工作正常。

• 依赖注入层：CDH 6.1.0通过CM的“服务依赖关系图”强制管理组件间的启动顺序与配置传递。例如，Hive服务启动前，必须确保ZooKeeper集群已就绪并提供/chroot路径；HBase启动前，必须从Hive Metastore读取其元数据schema。Kylin的构建引擎（Build Engine）需要直接访问Hive Metastore的Thrift接口和HBase的RPC端口，若Kylin不纳入此依赖图，其构建任务提交到YARN后，会因无法解析Hive表位置或HBase表名而失败。

• 安全治理层：CDH 6.1.0默认启用Kerberos认证，且所有服务的Keytab文件均由CM统一生成、分发与轮换。Kylin若自行管理Kerberos票据，其票据有效期（通常24小时）与CM管理的Hive/HBase服务票据（可配置为7天）不同步，导致Kylin在凌晨自动构建Cube时，因票据过期而批量失败，错误日志中仅显示模糊的“GSSException: No valid credentials provided”。

因此，任何试图绕过CM、在CDH节点上直接解压Kylin二进制包并执行bin/start-kylin.sh的方案，都是在技术债务上垒砖。我见过最典型的反面案例：某电商公司运维团队为赶工期，采用独立部署Kylin 3.1.2，初期查询响应快，但上线两周后，因CM自动升级HBase至2.1.1补丁包，导致Kylin底层使用的HBase Client API（0.98.x）与服务端协议不兼容，所有Cube构建任务卡在“Creating HTable instance”阶段，回滚HBase版本又牵扯整个实时数仓链路，最终耗时五天才完成CM集成式重装。

2.2 Kylin版本与CDH 6.1.0的兼容性矩阵

Kylin官方虽宣称支持CDH，但其“支持”定义需拆解为三个维度：编译兼容性、运行时兼容性、管理集成兼容性。下表是基于我实际测试（覆盖5个生产环境、12次版本组合）得出的权威兼容结论：

提示：Kylin 3.1.2是CDH 6.1.0生态中唯一经过Cloudera官方联合认证的版本。其核心价值在于内置了cdh610-compat模块，该模块重写了Kylin的Hive元数据解析器，能正确处理CDH 6.1.0中Hive Metastore的TBLPROPERTIES字段新增的storage_handler属性；同时，其HBase Storage Adapter支持CDH 6.1.0的HBase 2.1.0的AsyncConnection异步连接池，避免了旧版同步连接导致的YARN Container OOM。

2.3 最终选定方案：CM Parcel集成 + 多租户HBase命名空间隔离

综合评估稳定性、可维护性与未来扩展性，我们锁定“CM Parcel集成”为唯一可行路径。该方案要求Kylin以Parcel包形式上传至CM，并作为CDH集群的一个“一级服务”进行全生命周期管理。其优势在于：

• 配置即代码：所有Kylin配置（如kylin.env.hdfs-working-dir、kylin.job.yarn-queue）均通过CM界面集中配置，变更后自动下发至所有Kylin实例，杜绝配置漂移；
• 启停一体化：Kylin服务启停、重启、滚动升级，全部通过CM操作，与HDFS、YARN等服务同等待遇，运维动作可审计、可回溯；
• 监控可视化：CM自动采集Kylin的JVM GC时间、Heap使用率、Cube构建成功率、Query QPS等指标，与现有Grafana监控大盘无缝对接。

在此基础上，我们叠加“多租户HBase命名空间隔离”策略。CDH 6.1.0的HBase 2.1.0原生支持命名空间（Namespace），Kylin 3.1.2可通过kylin.storage.hbase.namespace参数指定Cube数据存储的独立命名空间（如kylin_ns_finance、kylin_ns_logistics）。此举带来三重收益：

1. 权限隔离：通过HBase ACL，可为不同业务线授予各自命名空间的CREATE/READ/WRITE权限，财务部门无法误删物流部门的Cube数据；
2. 资源隔离：为每个命名空间配置独立的RegionServer内存配额与Compaction策略，避免大流量Cube构建影响在线查询性能；
3. 故障域隔离：单个命名空间的RegionServer宕机，不影响其他命名空间的Cube查询，MTTR（平均修复时间）降低60%以上。

这个方案放弃了“快速尝鲜”的捷径，选择了“稳扎稳打”的正道。它可能让首次部署耗时增加2小时，但换来的是未来半年内零次因Kylin引发的P1级故障。在数据平台领域，慢即是快，稳即是省。

3. 核心细节解析与实操要点：从Parcel制作到CM服务配置的每一步深意

3.1 制作CDH 6.1.0专用Kylin Parcel包：不只是解压与打包

Kylin官方提供的Parcel包（如kylin-3.1.2-cdh6.1.0.parcel）仅包含基础二进制文件，要使其真正融入CDH 6.1.0，必须手工注入四个关键适配层。这一步无法跳过，否则CM在分配Parcel时会报错“Invalid parcel manifest”。

第一步：注入CDH 6.1.0专属的HBase Client JARCDH 6.1.0的HBase 2.1.0客户端API与社区版存在细微差异，主要体现在org.apache.hadoop.hbase.client.AsyncConnection的构造方法签名。Kylin 3.1.2默认依赖hbase-client-2.1.0.jar，但CDH 6.1.0实际提供的是hbase-client-cdh6.1.0.jar，后者包含了针对Cloudera Kerberos票据续订的补丁。操作如下：

# 进入Kylin解压目录 cd /opt/kylin-3.1.2 # 移除原生HBase Client rm -f lib/hbase-client-*.jar # 从CDH节点复制CDH专用Client（需在任意CDH节点执行） scp /opt/cloudera/parcels/CDH-6.1.0-1.cdh6.1.0.p0.770702/lib/hbase/lib/hbase-client-cdh6.1.0.jar lib/ # 重命名为标准名称，确保Kylin ClassLoader能加载 mv lib/hbase-client-cdh6.1.0.jar lib/hbase-client-2.1.0.jar

注意：此操作必须在制作Parcel前完成。若跳过，Kylin构建Cube时会在CreateHTableStep阶段抛出NoSuchMethodError，错误堆栈指向AsyncConnectionBuilder.create()，这是最典型的“版本错配”症状。

第二步：重写kylin.properties中的Hive连接字符串CDH 6.1.0的HiveServer2默认启用HTTP传输模式（而非二进制Thrift），且其JDBC URL格式为jdbc:hive2://<host>:10000/;transportMode=http;httpPath=cliservice。而Kylin默认配置kylin.source.hive.client=beeline，会尝试使用二进制模式连接，必然失败。需在conf/kylin.properties中显式指定：

# 替换原有kylin.source.hive.connection-url kylin.source.hive.connection-url=jdbc:hive2://cdh-master-01:10000/;transportMode=http;httpPath=cliservice # 强制使用HTTP模式 kylin.source.hive.http=true # 指向CDH的Hive Metastore Thrift服务（非HS2） kylin.metadata.url=thrift://cdh-master-01:9083

此处cdh-master-01必须是CM中Hive服务的“HiveServer2主机”配置值，而非任意HiveServer2节点IP。因为CDH的Hive Metastore是高可用的，其Thrift地址由CM统一管理，硬编码IP会导致Metastore切换后Kylin元数据同步中断。

第三步：生成CM兼容的parcel.json清单文件Parcel包必须包含manifest.json，其内容需精确匹配CDH 6.1.0的版本标识。一个常见错误是直接拷贝Kylin官网的模板，其中"version": "3.1.2"，而CM要求格式为"version": "3.1.2-cdh6.1.0"。完整清单如下：

{ "schema_version": 1, "name": "KYLIN", "version": "3.1.2-cdh6.1.0", "packages": [ { "name": "kylin", "version": "3.1.2-cdh6.1.0" } ], "depends": [ "CDH = 6.1.0" ], "provides": [ "kylin = 3.1.2-cdh6.1.0" ] }

实操心得："depends"字段是CM校验的核心。若写成"CDH >= 6.1.0"，CM在分配Parcel时会报错“Dependency resolution failed”，因为CM只接受精确版本匹配。这是CM设计的刚性规则，没有变通余地。

第四步：编写service.sdl服务定义语言文件这是让Kylin成为CM“一级服务”的灵魂文件，存放在Parcel根目录的meta/子目录下。它定义了Kylin服务的启动命令、健康检查脚本、配置文件映射关系。关键片段如下：

service { name = "kylin" version = "3.1.2-cdh6.1.0" displayName = "Apache Kylin" description = "OLAP engine for big data" process { name = "kylin-server" command = "/opt/cloudera/parcels/KYLIN-3.1.2-cdh6.1.0/bin/start-kylin.sh" healthCheck = "/opt/cloudera/parcels/KYLIN-3.1.2-cdh6.1.0/bin/check-kylin.sh" } config { file = "conf/kylin.properties" properties = [ "kylin.env.hdfs-working-dir", "kylin.job.yarn-queue", "kylin.storage.hbase.namespace", "kylin.source.hive.connection-url" ] } }

其中check-kylin.sh是自定义健康检查脚本，内容为：

#!/bin/bash # 检查Kylin Web UI是否响应 if curl -s --head http://localhost:7070/kylin/api/user | grep "200 OK" > /dev/null; then exit 0 else exit 1 fi

此脚本被CM每30秒调用一次，若连续3次失败，CM将自动触发Kylin服务重启。这是实现“自愈能力”的关键一环。

3.2 在Cloudera Manager中完成Kylin服务的全配置

Parcel上传并分发后，CM界面会出现“Add Service”按钮，选择“Kylin”即可启动向导。此过程有三个极易出错的配置环节：

环节一：HDFS工作目录（kylin.env.hdfs-working-dir）的权限陷阱Kylin需要一个HDFS目录存放中间计算文件（如MapReduce临时输出、HFile生成区）。很多人直接填写/kylin，但CDH 6.1.0默认启用了HDFS超级用户组（supergroup）权限控制。正确做法是：

1. 在CM中进入HDFS服务 → “配置” → 搜索“supergroup”，确认其值为hdfs（默认）；
2. 创建HDFS目录并赋权：

# 以hdfs用户执行 sudo -u hdfs hadoop fs -mkdir -p /kylin sudo -u hdfs hadoop fs -chown kylin:hdfs /kylin sudo -u hdfs hadoop fs -chmod 775 /kylin

注意：kylin用户必须已在所有CDH节点的Linux系统中创建（useradd kylin），且其UID需与CM中HDFS服务的“HDFS超级用户”配置一致。若不一致，Kylin进程将以yarn用户身份写入HDFS，触发Permission Denied。

环节二：YARN队列（kylin.job.yarn-queue）的资源博弈Kylin的Cube构建是典型的CPU密集型+IO密集型任务，会抢占YARN资源。CDH 6.1.0默认YARN队列是default，若将Kylin构建任务全部塞入此队列，会导致Hive Ad-hoc查询、Spark Streaming作业因资源饥饿而超时。必须为Kylin创建专用队列：

1. 在CM中进入YARN服务 → “配置” → 搜索“yarn.scheduler.capacity.root.queues”，添加新队列名kylin；
2. 设置yarn.scheduler.capacity.root.kylin.capacity=30（分配30%集群资源）；
3. 在Kylin服务配置中，将kylin.job.yarn-queue设为kylin。 这样，当Kylin构建Cube时，YARN Capacity Scheduler会将其调度到kylin队列，与其他业务队列物理隔离。

环节三：HBase命名空间（kylin.storage.hbase.namespace）的初始化Kylin不会自动创建HBase命名空间，必须手动初始化。在CM中进入HBase服务 → “操作” → “打开HBase Shell”，执行：

# 创建命名空间（假设业务线为finance） create_namespace 'kylin_ns_finance' # 为kylin用户授予权限 grant 'kylin', 'RWXCA', '@kylin_ns_finance'

随后在Kylin服务配置中设置kylin.storage.hbase.namespace=kylin_ns_finance。此步骤若遗漏，Kylin构建Cube时会报错NamespaceNotFoundException，且错误日志不明确提示缺失命名空间，排查成本极高。

4. 实操过程与核心环节实现：从服务启动到首个Cube构建的完整链路

4.1 服务启动与初始验证：不止是“绿色对勾”

CM完成Kylin服务添加后，界面会显示“Started”状态，但这仅表示Kylin进程已拉起。真正的验证需分三层穿透：

第一层：网络连通性验证Kylin服务监听三个关键端口：7070（Web UI）、7071（Query）、7072（Job）。需在CM管理节点执行：

# 检查端口监听 netstat -tuln | grep -E '7070|7071|7072' # 验证Web UI基础响应（返回HTML头） curl -I http://cdh-master-01:7070/kylin/api/user # 验证Query服务（返回空JSON，证明服务存活） curl -X GET http://cdh-master-01:7071/kylin/api/query

若curl -I返回HTTP/1.1 200 OK，而curl -X GET返回{"results":[],"columnMetas":[]}，说明网络层与服务进程层均正常。

第二层：元数据连通性验证登录Kylin Web UI（http://cdh-master-01:7070/kylin），使用默认账号ADMIN/KYLIN。进入“Model” → “Data Source”，点击“Sync from Hive”。此时Kylin会尝试连接CDH的Hive Metastore。成功标志是：界面列出CDH中所有Hive数据库（如default、ods、dwd），且每个库下的表数量与beeline -e "show tables in default;"输出完全一致。若列表为空或报错“Failed to get databases”，则需检查kylin.metadata.url配置是否指向正确的Hive Metastore Thrift地址（9083端口），以及CM中Hive服务的“Hive Metastore Server”主机配置。

第三层：存储连通性验证在Web UI中，进入“Settings” → “Configuration”，搜索kylin.storage.hbase.namespace，确认其值为已创建的命名空间（如kylin_ns_finance）。然后执行：

# 在HBase Shell中检查命名空间是否存在 list_namespaces # 检查kylin用户权限 user_permission '@kylin_ns_finance'

若user_permission返回kylin RWXCA，表明HBase层授权正确。至此，Kylin的“三横一纵”（Hive元数据、HDFS工作区、HBase存储、YARN计算）四维连通性全部验证通过。

4.2 构建首个Cube：从模型设计到构建成功的全流程拆解

以CDH中一张典型的订单事实表dwd.fact_order为例，构建一个按日期聚合的Cube。

步骤一：创建Model（模型）

1. Web UI → “Model” → “New Model”；
2. “Data Source”选择dwd库，表选fact_order；
3. “Dimensions”中，将order_date（STRING类型）拖入，Kylin会自动识别其为日期维度；
4. “Measures”中，添加SUM(order_amount)，类型选Count Distinct（若需去重计数）或Sum；
5. “Partition Date Column”设为order_date，格式yyyy-MM-dd；
6. 点击“Save”保存模型，命名为model_order_daily。

实操心得：Partition Date Column必须是Hive表中真实存在的分区字段，且其Hive表必须是分区表（PARTITIONED BY (order_date STRING)）。若表未分区，Kylin构建时会报错“Partition column not found”，且错误日志不提示需先建分区表，这是新手最大坑点。

步骤二：创建Cube（立方体）

1. “Cube” → “New Cube”；
2. 选择刚创建的model_order_daily；
3. “Advanced Setting”中，关键配置：
   • Retention Days: 设为90（保留90天历史数据，避免HBase Region无限膨胀）；
   • Engine Type: 选MR（CDH 6.1.0默认，Spark引擎需额外配置Spark on YARN）；
   • HBase Namespace: 自动继承kylin_ns_finance；
4. “Rowkey”设计：将order_date设为第一个Rowkey列，确保HBase按日期范围扫描高效；
5. “Aggregation Groups”中，勾选order_date，表示按日期聚合所有度量；
6. 点击“Save”保存Cube，命名为cube_order_daily_sum。

步骤三：全量构建（Build）

1. Cube列表中，找到cube_order_daily_sum，点击“Actions” → “Build”；
2. “Build Type”选Full Build；
3. “Segment Date Range”中，Start Date填2023-01-01，End Date填2023-12-31（需覆盖Hive表的实际分区）；
4. 点击“Submit”提交构建任务。

构建过程在CM的YARN服务页面可实时监控，任务名为Kylin_Cube_Build_XXX。成功标志是：

• CM中YARN队列kylin的Application Master状态为FINISHED；
• Kylin Web UI中Cube状态变为READY；
• HBase Shell中执行list 'kylin_ns_finance:KYLIN_XXXXXX'（XXXXXX为Cube ID），可见表已创建且有Region。

步骤四：SQL查询验证在Web UI → “Insight” → “New Query”，执行：

SELECT order_date, SUM(order_amount) as total_amount FROM dwd.fact_order WHERE order_date BETWEEN '2023-01-01' AND '2023-01-31' GROUP BY order_date ORDER BY order_date

首次查询会触发Cube预热，耗时稍长（约15-30秒）；后续相同查询响应时间应稳定在300ms内。若返回Query timeout，需检查kylin.query.timeout配置（默认60秒），或YARN队列kylin的资源是否被其他任务占满。

4.3 生产环境必备的JVM与YARN参数调优

Kylin默认JVM参数（-Xmx4g -Xms4g）在CDH 6.1.0生产环境中严重不足，会导致频繁GC甚至OOM。根据我处理的12个生产案例，黄金参数组合如下：

Kylin Server JVM参数（在CM Kylin服务配置中设置）：

# 堆内存：根据节点物理内存动态设定，建议为物理内存的40% kylin.server.jvm-options=-Xmx16g -Xms16g # GC算法：CDH 6.1.0的JDK 8u181+推荐G1GC kylin.server.jvm-options=-XX:+UseG1GC -XX:MaxGCPauseMillis=200 # 元空间：避免动态扩容开销 kylin.server.jvm-options=-XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=1024m # 关键：禁用偏向锁，减少多线程竞争 kylin.server.jvm-options=-XX:-UseBiasedLocking

YARN Container参数（在CM YARN服务配置中设置）：

# Kylin构建任务的Container内存上限（必须 >= Kylin Server堆内存） yarn.scheduler.maximum-allocation-mb=32768 # 单个Container的虚拟CPU核数（CDH 6.1.0默认vcores=4，Kylin需至少2） yarn.scheduler.maximum-allocation-vcores=8 # 为kylin队列单独配置 yarn.scheduler.capacity.root.kylin.maximum-allocation-mb=32768 yarn.scheduler.capacity.root.kylin.maximum-allocation-vcores=8

注意：yarn.scheduler.maximum-allocation-mb必须全局配置，不能仅在kylin队列中设置。若只在队列中设，Kylin提交任务时会因申请内存超限而被YARN拒绝，错误日志显示Requested memory 32768 beyond capability of cluster，排查时易误判为Kylin配置问题。

5. 常见问题与排查技巧实录：来自12个生产环境的真实故障库

5.1 故障速查表：高频问题、现象、根因与解决方案

5.2 独家避坑技巧：那些文档里不会写的实战经验

技巧一：“Cube构建失败”日志的黄金三行定位法Kylin构建日志（/var/log/kylin/kylin.log）动辄数百MB，盲目搜索效率极低。我总结出“三行定位法”：

1. 第一行：搜索ERROR，定位到第一个ERROR堆栈的起始行；
2. 第二行：从此行向上翻10行，找Step start:开头的行，它标识了失败的具体步骤（如Step start: CreateHTableStep）；
3. 第三行：从此行向下翻5行，找Caused by:，它揭示了最底层的异常类（如java.lang.NoClassDefFoundError: org/apache/hadoop/hbase/client/AsyncConnection）。 这三行组合，90%的问题可直击根因。例如，Caused by: NoClassDefFoundError必然是JAR包冲突，Caused by: SQLException必然是Hive连接问题。

技巧二：HBase RegionServer OOM的“静默杀手”排查Kylin Cube数据写入HBase时，若RegionServer内存不足，不会报错，而是静默丢弃写入请求，导致Cube查询结果缺失部分日期数据。判断方法：

1. 在CM中进入HBase服务 → “图表” → “RegionServer Heap Usage”，观察峰值是否>95%；
2. 若是，检查HBase配置hbase.regionserver.global.memstore.size（默认0.4），将其降至0.35；
3. 同时，在Kylin服务配置中，增加kylin.storage.hbase.region-count-min=50，强制Kylin为Cube创建更多Region，分散写入压力。 此技巧帮我定位过3起“数据丢失”事故，均因RegionServer内存饱和导致。

技巧三：CM服务依赖的“隐形链条”修复有时Kylin服务状态为“Stopped”，但CM界面不显示任何错误。执行sudo /opt/cloudera/cm-agent/bin/supervisorctl status，发现kylin-server进程为FATAL。此时并非Kylin自身问题，而是其上游依赖服务（如ZooKeeper）状态异常。CM的依赖图是“隐形”的，需手动检查：

# 查看Kylin依赖的服务 sudo cat /var/run/cloudera-scm-agent/process/*/env.sh | grep -E "(ZOOKEEPER|HIVE|HBASE)" # 逐个检查这些服务在CM中的状态

我曾遇到Kylin因ZooKeeper的/hbaseZNode被意外删除而无法启动，CM未报警，手动执行zkCli.sh并ls /hbase才发现问题。

5.3 性能基线与容量规划：给你的Kylin集群画一张“健康地图”

在CDH 6.1.0上稳定运行Kylin，必须建立一套容量基线。基于12个生产环境的实测数据，我整理出核心指标阈值：

• Cube构建吞吐量：单个Kylin Server节点（32核/128G内存），在YARN队列分配16G内存+4vcores条件下，每小时可稳定构建2-3个中等复杂度Cube（10亿行事实表，5个维度，3个度量）。若构建耗时>2小时/Cube，需检查HDFS IO吞吐或HBase Compaction压力。

• HBase存储增长：Kylin Cube数据量约为原始Hive表的3-5倍（因预计算聚合）。例如，dwd.fact_order表每日增量100GB，则对应Cube每日新增HBase存储300-500GB。需为HBase DataNode预留至少20%的磁盘空间用于Compaction临时文件。

• Kylin Server Heap压力：正常运行时，kylin.server.jvm-options中-Xmx值应为Kylin Server节点物理内存的35%-45%。若GC时间占比（通过jstat -gc查看）持续>15%，