漫談對大資料的思考

• 資料在我們的活動中扮演的角色發生了重大變化。

• 儘管大資料這個詞經常被用來描述這種變化，但這不僅僅是我們希望使用多少資料。

• 你可能想把“大”應用到資料的重要性上——資料在我們的生活中發揮著更大的作用，而不只是從字面上理解“大資料”。

• 大資料是一個引起大量炒作的術語。但我認為在這種情況下抵制我們通常對炒作的厭惡很重要——思維正在發生重大變化。

• 這種轉變迫使我們改變許多長期以來對資料的假設。它開闢了新機遇，但也需要新思維和新技能。

一 資料世界正在發生怎樣的變化

資料是凌亂的

在結構上

• 傳統上，資料被認為來自組織良好的資料庫，這些資料庫具有受控模式，具有強大的驗證條件。

• 但我們現在看到的資料有多種形式：日誌檔案、訊息佇列、電子表格。這些資料分散在整個組織及其生態系統中。

• 通常很少或沒有模式來控制其結構。

• 資料通常是不統一的，每個元素都具有不同的屬性。

在內容上

• 由於存在多個資料來源、眾包甚至自動推理和發現資料——資料質量存在很大問題。

資料是分散式

• 透過Internet的廣泛可用性和易於訪問意味著資料來自更多的貢獻者。

• 這引發了處理來自不同來源的許多更新、確保人們輸入有用資料以及考慮如何檢查輸入資料的一致性和準確性等問題。

我們曾經想過從資訊系統獲取資料，

但是現在有很多裝置需要考慮。

非洲98%的網際網路接入點是移動的，還有更多需要考慮的：

資料是量大的

• 沃爾瑪：每小時100萬筆交易†

• eBay：每天50PB的資料†

• Facebook：400億張照片

龐大的資料量足以擊敗許多長期採用的資料管理方法，集中式資料庫系統無法處理大量資料，因此不得不使用叢集。

最重要的是資料是有價值的

• 每年3000億美元：美國醫療保健

• 60%增長：零售利潤率

• 儘管很難獲得關於充分利用資料的價值的確切數字，但亞馬遜和谷歌等公司的成功在很大程度上歸功於它們對資料的有效利用。

二 如何應對這些變化

資料世界中正在發生的變化，我們需要了解軟體開發世界如何響應這些變化。

資料來自許多來源

提取資料很複雜，但真正的問題是知道去哪裡找

• 由於有用資料存在於如此多的地方，挑戰往往更多地在於認識到其中一些資料的價值。

• 通常只有每天使用應用程式的技術人員才知道有用資料隱藏在哪裡。他們可能知道資料是什麼，但通常不知道它的潛在價值有多大。

• 業務人員通常意識到問題，但不知道資料如何幫助他們，如果資料存在，它在哪裡。

所以跨職能協作必不可少

• 如果要將重要問題與資料匹配，則需要具有業務知識的人員、知道存在哪些資料的人員以及能夠了解如何處理資料以揭示問題的人員之間的協作。

• 瞭解哪些資料可用也是一項多學科工作。資料庫人員通常都非常瞭解資料庫，但要考慮更多的來源，讓廣泛的技術專家參與進來就很重要了。

資料管理的作用需要重新思考它是

• 旨在實現企業中單一、連貫和一致的資料模型

• 主要基於關聯式資料庫

• 專注於僅儲存經過驗證的資料

這些變化需要新的策略

• 需要新的資料庫技術來更直接地支援應用需求。應用程式團隊現在需要考慮哪種資料庫技術適合他們的情況，而不是對所有事情都使用單一（關係）技術。

• 資料的集中管理正在讓位於管理其自身資料需求的特定應用程式。中央小組現在需要專注於實現應用程式團隊之間的有效共享。

關係單一文化的時代已經結束，我們現在不得不問什麼是滿足我們需求的正確資料庫

• 二十多年來，關聯式資料庫一直是企業中占主導地位的資料儲存技術。

• 他們過去曾抵制過許多挑戰，但NoSQL資料庫的興起正在打破這種控制。

面向聚合的資料庫

適合

• 作為單個工作單元（聚合）讀取和操作的單一層次資料結構。

• 叢集操作，因為聚合是很好的分佈單位。

