简介：《Kyligence Enterprise 3.4》中文 PDF 文档面向大数据分析平台建设者、Kylin 运维与开发人员，以及需要查阅 API、部署与调优配置的工程师，服务于企业级 OLAP 分析场景。压缩包内含 1 个 PDF 文件，大小约 96.06MB，适合作为案头检索手册长期留存。文档系统覆盖 CDH、HDP、MapR、FusionInsight 等环境安装，集群、读写分离、多租户与资源组部署，以及安装验证、负载均衡、高可用、RDBMS 元数据存储、Cube 存储引擎、Spark 资源、Hadoop 队列配置、日志滚动、查询缓存、压缩配置与 Beeline 连接 Hive。数据接入部分梳理 Hive、Kafka、RDBMS、Impala 等数据源及全量、增量、流式导入策略；模型与 Cube 设计涉及维度聚合组、度量、TopN、精确与近似去重、优化器、缓慢变化维度、模型推荐与检测、可计算列、流式 Cube、半累加度量和明细表索引。查询与集成章节还包含 SQL 规范、查询下压、异步查询、JDBC/ODBC 驱动、Tableau 与 Power BI 等 BI 工具连接及安全权限控制，便于对照排查配置和性能问题；已有 529 人学习下载。

1. 版本先定死：Kyligence Enterprise 3.4 装之前要认清的三个硬门槛

搜 kylin api文档 的人，十个里有八个其实卡在装不上这一步：接口清单翻得再熟，服务起不来照样白搭。Kyligence Enterprise 3.4 的安装包解开就能跑，但它对底座挑剔得超出预期——JDK 必须是 8 的 64 位，HDFS 工作目录要提前建好并 chown 到位，Hive 中间表库得手工 create database，HBase 还得单独 grant。少任何一步，kylin.sh start之后日志里就是一片 AccessDeniedException。它适合已经有一套 CDH、HDP、MapR 或 FusionInsight 集群、想把 PB 级明细压成亚秒级查询的团队，也适合先在沙箱上跑通样例 Cube 再决定要不要上生产的人。下面按我实际装过一遍的顺序写，版本、参数、报错一条不落。

2. 前置条件核对：JDK 8、HDFS 工作目录和四类集群权限

装这套东西翻车，九成不是装的时候翻的，是装之前没核对。我习惯在动手解压之前先花半小时把三个东西确认掉：Java 版本、跑服务的 Linux 账户权限、YARN 的资源池。这三件事任何一件不达标，后面所有步骤都是白做，而且报错点会飘到很远的地方去，排查起来特别费劲。这一章就把这三件事逐条落到命令上，照着敲完再往下走。

2.1 JDK 与操作系统：JDK 8 64 位这条线不能松

产品本身和它跑的 Hadoop 环境里所有节点，Java 环境要求都是 JDK 8 的 64 位或以上。注意「所有节点」这三个字——不是只有装 Kyligence 的那台机器，集群里跑 YARN、跑 Hive 的节点也一样。我见过只在一台机器上升级了 JDK，结果 Cube 构建任务被调度到老节点上直接 ClassNotFound 的情况，日志里根本看不出是版本问题。

# 在每一台相关节点上确认，重点看 64-Bit 和 1.8 这两处 java -version 2>&1 | head -n 3 # 期望形如： # java version "1.8.0_xxx" # Java(TM) SE Runtime Environment (build 1.8.0_xxx-bxx) # Java HotSpot(TM) 64-Bit Server VM (build 25.xxx-bxx, mixed mode)

java -version默认输出到标准错误，所以要2>&1重定向再管道，否则head拿不到内容。看三行就够：第一行是版本号，第三行里有没有64-Bit决定了能不能撑住大内存堆。

如果集群底座还停在 JDK 7，也不要急着全集群升级，官方给了一条「在低版本 JDK 上运行」的路子：给 Kyligence 单独指一个 JDK 8 的JAVA_HOME，让它自己用 8，集群其他组件继续用 7。常见做法是在$KYLIN_HOME/conf/下放一个启动前加载的环境脚本，把JAVA_HOME写死：

