DynamoDB 是 Amazon 基于《 Dynamo: Amazon’s Highly Available Key-value Store 》實(shí)現(xiàn)的 NoSQL 數(shù)據(jù)庫(kù)服務(wù)。它可以滿足數(shù)據(jù)庫(kù)無(wú)縫的擴(kuò)展，可以保證數(shù)據(jù)的持久性以及高可用性。開(kāi)發(fā)人員不必費(fèi)心關(guān)注 DynamoDB 的維護(hù)、擴(kuò)展、性能等一系列問(wèn)題，它由 Amazon 完全托管，開(kāi)發(fā)人員可以將更多的精力放到架構(gòu)和業(yè)務(wù)層面上。

[[279564]]

本文主要介紹作者所在團(tuán)隊(duì)在具體業(yè)務(wù)中所遇到的挑戰(zhàn)，基于這些挑戰(zhàn)為何最終選型使用 Amazon DynamoDB，在實(shí)踐中遇到了哪些問(wèn)題以及又是如何解決的。文中不會(huì)詳細(xì)討論 Amazon DynamoDB 的技術(shù)細(xì)節(jié)，也不會(huì)涵蓋 Amazon DynamoDB 的全部特性。

背景與挑戰(zhàn)

TalkingData 移動(dòng)廣告效果監(jiān)測(cè)產(chǎn)品(TalkingData Ad Tracking)作為廣告主與媒體之間的一個(gè)廣告投放監(jiān)測(cè)平臺(tái)，每天需要接收大量的推廣樣本信息和實(shí)際效果信息，并最終將實(shí)際的效果歸因到推廣樣本上。

舉個(gè)例子，我們通過(guò)手機(jī)某新聞?lì)?APP 瀏覽信息，會(huì)在信息流中看到穿插的廣告，廣告可能是文字形式、圖片形式、視頻形式的，而不管是哪種形式的廣告它們都是可以和用戶交互的。

如果廣告推送比較精準(zhǔn)，剛好是用戶感興趣的內(nèi)容，用戶可能會(huì)去點(diǎn)擊這個(gè)廣告來(lái)了解更多的信息。一旦點(diǎn)擊了廣告，監(jiān)測(cè)平臺(tái)會(huì)收到這一次用戶觸發(fā)的點(diǎn)擊事件，我們將這個(gè)點(diǎn)擊事件攜帶的所有信息稱(chēng)為樣本信息，其中可能包含點(diǎn)擊的廣告來(lái)源、點(diǎn)擊廣告的時(shí)間等等。通常，點(diǎn)擊了廣告后會(huì)引導(dǎo)用戶進(jìn)行相關(guān)操作，比如下載廣告推薦的 APP，當(dāng)用戶下載并打開(kāi) APP 后，移動(dòng)廣告監(jiān)測(cè)平臺(tái)會(huì)收到這個(gè) APP 發(fā)來(lái)的效果信息。到此為止，對(duì)于廣告投放來(lái)說(shuō)就算做一次成功轉(zhuǎn)化。

DynamoDB實(shí)踐：當(dāng)數(shù)據(jù)量巨大而不可預(yù)知，如何保證高可用與實(shí)時(shí)性?

移動(dòng)廣告監(jiān)測(cè)平臺(tái)需要接收源源不斷的樣本信息和效果信息，并反復(fù)、不停的實(shí)時(shí)處理一次又一次轉(zhuǎn)化。對(duì)于監(jiān)測(cè)平臺(tái)來(lái)講，它的責(zé)任重大，不能多記錄，也不能少記錄，如果轉(zhuǎn)化數(shù)據(jù)記多了廣告主需要多付廣告費(fèi)給媒體，記少了媒體會(huì)有虧損。這樣就為平臺(tái)帶來(lái)了幾大挑戰(zhàn)：