不是為了

• 以不同的結構對資料進行切片和切塊時

• 面向聚合的資料庫將複雜的資料結構儲存在一個單元中，而不是將資料分佈在許多表中的許多行上。

圖資料庫

適合

• 具有豐富連線結構的小資料單元

• 圖資料庫將資料表示為節點和弧形圖結構。它們專為快速遍歷圖形結構而設計，並支援可以根據圖形構建的查詢。

我們發現NoSQL資料庫適合企業應用

• 現在大型集團已經使用多個NoSQL資料庫構建了關鍵的生產系統，特別是Couchbase、Riak、MongoDB（面向聚合）和Neo4J（圖形）。專案團隊報告了出色的生產力，我們會推薦這些用於未來的專案。

但這並不意味著關係已死

• 關係資料模型以其簡單的表格結構和強大的查詢語言，是多種資料的正確選擇。

• 關聯式資料庫是成熟的技術，很多人都熟悉並且擁有良好的工具。除非對其他事情有充分的論據，否則它們目前仍然是預設選擇。

NoSQL、Relational和其他資料庫技術都擺在桌面上

• 關鍵點是資料儲存不是決定的時候結束了。現在必須根據如何使用該資料來主動選擇資料庫。

我們稱之為多語言永續性

• 企業應該期待針對不同應用程式的多種資料儲存技術。

• 當資料集具有不同的特徵時，即使是單個應用程式也可以使用多語言永續性。

許多組織將應用程式與共享資料庫整合

• SQL作為標準查詢語言的存在實現了共享資料庫整合。

• 它透過共享資料庫結構將應用程式相互耦合，使應用程式更難快速更改。

• 它為所有應用程式使用單一的資料庫技術和模式，這使得針對單個應用程式的需求使用適當的資料庫技術變得更加困難。

• 這使得簡單案例的報告更容易，因為SQL的報告工具很多。但報告需求通常會降低應用程式的速度，並且只能報告共享資料庫中的資料。

現在我們封裝資料庫並透過服務API共享

• 應用程式資料庫僅由單個應用程式使用。任何外部整合都是透過該應用程式構建和公開的API完成的。

• 透過應用程式API封裝資料庫，客戶端不再直接耦合到資料庫技術和結構。

• 應用程式API提供比底層資料庫模型範圍更廣的資料模型。

• 一個問題是分析客戶可能需要專門為他們建立的API才能以有效的方式獲取重要資料。如果這對應用程式開發團隊不重要，可能會出現令人沮喪的延遲和交接。ServiceCustodian方法可以幫助解決這個問題。

三 大資料分析過程

• 業務領導使用他們的戰略目標來指示應該使用哪些指標進行分析。

6個月對於有效行動來說太長了

• 迅速採取行動具有競爭優勢。

• 長週期時間會導致白費力氣，因為在您開始嘗試使用資料之前，很難理解哪些資料是重要的。

• 最重要的是，緩慢的迴圈時間會降低學習能力。每次透過該迴圈時，都會了解到哪些分析形式是有價值的，並且對下一步應該做什麼有更深入的瞭解。學習的速度放大了整個迴圈中速度的優勢。

因此，需要一種具有快速週期的敏捷方法

• 縮小每個週期的範圍，以便可以快速執行整個週期。

• 使用一個週期的結果來決定下一個週期要做什麼。

一個敏捷分析的例子

首先建立一個高層次的業務目標：我們如何識別即將離開的高價值客戶並激勵他們留下來？

接下來，選擇目標的一個小而簡單的方面作為分析起點： 離開的客戶有哪些共同特徵？

離開的顧客有哪些購物行為？

與業務利益相關者一起驗證結果的有用性和可操作性，並選擇另一個方面進行探索。

使敏捷分析方法發揮作用的一些指南

• 構建小團隊，一次只專注於一個方面。

• 不要試圖構建一個宏大的分析平臺，而是解決特定問題並收穫一個平臺。

• 利用輕量級的工具，可以根據需要逐漸建立能力。

• 將分析操作視為一個敏捷軟體開發專案，遵循敏捷應用程式開發的常規原則。

一項針對美國3,141個縣的腎癌發病率的研究揭示了一個顯著的模式。腎癌發病率最低的縣大多是農村，人口稀少，位於中西部、南部和西部的傳統共和黨州。你怎麼看這個？