# $KYLIN_HOME/conf/setenv.sh，没有就新建，启动脚本会先加载它 export JAVA_HOME=/usr/java/jdk1.8.0_202 export PATH=$JAVA_HOME/bin:$PATH

注意这个文件只影响 Kyligence 自己的进程，不污染系统级环境变量，也不会影响同机上其他 Hadoop 组件。写完之后用$KYLIN_HOME/bin/kylin.sh start启动，再ps -ef | grep kylin看进程的启动命令行里带的是不是那个 8 的路径，这一步验证别省。

操作系统层面，官方验证过的是 RHEL 6.4+ 或 7.x、CentOS 6.4+ 或 7.x。客户端这边要求不高但也不是没门槛：CPU 2.5GHz 起步、内存 8G 以上，浏览器 Firefox 60.0.2 及以上、Chrome 67.0.3396 及以上。用旧版浏览器登管理界面会出现页面渲染错乱、按钮点不动的情况，很多人第一反应是服务挂了，其实是浏览器版本太低。

2.2 用 KyAdmin 这个账户把 HDFS、Hive、HBase 权限先跑通

跑 Kyligence 的那个 Linux 账户，需要具备四类权限：读写 HDFS 上的文件、创建和读取 Hive 表、创建和操作 HBase 表（如果你用 JDBC 接元数据存储，这条可以跳过）、提交 MapReduce 任务。下面统一用KyAdmin这个账户名举例，实际换成你自己的。

第一步是 HDFS 工作目录。默认工作目录是/kylin，可以通过conf/kylin.properties里的kylin.env.hdfs-working-dir改，改完两边必须一致，改一处不改另一处是最常见的低级错误。

# 切到 hdfs 账户去建目录，普通账户通常没这个权限 su hdfs hdfs dfs -mkdir /kylin hdfs dfs -chown KyAdmin /kylin hdfs dfs -mkdir /user/KyAdmin hdfs dfs -chown KyAdmin /user/KyAdmin

-mkdir不带-p只能建一级目录，父目录不存在会直接报错；-chown只改属主不改属组，够用。为什么要建/user/KyAdmin？因为跑 MR 任务时框架会在用户主目录下写临时文件，主目录不存在或者不可写，任务提交阶段就会失败，报错信息还藏在 YARN 的容器日志里，特别难找。

建完立刻验证，别等到装完再回头查：

# 传一个任意小文件上去，能传能删就算通 hdfs dfs -put /etc/hostname /kylin hdfs dfs -put /etc/hostname /user/KyAdmin hdfs dfs -ls /kylin hdfs dfs -rm /kylin/hostname

第二步是 Hive。中间表会落在某个 Hive 库里，假设叫kylinDB，这个库要手工建，同时把库位置指到 HDFS 工作目录下，并在conf/kylin.properties里同步配置kylin.source.hive.database-for-flat-table=kylinDB。

-- 用 KyAdmin 进 Hive，把建库、建表、删表这一圈跑通 show databases; create database kylinDB location "/kylin"; use kylinDB; create table t1(id string); drop table t1;

location "/kylin"让这个库的数据目录直接落在工作目录下，省得后面磁盘配额和权限再出岔子。create table加drop table这一对是必须的，只建不删说明不了问题——很多环境给的是只读权限，建表能过，删表报错，等到清理垃圾数据的时候才炸。

第三步是 HBase，只在用 HBase 存元数据时需要。假设实例标识是XXX_instance、命名空间是XXX_NS，配置项写成kylin.metadata.url=XXX_NS:XXX_instance@hbase，然后验证建表和删表权限：

# 进 HBase shell 走一遍完整动作 hbase shell # 下面这些在 shell 里执行 list create 't1',{NAME => 'f1', VERSIONS => 2} disable 't1' drop 't1'