• 數(shù)據(jù)量大：有的媒體為了利益最大化可能會(huì)采取非正常手段制造假的樣本，產(chǎn)生“虛假流量”，所以廣告監(jiān)測(cè)平臺(tái)除了會(huì)收到真實(shí)用戶樣本外，也會(huì)收到大量造假的樣本，影響正常的監(jiān)測(cè)和歸因。在最“瘋狂”的時(shí)候，我們的平臺(tái)會(huì)在一天內(nèi)收到 40 億 + 的點(diǎn)擊樣本事件請(qǐng)求。要知道，這些點(diǎn)擊樣本事件是要保留下來(lái)作為后續(xù)效果歸因用的，而且樣本有效期大不相同，從最短 12 小時(shí)到最長(zhǎng) 90 天不等。
• 數(shù)據(jù)量不可預(yù)知：對(duì)于廣告主的大推、應(yīng)用商店競(jìng)價(jià)排名等一系列的推廣，會(huì)導(dǎo)致突發(fā)大量樣本數(shù)據(jù)流入。面對(duì)這些流量不可預(yù)知的情況，我們?nèi)砸ＷC系統(tǒng)的正確、穩(wěn)定、實(shí)時(shí)。
• 實(shí)時(shí)處理：廣告主依賴廣告監(jiān)測(cè)平臺(tái)實(shí)時(shí)處理的結(jié)果來(lái)調(diào)整廣告推廣策略。因此廣告監(jiān)測(cè)平臺(tái)需要支持?jǐn)?shù)據(jù)實(shí)時(shí)處理，才能為廣告主更快的優(yōu)化推廣策略提供有力支撐。與此同時(shí)，廣告監(jiān)測(cè)平臺(tái)的處理結(jié)果也要實(shí)時(shí)回傳給媒體方以及廣告主。可以看到，準(zhǔn)確性和實(shí)時(shí)性是系統(tǒng)必須要滿足的基本條件。
• 樣本存儲(chǔ)：我們的業(yè)務(wù)最核心的功能就是歸因，我們要明確例如用戶下載打開(kāi) APP 的這個(gè)轉(zhuǎn)化效果是由哪一個(gè)推廣活動(dòng)樣本帶來(lái)的——也就是上圖中的第 7 步，當(dāng)用戶安裝 APP 后，監(jiān)測(cè)平臺(tái)要對(duì)應(yīng)找到第 1 步中樣本所在推廣活動(dòng)，這個(gè)是一個(gè)查詢匹配的過(guò)程。對(duì)于龐大的歸因樣本數(shù)據(jù)，有效期又各不相同，我們應(yīng)該怎樣存儲(chǔ)樣本才能讓系統(tǒng)快速歸因，不影響實(shí)時(shí)結(jié)果，這也是一個(gè)很大的挑戰(zhàn)。

最初形態(tài)

在 2017 年 6 月前我們的業(yè)務(wù)處理服務(wù)部署在機(jī)房，使用 Redis Version 2.8 存儲(chǔ)所有樣本數(shù)據(jù)。Redis 使用多節(jié)點(diǎn)分區(qū)，每個(gè)分區(qū)以主從方式部署。在最開(kāi)始我們 Redis 部署了多個(gè)節(jié)點(diǎn)，分成多個(gè)分區(qū)，每個(gè)分區(qū)一主一從。剛開(kāi)始這種方式還沒(méi)有出現(xiàn)什么問(wèn)題，但隨著用戶設(shè)置的樣本有效期加長(zhǎng)、監(jiān)測(cè)樣本增多，當(dāng)時(shí)的節(jié)點(diǎn)數(shù)量逐漸已經(jīng)不夠支撐業(yè)務(wù)存儲(chǔ)量級(jí)了。如果用戶監(jiān)測(cè)推廣量一旦暴增，我們系統(tǒng)存儲(chǔ)將面臨崩潰，業(yè)務(wù)也會(huì)癱瘓。于是我們進(jìn)行了第一次擴(kuò)容。

由于之前的部署方式我們只能將 Redis 的多個(gè)節(jié)點(diǎn)翻倍擴(kuò)容，這一切都需要人為手動(dòng)操作，并且在此期間我們想盡各種辦法來(lái)保護(hù)用戶的樣本數(shù)據(jù)。

DynamoDB實(shí)踐：當(dāng)數(shù)據(jù)量巨大而不可預(yù)知，如何保證高可用與實(shí)時(shí)性?

