企业官网建设流程全解析

朋友公司的数据分析团队找我唠嗑，说他们的报表查询最近越来越难扛。底层Hive表里已经攒了十几亿条明细，业务方每天要按区域、商品、日期各种维度看汇总，直接跑Spark任务一次要几分钟，几个人同时点，集群直接进入排队模式。我跟他们聊完就推荐先看Kylin。

Kylin是Apache旗下的开源分布式分析引擎，核心思路特别朴素：在数据进查询系统之前，先把各种维度的组合结果预计算好，查询时只做最轻量的扫描，把分钟级的SQL拉回秒级。这篇是Kylin快速入门系列的第一篇，重点只聊两件事，一是Kylin到底是什么、解决什么问题，二是我自己在服务器上一路跑通的安装部署流程。无论你是做数仓的、做BI的，还是刚接触OLAP的小白，这篇都适合当第一份读物。

1. 为什么需要Kylin：BI查询卡顿背后的计算困境

先说一个常见的场景。业务部门要看"昨日各门店的销售额"，底层数据在Hive表里，几百亿行明细。你写一条SQL丢给Hive或Spark，它要做的是：扫全表、做过滤、做聚合、洗数据，最后才吐出几十行结果。这个过程本质上是在查询发生时"现算"，数据量一大，算力全花在扫描和排序上。

这类问题的名字叫高并发低延迟OLAP查询。OLAP场景的特点是自己不写数据，只做各种维度的切片、钻取、汇总。BI工具给用户的体验预期是：点一下，几秒钟出图。可一旦底表上亿行、几十个维度的自由组合，直接查Hive或者Spark基本不可能达到秒级。

1.1 直接查Hive和Spark为什么搞不定高频查询

有人会说，Hive不行那我上Spark总可以吧。Spark确实比Hive快，但本质还是"查询时硬算"。你每次刷新一张报表，就是重新跑一遍全部的shuffle和聚合。同一份数据，十个人点了十次，Spark就得算十次，集群资源全耗在读数上。

还有一个更隐蔽的问题：BI工具喜欢做交互式下钻。用户先看全国汇总，然后点进上海，再点进浦东新区。每一次下钻都是一条新SQL，是重新聚合，不是在前一次结果上切片。数据量到一定规模以后，这种交互体验就彻底没法用了，资源再大也扛不住。

说白了，传统大数据计算模型是"为跑批优化"的，不是"为人点按钮优化"的。跑批你可以等十分钟，人点按钮等不了十分钟。Kylin的思路就是反过来：既然查询早晚要发生，而且维度和度量组合是有限的，那我提前把这些聚合结果全算好，查询时只做最少的计算。

1.2 Kylin在技术栈里到底处于哪一层

从技术栈看，Kylin坐在Hive/Spark和BI工具之间，是一个OLAP服务层，查询走它，数据源是数仓里的离线表。它自己不会去源头采集数据，而是从Hive表定期读取数据，构建出Cube，然后对外提供标准SQL接口。

也就是说，Kylin不是什么分析数据库，也不是存储引擎的替代品。它是你在现有离线数仓上叠加的一层预计算引擎。官方定位是"极速OLAP引擎"，追求的是让大数据量下的标准聚合查询达到亚秒级。

这个定位决定了它的适用场景。如果你的需求是几百亿行数据、几十个维度组合、要求查询延时在1秒上下，Kylin是合理的选项；如果你的需求是即席查询，SQL千奇百怪、维度组合完全不可预测，那Kylin可能反而会限制你，这后面我会专门讲。

2. Kylin的核心思路：预计算Cube与以空间换时间

Kylin的关键概念是Cube，中文可以叫数据立方体。把它理解成"提前做好的一堆结果集合"就行。维度、度量、预聚合，这三个词是理解Kylin的钥匙。

2.1 维度、度量和Cuboid到底指什么

