Ⅰ 大數據分析界的「神獸」Apache Kylin有多牛
1.Apache Kylin是什麼？
在現在的大數據時代，越來越多的企業開始使用Hadoop管理數據，但是現有的業務分析工具（如Tableau，Microstrategy等）
往往存在很大的局限，如難以水平擴展、無法處理超大規模數據、缺少對Hadoop的支持；而利用Hadoop做數據分析依然存在諸多障礙，例如大多數分析
師只習慣使用SQL，Hadoop難以實現快速互動式查詢等等。神獸Apache Kylin就是為了解決這些問題而設計的。
Apache Kylin，中文名麒（shen）麟（shou） 是Hadoop動物園的重要成員。Apache
Kylin是一個開源的分布式分析引擎，最初由eBay開發貢獻至開源社區。它提供Hadoop之上的SQL查詢介面及多維分析（OLAP）能力以支持大
規模數據，能夠處理TB乃至PB級別的分析任務，能夠在亞秒級查詢巨大的Hive表，並支持高並發。
Apache
Kylin於2014年10月在github開源，並很快在2014年11月加入Apache孵化器，於2015年11月正式畢業成為Apache頂級項
目，也成為首個完全由中國團隊設計開發的Apache頂級項目。於2016年3月，Apache
Kylin核心開發成員創建了Kyligence公司，力求更好地推動項目和社區的快速發展。
Kyligence是一家專注於大數據分析領域創新的數據科技公司，提供基於Apache
Kylin的企業級智能分析平台及產品，以及可靠、專業、源碼級的商業化支持；並推出Apache Kylin開發者培訓，頒發全球唯一的Apache
Kylin開發者認證證書。
2.Kylin的基本原理和架構
下面開始聊一聊Kylin的基本原理和架構。簡單來說，Kylin的核心思想是預計算，即對多維分析可能用到的度量進行預計算，將計算好的結果保
存成Cube，供查詢時直接訪問。把高復雜度的聚合運算、多表連接等操作轉換成對預計算結果的查詢，這決定了Kylin能夠擁有很好的快速查詢和高並發能
力。
上圖所示就是一個Cube的例子，假設我們有4個dimension，這個Cube中每個節點（稱作Cuboid）都是這4個dimension
的不同組合，每個組合定義了一組分析的dimension（如group
by），measure的聚合結果就保存在這每個Cuboid上。查詢時根據SQL找到對應的Cuboid，讀取measure的值，即可返回。
為了更好的適應大數據環境，Kylin從數據倉庫中最常用的Hive中讀取源數據，使用
MapRece作為Cube構建的引擎，並把預計算結果保存在HBase中，對外暴露Rest
API/JDBC/ODBC的查詢介面。因為Kylin支持標準的ANSI
SQL，所以可以和常用分析工具（如Tableau、Excel等）進行無縫對接。下面是Kylin的架構圖。
說到Cube的構建，Kylin提供了一個稱作Layer Cubing的演算法。簡單來說，就是按照dimension數量從大到小的順序，從Base
Cuboid開始，依次基於上一層Cuboid的結果進行再聚合。每一層的計算都是一個單獨的Map Rece任務。如下圖所示。
MapRece的計算結果最終保存到HBase中，HBase中每行記錄的Rowkey由dimension組成，measure會保存在
column
family中。為了減小存儲代價，這里會對dimension和measure進行編碼。查詢階段，利用HBase列存儲的特性就可以保證Kylin有
良好的快速響應和高並發。
有了這些預計算的結果，當收到用戶的SQL請求，Kylin會對SQL做查詢計劃，並把本該進行的Join、Sum、Count Distinct等操作改寫成Cube的查詢操作。
Kylin提供了一個原生的Web界面，在這里，用戶可以方便的創建和設置Cube、管控Cube構建進度，並提供SQL查詢和基本的結果可視化。
根據公開數據顯示，Kylin的查詢性能不只是針對個別SQL，而是對上萬種SQL 的平均表現，生產環境下90%ile查詢能夠在在3s內返回。在上個月舉辦的Apache Kylin
Meetup中，來自美團、京東、網路等互聯網公司分享了他們的使用情況。例如，在京東雲海的案例中，單個Cube最大有8個維度，最大數據條數4億，最
大存儲空間800G，30個Cube共占存儲空間4T左右。查詢性能上，當QPS在50左右，所有查詢平均在200ms以內，當QPS在200左右，平均
響應時間在1s以內。
北京移動也在meetup上展示了Kylin在電信運營商的應用案例，從數據上看，Kylin能夠在比Hive/SparkSQL在更弱的硬體配置下獲得更好的查詢性能。 目前，有越來越多的國內外公司將Kylin作為大數據生產環境中的重要組件，如ebay、銀聯、網路、中國移動等。大家如果想了解更多社區的案例和動態，可以登錄Apache Kylin官網或Kyligence博客進行查看。
3.Kylin的最新特性
Kylin的最新版本1.5.x引入了不少讓人期待的新功能，可擴展架構將Kylin的三大依賴（數據源、Cube引擎、存儲引
擎）徹底解耦。Kylin將不再直接依賴於Hadoop/HBase/Hive，而是把Kylin作為一個可擴展的平台暴露抽象介面，具體的實現以插件的
方式指定所用的數據源、引擎和存儲。
開發者和用戶可以通過定製開發，將Kylin接入除Hadoop/HBase/Hive以外的大數據系統，比如用Kafka代替Hive作數據源，用
Spark代替MapRece做計算引擎，用Cassandra代替HBase做存儲，都將變得更為簡單。這也保證了Kylin可以隨平台技術一起演
進，緊跟技術潮流。
在Kylin
1.5.x中還對HBase存儲結構進行了調整，將大的Cuboid分片存儲，將線性掃描改良為並行掃描。基於上萬查詢進行了測試對比結果顯示，分片的存
儲結構能夠極大提速原本較慢的查詢5-10倍，但對原本較快的查詢提速不明顯，綜合起來平均提速為2倍左右。
除此之外，1.5.x還引入了Fast
cubing演算法，利用Mapper端計算先完成大部分聚合，再將聚合後的結果交給Recer，從而降低對網路瓶頸的壓力。對500多個Cube任務
的實驗顯示，引入Fast cubing後，總體的Cube構建任務提速1.5倍。
目前，社區正在著手准備Apache Kylin 1.5.2版本的發布，目前正處於Apache Mailing list投票階段，預計將會在本周在Kylin官網發布正式下載。
在本次的1.5.2版本中，Kylin帶來了總計
36個缺陷修復、33個功能改進、6個新功能。一些主要的功能改進包括對HyperLogLog計算效率的提升、在Cube構建時對Convert
data to hfile步驟的提速、UI上對功能提示的體驗優化、支持hive view作為lookup表等等。
另一個新消息是Kylin將支持MapR和CDH的Hadoop發行版，具體信息可見KYLIN-1515和KYLIN-1672。相應的測試版本是MapR5.1和CDH5.7。
UI上提供了一個重要更新，即允許用戶在Cube級別進行自定義配置，以覆蓋kylin.properties中的全局配置。如在cube中定義kylin.hbase.region.count.max 可以設置該cube在hbase中region切分的最大數量。
另
一個重要的功能是Diagnosis。用戶經常會遇到一些棘手的問題，例如Cube構建任務失敗、SQL查詢失敗，或Cube構建時間過長、SQL查詢時
間過長等。但由於運維人員對Kylin系統了解不深，很難快速定位到root cause所在地。我們在mailing
list里也經常看到很多用戶求助，由於不能提供足夠充分的信息，社區也很難給出一針見血的建議。
當用戶遇到查詢、Cube/Model管理的問題，單擊System頁面的Diagnosis按鈕，系統會自動抓取當前Project相關的信息並打包成
zip文件下載到用戶本地。這個包會包含相關的Metadata、日誌、HBase配置等。當用戶需要在mailing
list求助，也可以附上這個包。
Ⅱ linux文件系統-LVM邏輯卷
LVM（Logical Volume Manager）卷組管理器，通過對底層物理磁碟的封裝，可以將多塊物理磁碟組合成邏輯資源池，提供給上層應用使用（如文件系統）. LVM的好處是，可以跨物理硬碟為文件系統提供容量，並且可以動態進行分區容量的調整，而不會損壞原有的文件系統.
物理磁碟 ：物理存儲介質，可以是整塊物理存儲或一個分區.
物理卷PV（physical volume） ：LVM要使用物理磁碟，在物理磁碟的頭部寫入lvm標簽頭，就創建了一個PV，PV是組成VG的基本單元.
卷組VG（Volume Group） ：VG相當於非LVM系統中的物理硬碟，一個卷組VG由一個或多個PV組成，形成一個存儲資源池.
邏輯卷LV（logical volume） ：LV相當於非LVM系統中的硬碟分區，LV建立在卷組VG之上，文件系統建立在LV之上.
物理塊PE（physical Extent） ：創建LV時可以分配的最小存儲單元，大小可以指定，默認為4MB
如上是從物理磁碟到lvm邏輯卷的創建過程及映射關系，lv01、lv02被創建後，通過device-mapper映射為邏輯塊設備（塊設備路徑/dev/vg01/lv01、/dev/vg01/lv02），供文件系統使用，通過mkfs.ext4 /dev/vg01/lv02可創建ext4文件系統.
元數據主要是兩部分，PV header + metadata，位置一般是在PV的0~2048 sector中，從2048 sector開始是數據區域.
通過pvcreate創建pv時，會將pv header寫入物理磁碟，位置一般是在磁碟的第二個sector（512B/sector），lvm掃描磁碟時，通過pv header來識別PV.
pv header主要信息包括，pv uuid、元數據位置和metadata位置.
pv header實例:
metadata記錄的是vg和lv的配置信息，以ASCII碼的方式寫入metadata區域；vg和lv的每次配置變更，都會以追加的方式寫入metadata區域，並打上時間戳，該區域寫滿後，新的變更記錄會覆蓋最早的一次記錄. 進行vgscan時，猜測應該是通過讀取最新一次的配置記錄，進行激活.
vg配置信息，主要是包含的pv信息.
lv配置信息，主要是lv的起始位置和PE大小.
實例：
pvcreate /dev/vdb1
pvcreate /dev/vdb2
pvcreate /dev/vdb3
vgcreate /dev/vdb1 /dev/vdb2 /dev/vdb3
vgcreate wan /dev/vdb1 /dev/vdb2 /dev/vdb3
lvcreate -L 300M -n lv01 wan
將PV的前2048個sector通過dd拷貝出來，用cat查看如下.
假設我們有一塊磁碟 /dev/sdb1 作為應用數據盤使用，以此為例創建lvm分區
先創建物理卷PV，命令： pvcreate /dev/sdb1
創建卷組VG,卷組命名為kylin，命令：vgcreate kylin /dev/sdb1
在VG中創建邏輯分區LV，命令：lvcreate -L 30G -n test kylin
創建邏輯分區後，進行格式化，然後便可以掛載使用.
mkfs.ext4 /dev/kylin/test
mount /dev/kylin/test /data
假設我們在上述基礎上，又獲得一塊磁碟/dev/sdc1進行擴容，將磁碟容量增加到LV分區/dev/kylin/test中，具體操作如下.
先創建物理卷PV，命令： pvcreate /dev/sdc1
將/dev/sdc1添加進VG kylin，命令：vgextend kylin /dev/sdc1
增加LV分區容量，命令：lvextend -L +30G /dev/kylin/test
lvm卷組配置備份
lvm的配置信息默認在/etc/lvm/backup、/etc/lvm/archive/兩個目錄存在備份，當lvm元數據損壞，lvm卷組讀取異常時，可通過備份文件進行恢復.
/etc/lvm/backup: 保留了當前配置的備份
/etc/lvm/archive/：保留了每次配置更新前的備份
實例演示
邏輯卷/dev/wan/lv01
在/dev/wan/lv01上創建文件系統
掛載並創建文件
覆蓋/dev/vdb1、/dev/vdb2的lvm元數據，並重啟系統，vg已不能識別
通過pvcreate命令修復pv header 和metadata數據.
激活邏輯卷
掛載/dev/wan/lv01成功，說明成功修復
Ⅲ 麒麟linux系統提供源代碼嗎
一、引言
麒麟操作系統是由國防科技大學、中軟公司、聯想公司、浪潮公司和民族恆星公司五家單位合作研製的伺服器操作系統。按照麒麟官方的說法：
「Kylin伺服器操作系統是國家863計劃的重大研究成果，擁有完全自主版權的內核，與Linux在應用上二進制兼容，並支持64位，是中國獨立研發成功的、具有完全自主知識產權的伺服器操作系統。」
[1] —— 來自麒麟官方網站 和 863計劃官方網站
[2] _105/inst/inst_news/l
「銀河麒麟操作系統是針對未來的主流網路服務和高性能計算服務的需求，參照國際主流標准，參考Darwin、 FreeBSD、Linux和其它商用操作系統，借鑒UNIX操作系統和微內核操作系統的設計思想，設計並實現具有自主版權的、可支持多種CPU晶元和多種計算機體系結構的、具有高性能、高可用性與高安全性的、並與Linux應用和設備驅動二進制兼容的中文伺服器操作系統，」 ——摘自麒麟操作系統2.0.21內自帶的幫助文檔
近日，有不少人對麒麟操作系統宣稱的「完全自主版權」和「中國獨立研發成功」這兩個核心問題產生了質疑。隨著麒麟2.0.14和2.0.21系統可以通過麒麟的官方網站下載後（ ），這種質疑的聲音越來越大。麒麟除內核以外的應用大部分都來自自由組織GNU的代碼，這些代碼並不屬於「中國獨立研發」，而且他們的版權也不屬於麒麟操作系統的開發者。更有甚者，有人開始通過反匯編麒麟操作系統內核發現和美國的FreeBSD開放源代碼操作系統非常相似。隨後又有人成功的用 FreeBSD的內核啟動了麒麟操作系統。按照麒麟官方的介紹，麒麟具有Linux的二進制兼容的能力，可是絲毫沒有提及與FreeBSD的兼容性，使得麒麟內核與FreeBSD的關系變得比較引人注目。在官方介紹中的簡簡單單的「參考」是無法解釋這種相似程度的。
在強烈的關注聲中，麒麟開發人員在2006年2月16日，給出了一個說明，《關於銀河麒麟操作系統的說明》[3]，發布在 .其中提到了和FreeBSD的關系：
「課題組通過評測和分析，認為當時正在研發中的FreeBSD 5.0 具有比Unix SVR4.2 更好的發展勢頭，特別是SMPng 項目的開展，為FreeBSD 5.0 支持SMP 對稱多處理器系統奠定了良好的基礎，因此銀河麒麟操作系統的系統服務層從SVR4.2 升級到當時正在研發中的FreeBSD 5.0.」
聲明發出後一定程度上得到了大家諒解，可是雖然提及和FreeBSD的關系，卻又十分隱晦，既沒有明確的對官方網站新聞中的報道失實承認錯誤，沒有明確闡述麒麟的操作系統是否具有「完全知識產權」以及是否是「中國獨立研發」，甚至也沒有對官方頁面上的事實報道進行修正。而且，既然說明使用了FreeBSD 5.0的代碼，卻又說僅限於系統服務層，而絲毫未提及所佔比例。這依舊讓人們對這個獲得863計劃軟體重大專項的資助的操作系統到底有多少創新產生一個大大的疑問。
為了調查清楚麒麟操作系統內核自主創新的百分比，以及與其它操作系統之間的關系，我將麒麟操作系統內核與FreeBSD、NetBSD、OpenBSD、 Linux和Solaris的內核進行了可執行代碼的相似度分析。
在整個過程中，我將盡量保持客觀的原則進行分析。由於麒麟操作系統屬於封閉源代碼系統，因此在無法獲得內核源代碼的情況下，我將只進行二進制可執行代碼文件的相似度分析。由於可執行代碼受編譯環境、內存分布情況以及模塊的變動的影響很大，因此，會產生即使採用同一套代碼，卻產生很低的相似度情況。但是，對操作系統內核這種大型軟體系統來說，卻不會因為不同的代碼而產生很高的相似度的情況。因此，我們將這次對二進制可執行代碼分析所得的相似度作為相似度的下限。換句話說，真實的相似度應該會高於此次分析結果，但是由於分析方法的局限性，無法取得上限。
二、可執行文件的相似度比較
二進制可執行文件的相似度分析一直是一個難題。大家都知道，即使是同一份源代碼，使用同一個編譯器，可用不同的編譯參數進行編譯後，代碼也會產生極大的差異。當發生有人因為盜用別人的源代碼而產生的侵權後，如果不能夠將二者的源代碼拿出進行比較的話，判斷是否抄襲非常困難。因此，一直以來或多或少，總會有人無所顧忌的將開放源代碼的軟體拿來加入到自己的軟體中，或者乾脆就是在那些源代碼的基礎上稍加修改和更換了版權信息就宣稱是自己研發的。因為他們知道，只要不把自己的源代碼公諸於眾，那麼抄襲就很難判定。