這種部署方式隨著監(jiān)測(cè)量的增長(zhǎng)以及用戶設(shè)定有效期變長(zhǎng)會(huì)越來(lái)越不堪重負(fù)，當(dāng)出現(xiàn)不可預(yù)知的突發(fā)量時(shí)就會(huì)產(chǎn)生嚴(yán)重的后果。而且，手動(dòng)擴(kuò)容的方式容易出錯(cuò)，及時(shí)性低，成本也是翻倍的增長(zhǎng)。在當(dāng)時(shí)由于機(jī)器資源有限，不僅 Redis 需要擴(kuò)容，廣告監(jiān)測(cè)平臺(tái)的一系列服務(wù)和集群也需要進(jìn)行擴(kuò)容。

化解挑戰(zhàn)

經(jīng)過(guò)討論和評(píng)估，我們決定將樣本處理等服務(wù)遷移到云端處理，同時(shí)對(duì)存儲(chǔ)方式重新選型為 Amazon DynamoDB，它能夠滿足我們的絕大部分業(yè)務(wù)需求。經(jīng)過(guò)結(jié)構(gòu)調(diào)整后系統(tǒng)大概是下圖的樣子：

DynamoDB實(shí)踐：當(dāng)數(shù)據(jù)量巨大而不可預(yù)知，如何保證高可用與實(shí)時(shí)性?

• 應(yīng)對(duì)數(shù)據(jù)量大且不可預(yù)知：我們的平臺(tái)需要接受推廣監(jiān)測(cè)連接請(qǐng)求，并進(jìn)行持久化用于后續(xù)的數(shù)據(jù)歸因處理。理論上來(lái)說(shuō)系統(tǒng)進(jìn)來(lái)多少?gòu)V告監(jiān)測(cè)數(shù)據(jù)請(qǐng)求，DynamoDB 就能存多少數(shù)據(jù)，只需要一張表就可以存儲(chǔ)任意數(shù)量級(jí)的數(shù)據(jù)。不用關(guān)心 DynamoDB 擴(kuò)容問(wèn)題，在系統(tǒng)運(yùn)行時(shí)我們感知不到存儲(chǔ)正在擴(kuò)容。這也是 Amazon 官方宣稱(chēng)的完全托管、無(wú)縫擴(kuò)展。
• 高可用：Amazon DynamoDB 作為存儲(chǔ)服務(wù)提供了極高的可用性，對(duì)于寫(xiě)入 DynamoDB 的全部數(shù)據(jù)都會(huì)存儲(chǔ)到固態(tài)硬盤(pán)中，并且自動(dòng)同步到 AWS 多個(gè)可用區(qū)，以達(dá)到數(shù)據(jù)的高可用。這些工作同樣完全由 Amazon DynamoDB 服務(wù)托管，使用者可以將精力放到業(yè)務(wù)架構(gòu)及編碼上。
• 實(shí)時(shí)處理：Amazon DynamoDB 提供了極高的吞吐性能，并且支持按秒維度配置任意級(jí)別的吞吐量。對(duì)于寫(xiě)多讀少的應(yīng)用可以將每秒寫(xiě)入數(shù)據(jù)的數(shù)量調(diào)整成 1000 甚至更高，將每秒讀取的數(shù)量降低到 10 甚至更少。吞吐量支持使用者任意設(shè)定，在設(shè)定吞吐量時(shí)除了可以隨時(shí)在 Web 管理后臺(tái)調(diào)整外，還可以通過(guò) DynamoDB 提供的客戶端動(dòng)態(tài)調(diào)整。比如系統(tǒng)在運(yùn)行時(shí)寫(xiě)入能力不足了，我們可以選擇到 Web 管理后臺(tái)手動(dòng)上調(diào)或在代碼中通過(guò)調(diào)用客戶端 API 的方式實(shí)現(xiàn)自動(dòng)上調(diào)。使用客戶端動(dòng)態(tài)調(diào)整的方式會(huì)讓系統(tǒng)具備較高的收縮能力，同時(shí)還可以保證數(shù)據(jù)的實(shí)時(shí)處理，系統(tǒng)數(shù)據(jù)流量變高了就動(dòng)態(tài)調(diào)整上去，數(shù)據(jù)流量變低了再動(dòng)態(tài)調(diào)整下來(lái)。相比手動(dòng)調(diào)整來(lái)看，動(dòng)態(tài)調(diào)整的方式更為靈活?；谝陨蠋c(diǎn)，我們認(rèn)為 Amazon DynamoDB 可以很輕松的支撐系統(tǒng)的核心業(yè)務(wù)能力。對(duì)于業(yè)務(wù)側(cè)需要做的就是，整理好業(yè)務(wù)邏輯把數(shù)據(jù)寫(xiě)到 DynamoDB 就可以了，剩下的就交給 DynamoDB 去做。

