If You Have Too Much Data, then ‘Good Enough’ Is Good Enough

1. If You Have Too Much Data, then ‘Good Enough’ Is Good Enough Pat Helland Microsoft Corporation Communications of the ACM,Volume 54 Issue 6, June 2011 指導教授:林娟娟 報告人:林佳緯

2. 前言 • 在過去資料量不是很大的時代裡，我們使用傳統的關聯式資料庫（Oracle、MS-SQL、MySQL..）就能為我們提供清晰與明確的查詢結果。 • web2.0網站的興起，周邊應用服務的資料量越來越大，資料儲存容量的需求越來越大，那是因為資料量只會暴增，絕對不會遞減，當資料量暴增的同時，處理資料的速度就必須跟進，所以過去的關聯式資料庫必須要有所改變。

3. 大綱 • 新興的資料庫”NoSQL” • 原則侵蝕 • 愛因斯坦做的事情 • 你到底在說什麼?! • 你喜歡穆利根燉嗎? • 海森堡是一個樂觀​​主義者 • 結論

4. 新興的資料庫”NoSQL” • NoSQL，意為”Not Only SQL”，並不是要來取代傳統資料庫的，而是作為傳統資料庫的補充。 • 優點:具有水平伸縮性、高並發讀寫性能、高可用性等優勢。 • 缺點:大部分都是只支持Key-Value 操作、有限制的查詢功能、不能使用類似Join等這樣的功能、大部分為一致性模型、還沒有標準化。 • 適用於具有大量的資料、不需要復雜的Join查詢等功能，但是需要高並發讀寫，例如微博、Facebook等等的網站。

5. 原則侵蝕

6. 原則侵蝕 • 傳統的SQL資料庫原則正被許多資料侵蝕: • 解鎖的資料(Unlocked data):傳統SQL先鎖定資料在進行交易，解鎖資料改變傳統資料庫的語義。 • 不一致的架構(Inconsistent schema):不同的文件來自不同的來源，必須要解決可擴展性、不同的與未知的語義問題。 • 提取、轉換、加載(Extract, transform, and load):資料可能來自不同的來源，你必須試圖找出類似的共同性。 • 推斷模式(Patterns by inference):你有沒有想過連結在哪裡?通過不斷的研究資料，你能推斷出什麼? • 太多不精確(Too much to be accurate):當你再計算的時候，答案可能會改變。太多、太快，你需要一個近似值。

7. 業務需求導致損耗答案 • 雖然我們希望能獲得完美的資訊，但業務需求的答案，通常是不完美的。 • 資料導致挑戰:可能是同一個時間中出現一個龐大的資料量;它可能來自不同的來源或不明來源。 • 流程導致挑戰:您可能需要轉換，轉化，轉譯資料，因此流失了一些資訊。 損耗

8. 愛因斯坦做的事情

9. 交易、傳統資料庫，“現在” • 知識傳播的速度為光速，當你看到他的時候，它可能已經改變了。 • 可串列化(serializability):每一筆交易都是不可分割，交易的並行執行就相當於以某種任意順序依序地執行這些交易。 • SQL資料庫依賴於生活中的“現在”，以提供他們的語義。 雖然許多 SQL系統提供了寬鬆的一致性語義增加並發性，交易可串列化仍然是最清晰的方式來思考一般的SQL機制

10. 交易、傳統資料庫，“現在”

11. 解鎖資料不是“現在” • 發送訊息時，他們通常是跨邊界，可以支持分佈式交易，因此，資料沒有交易的保護。相反，資料通常會賦予一個身份和一個版本。當發送訊息後不久可能會更改原始系統中的資料。 • Google‘s Megastore • 是一個內部的存儲系統,它的底層數據存儲依賴Bigtable,也就是基於NoSql實現的。 • Microsoft’s SQL Azure • 是建構在Windows Azure雲端作業系統之上，執行雲端運算 的關聯式資料庫服務，是一種雲端儲存的實作，提供網路型的應用程式資料儲存的服務。

12. 你到底在說什麼?!

13. 我嘗試去了解，但是你的腔調很重 • 在不同的公司，不同的國家，甚至在一個國家內不同的地區，對資料各有不同的理解，有時候是很難去溝通，例如同一間公司但不同的部門有時候還比外部的合作伙伴還難溝通。

14. 誰是狗，誰是尾巴？ • 當兩個組織的溝通，始終存在著經濟的狗和經濟的尾巴，狗想搖擺尾巴，尾巴就得搖擺。 • Walmart在零售業擁有主導權，他希望他的廠商。 除了包裝和標籤可以統一標準外，​對與廠商溝通的通訊也能統一標準。 • P&G在台灣算是零售業的龍頭，也要求廠商使用同一套的ERP系統，達到資料統一。

