成人国产在线小视频_日韩寡妇人妻调教在线播放_色成人www永久在线观看_2018国产精品久久_亚洲欧美高清在线30p_亚洲少妇综合一区_黄色在线播放国产_亚洲另类技巧小说校园_国产主播xx日韩_a级毛片在线免费

資訊專欄INFORMATION COLUMN

Appboy 基于 MongoDB 的數(shù)據(jù)密集型實踐

jindong / 1521人閱讀

摘要:相反,這些數(shù)來源于統(tǒng)計抽樣,統(tǒng)計抽樣通過抽樣小部分群體來獲得更大群體的特征。但調(diào)查機構(gòu)的報告與統(tǒng)計也經(jīng)常帶有所謂的置信區(qū)間,也稱為偏差。在進行一個多變量測試時,消息推送的目標(biāo)是測試全體,但是同一細分中的其他用戶不會收到該條消息。

摘要:Appboy 正在過手機等新興渠道嘗試一種新的方法,讓機構(gòu)可以與顧客建立更好的關(guān)系,可以說是市場自動化產(chǎn)業(yè)的一個前沿探索者。在移動端探索上,該公司已經(jīng)取得了一定的成功,知名產(chǎn)品有 iHeartMedia、PicsArt、Etsy 等。

【編者按】本文摘錄自 Appboy 聯(lián)合創(chuàng)始人兼 CIO Jon Hyman 在 MongoDB World 2015 上的演講。Appboy 正在過手機等新興渠道嘗試一種新的方法,讓機構(gòu)可以與顧客建立更好的關(guān)系,可以說是市場自動化產(chǎn)業(yè)的一個前沿探索者。在移動端探索上,該公司已經(jīng)取得了一定的成功,知名產(chǎn)品有 iHeartMedia、PicsArt、Etsy、Samsung、Urban Outfitters 等。本文主要包括 Statistical Analysis、Multivariate Testing and Rate Limiting、Flexible Schemas: Extensible User Profiles 和 Data Intensive Algorithms 四方面內(nèi)容,本文系 OneAPM 工程師編譯整理。

以下演講摘錄:

為了支撐其營銷自動化平臺,Appboy 為其分析和定位引擎使用了 MongoDB 作為其主要數(shù)據(jù)存儲層。時下,Appboy 每天需要處理上萬用戶的數(shù)十億數(shù)據(jù)點。本文將分享 Appboy 關(guān)于 MongoDB 的最佳實踐,看看該公司如何在規(guī)模迅速擴大后仍然保持敏捷。本文將談及諸多話題,如文檔隨機抽樣、多變量測試及其 Multi-arm bandit optimization、Field tokenization,以及 Appboy 如何在一個個體用戶基礎(chǔ)上存儲多維數(shù)據(jù)從而優(yōu)化以最佳的時間給終端用戶提供信息。

Part 1:Statistical Analysis

Appboy 適用于各種大小的客戶群體,其中包括了只有數(shù)萬用戶的初級客戶,也有客戶已經(jīng)擁有了數(shù)千萬用戶。但是毫無疑問的是,通過 Appboy 營銷自動化技術(shù),即使擁有上億用戶規(guī)模的客戶仍然可以便捷地收集和儲存用戶數(shù)據(jù)。

Appboy 平臺的核心是 customer segmentation(客戶細分)。segmentation 允許機構(gòu)根據(jù)行為數(shù)據(jù)、消費史、技術(shù)特性、社交概要等來定位。創(chuàng)新和智能的使用 Segmentation 和信息自動化使機構(gòu)可以無縫地、輕松地將安裝用戶轉(zhuǎn)化為活躍的用戶,從而斬獲 kpi,Segments 可以按需定制。