维度是你分组或者筛选的字段，比如地区、商品类别、日期。度量是你想算的数值，比如销售额、订单数、库存量。一条正常的业务查询，无非是"按某些维度分组，对某些度量做SUM、COUNT、AVG、MAX、MIN"。

Kylin的做法是，对一份数据，把所有可能被用到的维度组合全部预先算一遍并存下来。N个维度就能组合出2的N次方种分组方式，每一种组合在Kylin里叫一个Cuboid。比如三个维度是地区、品类、日期，那么Cuboid就包括"按地区聚合"、"按地区+品类聚合"、"按日期+地区+品类聚合"等等。

你可以这样类比：普通的查询方式像客人来了才切菜，厨房里堆着一堆土豆，每个菜都要现洗现切现炒，客人一多就手忙脚乱；Kylin像后厨提前把所有菜切好分装，客人一点菜，直接下锅翻两下就能端出来。代价就是你得为这些"切好的半成品"付出存储空间。

构建Cube的过程，就是拿Hive里的明细数据，按设计好的维度组合，一批批把这些聚合结果算出来。构建出来的文件，Kylin 3.x时代放在HBase里，Kylin 4.x时代放在HDFS上用Parquet格式存储。这里先记住结论，后面安装部署会涉及版本选型。

2.2 一条SQL是怎样命中预计算结果的

很多人怀疑Kylin是不是把所有SQL都预先跑一遍，其实不是。它是把"分组聚合结果"预先算好，等用户查询来了，Kylin先改写SQL，再把改写后的查询落到对应Cuboid上。

举一个最简单的例子。用户发一条这样的SQL：

SELECT store_region, SUM(payment_amount) FROM sales WHERE order_date >= '2024-01-01' AND order_date <= '2024-01-31' GROUP BY store_region;

如果Cube里已经构建过"按日期+地区"这个维度组合，Kylin会把查询重写成读那个Cuboid的存储片段，过滤条件只针对日期这个维度做裁剪，最后做一个极轻量的聚合。整个过程不需要碰明细数据，主要耗时是扫描已经算好的中间结果，通常就一两秒甚至毫秒级。

还有一个细节是：如果用户的查询恰好没被任何Cuboid覆盖，比如Cube里只设计了"日期+地区"，用户却拿商品类别来过滤，那Kylin会直接给出一个错误提示，而不是偷偷去跑Spark查询。这是预计算引擎和其他SQL引擎最大的行为差异，提前知道这一点能省很多排查时间。

2.3 Kylin的边界：不是所有OLAP需求都该上Kylin

我在实际交流中经常发现，一提到Kylin就有人误以为它能替代一切查询引擎。其实要分场景说清楚。

第一，它不适合明细查询。Kylin只保存聚合后的结果，如果你要查"某个用户过去一年下过的每一笔订单"，这种需求走Kylin是错配，应该直接查Hive、明细库或者倒排索引类引擎。

第二，它不适合维度组合完全不可控的即席分析。如果业务方今天按地区，明天按年龄段，后天按手机型号，而且允许任意组合，那Cube设计很难覆盖，构建量也爆炸，效果会非常差。Kylin更适合的是"分析路径相对固定，但数据量和并发都很大"的场景。

第三，它是离线批处理模型。Cube构建是定期做的，通常是T+1。如果你要求分钟级实时性，数据进来几分钟就要出结果，那Kylin也不是正解，应该考虑实时OLAP方案或者做混合架构。

你一定得先想清楚"我到底能不能接受预计算带来的模型约束"，再决定要不要花这个部署成本。它是搭在离线数仓上的加速层，不是万能数据库。

3. 安装前的准备：版本选型和依赖环境检查

Kylin本身是Java写的，它自己不存数据、不跑计算，而是依赖下游的Hadoop、Hive、HBase或Spark集群。所以安装Kylin的第一件事，不是看Kylin怎么装，而是先确认你手里的大数据底座能撑起它。

3.1 Kylin 3.x还是4.x：两条技术路线的差异

