大數(shù)據(jù)背景下，傳統(tǒng)關(guān)系型多維分析 ROLAP 引擎遇到極大挑戰(zhàn)，因而鏈家轉(zhuǎn)向基于 Hadoop 生態(tài)的 MOLAP(Kylin)及 HOLAP (多引擎)。

[[204914]]

本文分享鏈家在多維分析引擎方面的一些實(shí)踐經(jīng)驗(yàn)，主要從 OLAP 的背景和簡(jiǎn)介、鏈家多維分析架構(gòu)演進(jìn)和展望、OLAP 平臺(tái)鏈路優(yōu)化這三部分來(lái)介紹。

OLAP 的背景和簡(jiǎn)介

01OLAP vs OLTP

OLAP 翻譯成中文叫聯(lián)機(jī)分析處理，OLTP 叫聯(lián)機(jī)事務(wù)處理。OLTP 的核心是事務(wù)，實(shí)際上就是我們常見(jiàn)的數(shù)據(jù)庫(kù)。

我們的業(yè)務(wù)數(shù)據(jù)庫(kù)面向事務(wù)，并發(fā)量比較高，但是操作的數(shù)據(jù)量比較小，它是實(shí)時(shí)更新的。

數(shù)據(jù)庫(kù)的設(shè)計(jì)會(huì)按照 3NF 范式，更高的話可能會(huì)按照 BC 范式之類的來(lái)做。而 OLAP 的核心是分析，面向應(yīng)用是分析決策，需要分析的數(shù)據(jù)級(jí)會(huì)非常大，可能 TB，甚至 PB 都會(huì)有。

它的數(shù)據(jù)更新會(huì)稍微慢一些，因?yàn)槊嫦蚍治龅脑O(shè)計(jì)一般是反范式的。常見(jiàn)的是雪花模型和星型模型。

OLAP 實(shí)際上是什么呢?就是一個(gè) SQL，這里按照兩個(gè)維度，一個(gè) returnflag，一個(gè) orderstatus 來(lái)做 Group By，然后做一下 Sum，Group By 這段就叫維度，F(xiàn)rom 這段叫做指標(biāo)，非常簡(jiǎn)單。

02OLAP 引擎分類

OLAP 引擎的一些常見(jiàn)分類大概有這兩種：

• ROLAP，叫關(guān)系型 OLAP。它的特點(diǎn)是基于關(guān)系性模型，計(jì)算的時(shí)候，根據(jù)原始數(shù)據(jù)去做聚合運(yùn)算。常見(jiàn)的小數(shù)據(jù)量可以利用 MySQL、Oracle 這種傳統(tǒng)數(shù)據(jù)庫(kù)，而大數(shù)據(jù)量可以利用 Spark SQL、Presto 這些項(xiàng)目。
• MOLAP，叫多維 OLAP。它的特點(diǎn)就是它會(huì)基于一個(gè)預(yù)定義的模型，我需要知道，要根據(jù)什么維度，要去算哪些指標(biāo)，我提前就把這些結(jié)果弄好，存儲(chǔ)在引擎上。當(dāng)查詢的時(shí)候，根據(jù)結(jié)果簡(jiǎn)單地做下匯總就可以得出來(lái)。

03HOLAP

***一種叫 HOLAP，即混合 OLAP，這個(gè)就非常簡(jiǎn)單了，就是兩個(gè)雜交一下。根據(jù)業(yè)務(wù)場(chǎng)景路由不同的引擎。

圖1

如圖 1，是簡(jiǎn)單的 ROLAP 模型，具體操作流程剛才已經(jīng)提到了，它的優(yōu)勢(shì)就是，它其實(shí)就是個(gè)數(shù)據(jù)庫(kù)，所以任何的 SQL 都可以在里面執(zhí)行。數(shù)據(jù)是沒(méi)有冗余的。

缺點(diǎn)就是數(shù)據(jù)量很大的時(shí)候，計(jì)算速度會(huì)下降很多，所以并發(fā)會(huì)比較差。它的場(chǎng)景就是不知道要查什么數(shù)據(jù)，靈活性非常高時(shí)，一般會(huì)選 ROLAP。

04MOLAP

第二種 MOLAP，剛才提到 MOLAP 主要是要定義一個(gè)模型，比如說(shuō)圖 2 樣例里面定義了三個(gè)維度：Time，Web page，Action。

圖2

從這三個(gè)維度把所有的組合提前預(yù)計(jì)算好，存在一個(gè)存儲(chǔ)引擎中，需要的時(shí)候里面取出來(lái)做一下聚合就可以，所以它的原始數(shù)據(jù)支持非常大，查詢速度，因?yàn)橹苯铀愫昧?，可以很快返回?/p>

它的缺點(diǎn)就是因?yàn)榫酆狭艘院?，就查不到明?xì)數(shù)據(jù)。它的靈活性稍微差一點(diǎn)，因?yàn)樾枰A(yù)先去定義維度，還有指標(biāo)。所以說(shuō)當(dāng)需要能夠知道查詢的模式，才能用這個(gè) MOLAP。

鏈家多維分析架構(gòu)演進(jìn)和展望