删表必须先disable再drop，这是 HBase 的硬性顺序，跳过 disable 会直接报错，别以为是权限问题。如果建表被拒，让管理员授权：grant 'KyAdmin','RWXCA'，这五个字母分别是读、写、执行、创建、管理的缩写，做元数据存储这五项缺一不可。

如果集群开了 Sentry 管 Hive 数据权限，还要额外授权当前账户访问 Kyligence 的 HDFS 工作目录和临时目录，这一条经常被漏掉，表现是 Cube 构建到一半突然权限报错。

2.3 集群资源参数：那四个不能低于下限的 YARN 值

资源这块有个下限表，低于它任务跑不动但不是跑不了，表现是构建特别慢或者频繁重试，比直接报错更难查。

前两个是配套的：单节点总量 8192 而单容器上限只有 1024，大任务永远排不上，会一直卡在 ACCEPTED 状态。后两个也是配套的，堆不能超过容器内存，否则容器会被 NodeManager 直接 kill，日志里写的是Container killed on request，看不出是内存配置问题。

在沙箱或虚拟机上跑，还有一组下限：处理器不少于 4 个、内存不少于 10 GB、yarn.nodemanager.resource.cpu-vcores不小于 8。生产环境推荐配置是 32 vCore、128 GB 内存、至少一块 1TB 的 3.5 英寸 SAS 硬盘（7200RPM，RAID1）、至少两个 1GbE 网口。硬盘这块我的建议是别抠，Cube 构建时的中间数据和 HDFS 副本都吃 IO，机械盘做 RAID1 已经是底线了。

至于底座平台，下面的版本是经过认证和测试的，带「已停止维护测试」标记的就别往上装了：

强烈建议把 Kyligence 单独放在一个独立的 Hadoop 集群上，别和跑批的业务集群混用。混用的后果是两边抢 YARN 队列，白天查询慢、晚上构建慢，谁都不痛快。

3. 单节点安装：解压、KYLIN_HOME、profile_min 与 7070 端口

前置条件过完，单节点安装其实一共就五步：解压、设环境变量、建 HDFS 目录、选配置方案、启动。看着简单，但每一步都有一个容易写错的地方，尤其第二步和第四步。这一章按顺序走，命令都是能直接抄的，路径按/usr/local和root账户举例，实际换成你自己的。

3.1 解压到 /usr/local 并固定 KYLIN_HOME

拿到软件包之后先传到目标机器，解压路径建议就用/usr/local，这是官方示例的假设，也是后面所有相对路径能对上的前提。

# 解压到安装路径下 cd /usr/local tar -zxvf Kyligence-Enterprise-3.4.tar.gz # 解出来的目录名带版本号，把它固定成 KYLIN_HOME echo 'export KYLIN_HOME=/usr/local/Kyligence-Enterprise-3.4' >> ~/.bashrc echo 'export PATH=$KYLIN_HOME/bin:$PATH' >> ~/.bashrc source ~/.bashrc # 确认变量生效 echo $KYLIN_HOME

tar的四个参数z是 gzip 解压、x是解包、v是打印过程、f是指定文件名，顺序不用记，记住-zxvf后面跟包名就行。把KYLIN_HOME写进~/.bashrc而不是只在当前终端export，是因为后面所有脚本都依赖这个变量，开个新窗口就丢的环境变量是排查噩梦的源头。PATH那一行是我自己加的，加了之后可以直接敲kylin.sh start，省得每次打全路径。

环境变量设好之后建 HDFS 工作目录。默认是/kylin，建目录和授权要用 HDFS 超级用户身份：

# 普通账户没权限的话，先切 hdfs hdfs dfs -mkdir /kylin hdfs dfs -chown root /kylin hdfs dfs -mkdir /user/root hdfs dfs -chown root /user/root