很多人在选版本这里坐下来开始纠结。我的建议是：先知道你手里的集群环境是什么，再反推用哪个大版本，而不是先装了Kylin再想办法凑环境。

Kylin 3.x是过去企业落地最广的版本，它依赖HBase，Cube数据存放在HBase的RegionServer里，查询引擎也深度依赖HBase的Coprocessor机制来做聚合下推。如果你的生产环境里已经有一套成熟的HBase，用3.x会非常顺滑，资料也多，遇到问题网上基本都有答案。

Kylin 4.x是一次大的架构调整。它把存储层从HBase换成了HDFS上的Parquet列式文件，查询引擎改成了Spark。4.x省掉了HBase这个重依赖，部署上更清爽，但Cube构建和查询都依赖Spark的算力，对计算资源的要求反而更高。选择4.x的前提是你有一个稳定的大内存Spark集群。

如果你只是个人学习、在服务器上做Demo，或者公司集群规模不大，我个人更推荐先用3.x跑通。它依赖组件多，但每个组件都是各自领域比较成熟的东西，排错路径清晰。4.x虽然架构简单，遇到启动问题往往要查Spark和文件的交互细节，对新手更费劲。

3.2 一套实测可用的版本组合

Kylin与所依赖组件的版本兼容关系，官方有对应的版本矩阵，大版本不要随便搭配。下面是适合Kylin 3.x的一个稳定组合，我在测试环境里跑通过，你可以作为参考：

这个组合不一定是你公司生产环境的组合。如果你用的是某商业大数据发行版，组件的版本体系会不一样，我的建议是遵循发行版兼容表来选，然后看Kylin官方是否列入了支持范围。版本这个东西，宁可用经过验证的老组合，也不要擅自升级某一个组件，Kylin对底层API版本很敏感。

3.3 环境检查命令和前置条件确认

在安装Kylin之前，建议先逐项确认底层服务都是好的。HDFS、YARN、Hive、HBase、ZooKeeper，一个都不能缺，Kylin不会帮你启动它们。

我一般会先做一轮快速冒烟：

hdfs dfs -ls / hive -e "show databases;" hbase shell zkCli.sh -server localhost:2181

这四个命令能跑通，说明基础服务在线。然后再检查端口：7070是Kylin的Web端口，2181是ZooKeeper，16010是HBase的Web UI。确保这几类端口在防火墙里都是放行的。

有一点容易忽略的是Hive配置文件。Kylin启动时要用hive-site.xml，而且要求这个文件里的连接信息指向真实的Hive。我遇到过不止一次，机器上装了Hive但环境变量CLASSPATH没配好，或者多个hive-site.xml互相覆盖，导致Kylin启动后连不上元数据。建议在部署Kylin之前，明确知道哪一份hive-site.xml是生效的。

echo $HIVE_CONF_DIR find / -name "hive-site.xml" 2>/dev/null

这两条命令输出的结果最好能对应上。Kylin安装后也可以手动指定Hive配置目录，代码里对应kylin.env.hive-conf-dir这个配置项。先把这些前置确认做扎实，后面安装其实只是机械操作。

4. 安装部署完整步骤：下载、配置、启动一次跑通

环境就绪后，Kylin本身的安装不算复杂，半小时左右能完成。关键步骤集中在解压、改配置、选元数据库、启动验证这几个环节。

4.1 下载解压与环境变量

先把Kylin的二进制包下载到服务器。这里需要说明的是，不同大版本对应的包名不一样，3.x是一个tar.gz，解压后内含Tomcat和整套运行时。下载后放到规划好的目录，比如/usr/local/apps下，然后解压。

tar -zxvf apache-kylin-3.1.3-bin.tar.gz -C /usr/local/apps cd /usr/local/apps/apache-kylin-3.1.3-bin

然后配置环境变量。把Kylin的bin目录加到PATH里，写进/etc/profile或者当前用户的~/.bashrc。

