編者按

2020 年 6 月 11 日合搅，神策數(shù)據(jù)舉辦了我們的第一場技術(shù)直播”崦剑現(xiàn)場神策基礎(chǔ)研發(fā)部的負(fù)責(zé)人張倩瓊老師主講了《數(shù)據(jù)建模與存儲選型》粉私。

大數(shù)據(jù)技術(shù)是神策的根本，數(shù)據(jù)建模是神策產(chǎn)品得以成功的第一步壁顶。倩瓊老師的這個講座珠洗，誠意滿滿，討論了幾種不同的技術(shù)架構(gòu)具體的差異和特色若专。以下內(nèi)容许蓖，根據(jù)倩瓊老師的現(xiàn)場錄音整理而成。

▼▼▼

大家好富岳，我是神策數(shù)據(jù)的架構(gòu)師張倩瓊蛔糯。很高興今天晚上在這里和大家分享《數(shù)據(jù)建模與存儲選型》拯腮。首先我會從我自身的職業(yè)經(jīng)歷來介紹一下我所經(jīng)歷的數(shù)據(jù)模型的變遷窖式。其次會介紹數(shù)據(jù)建模相關(guān)的內(nèi)容以及 etl 相關(guān)的事情。再次對于各類數(shù)據(jù)动壤，我們?nèi)绾巫龃鎯x型萝喘。最后我會介紹神策在存儲選型上的考慮。順便說一下琼懊，今天提到的數(shù)據(jù)特指用戶行為數(shù)據(jù)阁簸。

一、數(shù)據(jù)模型的典型方案

1哼丈、第一代數(shù)據(jù)模型

首先启妹，這里所說的模型分代并不是行業(yè)共識，而是從我自身的職業(yè)經(jīng)歷出發(fā)醉旦，所做的一個模型劃分饶米。

08 年，我加入了騰訊的搜索部門车胡，我們小組正好負(fù)責(zé)騰訊的 10 型日志檬输。10 型日志是騰訊搜搜網(wǎng)頁搜索產(chǎn)生的用戶行為日志。數(shù)據(jù)模型非常簡單匈棘，主要描述哪里的用戶在什么時間搜索了哪些關(guān)鍵詞丧慈。其元數(shù)據(jù)也非常簡單，直接將字段固化在程序當(dāng)中主卫，字段之間采用 \t 分隔逃默，日志量也比較少鹃愤，每天只有幾十 GB，單機(jī)存儲就夠了完域。

我們保留最近三天的日志昼浦，過期數(shù)據(jù)壓縮存儲。通過自制的類 SQL 的單機(jī)引擎 LogScan筒主，依據(jù) Lex 和 Yacc 來做詞法語法分析关噪。數(shù)據(jù)應(yīng)用也非常簡單，主要供產(chǎn)品經(jīng)理 來統(tǒng)計 PV乌妙、UV使兔，甚至一些簡單的數(shù)據(jù)挖掘，如我當(dāng)時正好依據(jù) 10 型日志來做相關(guān)推薦藤韵，用戶在一段時間內(nèi)連續(xù)搜索了幾個關(guān)鍵詞虐沥，那么可以依據(jù)他搜索的這幾個關(guān)鍵詞來推斷他當(dāng)前興趣。并依據(jù)興趣來做相關(guān)搜索推薦泽艘，以吸引用戶點擊欲险，進(jìn)而縮短搜索路徑，提升搜索效率匹涮。

第一代數(shù)據(jù)模型的痛點或者說缺點很明顯：

• 字段固化天试，當(dāng)日志格式有變，需要數(shù)據(jù)處理程序也做相應(yīng)改動然低；

• 存儲結(jié)構(gòu)自定義喜每，沒有很好的查詢引擎去支撐；

• 數(shù)據(jù)按天存儲雳攘，只能按天做這種 PV带兜、UV 統(tǒng)計，不能做跨天的復(fù)雜分析吨灭；

• 擴(kuò)展性也不好刚照，因為它只是針對搜索產(chǎn)品特殊設(shè)計的日志格式，其它各類產(chǎn)品喧兄，要想擴(kuò)展上去并不容易无畔。

2、第二代數(shù)據(jù)模型