此外還有：

• TTL：我們利用了 Amazon DynamoDB 提供的 TTL 特性管理那些有生命周期的數(shù)據(jù)。TTL 是對(duì)表中要過(guò)期的數(shù)據(jù)設(shè)置特定時(shí)間戳的一種機(jī)制，一旦時(shí)間戳過(guò)期 DynamoDB 在后臺(tái)會(huì)刪除過(guò)期的數(shù)據(jù)，類(lèi)似于 Redis 中的 TTL 概念。借助 TTL 的能力，我們減少了很多業(yè)務(wù)上不必要的邏輯判定，同時(shí)還降低了因存儲(chǔ)量帶來(lái)的成本。
• 流：在我們的業(yè)務(wù)中沒(méi)有啟用流來(lái)捕獲表的動(dòng)作，但我們認(rèn)為 DynamoDB 流是一個(gè)非常好的特性，當(dāng)存儲(chǔ)在 DynamoDB 表中的數(shù)據(jù)發(fā)生變更(新增、修改、刪除)時(shí)，通知到相關(guān)的服務(wù) / 程序。比如我們修改了一條記錄的某個(gè)字段，DynamoDB 可以捕獲到這個(gè)字段的變更，并將變更前后的結(jié)果編寫(xiě)成一條流記錄。

實(shí)踐出真知

我們?cè)谑褂靡恍╅_(kāi)源框架或服務(wù)時(shí)總會(huì)遇到一些“坑”，這些“坑”其實(shí)也可以理解為沒(méi)有很好的理解和應(yīng)對(duì)它們的一些使用規(guī)則。DynamoDB 和所有服務(wù)一樣，也有著它自己的使用規(guī)則。在這里主要分享我們?cè)趯?shí)際使用過(guò)程中遇到的問(wèn)題以及解決辦法。

數(shù)據(jù)偏移

在 DynamoDB 中創(chuàng)建表時(shí)需要指定表的主鍵，這主要為了數(shù)據(jù)的唯一性、能夠快速索引、增加并行度。主鍵有兩種類(lèi)型，「單獨(dú)使用分區(qū)鍵」作為主鍵和「使用分區(qū)鍵 + 排序鍵」作為主鍵，后者可以理解為組合主鍵(索引)，它由兩個(gè)字段唯一確定 / 檢索一條數(shù)據(jù)。DynamoDB 底層根據(jù)主鍵的值對(duì)數(shù)據(jù)進(jìn)行分區(qū)存儲(chǔ)，這樣可以負(fù)載均衡，減輕單獨(dú)分區(qū)壓力，同時(shí) DynamoDB 也會(huì)對(duì)主鍵值嘗試做“合理的”分區(qū)。

在開(kāi)始我們沒(méi)有對(duì)主鍵值做任何處理，因?yàn)?DynamoDB 會(huì)將分區(qū)鍵值作為內(nèi)部散列函數(shù)的輸入，其輸出會(huì)決定數(shù)據(jù)存儲(chǔ)到具體的分區(qū)。但隨著運(yùn)行，我們發(fā)現(xiàn)數(shù)據(jù)開(kāi)始出現(xiàn)寫(xiě)入偏移了，而且非常嚴(yán)重，帶來(lái)的后果就是導(dǎo)致 DynamoDB 表的讀寫(xiě)性能下降，具體原因在后面會(huì)做詳細(xì)討論。發(fā)現(xiàn)這類(lèi)問(wèn)題之后，我們考慮了兩種解決辦法：