15. 描述性的，不是指令性架構 • 在非常大的和鬆散耦合系統，我們看到的描述，不是指令性的架構： • 描述性架構(Descriptive schema): • 在資料被寫入時，作者會描述主旨是什麼。 • 指令性架構(Prescriptive schema): • 資料被迫固定格式，所有作者保持一致性的分享。

16. 你喜歡穆利根燉嗎?

17. 穆利根燉 • 在20世紀初，生活在鐵軌上的流浪漢，經常吃“穆利根燉(Mulligan Stew)”，社區成員會貢獻出任何材料，然後將一切都丟入鍋內翻炒燉煮，可以有許多不同食材，而剩下的飯菜將成為明天的鍋底。 雖然這道菜很好吃，但是很難定義裡面的內容。

18. 提取，轉換和加載 • 許多資料系統執行提取，轉換和加載(ETL)：從一個或多個來源收集資料，轉換成一個新的形式，然後存入資料存儲庫。 • 資料轉換往往是一個有損耗的操作，這意味著轉換後的訊息比以前少。 但是你不能把轉換後的資料，恢復成原來的訊息。 O X

19. 建立一個異構的產品目錄 • 如Amazon、 Google Shopping、Bing Shopping的購物網站從數以百萬計的來源收集資料，資料回饋來自合作廠商與瀏覽網站資料的組合。 • 資料很少有一個標準格式，而且如果有的話，也會有語義的挑戰。 • 第一步是釐清。這樣就可以進行比較、比對，進而統一的數據。 • 誰是製造商:HP,Hewlett-Packard, Hewlett/Packard, H-P? • 這是什麼顏色:綠、祖母綠，蘆筍，黃綠色，橄欖?

20. 身份識別和模糊性 • 有很多競爭和統一的機制，分配一個唯一的數字類型的產品， • GTIN（全球貿易識別號碼）、UPC（通用產品代碼）、EAN（歐洲商品編號）、 ASIN（亞馬遜標準識別號碼）、ISBN（國際標準圖書編號）。 • 規範標識的挑戰的一個例子，不同的ISBN是分配給每本書的每個版本。 這意味著，每本書的不管是平裝本或者是精裝本都有一個獨立的身份。

21. 通過推理的觀察模式 • 然而，另一種形式的知識收集模式和推理。通過研究數據的內容，它有時可以推斷，兩個看似不同的身份實際上是相同的。 • 推理引擎看身份之間的關係， 一旦你意識到兩個身份是相同的，將合併成一個，形成新的人際關係。

22. 當​​你最不希望它時，意外發現 • 透過推理引擎所收集的資訊是非常有價值的。 • 詐欺分析(Fraud analysis): • 冒用信用卡的使用模式。 • 國土安全(Homeland Security): • 追蹤可疑人士的行為模式。 • 項目匹配市場目錄(Item matching in marketplace catalogs): • 出售的產品哪兩種型號相同?

23. 通過窺鏡 • 考慮選購大型和可伸縮的NoSQL模型應用程序，，我們必須考慮到，不可避免地伴隨他們的資料語義應用程序可能要簡化與精煉資料。 這種觀點難免會損耗資料，但也只有接受損失的必然性，我們才可以獲得可看性的商業價值。

24. 海森堡是一個樂觀​​主義者

25. 海森堡是一個樂觀​​主義者 • 海森堡表明，事情小，但我們沒辦法了解全部，而相反來說，事情大，我們因此感到困惑。 • 海森堡指出，在一個小規模的，不確定性是生活中的事實。在大規模計算，不確定性也是生活中的事實。

26. 美國人口普查 • 任何一個大集合的人口普查是很困難的。 • 我們無法在同一個時間在每個房子。 • 與女友生活再一起但是沒告訴父母。 • 如果有人去世，你要算他什麼? • 在出生前，進行普查。

27. 結論

28. 結論 • NoSQL系統即將興起，因為資料是不斷變化的。 • 資料的大小與異質性根本沒辦法符合舊系統的保障。幸運的是，我們正在學習如何在傳統資料庫之外的方式，以滿足業務需求。 • 我們需要一個新的資料理論和資料分類: • 身分與版本(Identity and versions) • 推導(Derivation) • 損耗的推導(Lossyness of the derivation) • 屬性模式(Attribution by pattern) • 傳統鎖定資料庫資料(Classic locked database data)