再說第二代數(shù)據(jù)模型繁莹。我 12 年 10 月加入百度檩互，13 年有幸參與到百度的 UDW 建設(shè)。UDW 的舞臺比當(dāng)年騰訊的搜索產(chǎn)品大得多咨演，它面向百度全公司的數(shù)據(jù)平臺闸昨，百度所有業(yè)務(wù)線的數(shù)據(jù)，都會匯集到 UDW。數(shù)據(jù)模型更復(fù)雜饵较，有了 event 的概念拍嵌，在描述上更加的泛化。符合 4W1H 模式：某個人在什么時間什么地點以什么樣的方式干了什么樣的事循诉，都可以用 event 來描述横辆。它的 schema，是公司內(nèi)部開發(fā)的 dt-meta茄猫，可以看作是類似 Hive Metastore 的元數(shù)據(jù)管理系統(tǒng)狈蚤。因為 UDW 面向全公司，數(shù)據(jù)量非常大划纽，每天的數(shù)據(jù)量在數(shù)百 TB 上下脆侮。存儲系統(tǒng)基于開源的 HDFS，查詢引擎基于 Hive勇劣，做了二次開發(fā)并進(jìn)行了服務(wù)化封裝靖避。我們主要將 UDW 作為基層數(shù)據(jù)，供上層的各類分析使用比默。

第二代數(shù)據(jù)模型已經(jīng)比較完備幻捏，但是也有缺點。大部分來自于歷史包袱命咐，如百度的多數(shù)業(yè)務(wù)線篡九，日志沒有統(tǒng)一規(guī)劃，將它們導(dǎo)入到 UDW 并不是一件容易的事情侈百。需要建立一個格式化的中間層瓮下，再從固定的中間層導(dǎo)入數(shù)據(jù)到 UDW翰铡，這兩個鏈條都非常復(fù)雜钝域，實時性并不好。百度天然無賬號锭魔，所以用戶數(shù)據(jù)是有缺失的例证。雖然這里我們可以通過 ID 來描述一個人，但是卻很難去精準(zhǔn)地定位這個人迷捧。雖然百度也一直在嘗試建立用戶體系织咧，還通過各種手段自建了用戶屬性服務(wù)——UPS，但是它和 UDW 的結(jié)合其實并不好漠秋。

3笙蒙、第三代數(shù)據(jù)模型

再看第三代數(shù)據(jù)模型，這是 15 年神策創(chuàng)立以來庆锦，一直采用的 user-event 模型捅位，它的 scheme 存放于基于 MySQL 的 meta 服務(wù)。存儲系統(tǒng)除了上面介紹到的 HDFS，還引入了 Kudu艇搀。查詢引擎選擇了 Impala尿扯。神策內(nèi)部的各類產(chǎn)品，都是基于這一套用戶行為數(shù)據(jù)倉庫焰雕。

二衷笋、數(shù)據(jù)建模

接下來是數(shù)據(jù)建模。這里是針對用戶行為數(shù)據(jù)來說的矩屁。數(shù)據(jù)模型就像一個分層的金字塔辟宗，可以分為原始數(shù)據(jù)層、結(jié)構(gòu)化數(shù)據(jù)層吝秕、實體層慢蜓、數(shù)據(jù)集市層和數(shù)據(jù)智能層。數(shù)據(jù)量從底向上逐層減少郭膛，信息聚合與匯總的程度逐層提高晨抡。一般公司，業(yè)務(wù)日志多數(shù)都會采集则剃，但對于上層的支持普遍是缺失的耘柱。

1、原始數(shù)據(jù)層

原始數(shù)據(jù)層棍现，主要是剛才所說的采集的用戶最原始的行為日志调煎，還包括一些數(shù)據(jù)庫的原始表等等。這一層通常是非結(jié)構(gòu)化的己肮。一般不會對外提供訪問服務(wù)士袄，僅用于追溯問題或恢復(fù)數(shù)據(jù)等一些特殊場景。

2谎僻、結(jié)構(gòu)化數(shù)據(jù)層

結(jié)構(gòu)化數(shù)據(jù)層娄柳，可以依據(jù)原始數(shù)據(jù)層來建立，它和原始日志同一數(shù)量級艘绍，但因為是格式化的赤拒，存儲數(shù)據(jù)量會少一些。因為這一層很貼近原始數(shù)據(jù)層诱鞠，我們通常不會在其上做復(fù)雜的 ETL 處理挎挖。這一層一般也不會對外提供直接的數(shù)據(jù)訪問，而是作為長期的結(jié)構(gòu)化備份存在航夺。

