亞馬遜Aurora讓數(shù)據(jù)庫可擴展，但Kappa Architecture讓數(shù)據(jù)庫的發(fā)展無極限，管理員可以跨服務器集群創(chuàng)建數(shù)據(jù)的物化視圖。

　　傳統(tǒng)的數(shù)據(jù)庫有許多先進的功能，其中對開發(fā)者最重要的就是物化視圖功能。這種存儲查詢會自動緩存創(chuàng)建耗時的查詢，并將數(shù)據(jù)寫入磁盤。但傳統(tǒng)的數(shù)據(jù)庫在數(shù)據(jù)的存儲量和接受請求的吞吐方面的擴展性不佳。雖然亞馬遜Aurora可以提高數(shù)據(jù)庫的擴展能力，還單個數(shù)據(jù)庫的處理能力仍然有限。Kappa Architecture可以在這點上有所助益。

[[168867]]

　　Kappa Architecture是一種軟件架構模式加上一個只允許追加不允許修改的日志。Kappa Architecture同Lambda架構系統(tǒng)類似，只是不支持批量處理。在數(shù)據(jù)庫中，有個細節(jié)叫做事務日志，每一次對數(shù)據(jù)庫的變更都會對日志進行寫入。事務日志是用來重建部分數(shù)據(jù)庫的內(nèi)容，如果出現(xiàn)問題的話可以恢復到特定的時間點。該日志包含底層數(shù)據(jù)的每一個原始動作。例如，如果一個客戶要購買一件物品，事務日志可能會這樣顯示：

　　at 1463086280008 row 123456 old value = [ "cust-123", 50 ] new value = [ "cust-123", 25]

　　該值顯示在unix時間戳1463086280008的時候，123456行記錄從“cust-123”，50變更為“cust-123”，25。

　　這就是被稱為fact，表明在某個特定的時間，一個值被從某個值改為另一個值。這個事實是真的，不管之后會發(fā)生什么。舉例來說，即便客戶在此之后又增加了25個積分，他們在這個特定的時間點仍然是減少了25積分。

　　數(shù)據(jù)庫常年都處理這種小細節(jié)，但大多作為一個小的實現(xiàn)細節(jié)。Kappa Architecture建議將此作為記錄的主來源，其他的一切都作為數(shù)據(jù)的物化視圖。傳統(tǒng)的數(shù)據(jù)庫可以在一臺服務器上執(zhí)行這種類型的活動，而這種方法允許管理員可以***擴展和創(chuàng)建橫跨不同服務器集群數(shù)據(jù)的物化視圖。

　　管理員可以使用日志流來查看跨服務器集群的數(shù)據(jù)

　　此日志流成為一個只能追加的系統(tǒng)，只接受寫入操作，在寫入的時候加上基本的時間戳，然后將信息寫入到磁盤中。這種交互的構想是，每一個寫操作都是按順序發(fā)生，所以該系統(tǒng)必須從頭開始按順序運行日志中的每一個事件，才能重建數(shù)據(jù)庫當前完整的視圖。

　　這使得開發(fā)人員可以在保持后臺系統(tǒng)完全運作的同時增加額外的視圖。每個數(shù)據(jù)視圖可以在一個完全獨立的系統(tǒng)或多個完全獨立的系統(tǒng)里，只要這些系統(tǒng)有訪問整個日志流的完整權限。日志流會通知每個視圖任何一切操作以及操作發(fā)生的精確時間戳，這樣所有的操作就可以順序執(zhí)行。然后每個視圖可以獲取其需要的所有信息以確保單個視圖的正確建立。

　　Kappa如何在AWS上工作

　　創(chuàng)建Kappa這樣的架構最顯而易見的工具是Amazon Kinesis，這是一個專門用來處理數(shù)據(jù)流的工具。當一個進程附加到一個Kinesis流，它可以自動按順序讀取每一個事件，以建立自己的數(shù)據(jù)庫視圖。這可以用來將數(shù)據(jù)庫的更改復制到其它數(shù)據(jù)存儲，如亞馬遜DynamoDB，甚至跨區(qū)域到其他的數(shù)據(jù)庫，因為區(qū)域鄰近優(yōu)化的關系。

　　Kinesis的另一種替代選擇是DynamoDB流，這對于使用DynamoDB數(shù)據(jù)庫的開發(fā)者來說使用方便。將這個想成是專門針對DynamoDB的自動Kinesis流。不幸的是，無論來自Kinesis還是DynamoDB的流都只存儲最近7天的記錄。因此，要創(chuàng)建一個新的視圖，開發(fā)人員必須首先從一個主數(shù)據(jù)庫里讀出包含所有變更的最終結(jié)果的全部數(shù)據(jù)。