所以我們選擇了第二種方法，調(diào)整業(yè)務(wù)代碼，在寫(xiě)入時(shí)將主鍵值做哈希，查詢時(shí)將主鍵條件做哈希進(jìn)行查詢。

自動(dòng)擴(kuò)容潛規(guī)則

在解決了數(shù)據(jù)偏移之后讀 / 寫(xiě)性能恢復(fù)了，但是運(yùn)行了一段時(shí)間之后讀寫(xiě)性能卻再次下降。查詢了數(shù)據(jù)寫(xiě)入并不偏移，當(dāng)時(shí)我們將寫(xiě)入性能提升到了 6 萬(wàn) +/ 秒，但沒(méi)起到任何作用，實(shí)際寫(xiě)入速度也就在 2 萬(wàn) +/ 秒。最后發(fā)現(xiàn)是我們的分區(qū)數(shù)量太多了，DynamoDB 在后臺(tái)自動(dòng)維護(hù)的分區(qū)數(shù)量已經(jīng)達(dá)到了 200+ 個(gè)，嚴(yán)重影響了 DynamoDB 表的讀寫(xiě)性能。

DynamoDB 自動(dòng)擴(kuò)容、支持用戶任意設(shè)定的吞吐量，這些都是基于它的兩個(gè)自動(dòng)擴(kuò)容規(guī)則：?jiǎn)畏謪^(qū)大小限制和讀寫(xiě)性能限制。

單分區(qū)大小限制

DynamoDB 會(huì)自動(dòng)維護(hù)數(shù)據(jù)存儲(chǔ)分區(qū)，但每個(gè)分區(qū)大小上限為 10GB，一旦超過(guò)該限制會(huì)導(dǎo)致 DynamoDB 拆分區(qū)。這也正是數(shù)據(jù)偏移帶來(lái)的影響，當(dāng)數(shù)據(jù)嚴(yán)重偏移時(shí)，DynamoDB 會(huì)默默為你的偏移分區(qū)拆分區(qū)。我們可以根據(jù)下面的公式計(jì)算分區(qū)數(shù)量：

數(shù)據(jù)總大小 / 10GB 再向上取整 = 分區(qū)總數(shù)

比如表里數(shù)據(jù)總量為 15GB，15 / 10 = 1.5，向上取整 = 2，分區(qū)數(shù)為 2，如果數(shù)據(jù)不偏移均勻分配的話兩個(gè)分區(qū)每個(gè)存儲(chǔ) 7.5GB 數(shù)據(jù)。

讀寫(xiě)性能限制

DynamoDB 為什么要拆分區(qū)呢?因?yàn)樗ＷC用戶預(yù)設(shè)的讀 / 寫(xiě)性能。怎么保證呢?依靠將每個(gè)分區(qū)數(shù)據(jù)控制在 10G 以內(nèi)。另一個(gè)條件就是當(dāng)分區(qū)不能滿足預(yù)設(shè)吞吐量時(shí)，DynamoDB 也會(huì)將分區(qū)進(jìn)行擴(kuò)充。DynamoDB 對(duì)于每個(gè)分區(qū)讀寫(xiě)容量定義如下：

寫(xiě)入容量單位：寫(xiě)入容量單位(WCU：write capacity units)，以每條數(shù)據(jù)最大 1KB 計(jì)算，最大每秒寫(xiě)入 1000 條。

讀取容量單位：讀取容量單位(RCU：read capacity units)，以每條數(shù)據(jù)最大 4KB 計(jì)算，最大每秒讀取 3000 條。

也就是說(shuō)，一個(gè)分區(qū)的最大寫(xiě)入容量單位和讀取容量單位是固定的，超過(guò)了分區(qū)最大容量單位就會(huì)拆分區(qū)。因此我們可以根據(jù)下面的公式計(jì)算分區(qū)數(shù)量：

(預(yù)設(shè)讀容量 /3000)+(預(yù)設(shè)寫(xiě)容量 /1000)再向上取整 = 分區(qū)總數(shù)