如果你用的是 CDH 那套环境，跑服务的账户通常是cloudera而不是root，把上面两条chown后面的用户名换成实际账户即可，/user/root也要换成/user/cloudera。这一步搞错，表现是启动时 HDFS 写入被拒，日志里能看到Permission denied。

需要改工作目录位置的话，编辑$KYLIN_HOME/conf/kylin.properties，改kylin.env.hdfs-working-dir这一项，改完记得把新的 HDFS 路径也建出来并授权，两边不同步是高频错误。

3.2 profile_prod 和 profile_min：两套出场配置怎么选

conf目录下预置了两套配置方案，profile_prod和profile_min，用软链接的方式切换。前者是默认方案，面向真实生产环境；后者占用资源更少，适合沙箱、单机、内存吃紧的虚拟机。

# 先删掉原来的软链 rm -f $KYLIN_HOME/conf/profile # 再指向 profile_min ln -sfn $KYLIN_HOME/conf/profile_min $KYLIN_HOME/conf/profile # 确认指向正确 ls -l $KYLIN_HOME/conf/profile

ln的三个参数要解释一下：-s建软链接而不是硬链接，-f强制覆盖已存在的同名文件，-n把已存在的软链接当普通文件处理，避免在软链接里面再套一层软链接。少了-n，在某些系统上会出现profile/profile_min这样的嵌套路径，看着指向对了实际读不到文件，属于典型的玄学问题。

什么时候切profile_min？我的判断标准很土：沙箱环境、虚拟机内存 10~16G、只做功能验证，直接切 min；只要开始接真实数据、跑 Cube 构建，就老老实实用 prod。min 配置省的是并发和内存池，不是省功能，但构建大 Cube 的时候会明显慢，不要拿它当性能测试的基线。

切换之后不需要额外操作，重启服务就会按新 profile 生效。

3.3 启动脚本与端口偏移：kylin.sh 和那个改端口的工具

启动就一条命令，但启动之后看什么，决定了你能不能第一时间发现异常。

# 启动 $KYLIN_HOME/bin/kylin.sh start # 另开一个窗口盯日志，这是唯一的黑匣子 tail -f $KYLIN_HOME/logs/kylin.log # 确认进程还在 ps -ef | grep kylin

kylin.sh支持start、stop两个动作，语义很直白。启动过程是异步的，命令返回不代表服务就绪，所以要tail -f看日志。看到控制台打出启动成功的提示，再用ps -ef确认进程存在，这三步缺一不可。我踩过的坑是只看命令返回码就以为起来了，结果进程启动到一半因为 HDFS 权限挂了，前面几十秒一切正常，后面全是异常栈。

停服务同理：

$KYLIN_HOME/bin/kylin.sh stop ps -ef | grep kylin # 确认真的停了，没有残留进程

停完一定要ps确认。有时候进程僵在那儿不退出，端口还被占着，直接重启会报端口冲突，你以为重启了其实跑的旧进程。

默认 Web 端口是 7070，访问地址http://{host}:7070/kylin/，{host}换成机器名、IP 或域名都行。端口要改的话用自带的工具：

# 设置偏移量，比如 100 $KYLIN_HOME/bin/kylin-port-replace-util.sh set 100 # 偏移量改完必须重启才生效 $KYLIN_HOME/bin/kylin.sh stop $KYLIN_HOME/bin/kylin.sh start

注意这个工具设置的是「偏移量」不是「端口号」。设成 100，后端实际监听的是 7070 + 100 = 7170，不是 100。这个设计第一次用很容易误解，设完之后访问 100 端口打不开，还以为工具没生效。

首次登录的默认账户是ADMIN，密码KYLIN。登进去第一件事是改密码，规则是长度至少 8 位，且同时包含数字、字母和特殊字符（~!@#$%^&*(){}|:"<>?[];',./这些）。别偷懒用纯字母，规则校验会直接拦住。

3.4 元数据落哪里：HBase 与 MySQL 的取舍