　　想更深入的了解如何創(chuàng)建一個Kappa風格的視圖，現(xiàn)在假設我們有兩個DynamoDB表，Customer和Orders。公司的市場部門可能通常會問，“客戶X這個月花了多少錢?”在傳統(tǒng)的數(shù)據(jù)庫方式下，查詢該數(shù)據(jù)需要連接Customer表和Orders表，然后匯總出客戶所花費的金額。

　　現(xiàn)在采用Kappa的方法，因為數(shù)據(jù)是存儲在DynamoDB，而不是關系型數(shù)據(jù)庫，這種類型的查詢要么預先知曉，要么是我們?yōu)榇私⒌囊粋€新的并會不斷更新的視圖。大量的數(shù)據(jù)被存在Orders數(shù)據(jù)庫中，但營銷部門可能并不想知道一個Customer ID，而是會查找一個客戶的姓名或電子郵件地址。在這種情況下，開發(fā)人員可以創(chuàng)建一個包含Customer ID，Customer Name，Customer Email，Month和Total Spend的視圖。你可以根據(jù)姓名和電子郵件來對這個視圖建立索引。DynamoDB可以自動處理這個問題，但如果不使用DynamoDB，開發(fā)人員還可以創(chuàng)建兩個獨立的視圖，一個根據(jù)名字建立索引和一個根據(jù)郵件索引。

　　Kappa Architecture結(jié)合AWS Lambda

　　首先，視圖的創(chuàng)建腳本需要先連接到流，并開始存儲DynamoDB流中的所有變更。該腳本可以從OldValue/NewValue的變化中識別出新的值。一旦腳本開始緩沖數(shù)據(jù)，會將當前數(shù)據(jù)表中所有的數(shù)據(jù)轉(zhuǎn)存出來，寫入到新表中。在所有的數(shù)據(jù)復制完畢后再開始處理事件。這種兩階段的方法有助于防止任何并發(fā)問題，以確保在數(shù)據(jù)被復制和腳本開始處理變更事件之間不會有數(shù)據(jù)丟失。

　　AWS Lambda是最有效的處理變更事件的方法。創(chuàng)建完用于創(chuàng)建該視圖的Lambda函數(shù)后，進入Event Sources頁，然后選擇Add event source。

　　從Event Sources頁選擇‘Add event source’。

　　在彈出框中，選擇DynamoDB。

　　選擇DynamoDB作為事件源類型

　　接下來，填寫細節(jié)，確保選擇正確的DynamoDB表(Orders)，在Starting Position處填寫Trim Horizon。Batch size列出在某個時間最多有多少條記錄被發(fā)送給AWS Lambda函數(shù)的單個實例。這意味著Lambda函數(shù)需要在單次執(zhí)行中處理多個事件。

　　為Lambda函數(shù)配置DynamoDB表，batch size和starting position

　　接下來，Add Amazon DynamoDB Permissions to your role，以便Lambda函數(shù)可以訪問DynamoDB流。開發(fā)者還應確保為角色添加AWS身份和訪問管理權限，使其能夠?qū)懭氲叫碌腄ynamoDB表，這將是新創(chuàng)建的視圖。開發(fā)人員應該首先測試Lambda函數(shù);鉤上Enable event source，直到函數(shù)的功能驗證成功。在確保函數(shù)工作之后，使用同樣的Event Sources控制臺暫時禁用流，直到新的視圖初始化完成。確保視圖初始化完成后再重新啟用源。

　　在重新啟動流之前，***一步是將所有現(xiàn)有的記錄復制到新的視圖。這涉及到用一個外部腳本來讀取Orders數(shù)據(jù)庫中的每條記錄，并將其提交給Lambda函數(shù)。開發(fā)人員可能會想臨時增加讀取吞吐量直到新的視圖產(chǎn)生，這樣可以快速創(chuàng)建新視圖。請記住，DynamoDB Kinesis流將在日志中最多保留七天的事件。

　　***，寫一個額外的句柄來處理Customer的DynamoDB表的變更，將任何變化，如電子郵件地址或姓名，更新到與該客戶相關的新視圖是一個不錯的主意。

　　Kappa Architecture是一個很好的方式將經(jīng)常請求的查詢進行緩存從而給出快速高效的響應。不幸的是，它本意不是為了同AWS一起用。AWS用戶可以運行一個Apache Kafka實例作為數(shù)據(jù)的主存儲，這將確保能夠建立新的視圖更簡單的能力。DynamoDB云則作為客戶的只讀源。同亞馬遜Kinesis的自動擴展能力相比，這種方法的缺點是開發(fā)人員將不得不維護Kafka以及處理關于擴展性的一切問題。

　　盡管如此，使用Kafka讓企業(yè)可以避免廠商的完全鎖定，因為所有的數(shù)據(jù)會以非專有的方法提供，能夠在別的數(shù)據(jù)存儲中復制，如果數(shù)據(jù)庫不得不在一個完全不同的云平臺重建的話。