export KYLIN_HOME=/usr/local/apps/apache-kylin-3.1.3-bin export PATH=$KYLIN_HOME/bin:$PATH

需要注意，Kylin运行时要通过KYLIN_HOME找conf目录、日志目录和Tomcat。如果你机器上有多个大数据组件，千万写清楚绝对路径，不要在PATH里搞玄学。写完顺手source一下确认变量生效。

4.2 kylin.properties里真正必须改的几项

Kylin的配置文件是conf/kylin.properties，里面配置项非常多，但初学者只需要关心几类，其他保持默认即可。

第一类是环境相关。比较重要的是指定Hadoop和Hive的配置文件目录。默认会从classpath里找，但生产上最好写明确：

kylin.env.hadoop-conf-dir=/etc/hadoop/conf kylin.env.hive-conf-dir=/etc/hive/conf

第二类是元数据库。默认Kylin用内置Derby，上一节说过，开发学习可以直接用，但生产环境建议换MySQL。这里先看一下初始配置是什么样，后面单独展开。

第三类是存储和构建相关。如果使用Kylin 3.x，需要确认ZooKeeper的基础路径和HBase的集群配置：

kylin.env.zookeeper-base-path=/kylin kylin.storage.hbase.cluster=default

第四类是缓存和并发参数。新手先不用动，等Cube构建多了再按资源调整。总的经验是：修改配置前先备份一份原始文件，我每次部署都会保留kylin.properties.bak，后面出了问题方便对照回滚。

4.3 元数据库：开发用Derby，生产用MySQL

Kylin元数据存的是Cube定义、模型定义、任务状态等信息，非常重要。默认的Derby是单机内嵌式的，好处是零配置，坏处是很容易产生锁文件，进程一中断，下次启动就可能被"锁"住。

开发学习阶段可以直接跑Derby，方便。但只要你开始部署到生产，我建议立刻切换到MySQL。

切换到MySQL的配置大致如下，在kylin.properties里替换关于metadata.url的配置：

kylin.metadata.url=kylin_metadata@jdbc,driverClassName=com.mysql.jdbc.Driver,url=jdbc:mysql://localhost:3306/kylin,username=kylin,password=kylin

然后在MySQL里先建好库和账号：

CREATE DATABASE kylin DEFAULT CHARACTER SET utf8; CREATE USER 'kylin'@'%' IDENTIFIED BY 'kylin'; GRANT ALL PRIVILEGES ON kylin.* TO 'kylin'@'%';

同时把MySQL驱动jar放到Kylin的库目录下。常见做法是创建$KYLIN_HOME/lib/ext目录，把mysql-connector-java的jar放进去。这一步漏掉的话，启动后会报找不到JDBC驱动，检查日志时注意看有没有ClassNotFound。

MySQL方案的好处是稳定、Lock问题少、方便备份恢复。代价只是多一个依赖，但对于生产系统来说完全值得。

4.4 启动、看日志、访问Web UI

配置改好之后，先跑一遍Kylin提供的环境检查脚本：

cd $KYLIN_HOME bin/check-env.sh

这个脚本会检查Java版本、Hadoop、Hive环境是否就绪。如果哪一项飘红，先解决它，不要强行启动。我见过有人跳过这一步直接start，结果启动失败后排查了半天，最后发现是HADOOP_CONF_DIR没配对。

环境检查通过后，启动服务：

bin/kylin.sh start

启动过程主要看日志，日志文件在logs/kylin.log。启动成功的标志一般包括Tomcat端口7070开始监听，以及日志里出现"Kylin has been started successfully"之类的字样。

然后打开浏览器访问：

http://服务器IP:7070/kylin

默认账号是ADMIN，密码是KYLIN。登录后能看到Kylin的Web控制台。到这里，安装部署就算完成了大半，剩下的工作是验证能不能真正跑一个Cube。

5. 部署后的第一道验证：构建Cube和跑通SQL

