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

[[279564]]

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

背景與挑戰(zhàn)

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

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

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

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

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

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

最初形態(tài)

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

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

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

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

化解挑戰(zhàn)

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

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

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

此外還有：

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

實(shí)踐出真知

我們在使用一些開源框架或服務(wù)時(shí)總會遇到一些“坑”，這些“坑”其實(shí)也可以理解為沒有很好的理解和應(yīng)對它們的一些使用規(guī)則。DynamoDB 和所有服務(wù)一樣，也有著它自己的使用規(guī)則。在這里主要分享我們在實(shí)際使用過程中遇到的問題以及解決辦法。

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

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

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

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

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

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

DynamoDB 自動擴(kuò)容、支持用戶任意設(shè)定的吞吐量，這些都是基于它的兩個(gè)自動擴(kuò)容規(guī)則：單分區(qū)大小限制和讀寫性能限制。

單分區(qū)大小限制

DynamoDB 會自動維護(hù)數(shù)據(jù)存儲分區(qū)，但每個(gè)分區(qū)大小上限為 10GB，一旦超過該限制會導(dǎo)致 DynamoDB 拆分區(qū)。這也正是數(shù)據(jù)偏移帶來的影響，當(dāng)數(shù)據(jù)嚴(yán)重偏移時(shí)，DynamoDB 會默默為你的偏移分區(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è)存儲 7.5GB 數(shù)據(jù)。

讀寫性能限制

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

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

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

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

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

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

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

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

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

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

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

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

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

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

表限制

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

屬性名長度

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

總結(jié)

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