01早期分析數(shù)據(jù)實(shí)現(xiàn)

我們剛開(kāi)始做大數(shù)據(jù)的時(shí)候，Hadoop 組建基本上都是基于開(kāi)源的。我們會(huì)從日志、Kafka 去導(dǎo)數(shù)據(jù)，MySQL 數(shù)據(jù)會(huì)用 Sqoop 同步到 Hadoop 中。

當(dāng)時(shí)是用一個(gè)開(kāi)源的調(diào)度引擎 Ooize，我們根據(jù)業(yè)務(wù)需求去建表，然后把數(shù)據(jù)導(dǎo)到 MySQL 中，因?yàn)橐龀尸F(xiàn)，必須要在一個(gè)比較快的返回的數(shù)據(jù)庫(kù)中，所以放在 MySQL。

它的缺點(diǎn)是什么?當(dāng)它的數(shù)據(jù)量越來(lái)越大，MySQL 做存儲(chǔ)，它的擴(kuò)展性是非常不好的。數(shù)據(jù)量大以后，第二個(gè)問(wèn)題是速度會(huì)比較慢。第三個(gè)，面臨分析的維度非常多，每個(gè)維度的分析，都要一個(gè)數(shù)據(jù)開(kāi)發(fā)做需求，平均做一個(gè)需求時(shí)間可能要兩周。

圖3

02技術(shù)選型

能不能用一些 OLAP 引擎來(lái)簡(jiǎn)化操作?我們總結(jié)了對(duì) OLAP 引擎的一些需求。

響應(yīng)要快，因?yàn)闃I(yè)務(wù)分析人員等不了太久，需要一定并發(fā)，***有一個(gè) SQL 接口，支持?jǐn)?shù)據(jù)級(jí)要非常大。當(dāng)然離線方面，我們目前是 T+1 的模式，所以說(shuō)綜合考慮選擇了 Kylin。

Kylin 就是基于 Hadoop 之上的提供 SQL 查詢和多維分析的能力，它能支持超大規(guī)模數(shù)據(jù)級(jí)。它能在亞秒返回巨大的一個(gè)查詢。

實(shí)際上它就是標(biāo)準(zhǔn)的 MOLAP 方案，我們需要預(yù)先定義維度和指標(biāo)，提前預(yù)計(jì)算它的 Cube，把結(jié)果存在 HBase，查詢時(shí)解析 SQL，根據(jù)路由把它到 HBase 到對(duì)應(yīng)的表中去拿取數(shù)據(jù)。

圖4

圖 4 是 Kylin 的架構(gòu)圖，最下面是構(gòu)建引擎，左邊是 Hadoop 數(shù)據(jù)倉(cāng)庫(kù)，右邊是 HBase。

最下面會(huì)根據(jù) Hadoop 不同的原始數(shù)據(jù)進(jìn)行構(gòu)建，然后把數(shù)據(jù)存在 HBase。查詢的時(shí)候，在 Query Engine 做解析，解析完了以后，下面路由選擇，去 HBase 中查對(duì)應(yīng)的數(shù)據(jù)。

左邊大家看到有根虛線，這個(gè)是什么意思呢?剛才提到 MOLAP 只能支持預(yù)聚合的數(shù)據(jù)，要查原始的明細(xì)數(shù)據(jù)應(yīng)該怎么辦，Kylin 是不支持的。

這條虛線劃出來(lái)，官方說(shuō)會(huì)在后續(xù)某個(gè)版本支持，但實(shí)際上一直沒(méi)做。后面會(huì)講到我們是怎么解決這個(gè)問(wèn)題的。

再介紹一下鏈家 Kylin 使用統(tǒng)計(jì)，定位是離線的 OLAP 引擎。線上有 100 多個(gè) Cube，公司 8 個(gè)業(yè)務(wù)正在使用，總共存儲(chǔ)容量應(yīng)該也到了 30T。

總的數(shù)據(jù)量應(yīng)該在 800 億行左右，單個(gè) Cube ***已經(jīng)到 40 億行。每天的查詢量大概有 10 萬(wàn)多，查詢性能還是非常好的，95% 能在 500ms 以內(nèi)，99% 都在 1s 中返回。除開(kāi)那種超大的，可能會(huì)在 10s 左右，還是非常好的滿足了我們的需求。

03鏈家 OLAP 平臺(tái)架構(gòu)

圖5

圖 5 是鏈家整個(gè) OLAP 平臺(tái)的架構(gòu)。首先核心還是基于 Kylin 這樣一個(gè) MOLAP 引擎，Kylin 做了讀寫(xiě)分離的部署，也做了負(fù)載均衡的高可用。

Build 機(jī)器是構(gòu)建任務(wù)的機(jī)器，下面對(duì)接的是主要的 Hadoop 集群，負(fù)責(zé)所有的數(shù)據(jù)倉(cāng)庫(kù)存儲(chǔ)和所有的計(jì)算。我們有自研的調(diào)度系統(tǒng)，每天會(huì)去調(diào)度 Kylin 的構(gòu)建任務(wù)。

