追求卓越
打造極致文化與產(chǎn)品研發(fā)結(jié)合的最佳實踐
神策已啟動「卓越產(chǎn)品計劃」
產(chǎn)品功能、性能、穩(wěn)定性不斷邁向新臺階
在為客戶提供服務時,我們通常會根據(jù)導入數(shù)據(jù)量、用戶資源以及用戶對于延時的要求來決定數(shù)據(jù)導入方案。接下來,本文將重點圍繞批量導入性能優(yōu)化,從“避免數(shù)據(jù)傾斜”和“提高并行度”兩個維度,詳細講述神策分析性能優(yōu)化之批量導入性能優(yōu)化的進化歷程。
關(guān)注神策數(shù)據(jù)公眾號,了解更多產(chǎn)品解讀。
數(shù)據(jù)倉庫常采用分區(qū)的方式進行數(shù)據(jù)組織。神策將數(shù)據(jù)分區(qū)分為三層:第一層為 project_id,代表用戶項目;第二層是 day_id,代表日期;第三層為 event_bucket(默認為 10 個,可自主配置),代表數(shù)據(jù)對應事件的分桶。批量導入會涉及多個項目、多個日期的多個事件,同一個項目、同一天的同一個事件桶數(shù)據(jù)應該輸出到同一個文件,在保證文件質(zhì)量(文件大小以及壓縮比)的基礎(chǔ)上,導入性能優(yōu)化核心要解決兩個問題:第一,避免數(shù)據(jù)傾斜;第二,盡可能提高并行度。
三層分區(qū)作為 PartitionKey 導入方案
PartitionKey 導入方案跟三層分區(qū)保持一致,使用(project_id, day_id, event_bucket)三元組作為 MapReduce 任務的 PartitionKey,直接對 PartitionKey.hashCode()%reduceNum 進行數(shù)據(jù) shuffle。
數(shù)據(jù) shuffle 擁有更優(yōu)的文件質(zhì)量,可以保證一個分區(qū)下的數(shù)據(jù)文件數(shù)最少,但卻不能避免數(shù)據(jù)傾斜問題,如果相同的(project_id, day_id, event_bucket)一次性導入大量數(shù)據(jù),那么便會導致導入性能急劇下降。
slice 導入方案
為了解決(project_id, day_id, event_bucket)三元組作為 PartitionKey 可能引起的數(shù)據(jù)傾斜問題,我們在優(yōu)化方案中引入了遞增的 slice 補充到 PartitionKey 中。也就是說,如果相同的(project_id, day_id, event_bucket)一次性導入大量數(shù)據(jù),則會將原來的一個 PartitionKey 變成 n 個 slice,如(project_id, day_id, event_bucket, slice_id=0),(project_id, day_id, event_bucket, slice_id=1)……該 shuffle 方案可以很好地避免數(shù)據(jù)傾斜問題。
如何切分 slice?在優(yōu)化過程中,我們會按照數(shù)據(jù)量切分 slice。slice_capacity 表示一個切分slice的數(shù)據(jù)條數(shù)閾值,比如 slice_capacity=10 萬,那么第一個 10 萬對應的 slice_id=0,第二個 10 萬對應的 slice_id=1,以此類推。
但是,按照固定數(shù)量進行 slice 切分可能會面臨以下兩個問題:
相同(project_id, day_id, event_bucket)下 slice_id=0 的數(shù)據(jù)較多,可能會導致數(shù)據(jù)傾斜
切分 slice 的 slice_capacity 閾值參數(shù)設置難度較大,閾值太大容易引起數(shù)據(jù)傾斜,閾值過小會導致數(shù)據(jù)被切分得太碎,文件質(zhì)量無法保障
對此,我們做了進一步優(yōu)化:第一,slice_id 依然從 0 開始,但第二個 slice_id 則從 100-10000 之間隨機生成初始值,然后依次遞增;第二,slice_capacity 不設置固定閾值,只設置最大/最小值,初始化為最小值,然后按照 2 的次冪遞增到最大值。
舉個例子,對于相同的(project_id, day_id, event_bucket)數(shù)據(jù),假設slice_capacity 初始值是 5 萬,最大值為 50 萬,則第一個 5 萬對應的 slice_id=0;第二個 10 萬對應的 slice_id=rand(100-10000),若 slice_id=3000,那么第三個 40 萬的 slice_id=3001,第四個 50 萬的 slice_id=3002 ,以此類推。
slice_id=0 的數(shù)據(jù)量變少,可以在保證文件質(zhì)量的前提下減少數(shù)據(jù)傾斜的概率。與此同時,非 slice_id=0 的數(shù)據(jù)采用隨機方式可以有效打散之后的大數(shù)據(jù)量分區(qū),進一步提升導入并行度。
數(shù)據(jù)分布預估導入方案
引入 slice 后,雖然可以一定程度上提升導入的性能,但依舊很難 100% 精準地避免數(shù)據(jù)傾斜。因此,我們進一步優(yōu)化,提出了數(shù)據(jù)分布預估的導入策略。
1、后置預估
后置預估假設:用戶導入的數(shù)據(jù)分布在一定時間范圍內(nèi)是一致的。比如,用戶在 10 點導入了 100 萬 key=(project_id=2, day_id=19902, event_bucket =3),那么用戶在 11 點也會繼續(xù)導入 100 萬左右的 key=(project_id=2, day_id=19902, event_bucket =3)。
于是我們設計了后置預估方式的導入優(yōu)化策略。
首次導入使用 slice 導入,假設導入后的 key 分布如下:
(project_id=2, day_id=19902, event_bucket =3)100 萬 3 個文件 1G
(project_id=2, day_id=19902, event_bucket =0)10 萬 1 個文件 100M
(project_id=2, day_id=19902, event_bucket =1)20 萬 1 個文件 100M
(project_id=2, day_id=19903, event_bucket =1)20 萬 1 個文件 100M
(project_id=3, day_id=19903, event_bucket =1)20 萬 1 個文件 100M
……
據(jù)此,我們可以預估下一次批量導入的分布。在提交 MapReduce 之前計算好每一個 key 對應的 reduce 分布,假設一個 reduce 分配 50 萬數(shù)據(jù),那么 10 個 reduce(project_id=2, day_id=19902, event_bucket =3)將分布在 reduce = (0,1)上,(project_id=2,day_id=19902, event_bucket =0)(project_id=2,day_id=19902, event_bucket =1)(project_id=2, day_id=19903, event_bucket =1)將分布在 reduce=2 上,(project_id=3,day_id=19903, event_bucket =1)分布在 reduce=3 上, 其余未知 key 分配到剩下的 reduce。
我們可以看到,該導入策略不僅可以保證文件質(zhì)量,還可以提高數(shù)據(jù)導入的并行度。但我們?nèi)孕枰P(guān)注這兩個問題:第一,每日 0 點前后,數(shù)據(jù)分布會發(fā)生質(zhì)的改變,因為 day_id 變了,因此在 0 點左右關(guān)閉導入策略可能會導致數(shù)據(jù)導入速度驟降;第二,當導入歷史數(shù)據(jù)時,會造成數(shù)據(jù)分布發(fā)生根本性改變進而導致策略失效,因此一旦有較大延遲時可關(guān)閉此導入策略。
2、前置預估
前置預估是指針對本次導入的數(shù)據(jù)計算數(shù)據(jù)分布,然后精確控制每一個 key 對應的 reduce。這種策略除了會帶來一定的前置計算額外開銷,近乎完美。在客戶環(huán)境的單個任務具體應用中,對于導入數(shù)據(jù)量大的客戶,優(yōu)化效果明顯;對于常規(guī)數(shù)據(jù)量的客戶,前置預估的帶來額外開銷較多,難以帶來導入性能的提升。
流水線提交導入方案
流水錢提交導入方案能夠有效避免前置預估帶來的額外開銷。在此次導入的 MapReduce 運行期間,如果未導入的數(shù)據(jù)量足夠多且本次的 Map 已完成,那么便會啟動下一次的預計算,保證下一次的導入只需要計算資源而沒有預計算的額外開銷;如果預計算任務先于此次導入完成,那么在具備充足資源的前提下會直接提交下一次的導入任務,進一步提高數(shù)據(jù)導入的并行度。提交流水線如下:
在完成以上批量導入性能優(yōu)化之后,神策數(shù)據(jù)能夠幫助企業(yè)客戶在數(shù)據(jù)量增大的業(yè)務場景中有效降低延時,已經(jīng)獲得了眾多客戶的認可。這也為神策數(shù)據(jù)的「卓越產(chǎn)品計劃」落地實踐提供了更多價值層面支持,我們將持續(xù)推動產(chǎn)品功能、性能、穩(wěn)定性不斷邁向新臺階,打造更多打造極致文化與產(chǎn)品研發(fā)結(jié)合的最佳實踐!
關(guān)注神策數(shù)據(jù)公眾號,了解更多產(chǎn)品解讀。
（免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）