比如預(yù)設(shè)的讀取容量為 500，寫(xiě)入容量為 5000，(500 / 3000) + (5000 / 1000) = 5.1，再向上取整 = 6，分區(qū)數(shù)為 6。

需要注意的是，對(duì)于單分區(qū)超過(guò) 10G 拆分后的新分區(qū)是共享原分區(qū)讀寫(xiě)容量的，并不是每個(gè)表單獨(dú)的讀寫(xiě)容量。

因?yàn)轭A(yù)設(shè)的讀寫(xiě)容量決定了分區(qū)數(shù)量，但由于單分區(qū)數(shù)據(jù)量達(dá)到上限而拆出兩個(gè)新的分區(qū)。

所以當(dāng)數(shù)據(jù)偏移嚴(yán)重時(shí)，讀寫(xiě)性能會(huì)急劇下降。

冷熱數(shù)據(jù)

產(chǎn)生上面的問(wèn)題是由于我們一開(kāi)始是單表操作。這樣就算數(shù)據(jù)不偏移，但隨著時(shí)間推移數(shù)據(jù)量越來(lái)越多，自然拆出的分區(qū)也越來(lái)越多。

因此，我們根據(jù)業(yè)務(wù)做了合理的拆表、設(shè)定了冷熱數(shù)據(jù)表。這樣做有兩大好處：

提升性能：這一點(diǎn)根據(jù)上面的規(guī)則顯而易見(jiàn)，熱表中數(shù)據(jù)量不會(huì)持續(xù)無(wú)限增長(zhǎng)，因此分區(qū)也穩(wěn)定在一定數(shù)量級(jí)內(nèi)，保證了讀寫(xiě)性能。

降低成本：無(wú)謂的為單表增加讀寫(xiě)性能不僅效果不明顯，而且費(fèi)用也會(huì)急劇增高，使用成本的增加對(duì)于誰(shuí)都是無(wú)法接受的。DynamoDB 存儲(chǔ)也是需要成本的，所以可以將冷表數(shù)據(jù)存儲(chǔ)到 S3 或其他持久化服務(wù)中，將 DynamoDB 的表刪除，也是降低成本的一種方式。

表限制

表對(duì)于數(shù)據(jù)的大小以及數(shù)量并沒(méi)有限制，可以無(wú)限制的往一張表里寫(xiě)入數(shù)據(jù)。但對(duì)于 AWS 的一個(gè)賬戶，每個(gè) DynamoDB 使用區(qū)域的限制為 256 張表。對(duì)于一個(gè)公司來(lái)說(shuō)，如果共用同一個(gè)賬號(hào)的話可能會(huì)存在創(chuàng)建表受限的風(fēng)險(xiǎn)。所以如果啟用了冷熱表策略，除了刪冷表降低成本外，也是對(duì) 256 張表限制的一種解決辦法。

屬性名長(zhǎng)度

上面提到了寫(xiě)入單位每條數(shù)據(jù)最大 1KB、讀取單位每條最大 4KB 的限制。單條數(shù)據(jù)的大小除了字段值占用字節(jié)外，屬性名也會(huì)占用字節(jié)，因此在保證可讀性的前提下應(yīng)盡量縮減表中的屬性名。

總結(jié)

DynamoDB 的使用也是存在成本的，主要體現(xiàn)在寫(xiě)入和讀取的費(fèi)用。我們自己研發(fā)了一套按照實(shí)際流量實(shí)時(shí)調(diào)整讀、寫(xiě)上限的策略。隨著發(fā)展 DynamoDB 也推出了 Auto Scaling 功能，它實(shí)現(xiàn)了自定義策略動(dòng)態(tài)調(diào)整寫(xiě)入與讀取上限的能力，對(duì)于開(kāi)發(fā)者來(lái)說(shuō)又可以省去了不少研發(fā)精力。目前我們也有部分業(yè)務(wù)使用了 Auto Scaling 功能，但由于該功能的限制，實(shí)際使用上動(dòng)態(tài)調(diào)整的實(shí)時(shí)性略顯欠缺。