關(guān)于調(diào)度系統(tǒng)，調(diào)度提供了很多功能，比如說(shuō)分布式調(diào)度，會(huì)根據(jù)機(jī)器的負(fù)載情況去分發(fā)任務(wù)，會(huì)做任務(wù)的依賴，會(huì)做任務(wù)的監(jiān)控等等。當(dāng)然今天的重點(diǎn)不是它。

第二塊就是 HBase 集群，是個(gè)單獨(dú)的集群。為什么這么做呢?如果 HBase 跟 Hadoop 在一起，Hadoop 一旦運(yùn)行大的任務(wù)，內(nèi)存壓力大的時(shí)候，HBase 就會(huì)性能非常差，所以把查詢服務(wù)獨(dú)立出來(lái)。

所有的查詢 Query 機(jī)器都會(huì)去查 HBase。上面的指標(biāo)分析平臺(tái)就是鏈家可視化的分析平臺(tái)，它底層的引擎主要就是 Kylin，它所有的預(yù)建模的查詢都會(huì)走 Kylin，當(dāng)然會(huì)做緩存，把那些常用的 SQL，重復(fù)的 SQL 緩存住。

第二塊就是剛才提到的，如果有查明細(xì)數(shù)據(jù)該怎么辦?鏈家這邊集群組自研了另一個(gè)引擎叫 Query Engine。

它主要是給另外一個(gè)業(yè)務(wù)提供服務(wù)，提供即時(shí)查詢服務(wù)。它底層是兩個(gè)引擎，Presto 和 Spark SQL。

在指標(biāo)上支持明細(xì)的查詢和靈活的查詢，如果 Kylin 不支持，就會(huì)把它轉(zhuǎn)到 Query Engine，Query Engine 會(huì)根據(jù)它的 Cost 來(lái)做優(yōu)化，來(lái)選擇 Presto 或者 Spark SQL 來(lái)查詢，這樣就解決了明細(xì)查詢的問(wèn)題。

指標(biāo)分析平臺(tái)同時(shí)也對(duì)外提供 API，如果其他業(yè)務(wù)需要我們的數(shù)據(jù)，可以提供 API 的形式。

然后 Cube 管理，Kylin 有原生頁(yè)面來(lái)做 Cube 管理的，但是那個(gè)原生的頁(yè)面會(huì)有很多問(wèn)題。比如說(shuō)涉及 LDAP 的權(quán)限控制，跟鏈家的權(quán)限是沒(méi)有打通的。

它本身的性能是非常差，刷一個(gè)頁(yè)面可能要發(fā)幾十個(gè) Post 請(qǐng)求，非?？āＳ谑俏覀儶?dú)立開(kāi)發(fā)了一套 Cube 管理，集成了鏈家的權(quán)限管理，性能會(huì)比原來(lái)好很多。

***一塊就是預(yù)警監(jiān)控，我們所有模塊都有 Supervisior 存活監(jiān)控，保證它掛了以后能啟動(dòng)，整個(gè)鏈路都會(huì)上報(bào)到 OP 部門(mén)維護(hù)的基于 Falcon 的監(jiān)控平臺(tái)。

圖6

圖 6 是報(bào)表查詢頁(yè)面，這里會(huì)顯示我有權(quán)限的報(bào)表，在里面搜索一下，我想看的一些報(bào)表。這是一張，首先選擇一個(gè)時(shí)間的維度，然后這里可以篩選很多條件，比如說(shuō)根據(jù)分公司，根據(jù)店組去查。

比如想看東北區(qū)的詳情，點(diǎn)進(jìn)去就可以顯示到這個(gè)區(qū)里面所有店主。如果需要看這個(gè)店主再點(diǎn)進(jìn)去，就可以到這個(gè)店主里面的每個(gè)人。

這個(gè)在 OLAP 領(lǐng)域，這個(gè)過(guò)程叫做下鉆的過(guò)程。如果往回這個(gè)過(guò)程叫上卷，相當(dāng)于把那個(gè)結(jié)果再往回聚合，我們感覺(jué) UI 設(shè)計(jì)的還可以。

圖7

然后圖 7 這是我們自研的 Cube 管理。如果大家有用過(guò) Kylin 的話，應(yīng)該覺(jué)得主要的功能都是差不多的，因?yàn)槎际歉鶕?jù) Kylin 來(lái)做定制的。

比如說(shuō)選擇維度，選擇指標(biāo)。然后可以設(shè)置一些參數(shù)，可以在這里面做查詢。它的未來(lái)可能就是它對(duì)接了我們權(quán)限平臺(tái)，能夠自己對(duì)它做管理。

04鏈家 OLAP 特色

總結(jié)一下鏈家 OLAP 的一些特色。一是自研的可視化平臺(tái)，支持上卷下鉆，維度對(duì)比，可視化報(bào)表創(chuàng)建，指標(biāo)管理。

開(kāi)源的時(shí)候，其實(shí)有些開(kāi)源產(chǎn)品比如 Saiku，有些公司 已有應(yīng)用。相比于它的話，個(gè)人感覺(jué) UI 還是美觀一些，更切近業(yè)務(wù)，方便靈活定制。