難道是因為...

• 共和黨統治？

• 農村空氣和環境乾淨嗎？

現在考慮腎癌發病率最高的縣。這些境況不佳的縣往往大多是農村、人口稀少，並且位於中西部、南部和西部的傳統共和黨州。

這是由於小數定律

• 農村人口少

• 人口少是樣本量小

• 較小的樣本量傾向於極端

對這種結果的解釋就像張三和李四各自從罐子裡抽出綵球。每個罐子裡裝有相等數量的紅球和白球。張三抽了四個球，李四抽了七個。就機率而言，張三會比李四看到更多的所有相同顏色球的平局（8倍）。

這是統計資料進行錯誤直覺推理的一個例子

• 人們通常會錯誤地將原因歸因於偶然事件。

• 這種在隨機中看到模式的傾向可以透過多種方式來欺騙我們。

• 小數定律是機率錯覺的現象的眾多例子之一

• 就像光學錯覺混淆了眼睛一樣，機率錯覺混淆了我們的推理。

• 隨著我們更多地使用資料，這個問題可能會變得更加普遍，因為有太多人患有機率文盲。事實上，即使是科學家和數學家也經常被這些錯覺所愚弄。

我們有責任對自己和使用者進行機率錯覺教育

資料科學家是新的熱門職位

“資料科學家”很快將成為我們行業中最被誇大的職位。很多人會把它附加到他們的簡歷中，以期獲得更好的職位

但儘管大肆宣傳，還是有一套真正的技能：

• 探索問題並將其表述為可以用統計資料檢驗的假設的能力。

• 業務知識、諮詢和協作技能。

• 瞭解機器學習技術。

• 程式設計能力足以實現他們正在使用的各種模型。

儘管大多數資料科學家會很樂意使用專門的工具，但這不僅僅是知道如何使用R語言。瞭解何時使用模型通常比能夠使用它們更重要，如何避免機率錯覺和過度擬合也很重要。

視覺化在將資料轉化為洞察力方面發揮著關鍵作用

• 很難看出原始資料發生了什麼。

• 良好的視覺化應該側重於資料如何告知分析目標。

• 現代視覺化工具可以使用互動性和動態性來探索和挖掘細節，同時保留整體檢視。

• 瞭解視覺化的一個好方法是探索不同方法的示例。

• 這個“元素週期表”是一個互動式顯示，是使用不同視覺化技術的重要靈感來源。

• d3.js是構建視覺化的重要工具。

• d3.js是一個允許從javascript資料繫結到DOM元素的框架，對於建立動態svg視覺化特別有價值。

• 上述照片展示了許多使用d3構建的有趣的視覺化效果，併為視覺化和實現技術提供了靈感。

探索可能性

• 令人印象深刻的視覺化可能非常有價值，值得為建立它們付出相當大的努力。

• 但是不要糾結於複雜性，通常可以毫不費力地構建有用的視覺化效果。

• 可以嘗試使用迷你圖為值提供歷史背景。

• 在沒有任何先驗知識的情況下，花了幾個小時搜尋有用的顯示（使用jquerysparklines）。

• 只有在構建迷你圖後，才會意識到不需要其他一些資料顯示。

四 大資料是大炒作嗎

• 炒作層出不窮，但硝煙背後卻是大火。

• 資料呈現給我們的方式發生了重大變化，這些變化導致了行業響應的適當重大行動。

• 許多權威人士，都會對未來幾年的確切變化做出錯誤的預測。然而，我相信會有重大變化。

• 與任何技術計劃一樣，大資料工作需要由業務驅動。但是在這個平臺上探索的主題意味著與技術團隊的密切合作比平時更為重要。

• 這些表明了公司發展的能力和個人獲得的技能。

任何軟體專案都應該融入“大資料”思想

• 許多軟體專案可以做更多的工作來有效地公開他們的資料。

• 尋找更多可以有效提取資料的地方

• 與客戶和使用者密切合作，探索哪些資料有用。

• 小心避免機率錯覺

• 嘗試視覺化，從可以快速構建的簡單視覺化開始

• 所有這一切都需要創新思維，而創新思維通常來自在自適應過程中運作的小型多元化團隊。