資料是不能從其他地方衍生的資訊的集合，但是在主資料集内，你可以用很多種方法來表示資料。除了傳統的關系型表之外，結構化的xml和半結構化的json文檔也是可以用于存儲資料的。然而，無論如何，我們都推薦基于事實的資料模型。在基于事實的資料模型中，我們把資料分解成（毫無疑問地）名為事實的基本單元。
在不可變性的讨論中，你簡單了解了基于事實的模型。在該模型中，主資料集會不斷增加額外、不可變的、帶有時間戳的資料。下面對已經讨論過的内容進行擴充，對基于事實的模型進行全面解釋：首先，在facespace示例的内容中介紹該模型并讨論其基本屬性；其次，繼續讨論如何，以及讓事實成為可識别的原因；最後，将解釋使用基于事實模型的好處，以及它為什麼對主資料集是一個很好的選擇。
圖2-11描述了facespace資料中關于tom的事實的示例以及事實的兩個核心屬性—它們具有原子性，并帶有時間戳。
事實具有原子性，因為它們不能再進一步被細分成有意義的元件。集合資料（如圖2-11中tom的朋友清單）可以表示為多個獨立的事實。由于結果具有原子性，是以不同的事實之間沒有備援的資訊。鑒于之前對資料的讨論，事實帶有時間戳應該不足為奇—時間戳使得每個事實都是不可變的且永遠真實的。
對于資料集來說，這些屬性使得基于事實的模型顯得簡單而富有表現力。我們還建議把一個額外的屬性加在事實上—可識别性。
使事實可識别：除了原子性和時間戳之外，事實應該與一塊唯一帶有辨別的資料相關聯。這通過例子最容易解釋。
假設想存儲facespace頁面浏覽量的資料，你可能采用如下方法（以僞代碼的形式給出）：
使用這個結構的事實資料不能唯一辨別一個特定的頁面浏覽事件。如果多個頁面浏覽是在相同的時間、相同的url從相同的ip位址傳入的，那麼每個頁面浏覽将擁有完全相同的資料記錄。是以，如果你遇到兩個相同的頁面浏覽記錄，就無法區分它們指的到底是兩個不同的事件，還是被意外引入資料集的重複記錄。
為了區分不同的頁面浏覽，可以給模式添加一個區分标志—為每個頁面浏覽随機生成一個64位的數值：
額外的區分标志使得彼此區分頁面浏覽事件成為可能，如果兩個頁面浏覽的資料單元是相同的（所有字段，包括區分标志），那麼它們指的就是完全相同的事件。
讓事實成為可識别的，意味着你可以多次寫同樣的事實到主資料集，且不需改變主資料集的語義。在做計算時，查詢可以過濾掉重複的事實。事實證明并且稍後你也将會看到，可區分的事實使得實作lambda架構的剩餘部分更加容易。
重複資料并不像你想象得那樣少
第一次看的時候，我們如此在意可識别性和重複性的目的可能不是很明顯。畢竟，為了避免重複，第一反應是確定一個事件隻被記錄一次。但是，當處理大資料時，事情并不總是這麼簡單。
一旦facespace變得更大，它将需要數百甚至數千台的web伺服器。建立主資料集需要将每一台伺服器的資料聚合到一個中心系統—這不是一項簡單的任務。有一些适合這種情況的資料收集工具，如facebook的scribe、apache flume、syslog-ng以及很多其他工具，但任何解決方案都必須是帶有容錯性的。
這些系統必須預先假設的一個常見的“錯誤”—存儲資料的目标網絡分區變得不可用。在這些情況下，容錯系統通常會通過重試來處理失敗的操作，直到它們成功。由于發
送者不知道哪些資料是失敗之前收到的，是以一個标準的方法是重新發送那些沒有被接收者接收的所有資料。但是如果最初嘗試的一部分資料已經進入元存儲，那麼最終會造成資料集中的資料重複。
有一些方法可以将這些類型的操作變為事務性的，但是相當複雜且是以損失性能為代價的。在系統中確定正确性的一個重要方法是避免棘手的解決方案。通過包含可區分的事實，免去了事務性地追加資料到主資料集的需要，使得整個系統的正确性更容易保證。畢竟，如果資料模型的一個小調整可以完全避免這些挑戰，為什麼還要給自己施加重負呢？
快速回顧基于事實的模型的特點：
将原始資料存儲為原子事實
通過使用時間戳保證事實的不變性和永遠正确性
確定每個事實是可區分的，這樣查詢過程可以區分重複
接下來，我們将讨論為主資料集選擇基于事實模型的優勢。
使用基于事實的模型，主資料集将是一個關于不可變的原子事實日益增長的清單。這不是關系型資料庫内置支援的—如果你有關系型資料庫的知識背景，你可能感到天旋地轉。好消息是，通過改變資料模型範例，你可以獲得許多優勢。具體來說，資料有以下特點：
任何時刻的曆史資訊都是可查詢的
容忍人為錯誤
隻需要處理部分資訊
擁有規範和非規範形式的所有優點
讓我們依次來看看這些優點。
1.資料集任何時刻的曆史都是可查詢的
不隻是像使用可變的關系模式那樣存儲系統的目前狀态，你可以在資料集中查詢任何時間的資料。這是具有時間戳和不可變性的事實的直接結果。通過添加帶最近的時間戳的新事實，來執行“更新”和“删除”操作，而且因為沒有資料被實際移除，你可以通過查詢指定的時間，重建該系統的狀态。
2.資料是容忍人為錯誤的
容忍人為錯誤是通過簡單地删除任何錯誤的事實來實作的。假設你錯誤地存儲了tom從san francisco搬到los angeles的資訊，如圖2-12所示。
通過删除los angeles的事實，tom的位置會自動“重置”，這是因為san francisco的事實成了最新的資訊。
3.資料集能簡單處理部分資訊
每個記錄存儲一個事實，這樣使得處理部分資訊變得更容易—這些資訊是關于無須引入null值到資料集的實體的。假如tom提供了他的年齡和性别，而沒有提供他的位置和職業，那麼資料集将隻有已知資訊的事實—任何“缺失”的事實将在邏輯上等效為null。一段時間後，tom提供的額外資訊将自然而然地通過新的事實引入。
4.資料存儲層和查詢處理層是獨立的
基于事實的模型的另一個重要優勢在一定程度上取決于lambda架構本身的結構。通過在批處理層和服務層存儲資訊，你可以用規範化和非規範化的形式儲存資料，并且同時擁有這兩種形式的優點。
規範化是一個被反複使用的術語：資料規範化與之前使用的語義規範化術語是完全無關的。在這種情況下，資料規範化是指以結構化的方式存儲資料，來減少備援和促進一緻性。
讓我們用一個涉及關系型表格的例子來做好準備—資料規範化的内容是最常見的。關系型表格需要你在規範和非規範模式之間進行選擇，基于什麼對你最重要的（查詢效率或資料一緻性）。假設你想要存儲不同興趣的人的就業資訊，圖2-13提供了一個适合這一目的、簡單非規範化的模式。
在該非規範化的模式中，同樣的公司名稱可能會存儲多個行。這将讓你能夠快速确定每個公司的員工數量，但是一旦公司改了名稱，你需要更新很多行。将資訊存儲在多個位置會增加資料不一緻的風險。
圖2-13 存儲就業資訊的一個簡單非規範化的模式
作為比較，下面來看一下圖2-14中的規範化模式。
圖2-14 兩張存儲相同就業資訊的規範化的表
規範化模式中的資料僅存儲在一個位置。如果将backrub改為google，那麼隻有company表中的一行需要修改。這消除了不一緻的風險，但你必須連接配接兩張表來響應查詢—這是潛在的昂貴計算。
規範和非規範模式之間的互斥選擇是必要的，因為對于關系型資料庫，查詢是直接在資料存儲層面執行的，是以你必須權衡查詢效率與資料一緻性的重要性，并在兩種模式之間進行選擇。
相比之下，查詢處理和資料存儲的目标在lambda架構中是清楚地被分離開的，如圖2-15所示。
在lambda架構中，主資料集是完全規範化的—就像你在基于事實的模型的讨論中看到的，沒有資料是備援存儲的。因為添加一個新的帶有時間戳的事實“覆寫”了任何以往相關的事實，是以更新是很容易處理的。
圖2-15 lambda架構通過在不同的層分離目标獲得了規範化和非規範化的所有優點
同樣，批處理視圖就像主資料集中一塊資料的非規範化的表，主資料集可能會被索引為許多批處理視圖。關鍵的差別是，批處理視圖被定義為主資料集上的函數，是以，沒有必要更新批處理視圖，因為它将不斷從主資料集重建。還有一個額外的好處就是批處理視圖和主資料集将永遠不會失去同步。lambda架構以不同的方式來優化查詢，擁有索引資料的性能優勢，提供了完全規範化的優勢。
總的來說，所有這些優勢使得基于事實的模型是主資料集非常好的選擇。在理論層面的讨論已經夠多了，下面讓我們深入實際，實作一個基于事實的資料模型的細節。