當(dāng)客戶使用 Appboy 儀表板定義 segment 時,Appboy 可以在一些特征上做實時計算,比如群體大小、開通消息推送的用戶規(guī)模、用戶平均消費能力。這些計算需要實時和交互式的,而在不具備谷歌規(guī)模的基礎(chǔ)設(shè)施上,在這種規(guī)模上做交互式分析是極具挑戰(zhàn)的。這里存在的挑戰(zhàn)是如何更有效率的支撐如此規(guī)模,以及如何服務(wù)于各種體積的用戶?;谶@些原因,隨機抽樣是個不錯的選擇。

關(guān)于統(tǒng)計抽樣

在現(xiàn)實世界中,隨機的統(tǒng)計抽樣時刻發(fā)生著,比如針對美國總統(tǒng)的輿情調(diào)查不可能去多帶帶的問每個人,全國收視率統(tǒng)計也并不是靠評級機構(gòu)查看每個用戶的電視機。相反,這些數(shù)來源于統(tǒng)計抽樣,統(tǒng)計抽樣通過抽樣小部分群體來獲得更大群體的特征。通過統(tǒng)計數(shù)據(jù),1個小樣本就可以對大規(guī)模群體做出準(zhǔn)確的評估。許多政治民意調(diào)查只調(diào)查幾千成年人就可以估計數(shù)以百萬計的公民的政治傾向。但調(diào)查機構(gòu)的報告與統(tǒng)計也經(jīng)常帶有所謂的置信區(qū)間,也稱為偏差。

統(tǒng)計抽樣的使用

相同的原則可以運用到這里。與傳統(tǒng)分析數(shù)據(jù)庫相比,抽樣用戶有一個明顯的優(yōu)勢,因為這里可以從用戶的整體行為上進行抽樣,而不是從原始事件流中取樣。需要注意的是,Appboy 只針對 segment 交互式反饋做抽樣,從而在網(wǎng)絡(luò)儀表板反饋。當(dāng)做營銷活動或?qū)?Segment 進行分析作為 Facebook Custom Audience 時,準(zhǔn)確用戶會被計算,而這些原則并不適用。

在開始時,會在已知范圍 document 內(nèi)添加一個隨機數(shù)字,稱之為「bucket」。選擇一個合理的小用戶群,從而有可能聚焦每個用戶,需要注意的是,這個抽樣規(guī)模乘以 bucket 的數(shù)量必須覆蓋該范圍。舉個例子,只選擇了1到10的抽樣顯然不可以支撐上億規(guī)模,1到100萬顯然是個不錯的選擇。在 Appboy 共擁有1萬個「bucket」,所以應(yīng)該是0到9999。

假設(shè)這里有1000萬個 documents(代表用戶),首先將給這些文檔加個數(shù)字并對其索引。

{
random: 4583,
favorite_color: “blue”,
age: 29,
gender: “M”,
favorite_food: “pizza”,
city: “NYC”,
shoe_size: 11
}

db.users.ensureIndex({random:1})

第一步是獲得1個隨機樣本。1000萬個 document ,10000隨機的 buckets,每個 buckets 應(yīng)該有1000個用戶:

db.users.find({random: 123}).count() == ~1000
db.users.find({random: 9043}).count() == ~1000
db.users.find({random: 4982}).count() == ~1000

如果抽取整個用戶基礎(chǔ)的1%,那就是10萬的用戶。為了實現(xiàn)這一點,必須選擇一個隨機范圍來「托管」這些用戶。舉個例子,這些都是可以的:

db.users.find({random: {$gt: 0, $lt: 101})
db.users.find({random: {$gt: 503, $lt: 604})
db.users.find({random: {$gt: 8938, $lt: 9039})
db.users.find({$or: [
{random: {$gt: 9955}}, 
{random: {$lt: 56}}
])

在有了隨機樣本后,下一步就是對其分析。要衡量其真正的大小,首先需要進行一個計數(shù),因為鑒于隨機性這里不可能精確到100000。

在并行的方式,這里可以在樣本上添加任意查詢,這里拿找出最喜歡藍色的男性用戶比例。

sample_size = db.users.find({random: {$gt: 503, $lt: 604}).count()
observed = db.users.find({random: {$gt: 503, $lt: 604}, gender: “M”, favorite_color: “blue”).count()

假如,樣本大小設(shè)定是100000,觀察數(shù)是11302。從這里可以推斷出,在1000萬用戶中有11.3%的用戶符合標(biāo)準(zhǔn)。要稱為優(yōu)秀的統(tǒng)計學(xué)家,還應(yīng)該提供一個置信區(qū)間來估計偏離值。置信區(qū)間背后的數(shù)學(xué)有點復(fù)雜,但是,如果想自己嘗試的話,有無數(shù)樣本 sizecalculators 可供參考。本文使用的案例中,置信區(qū)間為+ / - 0.2%

優(yōu)化

在實踐中,當(dāng)執(zhí)行統(tǒng)計抽樣時,Appboy 基于這些高等級概念概念做了大量優(yōu)化。首先,Appboy 使用 MongoDB 聚合框架,并且大量使用緩存。因為這里使用的是內(nèi)存映射存儲引擎,對于這種抽樣,使用 MongoDB 的好處是一旦將隨機樣本加載到內(nèi)存就可以運行任意查詢。這么做為 web 儀表盤上提供了卓越的體驗,用戶可以通過添加和刪除選擇標(biāo)準(zhǔn)并立即看到統(tǒng)計數(shù)據(jù)更新,從而用戶可以進行交互式探索。

Part 2:多變量測試和比率限制 多變量測試的快速入門

在當(dāng)今競爭激烈的市場中,用戶細分是必不可少的。隨著經(jīng)驗與品牌繼續(xù)快速轉(zhuǎn)向移動等新興渠道,對營銷來說,信息定制化和關(guān)聯(lián)性性比以往更加重要,這就是用戶分類為什么會成為與客戶交互的先決條件。

因此一旦定義了一個劃分,下一個目標(biāo)是優(yōu)化消息推送使其轉(zhuǎn)換最大化,多變量測試則是實現(xiàn)這一目標(biāo)的一種途徑。多變量測試是一個實驗,用來比較用戶對相同營銷活動多個不同推廣手段的反應(yīng)。這些版本擁有相同的營銷目標(biāo),但在措辭和風(fēng)格上有所不同,而多變量測試的目標(biāo)就是為了確定哪個版本能達到最好的轉(zhuǎn)換。

例如,假設(shè)您有3個不同的推送通知消息:

Message 1:This deal expires tomorrow!

Message 2:This deal expires in 24 hours!

Message 3:Fourth of July is almost over! All deals end tomorrow!

此外,除下消息,通常還會測試大量的圖片搭配合文本。

使用多變量測試,機構(gòu)可以發(fā)現(xiàn)哪種措辭產(chǎn)生更高的轉(zhuǎn)化率。在下次發(fā)送推送式通知談生意時,就可以知道哪種語氣和措辭更有效。更好的是,可以通過限制測試的大小,比如在一小部分聽眾內(nèi),找出哪些消息更有效,然后發(fā)送這些有效的消息給其他人。

在進行一個多變量測試時,消息推送的目標(biāo)是測試全體,但是同一細分中的其他用戶不會收到該條消息。從而,機構(gòu)可以通過對比兩種反應(yīng)來進行評估。

技術(shù)應(yīng)用

從技術(shù)的角度來看,接收消息的人應(yīng)該是隨機的。也就是說,如果你有100萬用戶且想要發(fā)送一個測試給50000人,這50000人應(yīng)該是隨機分布在你的用戶群里(你還想要另一組5000用戶為對照組)。同樣的,如果你想測試10到50000用戶,隨機性有助于確保每個測試組的用戶都不同。

思考這個問題,它與1個消息中的比率限制問題是一行。許多客戶想要給一小群用戶發(fā)送一條消息。比如,一個電子商務(wù)公司想隨機的在用戶群中發(fā)放50000個優(yōu)惠碼。這在概念上,是同樣的問題。

為了實現(xiàn)這一點,這里可以通過每個文檔上的隨機值來掃描用戶:

Appboy 會在不同的隨機范圍內(nèi)通過隨機值用并行處理的方式來管理用戶。并追蹤全局狀態(tài),因此可以知道何時達到比率的極限。對于多變量測試而言,隨后還會通過發(fā)送比率或者是隨機地選擇一個消息版本。

注意

那些有數(shù)學(xué)思維的人可能已經(jīng)注意到,如果在隨機字段中使用統(tǒng)計分析,并基于相同的隨機字段選擇個體接收消息,那么在某些情況下,將會產(chǎn)生偏差。為了闡釋這一說法,假定使用隨機 bucket 值為10來選擇所有用戶,給他們隨機發(fā)送消息。這意味著,在這個用戶 bucket 中收到消息的用戶將不再是隨機分布。作為一個簡單的解決方案,Appboy 對用戶使用多個隨機值,注意不要為了多個目的使用相同的隨機值。

Part 3:模式靈活——可擴展的用戶配置文件

在每個用戶打開 Appboy 的任意一個應(yīng)用,一個豐富的用戶概要文件都會被創(chuàng)建。用戶的基本字段看起來是這樣:

{
first_name: “Jane”,
email: “[email protected]”,
dob: “1994-10-24”,
gender: “F”,
country: “DE”,
...
}

Appboy 客戶端還可以存儲每個用戶的「自定義屬性」。作為一個例子,一個體育應(yīng)用程序可能想存儲用戶「最喜歡的球員」,而電子商務(wù)應(yīng)用程序可能會存儲客戶最近購買的品牌等。

{
first_name: “Jane”,
email: “[email protected]”,
dob: 1994-10-24,
gender: “F”,
custom: {
brands_purchased: “Puma and Asics”,
credit_card_holder: true,
shoe_size: 37,
...
},
...
}

這么做一個巨大的好處是,這些自定義屬性可以在其他屬性更新時直接插入。因為 MongoDB 提供靈活的模式,添加任意數(shù)量的自定義字段都很容易而,且不用擔(dān)心它的類型(boolean、string、intege、float 又或是什么)。MongoDB 會處理這一切,而查詢自定義屬性也很容易理解。針對一個 value 列,這里不提供復(fù)雜的連接,而在傳統(tǒng)關(guān)系型數(shù)據(jù)庫中你往往需要提前定義。

db.users.find(…).update({$set: {“custom.loyalty_program”:true}})
db.users.find({“custom.shoe_size” : {$gt: 35}})

這么做的缺點是,如果用戶不小心在客戶端中使用非常長的名稱來定義(「this_is_my_really_long_custom_attribute_name_it_represents_shoe_size」)或者是被 MongoDB,在 MongoDB 的早期版本中它會占用大量的空間。另外,因為類型不是強制的,這里也可能出現(xiàn)跨 documents 值類型不匹配問題。1個document 可能列出某人{ visited_website: true},但是如果不小心,另一個就可能是{ visited_website: “yes”}。

Tokenization

為了解決第一個問題,通常會使用1個 map 來切分用戶屬性名稱。通常情況下,這可以是 MongoDB 中的一個 documents,比如將「shoe_size」值映射成一個獨特的、可預(yù)測的短字符串。只要使用 MongoDB 的自動操作,就可以生成這種映射。

在映射中,通常會使用數(shù)組進行存儲,數(shù)組索引是「token」。每個客戶至少有一個 document 會包含 list 的數(shù)組字段。當(dāng)首次添加一個新的自定義屬性時,可以自動把它放到列表最后,生成索引(「token」),并在第一次檢索后緩存:

db.custom_attribute_map.update({_id: X, list: {$ne: "Favorite Color"}}, {$push: {list: "Favorite Color"}})

可能會有這樣一個列表:

[“Loyalty Program”, “Shoe Size”, “Favorite Color”]
            0            1            2          

MongoDB 最佳實踐需要警示 documents 的不斷增長,而自 Appboy 定義起,documents 就存在無限增長的情況。實際上,這個潛在的問題已經(jīng)被考慮,而這里則是通過限制數(shù)組大小來讓用戶使用多個 documents。當(dāng)給列表添加新的項時,如果數(shù)組長度小于一定規(guī)模,更新操作只能局限于 $push。如果更新操作沒有生成1個新 $push,一個自動的 $findAndModify 可以用來創(chuàng)建一個新文檔并添加元素。

Tokenization 確實增加了一些間接和復(fù)雜性,但它可以自定義映射屬性,從而在整個代碼庫傳遞。這個解決方案同樣可以應(yīng)用到其他問題上,可以是數(shù)據(jù)類型文檔中不匹配。在這里同樣可以使用映射來追蹤數(shù)據(jù)類型。例如,記錄「visited_website」是一個 boolean,只接受 true 或者 false。

Part 4:數(shù)據(jù)密集型算法 Intelligent Selection 和 Multi-Arm Bandit Multivariate Testing

多變量測試目標(biāo)是,在最短的時間內(nèi)尋找最高的轉(zhuǎn)化率,當(dāng)下已經(jīng)可以在大量平臺上發(fā)現(xiàn),客戶會定期進行測試,并發(fā)現(xiàn)最好的那個。

Appboy 一種叫做 Intelligent Selection(智能選擇)的特性,該特性可以分析多變量測試的性能,并依據(jù)統(tǒng)計算法自動調(diào)整接收到不同版本消息的用戶比例。這里的統(tǒng)計算法可以確保獲得最真實的性能,而不是隨機的可能性,該算法被稱為themulti-arm bandit。

multi-arm bandit 背后的數(shù)學(xué)算法非常復(fù)雜,本文不會闡述,這里不妨著眼劍橋大學(xué)數(shù)理統(tǒng)計學(xué)教授 Peter Whittle 在1979年的發(fā)言:

「The bandit problem」 是二戰(zhàn)期間被正式提出的,為了解決它,盟軍分析師絞盡腦汁,備受折磨,以至于建議把這個問題拋給德國,作為知識戰(zhàn)的終極手段。

但提出這個算法的理由表明,為了有效地運行,the multi-arm bandit 算法需要輸入大量的數(shù)據(jù)。對于每個消息版本,該算法會計算接受者以及轉(zhuǎn)換率。這就是 MongoDB 發(fā)光的地方,因為可以使用 pre-aggregated analytics 實時地自動積累數(shù)據(jù):

{
company_id: BSON::ObjectId,
campaign_id: BSON::ObjectId,
date: 2015-05-31,
message_variation_1: {
unique_recipient_count: 100000,
total_conversion_count: 5000,
total_open_rate: 8000,
hourly_breakdown: {
0: {
unique_recipient_count: 1000,
total_conversion_count: 40,
total_open_rate: 125,
...
},
...
},
...
},
message_variation_2: {
...
}
}

通過這樣1個模式,可以快速查看每天和每小時的轉(zhuǎn)換變化,打開并發(fā)送。Appboy 模式稍微復(fù)雜一點,因為這里還存在其他需要考慮的因素,這里需要注意。

預(yù)聚合 documents 允許快速終止實驗。鑒于為每個公司對 collection 進行分片,這里可以以擴展的方式同時優(yōu)化某個公司的全部活動。

智能交付

Appboy 提供給客戶的另一個專有算法稱為智能交付。當(dāng)規(guī)劃消息活動部署時,Appboy 分析出給每個用戶發(fā)送消息的最優(yōu)時間,并在正確的時刻提供可顧客。比如 Alice 更可能在晚上獲取應(yīng)用程序推送信息,而 Bob 則喜歡把這個事情放在早上上班前,那么 Appboy 將會在他們最樂意的時間推送消息。這是個能創(chuàng)造奇跡的特性,正如 Urban Outfitters CRM 和 Interactive Marketing 負責(zé)人 Jim Davis 所稱贊的:

對比使用前后的打開比率,可以看到表現(xiàn)提升了1倍。針對男性 Urban On members 一周活動目標(biāo)提升了138%。此外,細分功能也值得稱贊,提升了3個月以上不活躍用戶94%。

這種算法無疑是數(shù)據(jù)密集型,要智能地預(yù)測出給每個客戶發(fā)送消息的最佳時間,必須清楚的分析出這個用戶的行為特征。除此之外,Appboy 每天將發(fā)送數(shù)千萬智能交付消息,所以這里需求一個非常高的預(yù)測。

這里的方法是類似于 Intelligent Selection,主要通過實時地在每個用戶的基礎(chǔ)上預(yù)聚合多個維度完成。有了 MongoDB,每個用戶都有很多 documents,類似下面代碼:

{
_id: BSON::ObjectId of user,
dimension_1: [DateTime, DateTime, …],
dimension_2: [Float, Float, …],
dimension_3: […],
...
}

當(dāng)所關(guān)心的用戶維度數(shù)據(jù)進入時,應(yīng)使其正規(guī)化,并保存 documents 的副本。通過{_id: “hashed”}對每個 documents 進行,從而讓讀寫分布的更優(yōu)化。當(dāng)需要用 Intelligent Delivery 發(fā)送一條消息,這里可以快速地查詢一系列 documents,并送到機器學(xué)習(xí)算法。在這個方面,MongoDB 帶來的幫助很大,其可擴展性當(dāng)下已支撐系統(tǒng)的數(shù)十個維度。而隨著新的維度被添加,這個機器學(xué)習(xí)算法被不停的修改,而這個過程一直受益于 MongoDB 的靈活。

總結(jié)

本文討論了系統(tǒng)的主要設(shè)計思想,而這一切都得益于 MongoDB 靈活的模式和強擴展性。而通過 MongoDB,Appboy 在數(shù)據(jù)密集型工作上取得了一個很大的成功。

原文鏈接:Remaining Agile with Billions of Documents: Appboy’s Creative MongoDB Schemas

本文系 |6803da6e1241c3b46359f28d015fd7e314| 工程師編譯整理。想閱讀更多技術(shù)文章,請訪問 OneAPM 官方博客。

文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址:http://systransis.cn/yun/18786.html

相關(guān)文章

  • Spring Boot 2.x 系列教程:WebFlux 系列教程大綱(一)

    摘要:使用則需要及以上版本。開發(fā)使用框架七系列教程目錄系列教程大綱快速入門實踐實踐整合整合中和實踐整合中實現(xiàn)緩存中實現(xiàn)通信集成測試及部署實戰(zhàn)圖書管理系統(tǒng) WebFlux 系列教程大綱 一、背景 大家都知道,Spring Framework 是 Java/Spring 應(yīng)用程序跨平臺開發(fā)框架,也是 Java EE(Java Enterprise Edition) 輕量級框架,其 Spring ...

    jone5679 評論0 收藏0
  • 移動大數(shù)據(jù)平臺架構(gòu)思想以及實踐經(jīng)驗

    摘要:關(guān)于友盟數(shù)據(jù)架構(gòu)友盟架構(gòu)思想友盟的架構(gòu)主要參考了提出的架構(gòu)思想。關(guān)于友盟實踐通過以上的介紹,大家可能對整個大數(shù)據(jù)平臺的結(jié)構(gòu)和概念有了初步的了解。所以接下來,我給大家分享一些友盟在實踐中得到的一些經(jīng)驗。友盟的數(shù)據(jù)平臺經(jīng)歷了一個發(fā)展的過程。 摘要:友盟大數(shù)據(jù)平臺的架構(gòu)借鑒了Lambda架構(gòu)思想,數(shù)據(jù)接入層讓Kafka集群承擔(dān),后面由Storm消費,存儲在MongoDB里面,通過Kafka自...

    leone 評論0 收藏0

發(fā)表評論

0條評論

最新活動
閱讀需要支付1元查看
<