原始數(shù)據(jù)層和結(jié)構(gòu)化數(shù)據(jù)層很接近蕉朵，它們并存主要是由于，在企業(yè)的既有成熟業(yè)務(wù)中阳掐，日志多數(shù)沒有什么格式始衅。需要我們抽象出一層結(jié)構(gòu)化數(shù)據(jù)層堪伍。這樣，再往上的數(shù)據(jù)建設(shè)觅闽，可以從結(jié)構(gòu)化數(shù)據(jù)層得到數(shù)據(jù)帝雇。因為數(shù)據(jù)本身格式統(tǒng)一，可以使用大規(guī)模的并行 ETL 框架來處理蛉拙，會極大增加轉(zhuǎn)換效率尸闸。

如果直接從原始數(shù)據(jù)層來轉(zhuǎn)換數(shù)據(jù)到實體層，那么首先面臨一個困難：各個業(yè)務(wù)的數(shù)據(jù)格式不一致孕锄，每類數(shù)據(jù)都需要特殊處理吮廉。如將轉(zhuǎn)換任務(wù)下發(fā)給各個業(yè)務(wù)層，不只是在在效率上畸肆，在安全上也存在極大的問題宦芦。對某一特定業(yè)務(wù)，他們的日志格式可能變動不頻繁轴脐。但當(dāng)我們放眼全公司時调卑，因為有非常多的業(yè)務(wù)，那么對于日志格式的變動大咱，就是一個常態(tài)了恬涧。直接從原始數(shù)據(jù)層抽取數(shù)據(jù)，也不利于應(yīng)對這種變化碴巾。新業(yè)務(wù)可以直接打結(jié)構(gòu)化日志溯捆，就少了原始數(shù)據(jù)層到結(jié)構(gòu)化數(shù)據(jù)層的轉(zhuǎn)化處理，加快數(shù)據(jù)處理效率厦瓢。

結(jié)構(gòu)化數(shù)據(jù)層的存儲格式有一個推薦方案—谷歌開源的 Proto Buffer提揍，它的優(yōu)點是支持多語言，且非常輕便高效煮仇。另外劳跃，向前、向后的兼容性也比較好欺抗，可以比較方便地去應(yīng)對用戶日志格式的變更問題售碳。主要缺點是它不像 json 一樣肉眼可讀，需要自己編寫維護(hù)工具绞呈。

3、實體層

實體層非常重要间景，它的數(shù)據(jù)量與原始日志在同一數(shù)量級佃声，但是存儲更高效。這一層要經(jīng)過比較完整的 ETL 處理倘要，使其直接為上層應(yīng)用服務(wù)圾亏，如用戶畫像十拣、個性化推薦等等，可以直接由這一層提供訪問服務(wù)志鹃。這一層的數(shù)據(jù)建模也最重要夭问。我們常見的典型模型—星型模型、雪花模型和星系模型曹铃，都是針對這一層的建設(shè)缰趋。如何選擇事實表、維度表陕见，就是這一層要重點解決的問題秘血。

以互聯(lián)網(wǎng)產(chǎn)品的用戶分析為例。套用神策的 User-Event 模型评甜，我們可以以 Event 為核心灰粮，適當(dāng)?shù)財U(kuò)展維度表。

Event 本質(zhì)上是已發(fā)生的事情忍坷，理論上不可變粘舟。但是用戶的很多屬性是可變的，比如說用戶的年齡會隨著自然年的增長而增長佩研，用戶的地域蓖乘，確切地說是用戶的住址，可能會隨著工作的變遷或者搬家等也有所變動韧骗，甚至用戶的性別嘉抒，也可能因變性改變。所以這里將 User 表獨立出來袍暴，作為一張?zhí)厥獾木S度表些侍。

除了用戶屬性，還有一些特殊屬性也要求可變政模，這里的可變不是說已經(jīng)發(fā)生的歷史事件產(chǎn)生了變更岗宣，而是在我們的采集過程中，有些屬性我們當(dāng)時采集不到淋样，或者有些屬性就是隨時間變化而變化的耗式。這時，就可以通過維度表擴(kuò)展趁猴。例如商品信息刊咳，像商品庫存、價格等儡司，是經(jīng)常變動的娱挨，不適合固化在事件表里，而應(yīng)該存放于擴(kuò)展的維度表捕犬。對于其他不變的維度(屬性)跷坝，最好的方式就是將它放到事件表酵镜。這樣，行為分析時柴钻，可以避免過多的數(shù)據(jù) join淮韭，以提升分析效率。通過事件表贴届、用戶表以及擴(kuò)展維度表這三者的 join靠粪，可以滿足絕大多數(shù)用戶行為分析需求。

