kylin调优，项目中错误总结，知识点总结，kylin jdbc driver + 数据库连接池druid + Mybatis项目中的整合，shell脚本执行kylin restapi 案例
關(guān)于本篇文章的說明：
本篇文章為筆者辛苦勞作用了一整天總結(jié)出來的文檔，大家閱讀轉(zhuǎn)發(fā)的時(shí)候請不要吝嗇寫上筆者：涂作權(quán) 和 原文地址。
由于筆者所在環(huán)境沒有人用過kylin，筆者也是自學(xué)官網(wǎng)，閱讀書籍 將kylin用于實(shí)際項(xiàng)目，期間遇到了很多很多關(guān)于kylin使用的問題。為了讓后面的人在使用kylin實(shí)踐的時(shí)候能夠少走彎路，在此生成kylin的調(diào)優(yōu)，錯(cuò)誤總結(jié)，知識點(diǎn)文檔，這篇文檔應(yīng)該是目前網(wǎng)上最全的kylin調(diào)優(yōu)和總結(jié)文檔了(除了官網(wǎng))。
以下文章內(nèi)容主要來自官網(wǎng)，書籍，博文，網(wǎng)友，社區(qū)，同學(xué)，以及實(shí)際項(xiàng)目。
1 調(diào)優(yōu)方案
1.1 調(diào)優(yōu)：如何提高訪問連接并發(fā)（運(yùn)維層面）
根據(jù)書籍中的介紹，kylin單個(gè)的實(shí)例，支持的訪問連接并發(fā)是70個(gè)左右，所以，為了讓kylin能夠支持更多的訪問并發(fā)，可以通過增加實(shí)例的方式實(shí)現(xiàn)。將單實(shí)例的Kylin變成集群方式，增加query節(jié)點(diǎn)的個(gè)數(shù)。
官網(wǎng)介紹的方式：
http://kylin.apache.org/docs/install/kylin_cluster.html
說明：
A:假設(shè)有3臺機(jī)器，分別是machine1,machine2,machine3。其中Machine的運(yùn)行模式是all(即擁有 執(zhí)行job+執(zhí)行query的角色 (個(gè)人理解))，另外的machine2和machine3為query（主要用于查詢）。
B:注意，kylin2.0以后，kylin支持了多個(gè)job的方式，具體方式可以參考文檔進(jìn)行相關(guān)配置。
1.2 調(diào)優(yōu)：解決kylin預(yù)處理過程gc問題（運(yùn)維層面）
Kylin是基于預(yù)處理技術(shù)，如果公司資金雄厚，服務(wù)器配置高，內(nèi)存大，那就不要吝嗇內(nèi)存了。給kylin足夠的內(nèi)存分配，能夠減少很多問題。
如果處理的好，可以結(jié)合任務(wù)調(diào)度系統(tǒng)，比如azkaban,通過shell的方式將kylin的內(nèi)存在數(shù)據(jù)處理空閑的時(shí)候，將內(nèi)存多分配給kylin。
關(guān)于此部分的介紹，官網(wǎng)給出的建議是：
http://kylin.apache.org/docs/install/configuration.html
筆者配置：
[xxx conf]# pwd /data/installed/apache-kylin-2.3.1-bin/conf [xxxx conf]# vim setenv.sh1.3 調(diào)優(yōu)+錯(cuò)誤總結(jié)：配置build引擎支持Spark （運(yùn)維層面）
在kylin中支持以Spark作為預(yù)處理的方式，在內(nèi)存足夠的情況下，建議配置build引擎。使用Spark，默認(rèn)的build引擎使用的是mapreduce.
由于筆者使用的hadoop版本是3.0.1(原生)，當(dāng)前最高版本是：v2.5.2，發(fā)現(xiàn)使用Kylin的時(shí)候，會報(bào)jar沖突問題，因?yàn)槲噎h(huán)境使用的是3.x的jar包，但是在kylin發(fā)行版本目前還使用的是基于hadoop2.x的Spark。所以失敗了。
但是，若使用的是CDH，可以使用，apache-kylin-2.5.2-bin-cdh60.tar.gz for beta版本進(jìn)行安裝試用。
支持Spark的配置：http://kylin.apache.org/docs/tutorial/cube_spark.html，關(guān)于具體步驟，本文不進(jìn)行詳細(xì)敘述。
1.4 調(diào)優(yōu):kylin出現(xiàn)reduce階段內(nèi)存異常問題（hadoop運(yùn)維層面）
在kylin執(zhí)行cube build的過程中，可能會出現(xiàn)內(nèi)存溢出的問題，這個(gè)問題其中一個(gè)原因是hadoop的虛擬參數(shù)配置不合理導(dǎo)致的。
這里在$HADOOP_HOME/etc/Hadoop/yarn-site.xml 中的配置類似如下：
yarn.nodemanager.vmem-pmem-ratio ：虛擬內(nèi)存大小的一個(gè)系數(shù)，通過調(diào)整這個(gè)參數(shù)，可以增大虛擬內(nèi)存的值，避免kylin在cube build的過程中出現(xiàn)失敗。
此外，也要調(diào)整：$HADOOP_HOME/etc/Hadoop/mapred-site.xml中如下的值：
<property><name>mapreduce.map.java.opts</name><!--<value>-Xms3g -Xmx6g</value>--><value>-Xms3g -Xmx10g</value> </property> <property><!-- mapreduce.reduce.java.opts 這個(gè)值一般是mapreduce.map.java.opts的兩倍 --><name>mapreduce.reduce.java.opts</name><!--<value>-Xms6g -Xmx12g</value>--><value>-Xms6g -Xmx16g</value> </property><!-- 每個(gè)Map任務(wù)的物理內(nèi)存限制，這個(gè)值 * yarn.nodemanager.vmem-pmem-ratio 就是虛擬內(nèi)存的大小--> <property><name>mapreduce.map.memory.mb</name><!--<value>6144</value>--><value>10240</value> </property> <property><name>mapreduce.reduce.input.buffer.percent</name><value>0.5</value> </property><!-- 每個(gè)Reduce任務(wù)的物理內(nèi)存限制，一般還是機(jī)器內(nèi)存的80% --> <property><name>mapreduce.reduce.memory.mb</name><!--<value>12288</value>--><value>16384</value> </property>其中官網(wǎng)的介紹是：
1.5 將cuboid數(shù)據(jù)轉(zhuǎn)為HFile
這一步啟動一個(gè)MR任務(wù)來講cuboid文件（序列文件格式）轉(zhuǎn)換為HBase的HFile格式。Kylin通過cube統(tǒng)計(jì)數(shù)據(jù)計(jì)算HBase的region數(shù)目，默認(rèn)情況下每5GB數(shù)據(jù)對應(yīng)一個(gè)region。Region越多，MR使用的reducer也會越多。如果你觀察到reducer數(shù)目較小且性能較差，你可以將“conf/kylin.properties”里的以下參數(shù)設(shè)小一點(diǎn)，比如：
kylin.hbase.region.cut=2 kylin.hbase.hfile.size.gb=1如果你不確定一個(gè)region應(yīng)該是多大時(shí)，聯(lián)系你的HBase管理員。
1.6 調(diào)優(yōu)：解決kylin cube過程中的hive小文件問題(運(yùn)維層面)
Kylin中自帶文件合并，下面的過程可以考慮設(shè)置（這個(gè)筆者沒有驗(yàn)證過，有的博文中建議下面方式進(jìn)行設(shè)置，但是官網(wǎng)是另外一種說法）
官網(wǎng)：
一些博文上的寫法：
該文件原本的配置如下：
<property><name>hive.merge.mapfiles</name><value>false</value><description>Disable Hive's auto merge</description> </property><property><name>hive.merge.mapredfiles</name><value>false</value><description>Disable Hive's auto merge</description> </property>修改成：
<property><name>hive.merge.mapfiles</name><value>true</value><description>Enable Hive's auto merge</description> </property><property><name>hive.merge.mapredfiles</name><value>true</value><description>Enable Hive's auto merge</description> </property>1.7 調(diào)優(yōu)：hive建表過程（數(shù)倉層面）
kylin使用的是一種預(yù)處理方式，這種方式有別于hive、spark-sql、presto、hbase、impala、druid等的即時(shí)查詢方案，kylin能夠在機(jī)器內(nèi)存配置較少的情況下完成多維查詢，對于有多維分析需求(OLAP)的項(xiàng)目，是一個(gè)很不錯(cuò)的選擇。
但是，不要覺得kylin在調(diào)優(yōu)過程中只要保證了kylin的model和cube創(chuàng)建的好就能夠提升kylin的大大效率。對于kylin的數(shù)據(jù)來源hive中的hive表創(chuàng)建不好，會導(dǎo)致kylin cube build過程很漫長，這個(gè)筆者深有體會，優(yōu)化的好的能夠?qū)uild過程由1天多減少到分鐘級別。
使用kylin進(jìn)行多維查詢，能夠讓不熟悉HBASE二級索引，預(yù)分區(qū)，HBASE調(diào)優(yōu)，協(xié)處理等的開發(fā)人員減少很多時(shí)間。
在此，筆者建議kylin的hive數(shù)據(jù)表在創(chuàng)建的時(shí)候增加分區(qū)(partitioned)，筆者的與分區(qū)格式類似如下：
drop table if exists tb_table; CREATE TABLE IF NOT EXISTS tb_table ( Xxxxxxx 此處建表語句略去, addTime bigint comment '數(shù)據(jù)生成的時(shí)間，時(shí)間戳，秒值', createDate bigint comment '創(chuàng)建天，時(shí)間格式為yyyyMMdd的integer值，由addTime通過from_unixtime(actionTime,'yyyyMMdd') as createDate 得出' ) partitioned by(pt_createDate integer comment '創(chuàng)建天，時(shí)間格式為yyyyMMdd的integer值，分區(qū)時(shí)間') ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t' LINES TERMINATED BY '\n' STORED AS TEXTFILE;其中pt_createDate 是數(shù)據(jù)入庫時(shí)間。這個(gè)值很重要，在建立Model的時(shí)候，一定要使用這個(gè)時(shí)間作為partition,而不要使用數(shù)據(jù)生成時(shí)間createDate,否則可能會出現(xiàn)hive中的數(shù)據(jù)在kylin增量預(yù)處理之后，kylin的數(shù)據(jù)條數(shù)小于hive的數(shù)據(jù)條數(shù)，導(dǎo)致分析結(jié)果偏少的問題。
1.8 調(diào)優(yōu)：hive表數(shù)據(jù)類型導(dǎo)致kylin統(tǒng)計(jì)如sum出錯(cuò)的問題（數(shù)倉層面）
在hive進(jìn)行sum的時(shí)候，有時(shí)候發(fā)現(xiàn)不管怎么設(shè)置，數(shù)據(jù)值總是1或者一些莫名其妙的值，導(dǎo)致這個(gè)現(xiàn)象的其中一個(gè)原因就是使用了hive中一個(gè)數(shù)據(jù)類型定義為tinyint的列作為度量列。所以，在使用hive建表的時(shí)候，可以將這種字段設(shè)置成integer，然后再進(jìn)行處理，發(fā)現(xiàn)結(jié)果正確了。
類似：
1.9 調(diào)優(yōu)：group by 字段值，計(jì)算每個(gè)分組sum的查詢速度調(diào)優(yōu)（數(shù)倉層面）
kylin有一個(gè)坑，可能是設(shè)計(jì)問題，就是kylin對sum(case when 字段列 then 1 else 0 end) totalNum的支持很爛，它不支持。
為了處理這種場景，建議對所有以上場景或者類似group by然后計(jì)算sum結(jié)果的場景，都在數(shù)據(jù)處理結(jié)果，將這種結(jié)果1 or 0的狀態(tài)計(jì)算好，存儲在hive表中。類似筆者的一個(gè)Spark sql程序片段：
spark.sql("INSERT INTO TABLE tb_table partition(pt_createDate=" + pt_createDate + ") " +"SELECT " +" (case when st.registWay=10 then 1 else 0 end) as selfRegiste," +" (case when st.registWay=20 then 1 else 0 end) as agentRegiste," +" (case when st.registWay=30 then 1 else 0 end) as youxShopRegiste," +" (case when st.registWay=40 then 1 else 0 end) as salesmanRegiste," +" (case when st.registWay=50 then 1 else 0 end) as headShopRegiste," +" from_unixtime(registTime,'yyyyMMdd') as createDate " +"FROM " +" tb_table_temp "); spark.stop();也就是說將registWay 的分組求總和統(tǒng)計(jì)變成 selfRegiste 、agentRegiste 、youxShopRegiste、salesmanRegiste、headShopRegiste 的sum求和。通過這種方式之后，發(fā)現(xiàn)項(xiàng)目查詢速度有很大的提升，可能有原來的n秒級，變成毫秒級別。
1.10 調(diào)優(yōu)：使用和hive相同的partition column
在創(chuàng)建model的時(shí)候，指定類似如下的分區(qū)列：
使用增量build cube的方式。
1.11 調(diào)優(yōu)：定期清理Kylin cube build過程中產(chǎn)生的中間文件
在kylin 在cube build過程中會產(chǎn)生很多臨時(shí)文件，現(xiàn)象是：在hdfs中的/hbase/data/default，會產(chǎn)生很多時(shí)間為過往時(shí)間的文件，
可以使用一下命令查看磁盤占用大小：
其中：13.1 G 表示的是一個(gè)節(jié)點(diǎn)中暫用磁盤的大小，35.9 G
如果這個(gè)臨時(shí)中間文件不處理，最終將導(dǎo)致http://namenodeip:hdfs對應(yīng)的port/dfshealth.html#tab-datanode：
官網(wǎng)介紹：
Kylin 在構(gòu)建 cube 期間會在 HDFS 上生成中間文件；除此之外，當(dāng)清理/刪除/合并 cube 時(shí)，一些 HBase 表可能被遺留在 HBase 卻以后再也不會被查詢；雖然 Kylin 已經(jīng)開始做自動化的垃圾回收，但不一定能覆蓋到所有的情況；你可以定期做離線的存儲清理：
步驟：
1. 檢查哪些資源可以清理，這一步不會刪除任何東西：
請將這里的 (version) 替換為你安裝的 Kylin jar 版本。
2. 你可以抽查一兩個(gè)資源來檢查它們是否已經(jīng)沒有被引用了；然后加上“–delete true”選項(xiàng)進(jìn)行清理。
完成后，Hive 里的中間表, HDFS 上的中間文件及 HBase 中的 HTables 都會被移除。
3. 如果您想要刪除所有資源；可添加 “–force true” 選項(xiàng)：
完成后，Hive 中所有的中間表, HDFS 上所有的中間文件及 HBase 中的 HTables 都會被移除。
1.12 調(diào)優(yōu)：減少Cube Dimensions維度數(shù)
做多維數(shù)據(jù)分析的時(shí)候，一般都要涉及到SQL，在這個(gè)過程中適當(dāng)控制一些SQL，使用盡可能少的字段列以實(shí)現(xiàn)相同的數(shù)據(jù)查詢需求。
因?yàn)榫S度列越多，cuboid的數(shù)量越多，需要的內(nèi)存越多，cube build的時(shí)候時(shí)間也越長，生成的數(shù)據(jù)也越大。對于有n個(gè)維度的cube,組合字后會產(chǎn)生22…*（第n個(gè)2）體量的數(shù)據(jù)。
也就是說減少如下的Dimensions數(shù)量：
1.13 調(diào)優(yōu)：定義measure列
對于定義measure，結(jié)果將在cube build前就預(yù)處理好，作為度量列的字段不要在Cube的Dimensions中出現(xiàn)，以減少Cuboid的數(shù)量 。這里包括兩處：
A:Model創(chuàng)建過程中指定好Measures列，例如：
B:增加Cube Measures列的值
1.14 調(diào)優(yōu)+錯(cuò)誤總結(jié)：解決sum的時(shí)候結(jié)果莫名其妙的問題
出現(xiàn)這個(gè)現(xiàn)象的原因是在該定義measure的列上沒有定義相關(guān)的度量值。具體添加方式如上面的：定義measure列
1.15 調(diào)優(yōu)：定期merge cube
在kylin的model下的cube后見面的：
另外：設(shè)置好合適的Merge周期
1.16 調(diào)優(yōu)：對于維度多于12個(gè)場景
在Advanced Setting中對維度進(jìn)行Aggregation Groups分組。
也就是說在下面的維度列進(jìn)行分組設(shè)置。
每組只填寫好真正需要的維度列。添加新的分組的時(shí)候，可以使用：
在設(shè)置的時(shí)候一定要記著2的n次方這個(gè)問題。盡可能減少n(維度數(shù)量)這個(gè)值。
1.17 調(diào)優(yōu)：創(chuàng)建中間平表（來自官網(wǎng)）
這一步將數(shù)據(jù)從源Hive表提取出來(和所有join的表一起)并插入到一個(gè)中間平表。如果Cube是分區(qū)的，Kylin會加上一個(gè)時(shí)間條件以確保只有在時(shí)間范圍內(nèi)的數(shù)據(jù)才會被提取。你可以在這個(gè)步驟的log查看相關(guān)的Hive命令，比如：
hive -e "USE default; DROP TABLE IF EXISTS kylin_intermediate_airline_cube_v3610f668a3cdb437e8373c034430f6c34;CREATE EXTERNAL TABLE IF NOT EXISTS kylin_intermediate_airline_cube_v3610f668a3cdb437e8373c034430f6c34 (AIRLINE_FLIGHTDATE date,AIRLINE_YEAR int,AIRLINE_QUARTER int,...,AIRLINE_ARRDELAYMINUTES int) STORED AS SEQUENCEFILE LOCATION 'hdfs:///kylin/kylin200instance/kylin-0a8d71e8-df77-495f-b501-03c06f785b6c/kylin_intermediate_airline_cube_v3610f668a3cdb437e8373c034430f6c34';SET dfs.replication=2; SET hive.exec.compress.output=true; SET hive.auto.convert.join.noconditionaltask=true; SET hive.auto.convert.join.noconditionaltask.size=100000000; SET mapreduce.job.split.metainfo.maxsize=-1;INSERT OVERWRITE TABLE kylin_intermediate_airline_cube_v3610f668a3cdb437e8373c034430f6c34 SELECT AIRLINE.FLIGHTDATE ,AIRLINE.YEAR ,AIRLINE.QUARTER ,... ,AIRLINE.ARRDELAYMINUTES FROM AIRLINE.AIRLINE as AIRLINE WHERE (AIRLINE.FLIGHTDATE >= '1987-10-01' AND AIRLINE.FLIGHTDATE < '2017-01-01');在Hive命令運(yùn)行時(shí)，Kylin會用conf/kylin_hive_conf.properties里的配置，比如保留更少的冗余備份和啟用Hive的mapper side join。需要的話可以根據(jù)集群的具體情況增加其他配置。
如果cube的分區(qū)列(在這個(gè)案例中是”FIGHTDATE”)與Hive表的分區(qū)列相同，那么根據(jù)它過濾數(shù)據(jù)能讓Hive聰明地跳過不匹配的分區(qū)。因此強(qiáng)烈建議用Hive的分區(qū)列（如果它是日期列）作為cube的分區(qū)列。這對于那些數(shù)據(jù)量很大的表來說幾乎是必須的，否則Hive不得不每次在這步掃描全部文件，消耗非常長的時(shí)間。
1.18 調(diào)優(yōu)：重新分發(fā)中間表（來自官網(wǎng)）
在之前的一步之后，Hive在HDFS上的目錄里生成了數(shù)據(jù)文件：有些是大文件，有些是小文件甚至空文件。這種不平衡的文件分布會導(dǎo)致之后的MR任務(wù)出現(xiàn)數(shù)據(jù)傾斜的問題：有些mapper完成得很快，但其他的就很慢。針對這個(gè)問題，Kylin增加了這一個(gè)步驟來“重新分發(fā)”數(shù)據(jù)，這是示例輸出:
total input rows = 159869711 expected input rows per mapper = 1000000 num reducers for RedistributeFlatHiveTableStep = 160重新分發(fā)表的命令：
hive -e "USE default; SET dfs.replication=2; SET hive.exec.compress.output=true; SET hive.auto.convert.join.noconditionaltask=true; SET hive.auto.convert.join.noconditionaltask.size=100000000; SET mapreduce.job.split.metainfo.maxsize=-1; set mapreduce.job.reduces=160; set hive.merge.mapredfiles=false;INSERT OVERWRITE TABLE kylin_intermediate_airline_cube_v3610f668a3cdb437e8373c034430f6c34 SELECT * FROM kylin_intermediate_airline_cube_v3610f668a3cdb437e8373c034430f6c34 DISTRIBUTE BY RAND(); "首先，Kylin計(jì)算出中間表的行數(shù)，然后基于行數(shù)的大小算出重新分發(fā)數(shù)據(jù)需要的文件數(shù)。默認(rèn)情況下,Kylin為每一百萬行分配一個(gè)文件。在這個(gè)例子中，有1.6億行和160個(gè)reducer，每個(gè)reducer會寫一個(gè)文件。在接下來對這張表進(jìn)行的MR步驟里，Hadoop會啟動和文件相同數(shù)量的mapper來處理數(shù)據(jù)(通常一百萬行數(shù)據(jù)比一個(gè)HDFS數(shù)據(jù)塊要小)。如果你的日常數(shù)據(jù)量沒有這么大或者Hadoop集群有足夠的資源，你或許想要更多的并發(fā)數(shù)，這時(shí)可以將conf/kylin.properties里的kylin.job.mapreduce.mapper.input.rows設(shè)為小一點(diǎn)的數(shù)值，比如:
kylin.job.mapreduce.mapper.input.rows=500000其次，Kylin會運(yùn)行 “INSERT OVERWRITE TABLE … DISTRIBUTE BY “ 形式的HiveQL來分發(fā)數(shù)據(jù)到指定數(shù)量的reducer上。
在很多情況下，Kylin請求Hive隨機(jī)分發(fā)數(shù)據(jù)到reducer，然后得到大小相近的文件，分發(fā)的語句是”DISTRIBUTE BY RAND()”。
如果你的cube指定了一個(gè)高基數(shù)的列，比如”USER_ID”，作為”分片”維度(在cube的“高級設(shè)置”頁面)，Kylin會讓Hive根據(jù)該列的值重新分發(fā)數(shù)據(jù)，那么在該列有著相同值的行將被分發(fā)到同一個(gè)文件。這比隨機(jī)要分發(fā)要好得多，因?yàn)椴粌H重新分布了數(shù)據(jù)，并且在沒有額外代價(jià)的情況下對數(shù)據(jù)進(jìn)行了預(yù)先分類，如此一來接下來的cube build處理會從中受益。在典型的場景下，這樣優(yōu)化可以減少40%的build時(shí)長。在這個(gè)案例中分發(fā)的語句是”DISTRIBUTE BY USER_ID”：
請注意: 1)“分片”列應(yīng)該是高基數(shù)的維度列，并且它會出現(xiàn)在很多的cuboid中（不只是出現(xiàn)在少數(shù)的cuboid）。 使用它來合理進(jìn)行分發(fā)可以在每個(gè)時(shí)間范圍內(nèi)的數(shù)據(jù)均勻分布，否則會造成數(shù)據(jù)傾斜，從而降低build效率。典型的正面例子是：“USER_ID”、“SELLER_ID”、“PRODUCT”、“CELL_NUMBER”等等，這些列的基數(shù)應(yīng)該大于一千(遠(yuǎn)大于reducer的數(shù)量)。 2)”分片”對cube的存儲同樣有好處，不過這超出了本文的范圍。
1.19 調(diào)優(yōu)：提取事實(shí)表的唯一列（來自官網(wǎng)）
在這一步驟Kylin運(yùn)行MR任務(wù)來提取使用字典編碼的維度列的唯一值。
實(shí)際上這步另外還做了一些事情：通過HyperLogLog計(jì)數(shù)器收集cube的統(tǒng)計(jì)數(shù)據(jù)，用于估算每個(gè)cuboid的行數(shù)。如果你發(fā)現(xiàn)mapper運(yùn)行得很慢，這通常表明cube的設(shè)計(jì)太過復(fù)雜，請參考
優(yōu)化cube設(shè)計(jì)來簡化cube。如果reducer出現(xiàn)了內(nèi)存溢出錯(cuò)誤，這表明cuboid組合真的太多了或者是YARN的內(nèi)存分配滿足不了需要。如果這一步從任何意義上講不能在合理的時(shí)間內(nèi)完成，你可以放棄任務(wù)并考慮重新設(shè)計(jì)cube，因?yàn)槔^續(xù)下去會花費(fèi)更長的時(shí)間。
你可以通過降低取樣的比例（kylin.job.cubing.inmen.sampling.percent）來加速這個(gè)步驟，但是幫助可能不大而且影響了cube統(tǒng)計(jì)數(shù)據(jù)的準(zhǔn)確性，所有我們并不推薦。
1.20 調(diào)優(yōu)：構(gòu)建維度字典（來自官網(wǎng)）
有了前一步提取的維度列唯一值，Kylin會在內(nèi)存里構(gòu)建字典。通常這一步比較快，但如果唯一值集合很大，Kylin可能會報(bào)出類似“字典不支持過高基數(shù)”。對于UHC類型的列，請使用其他編碼方式，比如“fixed_length”、“integer”等等。
1.21 調(diào)優(yōu)：構(gòu)建基礎(chǔ)cuboid,調(diào)整map大小 和reduce的數(shù)量
這一步用Hive的中間表構(gòu)建基礎(chǔ)的cuboid，是“逐層”構(gòu)建cube算法的第一輪MR計(jì)算。Mapper的數(shù)目與第二步的reducer數(shù)目相等；Reducer的數(shù)目是根據(jù)cube統(tǒng)計(jì)數(shù)據(jù)估算的：默認(rèn)情況下每500MB輸出使用一個(gè)reducer；如果觀察到reducer的數(shù)量較少，你可以將kylin.properties里的“kylin.job.mapreduce.default.reduce.input.mb”設(shè)為小一點(diǎn)的數(shù)值以獲得過多的資源，比如:
kylin.job.mapreduce.default.reduce.input.mb=2001.22 調(diào)優(yōu)：設(shè)置好Mandatory Dimensions 列
這種維度意味著每次查詢的group by中都會攜帶的，將某一個(gè)dimension設(shè)置為mandatory可以將cuboid的個(gè)數(shù)減少一半
因?yàn)槲覀兇_定每一次group by都會攜帶字段A，將A設(shè)置成Mandatory Dimensions后，那么就可以省去所有不包含A這個(gè)維度的cuboid了
好的技術(shù)文章：
http://kyligence.io/zh/2017/04/21/apache-kylin-advanced-setting-mandatory-dimension-principle/
1.23 調(diào)優(yōu)：設(shè)置Joint Dimensions
很好的一篇博文：
http://kyligence.io/zh/2017/04/07/apache-kylin-advanced-setting-joint-dimension-principle/
1.24 調(diào)優(yōu)：設(shè)置Hierarchy Dimension
以下文章很好的介紹了如何關(guān)于Hierarchy Dimension的調(diào)優(yōu)策略http://kyligence.io/zh/2017/04/14/apache-kylin-advanced-setting-hierarchy-dimension-principle/
1.25 調(diào)優(yōu)：Configuration Overwrites 高級設(shè)置
參考官網(wǎng)更詳細(xì)介紹：
http://kylin.apache.org/cn/docs/install/advance_settings.html
另外在里面最好設(shè)置數(shù)據(jù)壓縮方式，以減少磁盤占用
1.26 調(diào)優(yōu)：改變kylin中Advanced Setting的維度順序
對于kylin中頻繁使用，或著一定使用的維度列，在設(shè)置Includes的時(shí)候，將這些配置的靠前一些。因?yàn)閗ylin內(nèi)部機(jī)制是越靠前的越優(yōu)先被找到，從而加快查詢速度。
就是上面紅色區(qū)域的維度列的順序。
1.27 調(diào)優(yōu)：Build Cube With Spark
kylin.engine.spark.rdd-partition-cut-mb = 10 (默認(rèn) 200)
直接影響 spark 的分區(qū)數(shù)，首先大概清楚 cuboid 數(shù)據(jù)總大小，例如 6032mb,那么 partitions = 6032/10 = 600，即會產(chǎn)生 600 個(gè)小文件，隨后在 step8 跑 mr 時(shí)，就會拉起 600 個(gè) map,使得 服務(wù)器負(fù)載驟增，發(fā)生報(bào)警。
調(diào)整參數(shù)后執(zhí)行，如何跟蹤服務(wù)器情況？只需跟蹤 step8 的 mr 情況即可
① http://bgnode1:8088/cluster/scheduler 找到對應(yīng)的 application
② %of Cluster 是否過高
③ 進(jìn)入詳情查看 map 數(shù)量是否過多，若過多則很可能是 rdd-partition-cut-mb 設(shè)置過 小導(dǎo)致，此時(shí)要調(diào)大參數(shù) 因此，合理的調(diào)整 rdd-partition-cut-mb 能防止機(jī)器報(bào)警。 這一步是對每一層的 cuboid 依次進(jìn)行計(jì)算并寫入 hdfs，耗時(shí)會比較長
這兩個(gè)參數(shù)自行根據(jù)數(shù)據(jù)大小來調(diào)整，cores 和 memory 都不是越大越好，需根據(jù)要 build 的數(shù)據(jù)量，再三調(diào)整測試最優(yōu)值。
1.28 調(diào)優(yōu)：Rowkey調(diào)優(yōu)
為什么要優(yōu)化 Rowkey? Apache Kylin 使用 HBase 做為 Cube 的存儲引擎。而 HBase 是 Key-Value 數(shù)據(jù)庫，這個(gè) Key 在 HBase 中稱為 Rowkey。為了能夠支持按多個(gè)維度進(jìn)行查詢，Kylin 需要將多個(gè)維度值以某 種次序組成 Rowkey。HBase Scan Range，排在 Rowkey 靠前部分的維度，將比排在靠后部分 的維度更易于做篩選，查詢效率更高。
那些維度適合排在前部分?
1.29 調(diào)優(yōu)：在查詢中被用做過濾條件的維度放在非過濾條件維度的前面
這一個(gè)環(huán)節(jié)如果 rowkey 沒設(shè)計(jì)好，會導(dǎo)致以下問題：
1.30 調(diào)優(yōu)：羅列幾個(gè)顯著影響性能的參數(shù)
以下都是默認(rèn)值：
kylin.engine.spark.rdd-partition-cut-mb = 10
kylin.engine.spark-conf.spark.executor.memory = 4G
kylin.storage.hbase.region-cut-gb = 5
官網(wǎng)提供的可設(shè)置參數(shù)：http://kylin.apache.org/docs/install/configuration.html
1.31 調(diào)優(yōu)：其它調(diào)優(yōu)思路
通過./kylin.sh org.apache.kylin.engine.mr.common.CubeStatsReader [cubeName] 查看 cuboid 總大小，然后再根據(jù)以下步驟進(jìn)行對參數(shù)的調(diào)整：
1. 3 種降維選項(xiàng)是否有根據(jù)業(yè)務(wù)實(shí)際情況調(diào)整 2. 有沒合理的使用分區(qū)列 3. 小文件是否過多 4. reducer 是否過少 5. spark partitions 是否合適 6. spark 的 excutor 內(nèi)存和 cores 數(shù)量分配是否合理 7. cuboid 文件轉(zhuǎn) hfile 時(shí)，map 是否過多，reducer 是否過少（region 塊的大小和數(shù)量是否合 理）1.32 調(diào)優(yōu)：輸出壓縮（來自官網(wǎng)）
使用 Snappy 壓縮 HBase Cube：
另一個(gè)選項(xiàng)為 Gzip：
壓縮輸出的結(jié)果為：
Snappy 和 Ggzip 的區(qū)別在時(shí)間上少于 1% 但是在大小上有 18% 差別
1.33 調(diào)優(yōu)：壓縮Hive表（來自官網(wǎng)）
時(shí)間分布如下：
按概念分組的詳細(xì)信息 ：
67 % 用來 build / process flat 表且遵守 30% 用來 build cube
大量時(shí)間用在了第一步。
這種時(shí)間分布在有很少的 measures 和很少的 dim (或者是非常優(yōu)化的) 的 cube 中是很典型的
嘗試在 Hive 輸入表中使用 ORC 格式和壓縮(Snappy)：
前三步 (Flat Table) 的時(shí)間已經(jīng)提升了一半。
其他列式格式可以被測試：
? ORC
? 使用 Snappy 的 ORC 壓縮
但結(jié)果比使用 Sequence 文件的效果差。
請看：Shaofengshi in MailList 關(guān)于這個(gè)的評論
第二步是重新分配 Flat Hive 表：
是一個(gè)簡單的 row count，可以做出兩個(gè)近似值
- 如果其不需要精確，fact 表的 row 可以被統(tǒng)計(jì)→ 這可以與步驟 1 并行執(zhí)行 (且 99% 的時(shí)間將是精確的)
? 將來的版本中 (KYLIN-2165 v2.0)，這一步將使用 Hive 表數(shù)據(jù)實(shí)現(xiàn)。
1.34 調(diào)優(yōu)：Hive 表 (失敗) 分區(qū)（來自官網(wǎng)）
Rows 的分布為：
| Fact Table | 3.900.00 |
| Dim | 2.100 |
build flat 表的查詢語句 (簡單版本)：
SELECT ,DIM_DATE.X ,DIM_DATE.y ,FACT_POSICIONES.BALANCE FROM FACT_POSICIONES INNER JOIN DIM_DATE ON ID_FECHA = .ID_FECHA WHERE (ID_DATE >= '2016-12-08' AND ID_DATE < '2016-12-23')這里存在的問題是，Hive 只使用 1 個(gè) Map 創(chuàng)建 Flat 表。重要的是我們要改變這種行為。解決方案是在同一列將 DIM 和 FACT 分區(qū)
? 選項(xiàng) 1：在 Hive 表中使用 id_date 作為分區(qū)列。這有一個(gè)大問題：Hive metastore 意味著幾百個(gè)分區(qū)而不是幾千個(gè) (在 Hive 9452 中有一個(gè)解決該問題的方法但現(xiàn)在還未完成)
? 選項(xiàng) 2：生成一個(gè)新列如 Monthslot。
為 dim 和 fact 表添加同一個(gè)列
現(xiàn)在，用這個(gè)新的條件 join 表來更新數(shù)據(jù)模型
生成 flat 表的新查詢類似于：
用這個(gè)數(shù)據(jù)模型 rebuild 新 cube
結(jié)果，性能更糟了 😦。嘗試了幾種方法后，還是沒找到解決方案
問題是分區(qū)沒有被用來生成幾個(gè) Mappers
(我和 ShaoFeng Shi 檢查了這個(gè)問題。他認(rèn)為問題是這里只有很少的 rows 而且我們不是使用的真實(shí)的 Hadoop 集群。請看這個(gè) tech note)。
結(jié)果摘要
調(diào)整進(jìn)度如下：
- Hive 輸入表壓縮了
- HBase 輸出壓縮了
- 應(yīng)用了 cardinality (Joint，Derived，Hierarchy 和 Mandatory) 減少的技術(shù)
- 為每一個(gè) Dim 個(gè)性化 Dim 編碼器并選擇了 Dim 在 Row Key 中最好的順序
現(xiàn)在，這里有三種類型的 cubes： - 在 dimensions 中使用低 cardinality 的 Cubes（如 cube 4，大多數(shù)時(shí)間用在 flat 表這一步）
- 在 dimensions 中使用高 cardinality 的 Cubes（如 cube 6，大多數(shù)時(shí)間用于 Build cube，flat 表這一步少于 10%）
- 第三種類型，超高 cardinality (UHC) 其超出了本文的范圍
1.35 調(diào)優(yōu)：用高 cardinality Dimensions 的 Cube
在這個(gè)用例中 72% 的時(shí)間用來 build Cube
這一步是 MapReduce 任務(wù)，您可以在 > 看 YARN 中關(guān)于這一步的日志
Map – Reduce 的性能怎樣能提升呢? 簡單的方式是增加 Mappers 和 Reduces (等于增加了并行數(shù)) 的數(shù)量。
注意： YARN / MapReduce 有很多參數(shù)配置和適應(yīng)您的系統(tǒng)。這里的重點(diǎn)只在于小部分。
(在我的系統(tǒng)中我可以分配 12 – 14 GB 和 8 cores 給 YARN 資源)：
? yarn.nodemanager.resource.memory-mb = 15 GB
? yarn.scheduler.maximum-allocation-mb = 8 GB
? yarn.nodemanager.resource.cpu-vcores = 8 cores
有了這些配置我們并行列表的最大理論級別為 8。然而這里有一個(gè)問題：“3600 秒后超時(shí)了”
參數(shù) mapreduce.task.timeout (默認(rèn)為 1 小時(shí)) 定義了 Application Master (AM) 在沒有 ACK of Yarn Container 的情況下發(fā)生的最大時(shí)間。一旦這次通過了，AM 殺死 container 并重新嘗試 4 次 (都是同一個(gè)結(jié)果)
問題在哪? 問題是 4 個(gè) mappers 啟動了，但每一個(gè) mapper 需要超過 4 GB 完成
? 解決方案 1：增加 RAM 給 YARN
? 解決方案 2：增加在 Mapper 步驟中使用的 vCores 數(shù)量來減少 RAM 使用
? 解決方案 3：您可以通過 node 為 YARN 使用最大的 RAM（yarn.nodemanager.resource.memory-mb) 并為每一個(gè) container 使用最小的 RAM 進(jìn)行實(shí)驗(yàn)（yarn.scheduler.minimum-allocation-mb）。如果您為每一個(gè) container 增加了最小的 RAM，YARN 將會減少 Mappers 的數(shù)量。
在最后兩個(gè)用例中結(jié)果是相同的：減少并行化的級別 ==>
- 現(xiàn)在我們只啟動 3 個(gè) mappers 且同時(shí)啟動，第四個(gè)必須等待空閑時(shí)間
- 3 個(gè) mappers 將 ram 分散在它們之間，結(jié)果它們就會有足夠的 ram 完成 task
一個(gè)正常的 “Build Cube” 步驟中您將會在 YARN 日志中看到相似的消息：
如果您沒有周期性的看見這個(gè)，也許您在內(nèi)存中遇到了瓶頸。
1.36 調(diào)優(yōu)：提升 cube 響應(yīng)時(shí)間
我們嘗試使用不同 aggregations groups 來提升一些非常重要 Dim 或有高 cardinality 的 Dim 的查詢性能。
在我們的用例中定義 3 個(gè) Aggregations Groups：
比較未使用 / 使用 AGGs：
使用多于 3% 的時(shí)間 build cube 以及 0.6% 的 space，使用 currency 或 Carteras_Desc 的查詢會快很多。
1.37 調(diào)優(yōu)：將多表的查詢業(yè)務(wù)處理成寬表查詢
在kylin中，將多表的統(tǒng)計(jì)分析轉(zhuǎn)變成寬表的統(tǒng)計(jì)分析，經(jīng)過驗(yàn)證，發(fā)現(xiàn)效率有相當(dāng)大的提升。也就是說，將之前分布在多個(gè)表中的數(shù)據(jù)，最終經(jīng)過拉平，從不同的表中取出所需的數(shù)據(jù)，轉(zhuǎn)換成寬表。2 Kylin錯(cuò)誤總結(jié)，知識點(diǎn)
2.1 錯(cuò)誤總結(jié)：變更kylin.metadata.url的值之后問題（運(yùn)維層面）
在kylin安裝過程中，如果變更了kylin.metadata.url，比如：
kylin.metadata.url=bigdata那么在$KYLIN_HOME/bin/kylin.sh start的時(shí)候會報(bào)錯(cuò)。解決辦法是：
cd $KYLIN_HOME mkdir bigdata然后再啟動kylin,發(fā)現(xiàn)已經(jīng)可以啟動成功了。
2.2 知識點(diǎn)：Kylin通過JDBC Driver連接
Jar的maven依賴：
<kylin-jdbc.version>2.3.1</kylin-jdbc.version><!-- 查詢kylin jdbc driver --> <dependency><groupId>org.apache.kylin</groupId><artifactId>kylin-jdbc</artifactId><version>${kylin-jdbc.version}</version> </dependency>Spring Cloud項(xiàng)目中的數(shù)據(jù)庫連接池配置
spring.datasource.name=data-center #使用druid數(shù)據(jù)源 spring.datasource.type=com.alibaba.druid.pool.DruidDataSource #數(shù)據(jù)源連接url spring.datasource.url=jdbc:kylin://xxx.xxx.xxx.xxx:7070/kylinProject spring.datasource.username=ADMIN spring.datasource.password=KYLIN spring.datasource.driver-class-name=org.apache.kylin.jdbc.Driver spring.datasource.filters=stat spring.datasource.maxActive=60 spring.datasource.initialSize=10 spring.datasource.maxWait=60000 spring.datasource.minIdle=10 spring.datasource.timeBetweenEvictionRunsMillis=60000 spring.datasource.minEvictableIdleTimeMillis=300000 spring.datasource.validationQuery=SELECT 1 spring.datasource.testWhileIdle=true spring.datasource.testOnBorrow=false spring.datasource.testOnReturn=false spring.datasource.poolPreparedStatements=true spring.datasource.maxOpenPreparedStatements=10可以使用MyBatis寫SQL的方式獲取到Kylin中的數(shù)據(jù)。
SQL示例：
2.3 錯(cuò)誤總結(jié)：分頁問題
Kylin中分頁查詢和MySQL中的方式不太一樣，使用下面的語法：
LIMIT ${pageSize} OFFSET ${(page - 1) * pageSize}
這個(gè)語法和Phoenix的查詢語法一樣。
但是，需要注意的是，這里的為pageSize，為{pageSize}，為pageSize，為符號，而MyBatis中防注入的是通過#，所以需要在傳遞參數(shù)的時(shí)候做好相應(yīng)的控制。如果寫成了#發(fā)現(xiàn)最后獲取不到自己想獲取的值（這個(gè)地方可能是其它原因）。
2.4 錯(cuò)誤總結(jié)：版本兼容問題
在筆者部署線上環(huán)境過程中，筆者使用的hive是hive-2.3.2 （原生），然后使用最新的： apache-kylin-2.5.2-source-release.zip ，發(fā)現(xiàn)其中出現(xiàn)了hive中有數(shù)據(jù)，但是直到kylin cube build完成之后也不能將數(shù)據(jù)拉取到kylin，發(fā)現(xiàn)Source Records 的條數(shù)為0，然后筆者將版本降低到：apache-kylin-2.3.1，問題現(xiàn)象不再出現(xiàn)，cube build正常了。
2.5 知識點(diǎn)：Cube的構(gòu)建參數(shù)查看方法
各層代表不同數(shù)量級的維度組合。每一層的計(jì)算都是一個(gè)單獨(dú)的Map Reduce任務(wù)。
2.5.1 Cube的構(gòu)建參數(shù)查看方法
可以看出，cuboid越多，build cube就越慢，可通過命令查看cuboid個(gè)數(shù)：
./kylin.sh org.apache.kylin.engine.mr.common.CubeStatsReader [cubeName]在這里可以看出，該cube在構(gòu)建之后得到的cuboids為63，大小約188mb
2.5.2 Build區(qū)間的數(shù)據(jù)源大小，可以在下圖查看
可以通過上面的提示看出：
一般Cube的膨脹率應(yīng)該在0%~1000%之間，如果Cube的膨脹率超過了1000%，那么就需要查詢其中的原因了，導(dǎo)致膨脹率高的原因一般為以下幾點(diǎn)：
A:Cube的維度數(shù)量較多了，沒有進(jìn)行良好的剪枝降維 B:Cube中存在較高基數(shù)的維度，導(dǎo)致這類維度每個(gè)Cuboid占用的空間很大，從而造成Cube體積變大 C:存在比較占用空間的(度量就是被聚合的統(tǒng)計(jì)值，也是聚合運(yùn)算的結(jié)果),例如Count distinct、max()、sum(),需要在cuboid的每一行中都為其保存一個(gè)較大的寄存器，導(dǎo)致整個(gè)體積變大。Cube體積直接影響整個(gè)build性能，所以在創(chuàng)建時(shí)需要再三注意有無可減少的度量和維度。
如果有 10 個(gè)維度，那么就會生成 2^10=1024-1 個(gè) Cuboid，如果有 20 個(gè)維度那么將會 生 成 2^20=1048576-1 個(gè) Cuboid ， 是 指 數(shù) 級 增 長 ， kylin.properties 中 參 數(shù) kylin.cube.aggrgroup.max-combination＝4096，也就是說當(dāng) Cuboid 數(shù)量大于 4096 時(shí)， Cube 定義是無法保存的的，會報(bào) TooManyCuboidException 異常。所以默認(rèn)維度不能超過 12 個(gè)，若非得超過 12 個(gè)，那必須降維：
3 Kylin RestAPI使用
使用kylin Rest API在shell腳本中執(zhí)行cube build/rebuid
Centos7上安裝jq工具
Jq源碼位置：https://github.com/stedolan/jq
下載安裝地址：https://stedolan.github.io/jq/download/
Centos下安裝jq
wget -O jq https://github.com/stedolan/jq/releases/download/jq-1.5/jq-linux64
chmod +x ./jq
cp jq /usr/bin
3.1 一個(gè)shell腳本案例：
env.sh 內(nèi)容：#!/bin/bash#kylin的參數(shù) export kylinUserInfo="--user ADMIN:KYLIN" export kylinCubeUrl="http://xxx:7070/kylin/api/cubes/" export kylinJobsUrl="http://xxxx:7070/kylin/api/jobs/" export startTime="2015-01-01 00:00" export startTimeTimeStamp=`date -d "$startTime" +%s` export startTimeTimeStampMs=$(($startTimeTimeStamp * 1000)) export endTime=`date +%Y-%m-%d -d "+1days"` export endTimeTimeStamp=`date -d "$endTime" +%s` #將時(shí)間戳編程毫秒值 export endTimeTimeStampMs=$(($endTimeTimeStamp * 1000))export tradeInfoArgs="dataName=tradeInfo&dataType=" #$dataType"&dataTime="$yesterday #json的url信息存儲的文件路徑 export tradeInfoJsonUrls=$current/tmpfile/tradeInfoJsonUrls #json的url存儲位置前綴 export tradeInfoJsonUrlPrefix=$current/tmpfile/tradeInfoJsonUrlPrefix export tradeAnalyzeCubeName="xxxx" export tradeCollectMoneyCubeName="xxxx" #用于存儲是否下載了的變量文件 export tradeInfoVariableFile=$current/tmpfile/tradeInfoVariableFile#!/bin/bashsource /etc/profile#引用公共文件中定義的參數(shù)變量 source $PWD/env.shjobId=#是否執(zhí)行過初始化程序了的控制邏輯 function isInited() {#如果文件存在，讀取相應(yīng)的數(shù)據(jù)類型if [[ `ls $tradeInfoVariableFile | grep tradeInfoVariableFile | grep -v grep` != "" ]];thendataType=`cat $tradeInfoVariableFile | grep kylinTradeAnalyzeCubeInited | sed 's/kylinTradeAnalyzeCubeInited=//g'`#如果沒有，說明這個(gè)Spark程序還沒有初始化過 if [[ $dataType == "" ]];thenecho -e "\n" >> $tradeInfoVariableFileecho "kylinTradeAnalyzeCubeInited=inited" >> $tradeInfoVariableFilereturn 0;elsereturn 1;fielsemkdir -p $current/tmpfilecd $current/tmpfile#如果沒有這個(gè)文件，則是在這個(gè)文件中添加echo "kylinTradeAnalyzeCubeInited=inited" > $tradeInfoVariableFilereturn 0;fi }#Spark處理 function kylinHandler() {isInitedif [[ $? == 0 ]];then#上傳數(shù)據(jù)文件到HDFS中cd $current#1、Disable Cubecurl -X PUT $kylinUserInfo -H "Content-Type: application/json;charset=utf-8" $kylinCubeUrl$tradeAnalyzeCubeName/disableecho ""echo ""#2、Purge Cubecurl -X PUT $kylinUserInfo -H "Content-Type: application/json;charset=utf-8" $kylinCubeUrl$tradeAnalyzeCubeName/purgeecho ""echo ""#3、Enable Cubecurl -X PUT $kylinUserInfo -H "Content-Type: application/json;charset=utf-8" $kylinCubeUrl$tradeAnalyzeCubeName/enableecho ""echo ""#4、Build cubecubeBuildInfo=`curl -X PUT $kylinUserInfo -H "Content-Type: application/json;charset=utf-8" -d '{ "startTime":'$startTimeTimeStampMs',"endTime":'$endTimeTimeStampMs', "buildType": "BUILD"}' $kylinCubeUrl$tradeAnalyzeCubeName/build`echo ""echo ""elsecubeBuildInfo=`curl -X PUT $kylinUserInfo -H "Content-Type: application/json;charset=utf-8" -d '{"endTime":'$endTimeTimeStampMs', "buildType": "BUILD"}' $kylinCubeUrl$tradeAnalyzeCubeName/rebuild`echo ""echo ""fiecho "cube build的狀態(tài)結(jié)果:"echo $cubeBuildInfoecho ""echo ""#查看是否build好了，如果build好了，發(fā)現(xiàn)last_build_time變成了build的最后時(shí)間了。jobId=$(echo $cubeBuildInfo |jq '.uuid')echo $jobId > $jobIdsed -i 's/"//g' $jobIdrealJobId=`cat $jobId`echo $realJobIdrm -rf $jobIdecho ""echo ""while :dosleep 1mcubeJobInfo=`curl -X GET --user ADMIN:KYLIN $kylinJobsUrl$realJobId`echo "獲取cube job運(yùn)行的狀態(tài)"echo $cubeJobInfoecho ""echo ""jobStatus=$(echo $cubeJobInfo | jq ".job_status")echo "jobStatus"echo $jobStatus > $realJobIdsed -i 's/"//g' $realJobIdrealJobStatus=`cat $realJobId`echo "$realJobStatus"echo ""if [[ $realJobStatus == "NEW" ]];thenecho "kylin cube build job status：NEW; sleep 1m;"elif [[ $realJobStatus == "PENDING" ]];thenecho "kylin cube build job status：PENDING; sleep 1m;"elif [[ $realJobStatus == "RUNNING" ]];thenecho "kylin cube build job status：RUNNING; sleep 1m;"elif [[ $realJobStatus == "STOPPED" ]];thenecho "kylin cube build job status：STOPPED"#如果stop了，停掉kylin腳本的運(yùn)行break;elif [[ $realJobStatus == "FINISHED" ]];thenecho "kylin cube build job status：FINISHED"break;elif [[ $realJobStatus == "ERROR" ]];thenecho "kylin cube build job status：ERROR"break;elif [[ $realJobStatus == "DISCARDED" ]];thenecho "kylin cube build job status：DISCARDED"break;else echo "kylin cube build job status：OTHER UNKNOWN STATUS"break;fidone#刪除文件rm -rf $realJobId }#上傳數(shù)據(jù)文件到HDFS中 kylinHandler#清理Linux系統(tǒng)中不用的垃圾暫用的內(nèi)存 sync echo 3 > /proc/sys/vm/drop_caches
4 參考資料
http://kylin.apache.org/cn/
http://kyligence.io/zh/blog-zh/
總結(jié)
以上是生活随笔為你收集整理的kylin调优，项目中错误总结，知识点总结，kylin jdbc driver + 数据库连接池druid + Mybatis项目中的整合，shell脚本执行kylin restapi 案例的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Cloudera Manager 和CD
- 下一篇： 31-32 python mysql-c