我們的引擎能力，其實(shí)并不是簡(jiǎn)單的 MOLAP，而是一個(gè)混合的 OLAP 模型，既支持明細(xì)查詢，又支持聚合查詢。針對(duì)需求實(shí)現(xiàn)了跨 Cube 查詢的功能，就是 Kylin 中，一個(gè) Cube 對(duì)應(yīng)一張實(shí)時(shí)表，一個(gè) Cube 里面只能查一張實(shí)時(shí)表的數(shù)據(jù)。

假如說(shuō)有多個(gè)實(shí)時(shí)表，但是我查的維度是類似的，我想把結(jié)果做聚合運(yùn)算，Kylin 是不支持的，我們平臺(tái)里面支持了跨 Cube 查詢。

然后在這里面完整監(jiān)控，有高可用的架構(gòu)。Cube 管理剛才也提到，前端會(huì)做一些簡(jiǎn)化，對(duì)接了權(quán)限，簡(jiǎn)化配置，提升我們的管理效率。

05OLAP 展望

下面是我們 OLAP 下半年的展望。

***是擴(kuò)展能力。剛才提到已經(jīng)有跨 Cube 查詢，但是隨著業(yè)務(wù)增長(zhǎng)，可能有更多的需求。

比如說(shuō)想把 Kylin 的數(shù)據(jù)去跟 Hive 里的數(shù)據(jù)做計(jì)算，或者業(yè)務(wù)那邊接入他們自己的 Oracle，里面放了一些他們不想給我們的數(shù)據(jù)，但是想跟我們的數(shù)據(jù)做一些混合運(yùn)算，我們這邊做一個(gè)多元數(shù)據(jù)查詢。

第二塊會(huì)做一些更多的路由優(yōu)化，優(yōu)化查詢效率。

還有就是 Kylin 目前它的源數(shù)據(jù)同步。Build 機(jī)器相當(dāng)于 Master，Query的機(jī)器相當(dāng)于 Slave，目前是 Push 的模式，Build 機(jī)器 build 好了，把一些元數(shù)據(jù)同步過(guò)去。

但是缺點(diǎn)是有時(shí)候會(huì)出現(xiàn)失敗的情況。我們目前做得非常 Low，就是用 Crontab，定期讓 Slave 去重新刷一下緩存。

后期我們正在做的就是讓 Slave 用心跳機(jī)制，Master 那里用一個(gè)狀態(tài)機(jī)模型，把每一個(gè)要下發(fā)的任務(wù)放在狀態(tài)機(jī)里，Slave 心跳了之后來(lái)取這個(gè)狀態(tài)。

當(dāng)我更新完緩存以后，我在下次心跳的時(shí)候，把這個(gè)狀態(tài)再置為已經(jīng)更新。其實(shí)這個(gè)非常類似于 Hadoop 里面的 YARN 架構(gòu)，都是基于狀態(tài)機(jī)的。

這樣的話，擴(kuò)展性會(huì)非常好，減少 Master 的一些壓力。我們正在做 Kylin 2.0 調(diào)研，比如它支持雪花模型，不用轉(zhuǎn)化數(shù)據(jù)倉(cāng)庫(kù)。支持 Spark 構(gòu)建，提升速度。

第三塊，我們目前的 OLAP 還是一個(gè)離線服務(wù)。隨著業(yè)務(wù)的發(fā)展，我們有更多實(shí)時(shí)需求。主要是 MOLAP 里面的一些實(shí)時(shí)的方向，一個(gè)是 Kylin 自身支持 Streaing Cubing，類似于 Spark Streaming，實(shí)際上是小批量近實(shí)時(shí)的，做到分鐘級(jí)。

另外我們也考慮 Druid 或者 Palo 這些架構(gòu)，它們是 Lambda 的架構(gòu)。就是內(nèi)存中會(huì)維護(hù)***的狀態(tài)，這樣可以做到純實(shí)時(shí)的更新。

OLAP 平臺(tái)鏈路優(yōu)化實(shí)踐

01Kylin 全鏈路架構(gòu)

***講一些比較接地氣的，我們?cè)?OLAP 平臺(tái)全鏈路的一些優(yōu)化經(jīng)驗(yàn)。首先看一下 Kylin 的整個(gè)鏈路，最上頭的 Kylin，它的存儲(chǔ)引擎是 HBase，HBase 又基于 HDFS，所有程序都跑到了JVM 上。

首先是 Kylin 本身有一些優(yōu)化，我們知道假如我們定義了 N 個(gè)維度，我查詢的時(shí)候，每一個(gè)維度可選擇或者不選擇，其實(shí)有 2 的 N 次方種選擇。

比如說(shuō) A、B、C、D 四個(gè)維度，這里頭一共有 16 種維度選擇。這個(gè) Kylin 里面會(huì)提供很多方式來(lái)避免這種維度的膨脹，見(jiàn)圖 8。

圖8

***個(gè)是聚合組，用戶查詢的時(shí)候不會(huì)所有條件都查，而是同時(shí)只會(huì)出現(xiàn)某幾個(gè)維度，我們就把這幾個(gè)維度定義為一個(gè)聚合組。

