朋友公司的数据分析团队找我唠嗑说他们的报表查询最近越来越难扛。底层Hive表里已经攒了十几亿条明细业务方每天要按区域、商品、日期各种维度看汇总直接跑Spark任务一次要几分钟几个人同时点集群直接进入排队模式。我跟他们聊完就推荐先看Kylin。Kylin是Apache旗下的开源分布式分析引擎核心思路特别朴素在数据进查询系统之前先把各种维度的组合结果预计算好查询时只做最轻量的扫描把分钟级的SQL拉回秒级。这篇是Kylin快速入门系列的第一篇重点只聊两件事一是Kylin到底是什么、解决什么问题二是我自己在服务器上一路跑通的安装部署流程。无论你是做数仓的、做BI的还是刚接触OLAP的小白这篇都适合当第一份读物。1. 为什么需要KylinBI查询卡顿背后的计算困境先说一个常见的场景。业务部门要看昨日各门店的销售额底层数据在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上。举一个最简单的例子。用户发一条这样的SQLSELECT 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构建是定期做的通常是T1。如果你要求分钟级实时性数据进来几分钟就要出结果那Kylin也不是正解应该考虑实时OLAP方案或者做混合架构。你一定得先想清楚我到底能不能接受预计算带来的模型约束再决定要不要花这个部署成本。它是搭在离线数仓上的加速层不是万能数据库。3. 安装前的准备版本选型和依赖环境检查Kylin本身是Java写的它自己不存数据、不跑计算而是依赖下游的Hadoop、Hive、HBase或Spark集群。所以安装Kylin的第一件事不是看Kylin怎么装而是先确认你手里的大数据底座能撑起它。3.1 Kylin 3.x还是4.x两条技术路线的差异很多人在选版本这里坐下来开始纠结。我的建议是先知道你手里的集群环境是什么再反推用哪个大版本而不是先装了Kylin再想办法凑环境。Kylin 3.x是过去企业落地最广的版本它依赖HBaseCube数据存放在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的一个稳定组合我在测试环境里跑通过你可以作为参考组件推荐版本说明JDKOpenJDK 8Kylin对JDK版本敏感不要用过高版本Hadoop3.1.1需要HDFS、YARN基础服务正常Hive3.1.0提供元数据与Cube构建时的数据源访问HBase2.1.x3.x版本的Cube存储层需要和Hadoop版本匹配Spark2.4.x构建引擎的高效执行器ZooKeeper集成在HBase/Hadoop体系内提供分布式协调能力MySQL5.7或8.0生产环境作为Kylin元数据库替代默认的Derby这个组合不一定是你公司生产环境的组合。如果你用的是某商业大数据发行版组件的版本体系会不一样我的建议是遵循发行版兼容表来选然后看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是ZooKeeper16010是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.clusterdefault第四类是缓存和并发参数。新手先不用动等Cube构建多了再按资源调整。总的经验是修改配置前先备份一份原始文件我每次部署都会保留kylin.properties.bak后面出了问题方便对照回滚。4.3 元数据库开发用Derby生产用MySQLKylin元数据存的是Cube定义、模型定义、任务状态等信息非常重要。默认的Derby是单机内嵌式的好处是零配置坏处是很容易产生锁文件进程一中断下次启动就可能被锁住。开发学习阶段可以直接跑Derby方便。但只要你开始部署到生产我建议立刻切换到MySQL。切换到MySQL的配置大致如下在kylin.properties里替换关于metadata.url的配置kylin.metadata.urlkylin_metadatajdbc,driverClassNamecom.mysql.jdbc.Driver,urljdbc:mysql://localhost:3306/kylin,usernamekylin,passwordkylin然后在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查询接口跑一条最简单的SQLSELECT 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设计、构建调优、增量构建、权限控制这些内容。把这个基础打牢后面就能少一点环境问题多一点时间研究真正有价值的东西。