背景引入：

鑑於大資料的性質及其分析能力，在專案開始時需要考慮和計劃許多問題，因此要求組織識別並建立一套獨特的治理流程和決策框架，以確保責任方瞭解大資料的性質，影響和管理要求。第三章通過詳細講解大資料分析時的主要的潛在問題和注意事項。 3.1-3.5資料分析之前要考慮的問題（同學講的是資料前期處理） 3.6-3.10 資料分析過程中可能遇到的問題（硬體和技術支援） 3.11 具體闡述分析過程（大資料分析的生命週期）

3.1 組織的先決條件：

大資料管理框架、能進行良好資料管理的高質量資料。

3.2 資料獲得（不應該為獲取）

Data Procurement為資料採購的意思，由於某些資料由公司的裝置或者其他平臺免費獲得，無需購買，所以我把這部分稱為獲得。（資料獲取指利用一種裝置，將來自各種資料來源的資料自動收集到一個裝置中，書中資料獲得方式更豐富）

網際網路或者企業獲取：直接從一些專業類服務網站上抓取或者購買（例如大眾點評、攜程），或直接從大家在其公開的地圖服務上的標註中進行篩選和獲取。這就是google、百度、高德自己免費向社會開放其地圖服務所能夠獲得的利益。尤其對於開放API免費企業客戶的使用，這種獲取是很有價值的。

3.3 隱私性

無隱私不資料，無資料就無服務。享受大資料時代便利的同時我們也在產生大量資料，通過平時瀏覽的網頁、購買的商品、出行的記錄等等行為都透露著自身的資訊，分析這些資料可以揭示一些隱私資訊。（通過大資料演算法勾勒出使用者肖像，然後把他們想要的、喜歡的精準送達，進而帶動商業價值實現幾何數級的增長。亞馬遜的個性化推薦助其銷售量翻番，而Facebook的精準廣告投放更是成功將大把的粉絲和流量變現，這些商業佳話也是我們隱私洩露的證明。） 解決這些隱私問題需要深刻理解資料積累的本質和資料隱私管理,同時也要使用一些資料標記化和匿名化技術。

3.4 安全性

資料儲存可以包含各種型別的資料，包括使用者應用程式引數、個人私密資料和醫療記錄、稽核以及安全日誌，甚至還包括使用者訪問應用程式所需的憑據。很明顯，這些資料都應該受到保護，不論是在存 儲期間還是在讀/寫的操作過程中，都要確保這些資料只能被擁有相應許可權的使用者訪問。 （舉例：資料訪問許可權集對具有相同科目表、日曆和期間型別的分類帳及其所有平衡段值或管理段值的定義讀寫許可權，系統管理員將其分配至不同的責任以控制不同的責任對分類帳資料的訪問。 感覺校園網認證算認證授權機制，上網不涉密，涉密不上網。）

3.5 資料來源（實指來源資訊，與資料獲得區別）

3.6 有限的實時支援

實時處理（流處理）：我想知道某個使用者A的行為資訊（例如A幾點幾分點選什麼商品，幾點幾分瀏覽過什麼），從而根據這些行為推薦出商品資訊。這類使用者的行為資訊是源源不斷的，一個接一個來，如A在7點40分32秒瀏覽了產品1，在7點40分35秒就看了產品2，這些資訊一個個來到，越積越多，要求要迅速處理這些資訊，沒有延遲。就像在溪流的某個地方設立一個檢測儀，檢測水(資料）的實時情況。批處理：根據使用者的一段時間的資訊推薦商品，比如我可以根據使用者1年在亞馬遜的消費資訊，統一進行分析處理。還是用水流的例子，我可以把水流的水（資料）都集中在一個大水箱裡面，然後分析水（資料）的情況。這樣的分析並不是實時的。總之流處理是實時性小任務的處理，它對處理的延遲容忍度較低，但是容錯性（發生的錯誤並從錯誤中恢復的能力）較高。

3.7 不同的效能挑戰（效能問題）

（1）資料量大導致查詢時間很長 （2）資料量增加導致單位資料的傳輸時間超過處理時間

3.8 不同的管理需求

管理框架結構作用：保證資料和解決方案環境以一種可控的方式被管理、標準化和逐步發展（譯文為演化）。因此需要一個良好的有價值的管理框架。

3.9 不同的方法論

為了解決資料的不同處理要求，要使用不同的方法論，考慮如何建立反饋迴圈使處理過的資料能夠重複細化。 舉例如下： 每一輪迴圈都能對操作步驟、演算法和資料模型進行微調以改善結果的準確性,為商業活動提供更高的價值。

3.10 雲

雲端計算：通過將海量的伺服器資源通過網路進行整合，排程分配給使用者，從而解決使用者因為儲存計算資源不足帶來的問題。 雲端計算技術就是一個容器，大資料正是存放在這個容器中的水，大資料是要依靠雲端計算技術來進行儲存和計算的。

3.11 大資料分析的生命週期

第一章中總結過資料的生命週期是從資料的處理過程角度給出的： 第三章的生命週期從組織和管理與大資料分析相關的任務角度給出的：