比如說(shuō)這里就用了 A、B、C 和 B、C、D，于是只有 A、B、C 內(nèi)部的這些維度和 B、C、D 內(nèi)部維度會(huì)進(jìn)行計(jì)算，而且如果兩個(gè)有交叉，就會(huì)計(jì)算一份。

其他的各種衍生維度、強(qiáng)制維度、層次維度，大家如果做 Kylin 引擎，后續(xù)可以在這塊著重關(guān)注一下，我這邊就不詳細(xì)解釋了。

反正原理都是盡量根據(jù)查詢的一些條件或者業(yè)務(wù)的一些條件，盡量減少要計(jì)算的維度搭配。

02Kylin 改造以及優(yōu)化

我們?cè)?Kylin 里面做了很多改造和優(yōu)化，***個(gè)是 Kylin 默認(rèn)只能在 HBase 中，放在默認(rèn)庫(kù)里面，前綴是 Kylin 加下劃線。

我們?nèi)绻谏厦娌渴鸲嗵篆h(huán)境就會(huì)有沖突，我們這邊修改了一下，讓它支持配置一個(gè)前綴，可以在一套 HBase 中部署多套 Kylin。

我們之前講漏了一件事兒，剛才架構(gòu)圖里面有一個(gè)預(yù)上線的 Kylin，我們所有的，因?yàn)樯暇€前都會(huì)在預(yù)上線的 Kylin 里面進(jìn)行驗(yàn)證，然后只有它的數(shù)據(jù) OK 了以后才會(huì)上到線上，預(yù)上線的環(huán)境。

還有第二個(gè)功能就是雙寫(xiě)，假如一些重要的業(yè)務(wù)，我會(huì)在兩個(gè)集群里邊同時(shí)構(gòu)建。如果主集群先出現(xiàn)問(wèn)題，立馬切到備用集群。我們修復(fù)了它里面的一個(gè)死鎖的問(wèn)題，主要是更新緩存部分，這個(gè)引擎加了社區(qū)。

然后接下來(lái)是一些，比如說(shuō)構(gòu)建的時(shí)候，MR 引擎的一些優(yōu)化，比如開(kāi)啟壓縮等等。Kylin 也是內(nèi)存型的查詢服務(wù)，它是 Java 寫(xiě)的，所以說(shuō)自然 GC 的問(wèn)題，等一下會(huì)詳細(xì)講一下。

如果你使用全局字典，你是要調(diào)大一些 MAP 內(nèi)存。定期會(huì)做 Segment 的合并，清理一些過(guò)期數(shù)據(jù)，減少 HBase Region 個(gè)數(shù)。因?yàn)? HBase 如果 Region Server 太多，壓力非常大。

***還有一個(gè)默認(rèn)使用的授權(quán)的時(shí)候，有個(gè) Byct 加密，這個(gè)非常影響性能。后續(xù)我會(huì)講如何定位這個(gè)問(wèn)題。

03系統(tǒng)性能調(diào)優(yōu)

關(guān)于系統(tǒng)調(diào)優(yōu)給大家推薦一個(gè)工具叫火焰圖，見(jiàn)圖 9?；鹧鎴D是什么呢?它就是一個(gè)可視化的去展示 CPU 占用情況的圖。

圖9

每一個(gè)小方框里面都是一個(gè)函數(shù)，水平方向看它的寬度就是 CPU 的時(shí)間占用，垂直方向看就是一個(gè)函數(shù)的堆棧。下面的函數(shù)就會(huì)調(diào)用上面的函數(shù)。所以自然上面函數(shù)的時(shí)間會(huì)累加到下面函數(shù)中。

如何定位性能的問(wèn)題呢?從下往上看，可以理解成，如果一個(gè)山峰一直沒(méi)有縮短，到最頂層的時(shí)候，調(diào)用堆棧最上面的一個(gè)函數(shù)，那是最終調(diào)用的函數(shù)，如果它占用非常多，一定是它的性能問(wèn)題。

我們之前發(fā)現(xiàn) Kylin 在高并發(fā)的時(shí)候，CPU 會(huì)滿載，非常高，但是查詢非常簡(jiǎn)單。利用火焰圖去分析發(fā)現(xiàn)，它有 80% 的時(shí)間在做一個(gè) Spring 的 Bcybt 加密的驗(yàn)證。然后右邊那一小塊占 4% 的，這個(gè)才是 Kylin 的查詢。

我們查了一下，其實(shí) Bcybt 加密是一個(gè)比較好，相當(dāng)于是比較不容易破解的加密。它的方式就是讓它每次計(jì)算非常耗性能，降低它的速度。

我們將 Bcybt 加密換成了其他加密的算法。大家可以看到，這段(Kylin 查詢部分)就是之前 4% 的時(shí)間，因?yàn)槲野哑渌麜r(shí)間消掉了，所以它的占比就大幅度提升，提升到 40%，提升了大概 1 倍 QPS。

第二塊就是 Java GC。Java 大家應(yīng)該還是比較熟悉的，像傳統(tǒng)的 CMS 非常經(jīng)典，但是它的缺點(diǎn)就是對(duì)于大內(nèi)存回收會(huì)有問(wèn)題，而我們現(xiàn)在線上基本開(kāi)到 80G，甚至 90G，CMS 在這種情況下基本上是 STW 非常長(zhǎng)，可能要達(dá)到幾分鐘。