對于用戶行為表粱腻，一條記錄描述的是一個用戶做了什么庇配，比如說在什么時間，哪個用戶（用戶 ID）绍些，發(fā)生了什么事情（Event Type）捞慌，然后再是一些詳細(xì)信息。例如柬批，按時間序列來說啸澡，用戶 123 通過百度渠道注冊了我們的產(chǎn)品；之后在另一個時間氮帐，用戶 123 進(jìn)行 app 登錄嗅虏；之后，用戶 123 搜索了 iPad上沐；最后用戶 123 以 4888 的價格支付了訂單皮服。大家可以看到，這張表非常容易地還原了當(dāng)時用戶 123 的操作場景参咙。剛才也說了龄广，用戶行為表被設(shè)計成了不可變的，再加上這部分?jǐn)?shù)據(jù)量非常大蕴侧，所以這部分?jǐn)?shù)據(jù)以追加為主择同，輔之以有限的修改和刪除。之后在存儲上净宵，我們也會依據(jù)這個特點來做適合它的存儲選型敲才。

對于用戶 123，除了用戶 ID 外择葡，還有性別紧武、注冊渠道、會員等級等等屬性刁岸。我們將這些數(shù)據(jù)放到用戶表里面脏里，它的一個特點是屬性會隨時變化，另外虹曙，相對于用戶行為表來說迫横，數(shù)據(jù)量會極大的下降。比如說現(xiàn)在全世界的人口也只有 60 多億酝碳。即使一個用戶有多個馬甲矾踱，用戶表能達(dá)到千億量級，也已經(jīng)相當(dāng)也不起了疏哗∏航玻基于這種特點，數(shù)據(jù)量相對有限返奉，但經(jīng)常修改贝搁。存儲選型上，這就是它的重點考量芽偏。

回到剛才的數(shù)據(jù)金字塔雷逆，針對實體層，我們簡化后的數(shù)據(jù)模型就變成了用戶行為表和用戶表污尉。這個數(shù)據(jù)模型非常簡單膀哲，那么原始日志層和結(jié)構(gòu)化數(shù)據(jù)層其實都可以省掉，或者結(jié)構(gòu)化日志我們不省略被碗，通過實時導(dǎo)入工具某宪，將它加載到用戶行為表和用戶屬性表中去。我們也可以通過代碼埋點的方式锐朴，實時上報用戶行為數(shù)據(jù)兴喂。它足夠簡單，可以做到秒級導(dǎo)入焚志，也可以滿足各種各樣的分析需求衣迷。

ETL 是不可不提的一個事情。顧名思義娩嚼，它是對數(shù)據(jù)的抽取蘑险、轉(zhuǎn)化和加載。這里有幾個事情要做岳悟，比如數(shù)據(jù)校驗和清洗佃迄，主要是要過濾掉無效的數(shù)據(jù)，用干凈的數(shù)據(jù)來替換一些臟數(shù)據(jù)等等贵少；如加列補列呵俏，拿 UA 字段來說，可以從中解析出用戶使用的設(shè)備滔灶，采用的瀏覽器等等普碎。也可以從 IP 字段中解析出一些地理信息，如用戶所在的省市等录平。這里也需要補充一些通過正常采集沒能采集到的信息麻车，如一些字典數(shù)據(jù)缀皱，需要通過 ETL 將其補充到事件信息中。

當(dāng)然假如果這些字典數(shù)據(jù)經(jīng)常變動的动猬，它就適合作為一個維度數(shù)據(jù)啤斗，放在 item 表中；再就是脫敏處理赁咙，對于一些數(shù)據(jù)钮莲，比如用戶的隱私數(shù)據(jù)，像生日彼水、身份證號等等崔拥，還有一些用戶敏感的信息，比如一些消費記錄凤覆、通訊記錄等等链瓦，這些數(shù)據(jù)是需要做脫敏處理的；ID-Mapping 是這個階段一個非常重要的功能叛赚，它可以跨屏貫通一個用戶澡绩。在現(xiàn)今移動互聯(lián)網(wǎng)時代，同一個用戶是擁有多個設(shè)備的俺附，那么他可能在多個設(shè)備上去操作同一個產(chǎn)品肥卡，ID-Mapping 就是將用戶在多設(shè)備上的行為序列，關(guān)聯(lián)在一起事镣，作為一個完整的序列展示出來步鉴。

