Kylin 初體驗總結（kafka+superset+ldap）

03-31

基礎知識

OLAP(on-Line AnalysisProcessing)的實現方式

ROLAP:

基於關係資料庫的OLAP實現（Relational OLAP）。ROLAP將多維資料庫的多維結構劃分為兩類表:一類是事實表,用來存儲數據和維關鍵字;另一類是維表,即對每個維至少使用一個表來存放維的層次、成員類別等維的描述信息。維表和事實表通過主關鍵字和外關鍵字聯繫在一起,形成了"星型模式"。對於層次複雜的維,為避免冗餘數據佔用過大的存儲空間,可以使用多個表來描述,這種星型模式的擴展稱為"雪花模式"。特點是將細節數據保留在關係型資料庫的事實表中，聚合後的數據也保存在關係型的資料庫中。這種方式查詢效率最低，不推薦使用。

MOLAP:

多維數據組織的OLAP實現（Multidimensional OLAP。以多維數據組織方式為核心,也就是說,MOLAP使用多維數組存儲數據。多維數據在存儲中將形成"立方塊（Cube）"的結構,在MOLAP中對"立方塊"的"旋轉"、"切塊"、"切片"是產生多維數據報表的主要技術。特點是將細節數據和聚合後的數據均保存在cube中，所以以空間換效率，查詢時效率高，但生成cube時需要大量的時間和空間。

HOLAP:

基於混合數據組織的OLAP實現（Hybrid OLAP）。如低層是關係型的，高層是多維矩陣型的。這種方式具有更好的靈活性。特點是將細節數據保留在關係型資料庫的事實表中，但是聚合後的數據保存在cube中,聚合時需要比ROLAP更多的時間,查詢效率比ROLAP高，但低於MOLAP。 kylin的cube數據是作為key-value結構存儲在hbase中的，key是每一個維度成員的組合值，不同的cuboid下面的key的結構是不一樣的，例如cuboid={brand，product，year}下面的一個key可能是brand=Nike，product=shoe，year=2015，那麼這個key就可以寫成Nike:shoe:2015，但是如果使用這種方式的話會出現很多重複，所以一般情況下我們會把一個維度下的所有成員取出來，然後保存在一個數組裡面，使用數組的下標組合成為一個key，這樣可以大大節省key的存儲空間，kylin也使用了相同的方法，只不過使用了字典樹（Trie樹），每一個維度的字典樹作為cube的元數據以二進位的方式存儲在hbase中，內存中也會一直保持一份。

cube 構建

Dimension：Mandatory、hierarchy、derived

增量cube: kylin的核心在於預計算緩存數據，因此無法達到真正的實時查詢效果。一個cube中包含了多個segment，每一個segment對應著一個物理cube，在實際存儲上對應著一個hbase的一個表。每次查詢的時候會查詢所有的segment聚合之後的值進行返回，但是當segment數量較多時，查詢效率會降低，這時會對segment進行合併。被合併的幾個segment所對應的hbase表並沒有被刪除。- cube詞典樹：cube數據是作為key-value結構存儲在HBase中的。key是每一個維度成員的組合值

Streaming cubing

支持實時數據的cub。與傳統的cub一樣，共享storage engine(HBase)以及query engine。kylin Streaming cubing相比其他實時分析系統來說，不需要特別大的內存，也不需要實現真正的實時分析。因為在OLAP中，存在幾分鐘的數據延遲是完全可以接受的。於是實現手法上採用了micro batch approach。
micro batch approach:將監聽到的數據按照時間窗口的方式劃分，並且為每個窗口封裝了一個微量批處理，批處理後的結果直接存到HBase。
Streaming cubing data 最終會慢慢轉換成普通的cubes,因為所有的數據是直接保存到HBase中的，並且保存為一個新的segment，當segment數量到達一定程度時，job engine會將segment 合併起來形成一個大的cube。

實戰問題總結

由於集群環境是CDH集群，所以選擇了kylin CDH 1.6的版本，支持從Kafka讀取消息建立Streaming cubes直接寫入HDFS中
選擇一個集群namenode節點，將解壓包放入/opt/cloudrea/parcels/目錄中。如果是部署單節點，暫時不用更改配置文件。所有的配置載入都在bin/kylin.sh中。
直接kylin.sh start/stop 運行腳本，服務就會在7070埠起一個web界面。這個界面是可以進行可視化操作的。

Hive 數據源

直接測試hive數據源是沒有問題的，這一功能比較完善，也是主打功能，按照官網文檔來沒什麼問題

kafka數據源

從kylin 1.6 版本開始正式支持Kafka做數據源，將Streaming Cubes實時寫入 HBase中。這一塊在測試的時候也出現了問題：

Kafka版本問題

由於實驗環境的CDH集群Kafka版本是0.9的，而kylin 僅支持0.10以上的版本，所以需要對CDH kafka集群進行升級。

mapreduce運行環境無jar包

kylin中提交cube build之後，map reduce任務直接拋錯。錯誤提示是，找不到Kafka的Consumer類。根本原因是kylin默認集群上的map reduce classpath是會載入kafka-clients.jar包的，所以在提交任務的時候沒有將kafka-clients.jar包打進去。這時可以有三種做法：

1、直接修改kylin的源碼，將kafka-clients.jar包給包括進去（待嘗試）。

2、可以通過修改集群的HADOOP_ClASSPATH的路徑，將jar包給包括進去。