G1 是 Java ***的垃圾回收算法，它的核心還是保留了 CMS 的分代概念，但是它把每一代分成了很多 Region，打散。G1 定位是暫停時(shí)間可控的 GC，它會(huì)根據(jù)你設(shè)定暫停時(shí)間，在暫停時(shí)間內(nèi)盡可能多地回收內(nèi)存。

因?yàn)榇蛏⒊闪撕芏?Region，我可以不全部回收，我可以回收部分，保證我每次回收的時(shí)間可控。因?yàn)樾律?GC 是發(fā)生非常頻繁的，所以我們要控制新生代的大小，保證每次回收時(shí)間可控。

如下圖，是 GC 調(diào)優(yōu)后的對(duì)比圖，上面是 CMS，下面是 Java。可以看到，GC 頻率和時(shí)間都有大幅地縮短。

第二塊就是我們 Java 的存儲(chǔ)是放在 Hbase 中，HBase 又放在 HDFS 中，HDFS 的底層就是物理上的磁盤(pán)。

我想提升 Java 的查詢性能，從硬件上我就想，現(xiàn)在主流的磁盤(pán) IOPS 可能就幾百，但是現(xiàn)在的 SSD，普通的 SSD 能達(dá)到幾萬(wàn)，像 PCI 組建的 SSD 現(xiàn)在已經(jīng)達(dá)到 30、40 萬(wàn) IOPS。

我們今年年初做了一件事情，我們把 Hadoop 集群從 2.4 升到了 2.7，2.7 里面引入了一個(gè)非常重要的特性，叫異構(gòu)存儲(chǔ)，或叫混合存儲(chǔ)。

就是 Hadoop 支持我把我的磁盤(pán)標(biāo)記一個(gè)標(biāo)簽，支持四種標(biāo)簽。***種叫內(nèi)存磁盤(pán)，第二種叫 SSD，第三個(gè)是普通磁盤(pán)，***一種是歸檔，歸檔是一種性能非常差的磁盤(pán)，可以認(rèn)為，定義了存儲(chǔ)策略。

比如說(shuō) ALLSSD 是指我的所有副本全放在 SSD 中，ONE-SSD 就是放一份，放在 SSD 中。默認(rèn)是 Hot 全部放磁盤(pán)。

我們這邊會(huì)把 HBase 的核心日志，還有核心業(yè)務(wù)都會(huì)放在 ALLSSD 中，對(duì)重要業(yè)務(wù)會(huì)使用 ONE-SSD，如果是普通業(yè)務(wù)放在磁盤(pán)上就行了。

剛才提到，我們?yōu)榱斯?jié)省成本，如果用 SSD 也是主要用 ONE-SSD。ONE-SSD 有一個(gè)問(wèn)題，假如說(shuō)這個(gè)客戶端讀取數(shù)據(jù)，我有三個(gè)備份。

其中一個(gè)是 SSD，但是我本地的副本是一個(gè)機(jī)械磁盤(pán)，默認(rèn)的社區(qū)版會(huì)優(yōu)先讀取本地，因?yàn)樗南敕ň褪蔷W(wǎng)絡(luò)延遲是比較高的。

但實(shí)際上我們鏈家大數(shù)據(jù)已經(jīng)全部是萬(wàn)兆的架構(gòu)，所以說(shuō)網(wǎng)絡(luò)瓶頸已經(jīng)是不存在的。我們這里給它定制了一個(gè) First 選擇策略，叫 SSD-FIRST。

就是如果我遠(yuǎn)程有 SSD，我還是優(yōu)先使用遠(yuǎn)程的。后面會(huì)給一個(gè)對(duì)比數(shù)據(jù)，這個(gè)已經(jīng)提交給社區(qū)。

圖10

圖10 是一個(gè) HBase 就是讀寫(xiě)分離。HBase 默認(rèn)所有隊(duì)列和處理線程實(shí)際上是不區(qū)分的，我查詢請(qǐng)求分 Scan、Get、Write，三種請(qǐng)求都會(huì)打到相同的隊(duì)列里面。

如果出現(xiàn)了 Scan，把所有隊(duì)列和線程都堵滿了以后，簡(jiǎn)單的小查詢都會(huì)卡住。這個(gè)是 HBase 在 1.2，還是 1.3 的時(shí)候已經(jīng)實(shí)現(xiàn)了，我們可以把隊(duì)列和線程按照比例去分配給 Scan、Get、Write 三種請(qǐng)求，避免 Scan 請(qǐng)求阻塞小請(qǐng)求。

圖11

圖 11 是我們 HBase 的測(cè)試數(shù)據(jù)。大概是三臺(tái)機(jī)器，使用 ONESSD 測(cè)試工具。我們就關(guān)注綠色這條線，這條線就是吞吐量，或者叫 QPS 。

最右邊是 HDD，當(dāng)我們使用 ONE-SSD 以后，大概能提升 4 倍左右的吞吐。我們?cè)僮饔?，上線 SSD-FIRST 策略以后，又能提升一倍的吞吐。