這兒有一些經(jīng)驗教訓(xùn)要同步給大家：

一、數(shù)據(jù)模型要盡量簡潔璃哟，模型簡潔 ETL 才會簡單高效氛琢，才會做到更快速的導(dǎo)入。

二随闪、不到萬不得已阳似，要盡量避免 join 操作。大家都知道 join 操作是一個非常昂貴的操作铐伴，在上層分析的時候撮奏，join 會極大地降低 ETL 效率牢酵。因此我們神策的事件表中攻臀，包含了各種不變的維度。如必須要進(jìn)行 join 管钳，那么就盡早户矢，越早 join玲献，后面的處理也就越容易。

3、數(shù)據(jù)集市層

數(shù)據(jù)集市層的數(shù)據(jù)量就非常小了捌年，比原始日志至少小一個數(shù)量級瓢娜，甚至多個數(shù)量級。它的數(shù)據(jù)來自數(shù)據(jù)倉庫實體層延窜，偶爾也會有部分?jǐn)?shù)據(jù)基于格式化數(shù)據(jù)層恋腕。這里一般都是針對一些特定的主題或者一些部門的聚合數(shù)據(jù)抹锄。因為這一層的數(shù)據(jù)量大大減少逆瑞，信息聚合程度又大大豐富，所以數(shù)據(jù)的主要訪問需求伙单，都應(yīng)由這一層滿足获高。以商品信息庫為例，應(yīng)該包含商品的進(jìn)貨量吻育、庫存量念秧、銷量、利潤等等信息布疼，作為一個聚合表存在摊趾。這張聚合表有可能作為上層實體層的一個商品維度表，以實體層來提供服務(wù)游两。

4砾层、數(shù)據(jù)智能層

最后再說數(shù)據(jù)智能層，這一層比原始日志的數(shù)據(jù)量少多個數(shù)量級贱案。它的數(shù)據(jù)來自數(shù)據(jù)倉庫層和數(shù)據(jù)集市層肛炮。這一層通常是為滿足特定的應(yīng)用，采用專有算法得到宝踪，一般直接供在線服務(wù)使用侨糟。

這里舉兩個例子：

一、多維數(shù)據(jù)瘩燥，是按照維度和指標(biāo)進(jìn)行了一些聚合計算的結(jié)果數(shù)據(jù)秕重，用來滿足多維分析需求。多維數(shù)據(jù)有兩種存儲方式厉膀，具體選擇哪一種還是要根據(jù)具體的業(yè)務(wù)來溶耘，這一塊后面會專門講到。

二站蝠、用戶畫像數(shù)據(jù)汰具，它描述了每個用戶的一些自然屬性、以及長期興趣和短期興趣等等菱魔。用戶畫像留荔，主要是滿足個性化推薦等一些個性化的數(shù)據(jù)應(yīng)用需求。用戶畫像數(shù)據(jù)，它也描述了用戶的自然屬性聚蝶，它和事件模型中的 User 表區(qū)別在于杰妓，user 表主要是包含用戶自然屬性，如用戶的年齡碘勉、用戶的住址巷挥。而畫像數(shù)據(jù)，還包括我們挖掘出的標(biāo)簽验靡、興趣倍宾。比如我們根據(jù)用戶的一些行為歷史，可以分析出用戶喜好胜嗓。像這個人喜歡看什么樣的電影高职，喜歡哪類體育運動等等。然后在業(yè)務(wù)上辞州，我們就可以根據(jù)他的興趣愛好去做個性化推薦怔锌。

三、數(shù)據(jù)存儲的選型

1变过、行存儲和列存儲

再說數(shù)據(jù)存儲的選型埃元。數(shù)據(jù)存儲主要分行存儲和列存儲。它們的特性非趁恼互補岛杀。例如行存儲寫入效率非常高，列存儲寫入效率就非常低哈雏；行存儲的壓縮率比較低楞件，列存儲的壓縮率卻很高；再說掃描裳瘪，行存儲的讀取掃描的效率非常低土浸，但列存儲在這上面的效率非常高；對于一些有修改需求的記錄彭羹，選擇行存儲非常方便黄伊，但相對應(yīng)的，基于列存儲的修改非常困難派殷。