3、 hadoop classpath 查看classpath目錄信息將對應jar包直接拷入map reduce classpath中，這方法簡單，但是缺點就是需要逐個得對node進行操作。

Property is not embedded format

使用開源框架不會看其源碼是不行的...就在我折騰倆天終於將mapreduce任務跑起來之後，新的錯誤出現了:"ava.lang.RuntimeException: java.io.IOException: Property xxx is not embedded format"。莫名奇妙的錯誤。迫使我直接去github上看kylin kafka模塊的源碼。在TimedJsonStreamParser.java中發現代碼邏輯中默認json數據中，如果key存在下劃線就會將該key按照下劃線split... 然後看key對應的value是不是map類型，如果不是直接拋出標題的錯誤。

明確了問題之後，如何複寫默認下劃線split的配置成為問題。由於官網的文檔十分雞肋，很多坑都沒有涉及到，所以繼續看源碼。發現StreamingParser.java這個類中會去寫一些默認的配置。

public static final String PROPERTY_TS_COLUMN_NAME = "tsColName";public static final String PROPERTY_TS_PARSER = "tsParser";public static final String PROPERTY_TS_PATTERN = "tsPattern";public static final String EMBEDDED_PROPERTY_SEPARATOR = "separator";static { derivedTimeColumns.put("minute_start", 1); derivedTimeColumns.put("hour_start", 2); derivedTimeColumns.put("day_start", 3); derivedTimeColumns.put("week_start", 4); derivedTimeColumns.put("month_start", 5); derivedTimeColumns.put("quarter_start", 6); derivedTimeColumns.put("year_start", 7); defaultProperties.put(PROPERTY_TS_COLUMN_NAME, "timestamp"); defaultProperties.put(PROPERTY_TS_PARSER, "org.apache.kylin.source.kafka.DefaultTimeParser"); defaultProperties.put(PROPERTY_TS_PATTERN, DateFormat.DEFAULT_DATETIME_PATTERN_WITHOUT_MILLISECONDS); defaultProperties.put(EMBEDDED_PROPERTY_SEPARATOR, "_"); }

自然而然會聯想到，這個默認的配置肯定是可以在用戶設置的時候通過key（separator）去覆蓋的...於是發現在構建Streaming table的時候，可以通過Parse Properties去覆蓋配置。

於是直接寫成如下的形式：

tsColName=timestamp;separator=no

//源碼中拿到這個配置之後會做覆蓋處理，然後執行 getValueByKey：protected String getValueByKey(String key, Map<String, Object> rootMap) throws IOException { if (rootMap.containsKey(key)) { return objToString(rootMap.get(key)); } String[] names = nameMap.get(key); if (names == null && key.contains(separator)) { names = key.toLowerCase().split(separator); nameMap.put(key, names); } if (names != null && names.length > 0) { tempMap.clear(); tempMap.putAll(rootMap); //這塊如果複寫了separator屬性的話split後的names數組長度為1會跳過這一步循環，防止解析出錯 for (int i = 0; i < names.length - 1; i++) { Object o = tempMap.get(names[i]); if (o instanceof Map) { tempMap.clear(); tempMap.putAll((Map<String, Object>) o); } else { throw new IOException("Property " + names[i] + " is not embedded format"); } } Object finalObject = tempMap.get(names[names.length - 1]); return objToString(finalObject); } return StringUtils.EMPTY; }

kylin ldap:

配置ldap的時候嘗試了很多遍，最終試出的配置方法如下：

1、先用源碼中PasswordPlaceholderConfigurer類生成connection-password密碼串

kylin.security.profile=ldap //設置許可權為ldapkylin.security.acl.default-role=ROLE_ANALYST,ROLE_MODELER //默認的許可權是這倆個kylin.security.acl.admin-role=ROLE_ADMIN //指定admin許可權為ROLE_ADMIN,也就是說通過ldap的用戶都不是admin許可權kylin.sandbox=false //本來也不是sandbox,設置成falsekylin.security.ldap.connection-server=ldap://xxxxx:389/ //你自己的ldap server地址kylin.security.ldap.connection-username=xxxx //通過bind search方式綁定的用戶名kylin.security.ldap.connection-password=XcYL8SMhe+oOEri7lR/4mw== //綁定的用戶名對應的密碼（第一步生成後的加密串）kylin.security.ldap.user-search-base=xxxxx //搜索的開始節點，表示ldap從哪開始搜索用戶kylin.security.ldap.user-search-pattern=(uid={0}) //匹配模式，默認是uidkylin.security.ldap.user-group-search-base=xxxxx //這個跟user-search-base一樣即可

Kylin+superset可視化

縱使kylin在預計算查詢方面做的比較好，但是其數據可視化支持方面實在是不夠強大。而druid和superset天衣無縫的結合使得我們的基礎架構的選擇有了一絲猶豫。

那麼superset 是否可以支持kylin？雖然兩者的官網文檔都沒有對此進行說明，但是看superset是python寫的，又可以橫向支持到 SQLAlchemy 這樣的常見Python ORM框架上面。而kylin是提供restful查詢介面的。這意味著我們可以在 kylin+superset之間引入ORM層作為數據的轉換。碰巧，在網上發現了一個倆年多不維護的開源項目pykylin，於是在其基礎上做了兼容性的修改和調試，最終完成了kylin+superset的對接。效果圖如下：