***在上線讀寫(xiě)分離以后又能提升一倍，整體提升的大概 10 多倍。而且只有***步是需要硬件成本的，后面的兩個(gè)策略都是純策略上的調(diào)整。

圖12

如圖 12 還有很多常見(jiàn)的一些優(yōu)化項(xiàng)，我這邊就不詳細(xì)解釋了，主要是針對(duì) Hadoop 的一些讀寫(xiě)優(yōu)化。

下面講一些操作系統(tǒng)常見(jiàn)的一些調(diào)優(yōu)。首先給大家講一個(gè)最常見(jiàn)的命令 Free，運(yùn)行出來(lái)能顯示當(dāng)前內(nèi)存的情況。

我這里寫(xiě)了三種境界，***種是剛接觸 Linux 同學(xué)，F(xiàn)ree 是 0，是不是內(nèi)存不夠了，是不是感覺(jué)要掛。經(jīng)過(guò)一段時(shí)間學(xué)習(xí)，發(fā)現(xiàn) Cache，Buffer 都是可以拿來(lái)用的，看第二行， Free 是 4G，內(nèi)存什么問(wèn)題都沒(méi)有。真正老司機(jī)是什么樣的呢?

我們要知道 Cache 是用來(lái)干什么的，使用的***率如何，Cache 是干什么的，Cache 默認(rèn)就是 Page Cache，就是頁(yè)面緩存，主要是為了緩存文件系統(tǒng)，它在 VFS 里面會(huì)用到的。然后一般的 Cache 都是可以釋放出來(lái)給程序使用的。

但是有一種情況 Cache 不能釋放。就是有一種文件系統(tǒng)叫 tempfs，相當(dāng)于內(nèi)存的一個(gè)文件系統(tǒng)，利用了 Page Cache 的空間來(lái)做存儲(chǔ)，這種數(shù)據(jù)是沒(méi)法被清掉的。

所以 Cache 并不是所有的可以用。如果拿來(lái)做文件緩存，本身操作系統(tǒng)這么設(shè)計(jì)一定是有它的作用，我們想知道這個(gè)緩存***率如何。

我看了一下網(wǎng)上各種工具，實(shí)際上沒(méi)有一個(gè)對(duì)緩存***率計(jì)算的方法。還是剛才提到做火焰圖那哥們，在他的博客上公布了一個(gè)利用 ftrace 的方案，原理非常簡(jiǎn)單。

***率我們現(xiàn)在算 100%-Miss 的概率，Miss 是什么情況呢?Miss 的分母就是 Page 的訪問(wèn)次數(shù)，分子是，如果發(fā)生了 Misses，我就會(huì)把它從磁盤(pán)上讀出來(lái)，再放到緩存中。所以說(shuō)分子就是添加到 Page 緩存的一個(gè)次數(shù)。

我們這邊因?yàn)?ftrace 會(huì)在系統(tǒng)上有問(wèn)題，我用 System Tap 把腳本改寫(xiě)了一下，著重是四個(gè)系統(tǒng)的調(diào)用。

System Tap 就是一個(gè)動(dòng)態(tài)跟蹤技術(shù)，它可以在內(nèi)核任何一個(gè)函數(shù)上動(dòng)態(tài)去注入一段代碼，然后可以規(guī)定在函數(shù)運(yùn)行前或者是運(yùn)行后，我們這里只是給了四個(gè)過(guò)濾器，就是在四個(gè)條件上面做了過(guò)濾。

下面大家看一下 Total，里面***項(xiàng)叫 Mark Page Accessed，就是頁(yè)面訪問(wèn)次數(shù)，Miss 的***項(xiàng)就是添加到 LRU 緩存的一個(gè)次數(shù)。后面減掉的一部分是什么呢?

大家知道，頁(yè)面緩存除了去讀的時(shí)候用到，寫(xiě)的時(shí)候也會(huì)用到。任何一次寫(xiě)入都會(huì)寫(xiě)入到 Page 中。有時(shí)候我們要從分子分母中把寫(xiě)入的那部分?jǐn)?shù)據(jù)給減掉。

我們會(huì)把 Cache 的***率定期同步到我們里面做監(jiān)控。我們線上現(xiàn)在應(yīng)該能達(dá)到 70%-90% 的***率。據(jù)我們的試驗(yàn)，一般在 60% 以上，HBase 會(huì)比較穩(wěn)定，因?yàn)?HBase 對(duì)于 IO 性能要求非常高。

如果 Cache ***率非常高，實(shí)際上每次讀寫(xiě)都會(huì)非常快。當(dāng)然這個(gè)也跟業(yè)務(wù)有關(guān)系。如果你的查詢是非常隨機(jī)的話，這個(gè)緩存也很容易被弄臟。

下面講一個(gè)比較大的坑：NUMA。現(xiàn)在大家的服務(wù)器基本上都是多個(gè) CPU，常見(jiàn)的有兩種架構(gòu)，一種叫 SMP，對(duì)稱多處理。內(nèi)存其實(shí)是跟 CPU 之間連著一根總線，它的問(wèn)題就是隨著CPU 越來(lái)越多，內(nèi)存越來(lái)越大，所有的瓶頸都?jí)涸诳偩€上。