將數(shù)據(jù)看作一個矩陣的話还最，列存恰恰是行存的轉(zhuǎn)置，一個完整的記錄行毡惜，在列存中會分散到各個列文件拓轻。因為每一列都是同屬性的數(shù)據(jù)，數(shù)據(jù)高度同質(zhì)化经伙，列存的壓縮率會非常高扶叉。寫入效率上，數(shù)據(jù)應(yīng)用都是按行產(chǎn)生的，但在使用列存時枣氧，需要打散到各個列文件中溢十。寫一條記錄會涉及到非常多的列文件，效率自然就不高达吞。再說掃描效率张弛，主要是針對分析場景，數(shù)據(jù)分析一般是不會用到全部列酪劫，如只關(guān)注最感興趣的幾個列吞鸭，那么在列存上使用列裁剪，數(shù)據(jù)量少了契耿，掃描效率就上去了瞒大，當(dāng)然要做全量數(shù)據(jù)掃描，列存不一定比行存效率高搪桂。在列存中，要想修改一條記錄盯滚，可能會涉及非常多的列文件踢械，這不僅加大了修改難度，也很難保證事務(wù)性魄藕。

根據(jù)剛才的介紹内列，行存特別適合基于事務(wù)的應(yīng)用，而列存就比較適合分析類的應(yīng)用背率。文本格式话瞧，還有 Hadoop上 的 Sequence File、Avro 等寝姿，都是比較典型的行存格式交排。列存中比較有名的有 Parquet 和 ORCFile。當(dāng)時百度的 UDW 就是基于 ORCFile饵筑。神策基于 Parquet埃篓，這跟我們選取的查詢引擎和存儲引擎有關(guān)。

2根资、各層數(shù)據(jù)的存儲選型

下面說一下各層數(shù)據(jù)的存儲選型架专。

原始數(shù)據(jù)層，主要是文本的原始日志玄帕，數(shù)據(jù)量非常大部脚，所以比較適合使用廉價的大型行存儲，比如 hdfs 來存放裤纹。

結(jié)構(gòu)化數(shù)據(jù)層委刘，它雖然是二進(jìn)制的數(shù)據(jù)格式，但是為了比較快速地追加寫，仍然優(yōu)選行存钱雷，它的數(shù)據(jù)量和原始數(shù)據(jù)層相當(dāng)骂铁，HDFS 依然是這層最好的選擇。

實體層主要服務(wù)上層業(yè)務(wù)罩抗，面對各類分析需求拉庵，列存非常適合。在這一層套蒂，像 Adhoc 的即時查詢需求钞支，我們一般會通過 SparkSQL 或 Impala 這類高效工具；一些比較復(fù)雜的數(shù)據(jù)應(yīng)用需求操刀，可能需要寫一些比較復(fù)雜的算法烁挟，又或者數(shù)據(jù)量非常巨大，那么我們可以使用 Hive 或者 MapReduce骨坑。

對于數(shù)據(jù)集市層和數(shù)據(jù)智能層撼嗓，如主題數(shù)據(jù)，也主要是為了分析類需求欢唾，可以采用和實體層一樣的存儲方案且警；對于用戶畫像數(shù)據(jù)，它可能會用到各類業(yè)務(wù)礁遣，甚至在線業(yè)務(wù)中（比如實時推薦）斑芜，對訪問時延及吞吐有更高的要求。

我們可以在計算完成后祟霍，導(dǎo)入到實時表現(xiàn)更好存儲系統(tǒng)中杏头，如 Hbase 或其它的 KV 存儲系統(tǒng)；而對于多維數(shù)據(jù)沸呐，我們需要依據(jù)實際的需求選擇存儲方案醇王。這里面有 MOLAP 和 ROLAP 兩種。MOLAP 需要預(yù)先定義好一些維度和指標(biāo)垂谢，并且完成相應(yīng)的聚合運算厦画。它的優(yōu)點是查詢速度非常快滥朱，并發(fā)也比較高根暑，存儲占用的空間也很小，適合在線業(yè)務(wù)徙邻。但它也有一個非常大的缺點：因為它是預(yù)計算的排嫌，所以調(diào)整維度或指標(biāo)時，非常不靈活缰犁。假設(shè)維度或指標(biāo)變了淳地，需要一個很長時間的重新裝載過程怖糊；另外，它的實時性比較差颇象，這也是因為經(jīng)過預(yù)計算伍伤，無法從明細(xì)數(shù)據(jù)中直接得到相應(yīng)的結(jié)果。