元数据存储是这个产品里最容易被忽略、又最影响后期运维的一环。默认走 HBase，配置项是kylin.metadata.url，格式形如命名空间:实例名@hbase。HBase 方案的优点是开箱即用，集群里现成有就能连；缺点是元数据量大了之后查询和备份都别扭，而且和 HBase 的权限、Kerberos 绑得比较死。

另一条路是用 RDBMS，MySQL 或 Microsoft SQL Server 都支持。切过去之后元数据落在关系库里，备份、迁移、审计都顺手得多，运维侧的日常检查也简单——直接用 SQL 客户端就能看。代价是要多维护一套库，连接串、账号、字符集都得配对。

切换的时候有几个点必须注意。字符集必须是 UTF-8，不然 Cube 名字里的中文会变问号，而且这种损坏是不可逆的。连接池大小按并发量给，给太小会在并发构建时出现连接等待，日志里是获取连接超时，看起来像是数据库挂了。切换前一定先把原有元数据备份出来，官方在运维章节里专门有「元数据备份与恢复」和「元数据检查」两节，那个流程别跳。

已经用 HBase 跑了一段时间想搬过去，官方有专门的迁移章节，思路是先把元数据导出，再按 RDBMS 的连接配置导入。我的血泪经验是：迁移前先在测试环境完整走一遍，包括导出、导入、启动、构建、查询五个动作，别在生产上直接试。元数据这东西没有后悔药，删了就真没了。

4. 平台适配安装：CDH、HDP、MapR、FusionInsight 的差异步骤

同样是解压、设变量、建目录、启动，放在不同底座上，差别全在「准备工作」这一段：用哪个账户、组件怎么起、权限怎么给。这一章按平台拆开写，都是沙箱和集群上验证过的路径。选哪一节看你的底座，别跳着看，里面有些坑是通用的。

4.1 CDH 环境：桥接网卡、cloudera 账户和 HBase 那一刀

沙箱安装第一件事是网络模式。推荐用 Bridged Adapter 而不是 NAT，原因很实际：桥接会给沙箱分配一个独立 IP，本地访问和远程访问都行，NAT 模式下端口映射没配好，Web 界面死活打不开，你会以为是服务没起来。

账户统一用 CDH 默认的cloudera，避免权限问题。进管理控制台（默认 7180 端口）确认 HDFS、YARN、Hive、HBase、ZooKeeper 全部正常且没有告警，然后按第 3 章的流程装。

CDH 上最容易撞的报错是这个：

org.apache.hadoop.hbase.security.AccessDeniedException: Insufficient permissions for user 'root' (auth:SIMPLE)

意思是 HBase 写入权限不够。两条路：要么按 2.2 节给账户授权，要么在沙箱这种非安全环境里直接把 HBase 的权限检查关掉——把hbase.coprocessor.region.classes和hbase.coprocessor.master.classes两个配置项的值设为 empty，把hbase.security.authentication设为simple。注意这是沙箱做法，生产环境老老实实授权，别图省事。

4.2 HDP 环境：Ambari 起来之后别忘了手动拉 HBase

HDP 沙箱的账户用root，账号密码细节参考对应版本的文档。启动顺序是先起 agent 再起 server：

# 启动 Ambari ambari-agent start ambari-server start

起来之后访问管理页面（默认 8080 端口），默认账户admin。这里有个 HDP 特有的坑：HBase 不在默认启动项里，必须手动启动。很多人看完组件列表发现 HDFS、YARN、Hive、ZooKeeper 全是绿的，就直接往下装了，结果装到一半报 HBase 连不上。手动把 HBase 拉起来，确认五个组件都正常且无告警，再走安装流程。

HBase 权限那个报错和 CDH 上一模一样，处理方式也一样，不重复写。

4.3 MapR 环境：mapr 账户与 maprlogin 票据

MapR 沙箱用mapr账户，默认密码也是mapr。集群版比沙箱复杂，差异集中在这几点：