安装完成不代表能用，真正的验证是把示例Cube构建出来，然后跑一条SQL。这步走完，你才算把Kylin的链路完整打通。

5.1 用自带的sample数据集走一遍全流程

Kylin自带一个示例数据脚本，专门用来让新手体验完整流程。在命令行执行：

bin/sample.sh

这个脚本会把一个名为learn_kylin的Cube定义示例加载进系统，并在Hive里准备对应的模拟数据表。执行成功后，回到Web UI，在Model和Cube页面就能看到示例模型和示例Cube。

接下来在Cube页面找到这个Cube，点击Build按钮，会触发一次Cube构建任务。构建任务会提交给YARN执行，本质上是通过Spark或MapReduce去Hive里读数据、算预聚合、写存储。任务进度可以在Web UI的Jobs页面看到。

第一次构建的耗时取决于集群资源，小数据量通常几分钟内能完成。构建成功后会看到对应Segment的状态变成READY。

5.2 从构建日志判断Cube是否真的成功

很多人看到构建状态还是RUNNING就一直干等，其实更靠谱的判断方式是直接看日志。点进任务详情，看每个步骤Job Step的执行状态，重点关注数据源读取步骤和保存Cube步骤。

如果构建失败，最常见的症状是日志中出现与Hive连接、元数据读取、HBase写入相关的异常。这时候先别急着怀疑Kylin本身，按顺序排查：Hive表能不能直接查、HDFS空间够不够、HBase region是否正常、YARN队列资源还有没有余量。

Cube构建成功后，就可以用SQL验证了。在Web UI左侧的Insight页面，或者直接用命令行SQL查询接口，跑一条最简单的SQL：

SELECT part_dt, SUM(price) AS total FROM kylin_sales GROUP BY part_dt;

如果返回结果正常，说明CuCube已经生效，SQL能命中预计算结果。可以再手动把这条查询连续执行几遍，体感一下查询响应速度。构建完的这步验证是整个部署过程里最让人踏实的一刻，它说明你前面所有配置都串对了。

5.3 我在第一次部署时踩过的三个坑

每次分享技术我都会把踩坑记录放在最后，因为这些东西文档里不会主动写，但遇到了是真耽误时间。

第一个坑是check-env.sh报Hive配置找不到。原因是服务器上有多个Hive配置文件，环境变量取到了旧的那份。我当时的处理方法是把正确的配置文件目录写死到kylin.properties里，同时清理了冲突的环境变量。这个坑尤其容易出现在服务器上装过多次大数据组件、路径混乱的场景。

第二个坑是Derby锁。当时我用默认Derby跑Demo，随后手动杀了Kylin进程，再重启就报元数据锁异常。说白了就是Derby这种内嵌数据库不适合跨进程操作，数据库文件被别人占用。处理办法也很朴素：备份之后把元数据目录清理掉重新初始化，再后来就直接换MySQL了。如果你在生产环境看到类似"lock file"的报错，大概率也是元数据库没有选好。

第三个坑和HBase有关。构建任务一直卡在某个阶段，日志显示连不上RegionServer。排查下来是hbase-site.xml里的ZooKeeper地址和实际集群不一致。Kylin启动时不会主动校验这些底层配置，它以为自己能连上，实际却连不上。建议在启动之前，把HBase自带的客户端命令测一遍，确认能从Kylin所在机器正常访问HBase。

这些坑本质上都不是Kylin本身的问题，而是底层依赖链太长、配置文件互相引用导致的。这也是为什么我一再强调：先把环境检查做到位，出了问题不要慌，顺着日志一层层找，通常都能定位到某个配置文件上。

最后说一个我自己的小习惯。部署完成后，把本机的Java版本、依赖组件列表、配置文件关键项的修改，都记在一个文本里留档。Kylin的部署只是整个系列的第一步，后续还有Cube设计、构建调优、增量构建、权限控制这些内容。把这个基础打牢，后面就能少一点环境问题，多一点时间研究真正有价值的东西。