現(xiàn)在開源界的 Kylin 和 Druid 都是比較優(yōu)秀的 MOLAP 方案遣钳。而對于關(guān)系型 ROLAP扰魂，它在查詢時可以從最細(xì)粒度的明細(xì)數(shù)據(jù)做聚合運算，MOLAP 的優(yōu)點恰恰就是它的缺點蕴茴，如它在查詢速度上一般會比 MOLAP 慢至少一個量級劝评，并發(fā)也比較差。但是它的優(yōu)點也非常明顯倦淀，維度和指標(biāo)非常靈活蒋畜，可以滿足非常靈活的分析需求，應(yīng)用拓展性也非常好撞叽。在業(yè)界姻成，Vertica 和 Greenplum 都是表現(xiàn)比較優(yōu)秀的產(chǎn)品。當(dāng)然也可以利用開源的 Hadoop 生態(tài)能扒，自制 ROLAP 數(shù)據(jù)倉庫佣渴。

神策選用了 ROLAP。這是因為面向用戶分析市場初斑，模型要簡單，可以支撐比較靈活的分析需求膨处。在查詢性能上见秤，它要比 MOLAP 慢，但分析需求本身不需要特別高的實時性真椿，我們還能通過數(shù)據(jù)組織優(yōu)化鹃答、查詢優(yōu)化和一些緩存，也可以做到相對比較好的性能突硝。比如我們大多數(shù)的事件分析测摔，也僅在 10 秒左右。

四解恰、神策的方案

神策的 Event 數(shù)據(jù)使用 Parquet+HDFS 做為主存儲锋八，按時間做了分區(qū)，分區(qū)內(nèi)的數(shù)據(jù)按用戶 ID 局部有序护盈。這樣在多數(shù)事件分析上都有較好的性能挟纱，但也有問題：Parquet 文件只能批量寫入，無法實時寫入腐宋。我們通過 KUDU 解決這個問題紊服。它是 Cloudera 開源的新一代面向?qū)崟r分析的存儲引擎檀轨，kudu 底層存儲格式類似 Parquet，存放于它自己實現(xiàn)的本地存儲上欺嗤。

Kudu 本身就支持實時寫入参萄、實時更新和實時查詢。它的掃描性能比較 Parquet 略差煎饼，比 Hbase 要高一些讹挎，而寫入性能比 Hbase 要差一些。在神策內(nèi)部腺占，我們將它作為熱數(shù)據(jù)的緩存層淤袜。通過 Parquet 和 Kudu 的融合，我們做到了數(shù)據(jù)的實時導(dǎo)入衰伯。在查詢上铡羡，我們通過視圖對外屏蔽了用戶對存儲系統(tǒng)的感知。也即是說意鲸，在上層烦周，用戶看到的僅是用戶行為表，針對用戶行為表的查詢怎顾，在我們系統(tǒng)內(nèi)部读慎，會通過 Union 將 kudu 和 Parquet 的數(shù)據(jù)匯總后展現(xiàn)給用戶。這里 Kudu 的數(shù)據(jù)會定時的轉(zhuǎn)儲到 hdfs上槐雾，以提升它的掃描性能夭委。

user 和 item 數(shù)據(jù)的要求是能夠隨時修改，因為數(shù)據(jù)量比較小募强，所以我們直接采用了 Kudu 存儲株灸。

雖然 Event 數(shù)據(jù)被設(shè)計為不可變，但在神策服務(wù)了上千家客戶擎值，尤其是深入到行業(yè)化之后慌烧，對于 Event 數(shù)據(jù)的修改也變成了一個實實在在的需求。所以在接下來的未來鸠儿，神策也將推出部分事件可變的模型屹蚊。

▼▼▼

接下來的時間，神策將會繼續(xù)推出一系列的技術(shù)直播活動进每，第二講已經(jīng)在 6 月 29 日上線汹粤，由《Android 全埋點解決方案》和《iOS 全埋點解決方案》作者，神策數(shù)據(jù)合肥研發(fā)中心負(fù)責(zé)人王灼洲老師為大家?guī)怼稊?shù)據(jù)采集的那些事兒》品追。

神策是一個正在快速成長的高科技企業(yè)玄括，求賢若渴，正在等待你的加入肉瓦。