安装时建议给每个节点分配公网 IP，装完在安全组里开放常用端口，至少 7070（Kyligence 的 Web 端口）和 8090（ResourceManager）。

集群节点不能直接 ssh 登录，要以 MapR Installer 节点为跳板，密钥放在/opt/mapr/installer/data目录下。这个设计第一次用会卡很久，因为直接连会被拒，报错信息也不提示你是跳板机的问题。

最关键的差异是票据。在集群节点上访问 MapR 集群资源，需要先生成mapr_ticket：

# 生成票据，按提示输入密码 maprlogin password # 确认票据有效期 maprlogin print

没有票据的情况下，HDFS 操作会直接失败，而且报错信息指向的是权限而不是票据，很容易往错误方向查。我的习惯是每次新开终端先maprlogin print看一眼票据还在不在，过期了就重新生成。这个动作五秒钟，能省半小时排查。

4.4 部署模式选型：从单机切到集群、读写分离与多租户

单节点跑通之后，什么时候该切部署模式，判断标准不是数据量，是并发和可用性要求。

集群部署加负载均衡是最常见的下一步，多个实例挂同一个元数据库，前面放负载均衡，查询请求分散开。读写分离是构建和查询分开部署，构建节点吃 CPU 和内存跑 Spark 任务，查询节点专心响应 SQL，互不干扰——这个模式在白天也要跑构建的场景下收益最大。多租户部署解决的是不同业务线互相隔离的问题，每个租户有自己的项目和资源配额。资源组部署则是把 YARN 队列和 Kyligence 的资源组对上，保证重要任务能优先拿到资源。此外还有服务发现与任务引擎、高可用部署，以及云端部署。

配置层面这些模式都不是改一个开关就完事，涉及集群节点列表、元数据库连接、服务发现组件、资源组映射几处要一起改。我的建议是先在测试环境把目标模式跑通一遍，尤其是高可用和读写分离，切换过程中元数据的读写一致性最容易出问题。切之前把元数据备份做掉，这是唯一能救命的东西。

5. 避坑与排查：装 Kyligence Enterprise 3.4 最常翻的四个车

这一章是我自己的错题本，四条都是真实撞过的，按「现象、原因、解决」写。装的时候遇到问题先来这里对一遍，比漫无目的翻日志快得多。

5.1 权限类：AccessDeniedException 的两种身份

现象一：启动或首次建 Cube 时，日志里出现org.apache.hadoop.hbase.security.AccessDeniedException: Insufficient permissions for user 'xxx' (auth:SIMPLE)，服务起不来或者建表失败。

原因：运行账户在 HBase 上没有建表和写数据的权限。auth:SIMPLE说明当前是非 Kerberos 的简单认证模式，权限完全靠 HBase 的 ACL 控制。沙箱环境经常是默认开了 ACL 但没给账户授权。

解决：生产环境走授权路线，grant '账户名','RWXCA'五项全给；沙箱环境如果只是想快速验证功能，把hbase.coprocessor.region.classes和hbase.coprocessor.master.classes设成 empty、hbase.security.authentication设成simple，关掉检查。两条路的区别要记清楚：授权是长期的，关检查是临时的，别把沙箱配置带到生产去。

现象二：HDFS 上传文件时报Permission denied: user=xxx, access=WRITE, inode="/kylin"，明明目录已经建了。

原因：目录建了但属主不对。用hdfs账户建的目录，属主默认是hdfs，跑服务的账户没有写权限。或者建的时候用了-chown但用户名写错了。

解决：hdfs dfs -ls /看一眼/kylin和/user/xxx的属主，不对就重新chown。这两个目录的属主必须是实际跑 Kyligence 的那个 Linux 账户，一个字符都不能差。

5.2 启动类：半死状态、端口占用和那两个被忽略的配置

现象三：kylin.sh start返回成功，ps -ef | grep kylin也能看到进程，但浏览器打不开 7070，或者打开了登录页但登录后一片空白。

