本章内容
資料的屬性
基于事實的資料模型
大資料基于事實的模型的優點
圖模式
在第1章中，你看到了使用傳統工具建構資料系統時所走入的誤區，然後我們回到基本原理，以獲得更好的設計。可以看到，每一個資料系統都可以被定義為資料上用來計算的函數，并且你學習了lambda架構的基礎，這種架構提供了一種用來實時聲明任意資料上的任意函數的可行性方法。
lambda架構的核心是主資料集，這在圖2-1中是突出顯示的。在lambda架構中，主資料集是計算系統中的事實來源。即使失去了所有的服務層資料集和速度層資料集，你仍然可以從主資料集中重構應用程式。這是因為由服務層來服務的批處理視圖是由主資料集上的函數生成的，并且由于速度層隻基于近期的資料，它可以在幾個小時内進行自動重構。
主資料集是lambda架構中唯一不能受損的部分。過載的機器、失效的磁盤以及停電都可能導緻錯誤的發生，動态資料系統中的人為錯誤是内在風險且可能無法避免。你必須仔細設計主資料集，以避免所有這些情況下的資料損壞，因為容錯對于長時間運作的資料系統能夠正常工作是至關重要的。
對于主資料集，我們将探讨兩個方面：所使用的資料模型以及如何實體地存儲主資料集。本章介紹主資料集的資料模型的設計以及一個資料模型應有的屬性。第3章介紹如何實體地存儲主資料集。
在本章，你應掌握如下内容：
掌握資料的關鍵屬性
檢視這些屬性如何維護基于事實的模型
檢視主資料集基于事實的模型的優點
使用圖模式表示基于事實的模型
下面從具有普遍性的術語資料展開讨論。
按照本書的側重點，我們将圍繞一個示例應用程式展開讨論。假設你正在設計下一個大型社交網絡—facespace。當一個新的使用者（名叫tom）加入這個網站時，他開始邀請他的朋友和家人。關于tom這個使用者，你應該存儲什麼資訊？你有很多選擇，其中包括以下幾種：
tom朋友和非朋友事件的序列
tom目前朋友的清單
tom現在朋友的數量
圖2-2展示了這些選項和它們之間的關系。
這個例子說明了資訊的依賴性。請注意，每一層的資訊可以從前一個（其左邊）擷取到，但這是一個單向的過程。從朋友和非朋友事件的序列，你可以确定其他的數量。但是如果你隻有朋友的數量，就不可能準确地知道他們是誰。同樣，從目前朋友的清單中，不可能确定tom是jerry以前的一個朋友，或者近來tom的社交圈子有所增長。
概念的依賴性決定了我們将要使用的術語定義：
資訊是與大資料系統相關的知識的一般集合。這是“資料”一詞的口語化表達。
資料是指不能來源于任何其他東西的資訊。資料是衍生一切的公理。
查詢是向資料“詢問”的問題。例如，你通過查詢财務交易曆史來确定自己目前的銀行賬戶餘額。
視圖是來自基礎資料的資訊，用來協助完成特定類型的查詢。
圖2-3展示了facespace的資料、視圖和查詢這些術語的資訊依賴性。
注意，一個人的資料可以成為另一個人的視圖，這是很重要的。假設facespace已成為一個非常成功的網站，并且現有某第三方廣告商建立了一個網絡爬蟲，用來從該網站的使用者資料中擷取人口統計資訊。facespace可以完全通路tom所提供的資訊—比如他完
整的出生年月日（1984年3月13日）。但tom對他的年齡很敏感，他隻會讓3月13日這一資訊出現在自己的公開資料中。從facespace的角度來看，tom的生日是一個視圖，因為生日來自他的出生日期，但對廣告商來說這已經是資料了，這是因為他們隻掌握tom很有限的資訊。這種關系如圖2-4所示。
通過建立一個共享的詞彙庫，我們現在可以介紹資料的關鍵屬性：原始性、不變性和永久性（或“資料的永恒真實性”）。這三個關鍵屬性是了解大資料系統的基礎。
如果你有關系型資料庫的知識背景，這可能會讓你感到困惑。典型的表現就是你會通過不斷更新和總結資訊來反映目前世界的狀态，而不關心不變性或永久性。但這種方法限制了你可以利用資料回答的問題，并且對于避免錯誤和損壞來說也不夠“魯棒”。通過實作大資料世界裡的關鍵屬性，你會建構一個魯棒性更高的系統，獲得更強大的功能。
下面将深入讨論資料的原始性。
資料系統根據已經擷取到的資訊回答問題。當設計大資料系統時，你希望它能夠回答盡可能多的問題。在facespace示例中，這一社交網絡所擁有的資料比廣告商的資料更有價值，因為你可以據此推斷出更多關于tom的資訊。我們将這個屬性通俗地稱為資料的原始性。如果可以，你需要存儲可以獲得的最原始的資料。所存儲的資料越原始，可以問的問題就越多。
facespace示例有助于說明資料原始性的價值，但是現在讓我們通過另一個例子來更好地了解這個觀點。股市交易價格是資訊的來源，每天都有數以百萬計的股票和數十億的美元在轉手。随着這些海量交易的發生，我們每天都會記錄股票的曆史價格，包括開盤價、最高價、最低價和收盤價。但這些資料通常無法描述股市的大局，并且可能會改變你對某些事情的看法。如圖2-5所示，它記錄了當google針對競争對手釋出了新産品時，google、apple和amazon的股票在一天之内的價格資料。
這份資料表明，amazon可能沒有受到google公告的影響，因為它的股票價格隻有輕微波動。這份資料還表明，google的公告對apple完全沒有影響，或者說造成了積極的影響。
但是如果可以通路以更細時間粒度存儲的資料，你就能得到關于那一天所發生事件更清晰的總體圖像，并據此進一步探究潛在的因果關系。圖2-6實時描述了三家公司股票價格的相對變化，這表明amazon和apple确實受到了這份公告的影響，且amazon比apple受到的影響更大。
還要注意的是，額外的資料可以闡述一些你可能在檢視原來每天的股票價格概要時沒有考慮到的新方向。例如，更細粒度的資料讓你懷疑amazon是否受到了更大的影響，因為google的新産品與amazon在平闆電腦和雲計算市場都産生了競争。
存儲原始資料有巨大的價值，因為你很少提前想好所有問題的答案。通過盡可能地儲存原始資料，你可以充分利用自己的能力來獲得新的見解，因為彙聚、重寫或删除資訊限制了資料可以告訴你答案的數量。交易資料通常需要很多的原始資料—有時是海量資料。而大資料技術就是用來管理pb和eb級别的資料。具體來說，它們是以一種分布式的、可擴充的方式管理資料，同時提供直接對資料進行查詢的能力。
盡管概念很簡單，但你并不總是清楚應該存儲什麼資訊以作為原始資料。下面将提供幾個例子來幫助和引導你做出這個決定。
1.非結構化的資料比規範化的資料更原始
在決定存儲什麼原始資料時，一個常見的令人困惑之處就是解析和語義規範化之間的界線。語義規範化是将任意格式的資訊變成結構化形式的資料的過程。
例如，facespace可能會請求tom給出自己所處的地理位置。他可能會輸入該字段的任何資訊，如san francisco（舊金山）、ca、sf、north beach（北灘）等。語義規範化算法會嘗試将輸入資料比對為已知的地方，如圖2-7所示。
如果遇到非結構化位置的字元串形式的資料，那麼随後在調整算法時你應該存儲非結構化的字元串形式，還是語義規範化的形式？我們認為最好存儲非結構化的字元串，因為
語義規範化算法可能随着時間的推移有所改進。如果存儲的是非結構化的字元串，那麼随後在調整算法時你就可以重新規範化資料。在前面的示例中，你可以随後調整算法來識别north beach在san francisco附近，或者将相關資訊作為他用。
如果出現下述情況，需要存儲非結構化資料：作為經驗法則，如果用于提取資料的算法簡單、準确，比如從html頁面中提取年齡資訊，那麼應該存儲該算法的結果。如果出于改進或擴大的需求，算法經常要變化，那麼應該存儲非結構化資料。
2.更多的資訊并不意味着更原始的資料
通常人們會很容易地認為，更多的資料相當于更原始的資料，但事實并非總是如此。假設tom是一個部落客，他想将自己的文章添加到facespace資料中。當tom提供了他部落格的url位址時，你究竟應該存儲什麼？
存儲部落格記錄的純文字無疑是一種可能性。但tom特意強調了任何斜體、黑體、大字型的短語—在文本分析中，它們可能是有用的。例如，你可以使用這些額外的資訊作為索引，使得facespace可以被搜尋到。是以我們認為，與ascii的文本字元串相比，帶注釋的文本記錄是一種形式更為原始的資料。
此外，你也可以存儲tom部落格完整的html。然而，這會在總位元組數、配色方案、網站樣式方面存儲相當多的資料，并且該網址的javascript代碼不能用來獲得任何關于tom的額外資訊。它們隻是作為網站内容的容器，而不應該作為原始資料的一部分。
如果你精通關系型資料庫，想必會覺得不可變的資料似乎是一個奇怪的概念。畢竟在關系型資料庫和大多數其他資料庫中，更新是最基本的操作之一。但就不變性來說，你不會更新或删除資料，你隻是添加更多的資料。通過對大資料系統使用不可變模式，你将獲得兩個至關重要的優勢：
容忍人為錯誤—這是不可變模式最重要的優勢。正如第1章所讨論的，容忍人為錯誤是資料系統的基本屬性。人都會犯錯誤，你必須對這種錯誤所帶來的影響予以限制，并且需要有恢複機制。對于可變的資料模型，一個錯誤會導緻資料的丢失，因為在資料庫中，值會被覆寫掉；而對于不可變的資料模型，沒有資料會丢失。如果寫入壞資料，更早些（好）的資料單元仍然存在。修複資料系統隻是删除損壞的資料單元，并重新計算由主資料集生成的視圖。
簡易性—可變的資料模型意味着資料必須以某種方式被索引，這樣特定的資料對象才可以被擷取和更新。相反，對于不可變的資料模型，你隻需要能夠添加新的資料單元到主資料集中。這樣資料就不需要索引，這是一種巨大的簡化。在第3章中你會看到，存儲主資料集和使用普通檔案一樣簡單。
當與可變的資料模式進行比較時，保持資料不可變的優勢就會變得很明顯。圖2-8所示的基本可變模式可以為facespace所用。
如果tom搬到los angeles（洛杉矶），你就要更新突出顯示的記錄，以反映他目前所處的位置—但在這個過程中，你也會失去tom之前在san francisco的所有資訊。
對于不可變模式，情況則完全不同。不可變模式并不是存儲目前系統的快照，這是可變模式做的。不可變模式是每次使用者資訊有變化時，就建立一個單獨的記錄。完成該項工作需要兩個變化：第一，用一個單獨的表追蹤使用者資訊的每個字段；第二，當資訊真實時，及時将每個資料的單元和一個時刻連接配接在一起。圖2-9顯示了存儲facespace資訊所對應的不可變模式。
tom于2012年4月4日注冊了facespace，并提供了他的個人資訊。你首先了解到，這些資料的時間戳反映了記錄的時間。當他後來于2012年6月17日搬到了los angeles時，你需要在位置表中添加一個新的記錄，時間戳是他改變個人資料的時間，如圖2-10所示。
現在有tom的兩個位置記錄（使用者id 為3），并且因為資料單元與特定的時間綁定，是以它們都是真實的。tom的目前位置涉及對資料的簡單查詢：檢視所有位置，并選擇有最近時間戳的位置。通過在一個單獨的表中儲存每個字段，你隻需要記錄更改的資訊。這需要更少的存儲空間，并保證每條記錄都是新的資訊，而不僅僅是從最後一條記錄轉入。
不可變模式的代價之一是它比可變模式使用了更多的存儲。首先，使用者id對于每一個屬性都是特定的，而不像可變模式那樣一行一個。此外，存儲的是所有時間段的事件，而不是系統的目前狀态。但是被稱作“大資料”并不是毫無原因的。你應該充分利用大資料技術的能力來存儲海量資料，以獲得不變性的優勢。當然，也不能誇大一個簡單而較能容忍人為錯誤的主資料集的重要性。
不變性的主要結果是，每一塊資料都是永遠真實的。也就是說，一塊資料一旦真實，那麼就必須始終真實。如果不具備這個性質，資料的不可變性就無從談起了。你已經了解了通過打上時間戳來标記一塊資料—這是一種使資料永遠真實的可行方法。
這種思路和你在學校學曆史是一樣的。由于“1776年7月4日，美國包括13個州”這一資訊總是正确的，是以“自那時以來州的數量已經增加”的事實就被捕獲到額外的（也是永久的）資料中了。
一般來說，通過添加新的不變的和永遠真實的資料，主資料集會持續增長。但是在一些特殊的情況下，你需要删除資料，這些情況和資料的永遠真實性并不沖突。具體情況如下：
垃圾回收—當執行垃圾回收操作時，你應删除所有價值較低的資料單元。你可以使用垃圾回收，來實作控制主資料集增長的資料保留政策。例如，你可以決定實作一個政策，即每人每年僅保留一個位置，而不是每次使用者更改位置的全部曆史。
法規—在特定條件下，政府法規可能會要求清除資料庫中的資料。
在這兩種情況下，删除資料不是對資料真實性的聲明。相反，它是對資料價值的聲明。雖然資料永遠是正确的，但是你可能更願意“忘記”一些資訊，要麼是因為你必須這麼做，要麼是因為相對于所花費的存儲成本它不能實作足夠的價值。
我們将使用資料的這些關鍵屬性，繼續引入另一個資料模型。
删除不可變資料？
你可能會疑惑，我們怎麼才能删除不可變的資料。從表面上看，這似乎是沖突的。一個很重要的方面是要區分對待，這裡所說的“删除”是一種特殊的和少見的情況。在正常使用中，資料是不可變的，并且需要通過采取一些強制政策（如設定适當的權限），來確定其不可變。由于删除資料的情況很少發生，是以要非常謹慎地確定它能夠安全删除。首先需要生成“壞的”資料被過濾掉的主資料集的另一個副本，其次運作分析工作來驗證正确的資料是被過濾後的，最後再取代主資料集的舊版本—通過上述操作步驟來完成資料删除是最安全的方式。