接下來(lái)英特爾公司就想到另一個(gè)方案，就是每個(gè) CPU 給它分配專屬的內(nèi)存，這個(gè) CPU 的專屬內(nèi)存訪問(wèn)速度非?？?。

現(xiàn)在內(nèi)存非常大，每個(gè)地方的專屬內(nèi)存應(yīng)該是足夠的，如果我實(shí)在是需要遠(yuǎn)程內(nèi)存，我再走主線。默認(rèn)是一個(gè)親和模式，什么意思呢?就是我這個(gè) CPU 分配的內(nèi)存和淘汰的內(nèi)存都會(huì)優(yōu)先從我的專屬內(nèi)存中來(lái)找。

比如說(shuō)我專屬內(nèi)存不夠用了，我就會(huì)優(yōu)先從我專屬內(nèi)存里去淘汰。這樣會(huì)導(dǎo)致一個(gè)問(wèn)題，我系統(tǒng)看系統(tǒng)非常充足，但是我發(fā)現(xiàn)有 SWAP 占用，我的 Java 在做 GC。這個(gè)就非常奇怪，就是因?yàn)槟J(rèn)的親和模式造成的。

這個(gè)親和模式實(shí)際上對(duì)小內(nèi)存應(yīng)用非常好的，因?yàn)槲乙豢?CPU 內(nèi)存其實(shí)也很大了，至少 64G、128 個(gè) G 都有，因?yàn)榭偣部赡?256、512。

單個(gè)小內(nèi)存應(yīng)用內(nèi)存是足夠的，但是像 HBase 或者說(shuō)數(shù)據(jù)庫(kù)，我們現(xiàn)在可以到 80G，甚至 100G，實(shí)際上單個(gè) CPU 的專屬內(nèi)存是不夠用的。

我們這兒主要做了一個(gè)調(diào)整策略，就是把它的分配參數(shù)調(diào)整了一下。如果專屬內(nèi)存不夠的時(shí)候，我允許從其他地方獲取內(nèi)存，而不是去做本地的回收。

***一個(gè)也是比較大的一個(gè)坑，就是透明大頁(yè)。什么是透明大頁(yè)呢?大家知道，現(xiàn)在操作系統(tǒng)都是分頁(yè)的，每一個(gè)程序有一個(gè)頁(yè)表。

程序分配都是邏輯地址，它要真的訪內(nèi)存要通過(guò)一次邏輯地址到物理地址映射，然后 TLB 是用來(lái)做一個(gè)加速的，現(xiàn)在默認(rèn)的大小是 4K，隨著內(nèi)存越來(lái)越大就會(huì)有問(wèn)題，頁(yè)表會(huì)越來(lái)越長(zhǎng)，TLB 緩存***率也會(huì)降低。

操作系統(tǒng)想到一個(gè)方式，我就把配置調(diào)大，就給了兩個(gè)選項(xiàng)，一個(gè)是 2M，***可以開(kāi)到 1G。

這樣看起來(lái)非常***，但是在 6.5 的 centOS 中，這個(gè)大頁(yè)是默認(rèn)開(kāi)啟的，但是我們會(huì)發(fā)現(xiàn) HBase 在使用過(guò)程中，CPU 占用會(huì)非常異常，System Tap CPU 會(huì)非常高。

大家可以看，JVM 的使用才 24%，但是我內(nèi)核達(dá)到 32%，我們用 Perf 工具來(lái)做這個(gè)實(shí)時(shí)采樣，你會(huì)發(fā)現(xiàn) Kernel 會(huì)發(fā)生在一個(gè)自選鎖上，自選鎖里面是什么呢?你就能看到，會(huì)做一個(gè)異名的一個(gè)大頁(yè)內(nèi)存分配。

這個(gè)就會(huì)造成在系統(tǒng)非常繁忙的時(shí)候，內(nèi)核的 CPU 占用非常高。然后我們做了一個(gè)測(cè)試，在開(kāi)啟透明大頁(yè)和關(guān)閉透明大頁(yè)，看藍(lán)色和紅色的線。

在開(kāi)啟透明大頁(yè)的功能以后，就是 Always 這個(gè)選項(xiàng)下，它的性能有很多毛刺，性能總體會(huì)下降 30%- 40%。

所以說(shuō)我們推薦把透明大頁(yè)關(guān)閉，當(dāng)然操作系統(tǒng)還有很多其他的一些選項(xiàng)，這邊就不詳細(xì)說(shuō)了，比如說(shuō)文件數(shù)限制，關(guān)閉 SWAP ，TCP 這一塊。

[[204920]]

鄧鈁元

鏈家網(wǎng)大數(shù)據(jù)資深研發(fā)工程師

2015 年開(kāi)始負(fù)責(zé)鏈家大數(shù)據(jù)集群建設(shè)，專注于 Hadoop 生態(tài)組的定制開(kāi)發(fā)及應(yīng)用，深入 Hadoop/HBase 等源碼，成為 contributor 回饋社區(qū)。擅長(zhǎng)底層性能調(diào)優(yōu)，打造公司級(jí)計(jì)算存儲(chǔ)平臺(tái)。