原因：进程活着不代表服务就绪。启动是分阶段的，前面的进程起来了，后面的元数据连接、Hive 连接可能还在失败重试。另一个常见原因是端口被改过——之前有人跑过kylin-port-replace-util.sh set，偏移量还在，实际监听的不是 7070。

解决：第一件事tail -f $KYLIN_HOME/logs/kylin.log，从头看，不要只看最后几行。第二件事netstat -tlnp | grep java确认实际监听端口。第三件事确认访问的地址里带没带/kylin/这个路径后缀，漏了会 404，很多人以为是服务问题。

现象四：重启服务时报端口已被占用，但ps -ef | grep kylin看不到进程。

原因：上次stop没有真正停干净，进程僵死或者子进程残留，端口还被占着。也可能是同机上另一个 Java 应用占了这个端口。

解决：netstat -tlnp找到占端口的 PID，确认是残留进程就kill -9。养成stop之后必须ps确认的习惯，这个动作能省掉后面一半的「莫名其妙起不来」。

另外补两个最容易被忽略的配置点。一是 JDK 7 集群没做单独JAVA_HOME隔离，启动时用的是系统的 7，跑起来各种UnsupportedClassVersionError，看着像包坏了其实是版本不对。二是集群开了 Kerberos 之后，自带的 Spark 需要正确配置才能安全访问集群资源，没配的话构建任务会在提交阶段就被拒，报错信息是一堆 GSS 相关的异常，跟权限看着没关系，实际就是认证没配。

6. 装完怎么验证：从 sample.sh 到 kylin_sales_cube 的一条龙自检

服务起来只是第一步，能不能真正跑通一条链路才是验收标准。官方的验证路径很清晰：导入样例数据、构建样例 Cube、跑一条 SQL 看命中情况。我每次装完都按这三步走，任何一步不对就停下来查，不往下推进。

6.1 导入样例数据并重载元数据

前提是 Hive 已经能正常读写。样例数据脚本在$KYLIN_HOME/bin下，跑一条命令就行：

# 把自带样例数据灌进 Hive，脚本会自动建库建表并加载数据 $KYLIN_HOME/bin/sample.sh

脚本执行完，回到系统页面点一次「重载元数据」，让服务重新扫描 Hive 里的库表。不点这一步，页面上看不到新导入的表，你会以为是脚本没跑成功。重载之后应该能看到一个叫learn_kylin的项目。

6.2 构建 kylin_sales_cube 并用一条 SQL 确认命中

进learn_kylin项目，选kylin_sales_cube点构建。构建过程可以在监控页面看进度，正常的话会经历几个阶段，每个阶段都有状态。

构建成功后到查询页面执行：

-- 按分区日期统计，验证 Cube 是否被命中 select PART_DT, COUNT(*) from KYLIN_SALES group by PART_DT;

结果返回后，看状态下方的「查询引擎」条目，那里会显示这次查询命中的是哪个 Cube。如果显示的是下压到 Hive 或 Spark，说明 Cube 没被用上，可能是维度没覆盖或者构建没完成。这里有两个查询限制要记住：只支持 SELECT 查询；如果没开查询下压，Cube 满足不了的查询不会自动重定向，会直接报错，别以为是语法问题。

验收清单我一般按这张表逐项打勾，全绿才算装完：

这套流程走完，安装这件事就算闭环了。手册里 REST API 那一整章——项目 API、数据源 API、模型 API、Cube API、Segment 管理 API、任务 API、查询 API，还有访问控制那一堆权限接口——我一般等接口联调的时候再翻，装的时候不用全看。但元数据备份和日常检查这两节建议提前读一遍，从第一次装完就养成备份习惯，比出事之后再找后悔药强。从那以后我每次装完一套环境，sample.sh加kylin_sales_cube这两步都强制走一遍，不看界面绿不绿，只看那条 SQL 有没有真的命中。希望帮到你。

本文还有配套的精品资源，点击获取