對於很多中小企業而言，在數據方面一般存在著：數據不完整、數據指標不完善、統計口徑不一、數據更新不及時等問題；在數據利用方面一般存在著：因數據分散而難以整合，因技術門檻而難以實現數據價值呈現。 現大多企業已經意識到數據管理對決策帶來的指導性價值，都紛紛重視數據治理工作，重新部署BI、針對核心業務上線大數據分析軟體平台。都希望搶佔這一刻先機，實現數據最大程度的轉換為業務價值。 而對於佔據國內比重最大的中小企業，在數據管理方面，有不足也有機遇。不足在於由於預算技術等方面的原因，信息化建設相對落後。那又談何機遇呢？大多數中小企業的數據量不是很大，管理建設也在發展和完善中，數據的治理、整合以及報表製作體系，分析指標體系搭建的工作還大有可為，推翻的東西較少。除此之外，數據化的意識融入到管理中，未來有很長一段的時間完善，被大家所接受。 當前流行的輕量化的數據產品是滿足企業輕量化信息化建設需求的最便捷途徑。 對於數據的使用，帆軟接觸到的最直接的就是通過業務報表體系的建設，來整合數據、完善流程、可視化業務分析，讓數據驅動企業。 一般而言，對於大多數企業，數據的高價值主要體現在幫助企業「了解過去發生了什麼事，了解當前正在發生什麼事，明確各個事件/問題發生的原因，預測未來可能發生什麼事，進行全局優化這一「從數據到全局優化」的轉化過程中。 換種方式來描述這一價值顯現過程，即為「數據查看，數據監控，數據分析，分析結果應用」。對應的數據分析/報表體系建設，就是數據查詢、管理分析和主題分析。 基礎查詢報表滿足的是「數據查看」的需求，主要給業務人員或一線管理人員看的，偏執行層面，用以每天了解自己所負責工作的具體情況，比如我想了解我負責的業務昨天做的怎麼樣了，最近一周或一個月的進展如何等。 關鍵指標是基礎看板的主要組成元素。不同公司、不同部門、不同業務的基礎看板必定是不一樣的，比如對於電商來說，運營部門的KPI是用戶復購、用戶流失率、用戶轉化率等，銷售部門的KPI是銷售額、用戶數、銷售量、利潤額等，市場部的KPI則是流量、新用戶等。基礎看板質量的高低，取決於該看板的設計者對其業務理解程度的深淺。在設計時，基礎看板在最好能夠選擇時間段，這樣如果昨天的數據出現了問題，就可以選取過去一段時間的數據，看看是否是趨勢上出了問題。選取的指標越豐富越好，指標越豐富，對於業務的把握就能越全面越詳盡。數據粒度一般都會很細，數據粒度主要針對數據的計算範圍，比如統計用戶增長情況，選擇按周統計，其粒度就不如按日進行統計細緻。 如下圖用finereport搭建的數據查詢表，稍有偏數據監控： 管理分析滿足的是數據監控、業務分析的需求，主要使用者是管理層，用以揭露業務運轉上的不暢或問題。例如店長業績管理看板、庫存管理、異常店鋪管理等。這類報表基於日常管理工作，通過查看這類報表來監控所負責業務的當前狀態，發現問題，這類報表就屬於決策輔助了。 管理類報表需要對業務有一個全面基本的了解。在規劃時，先建立一個初步規劃的模型，與業務與領導進行深入的溝通，溝通的目的是挖掘他們關注的點，即需求，然後再完善。 主題分析滿足的是特定業務場景分析的需求，主要用於明確各個事件/問題發生的原因，以及預測未來可能發生什麼事。主要對象是數據分析師傅、經營分析師、商業分析師（不同公司叫法各有不同）。 分析報表是數據由低價值轉換為高價值過程中的重要一環，因為它是全局優化的基礎，直接影響著優化方案的可實現性和有效性。分析類報表相比於管理類報表跟具主動性，往往是帶有一定目的去查看和分析，並非基於日常工作，所以分析類報表除了基於基礎的數據外，還要根據目的結合多種分析方法或分析工具來實現。 商品分析 中小企業的數據管理往往並不難，業務相對簡單，需求相對明確。但是重要的前提是，數據規範、以及指標數據口徑的的統一，底層基礎建設好了，往後的路就好走多了。

某位網友在筆者的搭台唱戲文章中留言，「企業內部的大數據普及很困難，看看以前BI的推廣情況就知道了。」這個問題很尖銳，也直指問題的核心。（註：這裡的BI 特指專題分析、精確行銷等內容，不包括傳統意義上的報表取數） 擁有大數據的企業，對內運營的意義不必多說，而判斷大數據運營成功的一個標誌，就是企業能否自覺採用數據化的思維和手段來解決生產經營中的問題，企業成立了新的大數據組織，這些組織的一個使命就是普及大數據在本企業的應用。 筆者從傳統BI時代走來，知道普及BI和大數據本質並沒有什麼不同，面對同樣的機制、業務和流程，有多少信心說大數據對內就能成功？ 但仔細比較下傳統BI和大數據所處的環境，的確發生了很多變化，也許能給大數據的普及以新的機會，希望能回答以上網友的質疑，當然仁者見仁了： 1、天時已經完全不同 大數據和BI本質都是數據化的運營手段，其對內推廣成功與否是受制於天時地利與人和的，所謂時勢造英雄，假如企業屬於爆發增長期，這個時候重要的是資源驅動，速度驅動和執行力驅動，而精細化運營的手段似乎性價比不高。 比如運營商大發展時期，新增用戶不需要分析的多精細，動感地帶、神州行和全球通三個品牌已經定位的很清楚，大家發力行銷就可以了，春節迴流車站擺攤賣卡的效率就很高。 BI中的精確行銷等手段，實施的成本現在看來其實很高，溝通成本，計算成本，數據成本，變革成本等等，特別是傳統企業線下為主，大幅抑制了數據價值的發揮。 這也是傳統BI無法普及的一個根本原因，在驅動力問題未解決之前，妄談數據價值，建模能力就失去了意義，對於依賴迭代優化的數據分析來說，甚至不會給你有效迭代的機會。 如果企業進入了存量運營期，則需要考慮更為精細化的手段了，這個時候，BI或大數據分析軟體才有了用武之地，因為數據化運營的方式性價比可能超過了傳統方式。 筆者前面說了這麼多，只是為了說明，大數據要有用武之地，跟企業的發展階段是密切相關的，當前 「大數據是大忽悠」 的說法不在少數，不能說沒有道理，對於還不具備條件的企業，你跟他去推銷大數據，的確就變成大忽悠了，需要辯證的看這個事情。 因此，筆者提的決戰大數據對內運營，針對的企業是有嚴格限制的，即已經過了高速發展期、擁有大數據、開始謀求轉型發展、希望採取更為精益化手段來實施高效低成本運作的企業，比如運營商。 2、數據已經完全不同 在傳統BI的時代，其實專題分析使用的原始數據跟業務人員平時報表製作取數能接觸到的原始數據並沒有什麼不同，由此僅靠挖掘能帶來的價值是有限的，再好的規則或演算法，也頂不上引入一個新的好數據。 以運營商為例，以前經分( BI )用的更多的是B域數據，大概300多個核心介面，現在B域的介面超過1400個，兩者相差很大，而 B域數據的量僅佔到公司總數據的10-15%，運營商更多的是O域數據，比如DPI位置，位置信令等，浙江行動一天計費話單2個多億，但上網日誌700億，兩者是幾何級的差距，在大數據平台未起來之前，要採集這些數據是不可能完成的任務。 其次，B域數據更多的是結構化數據，雖然價值密度高，但從數據中生成新數據的可能性幾乎為0，B域的一條用戶賬單記錄跟O域的一條上網日誌記錄，後面蘊藏的含義是不同的，從上網日誌我們可以爬取到網頁的內容，從內容中我們能挖掘到更多信息。 更為關鍵的是，大量的新數據我們還沒搞懂是什麼含義，大量的新數據有待於去採集，這是一個全新的藍海。 無論是BI還是大數據推廣，將更全更多維度的數據行銷出去是最重要的，有了新的生產資料，一線就可以基於生產資料馬上進行生產，即使生產關係暫時是落後的。 因此，在企業內，保持一隻專註於大數據整合和質量的團隊，採集解析更多的數據，終是企業搞大數據的第一要務，但現實情況往往是，即使當前企業有大數據的團隊，但主要還是在做報表取數的需求類工作。 同時很多企業傳統的數據分析者的思維模式還停留在G或者T時代，全然沒想過P是什麼概念，也沒想過去用它，這是思維的局限。 3、平台已經完全不同 站在業務人員的角度來講，大數據平台是hadoop還是DB2或是Oracle沒有什麼區別，人家要的只是一個數據操控體驗，數據操控體驗可以分解為以下幾個要素，也正是大數據平台要解決的核心問題。 數據字典一目了然，數據處理速度足夠快，資源申請足夠快，數據操作足夠方便， 這是大數據對內運營的第二個核心問題，我們即使有了好數據，但一線接觸不到，使用不好也失去了意義，而要降低這個門檻對於大多企業挑戰很大。 為什麼？ 因為我們不是BAT，大多的平台和產品來自於合作夥伴，對於企業技術人員來講，產品的體驗差點能忍受，但對於企業大多的業務人員，卻是過不去的檻，不可能去向他們推廣hadoop後台吧，總要封裝個可視化界面啥的， 如果將業務人員當成客戶，我們就得把自己當成產品經理，這對於產品的要求就拉高了一個層次。 為什麼運營商要提核心能力自我掌控，道理往往在那裡，因為合作夥伴把企業的技術人員當客戶，而真正的用戶卻是業務人員，這個差距就需要有人去彌補。 我們在推廣大數據的過程中，一個核心工作是要將平台的體驗做好，包括打造一本真正業務化的數據字典，一個足夠快的資源申請流程，一個傻瓜式屏蔽技術細節的開發運行環境。 大家都在喊PaaS，但大多人理解的這個PaaS是技術人員的PaaS，而不是給我們真正的用戶的PaaS，在提搭台唱戲的時候，又有多少人想到了業務人員的體驗？ 4、授予業務人員的漁 有人會質疑，大數據平台怎麼會直接給業務人員用？ 筆者以前提過，大數據的特點決定了業務人員才是大數據平台唱戲的主角，業務人員必須革命自己，必須自己去挖掘大數據的價值。 最近企業剛剛完成了全省的第一次建模大賽，也驗證了筆者的看法，大賽的題目是寬頻挖潛，業務人員的模型準確率輕鬆的擊敗了省公司技術人員折騰了半年的模型，差距在哪裡呢？就在於業務的理解，很多因素不是技術人員在實驗室里能想出來的，號稱熟悉業務的大數據人員，遠沒有在一線的業務人員更能理解業務的精髓。 如果平台體驗做的足夠好，業務人員不僅能操作SPSS，操作SPARK也不是不可能的事情。 技術人員要做的就是全力做好數據、平台及體驗，並做好培訓。 當然，如果企業需要探索新的業務，比如對外變現，這個時候，雙方處於同一個起跑線，無所謂誰做誰有優勢，一定程度上講，技術部門去做大數據新業務的探索，更有優勢，畢竟數據和技術直接捏在手裡，也不受傳統機制、流程的束縛。 關於如何做培訓，筆者在《我們需要什麼樣的大數據培訓？》中有相關的闡述，最近的一點體會是培訓也要有平台化思維，只有做成標準課件才能儘快擴散，因為講師有限，不可能總是親身現身說法。 5、自頂向下是星星之火 每個企業有自己的機制、流程和文化，大數據是一種新的工具，要普及推廣一個工具離不開企業一把手的支援，更離不開一線管理者的認可，畢竟學習新的工具是有成本的，企業要為儲備新的能力付出代價。 大數據更多時候是一種數據化的決策的思維，其價值的發揮是潛移默化的，可能在相當長的時間內沒有明顯的收益，這個時候，更考驗企業上層管理者的耐心，也正因為不是一棍子買賣，一旦企業形成了大數據的優勢，其形成的競爭力也是別人難以企及的。 當前很多企業的管理者身體力行的支援大數據的發展，這為企業的大數據普及工作提供了動力。 最後，企業搞大數據對內運營是一項艱巨的工程，沒有什麼現成的經驗，大家都是摸著石頭過河，但還是需要用發展的眼光看它。 作者 | 傅一平 來源 |與數據同行

數據可視化是數據呈現的趨勢，很多人卻對此產生質疑，認為數據可視化只不過是走花哨、抬逼格。更有人舉出例子，說做了各類圖形化報表，領導只是「嗯，哦」了一下，決策仍就是拍腦袋決定。 質疑分析 ——————————————————————————————————————————– 首先，要搞清楚數據可視化和信息圖兩者的概念好和實際應用。 信息圖是指數據的可視化表現形式。主要應用於必須要有一個清楚準確的解釋或表達甚為複雜且大量的信息，例如在各式各樣的文件檔案上、各個地圖及標誌、新聞或教程文件，表現出的設計是化繁為簡。 數據可視化是數據視覺表現形式的一種技術，實際應用於數據分析生產、分析過程中的決策輔助，大量服務於企業機構。 為什麼會有這樣的質疑呢？打個比方，數據可視化就好比一杯燒酒，適量喝暖身，過渡喝傷身，甚至紙醉金迷，不知所以。 可視化誕生的目的肯定是沖著好的方向去的，目的就是直觀地展現數據，讓花費一個小時才能歸納的數據量，轉化成一眼就能讀懂的指標；讓加減乘除、各類公式權衡計算得到的兩組數據差異，在圖中顏色敏感、長短大小即能形成對比；讓拿著各類excel報表愁眉苦臉的領導，對手中拿著酷炫報告的你，讚賞有加。 很多經典的應用，比如股市裡的K線了，其試圖以可視化的目的來發現某些規律。 再如布林線之類的，像石頭剪子布遊戲擴展到斯派克蜥蜴紙的遊戲，也可以用一張信息圖來顯示 ，跟上邊的圖差不多，放大後，單從點的方式來看也方便的不少，更重要的，此類圖實現了信息的壓縮，最少的路徑達到了信息量最大的目的。 而以下的信息圖 這一類表達形式在新聞媒體中比較多，大家看到的微信、微博、經常通過信息圖直接呈現結果，某個現象，幫助達到耳目一新的傳播效果。媒體有媒體的立場，有他們的目的，這裡不多闡述。 複雜的數據可視化有可能本末倒置 比如以上數據可視化的圖，數據量多、複雜，私以為歸納不出信息。如果只是為了讓數據都堆砌在圖表裡，看起來很酷的話，很容易本末倒置。這裡會涉及到主觀心理，你的分析會遵從你已經構想好的分析去「執行」，沒錯，就是執行，會讓你的數據報告看起來不那麼可觀。舉個最簡單的例子（自己編的，可能不那麼恰當，只為陳述觀點），比如一組數據，98、97、96、97、99、96。 同樣一組數據應為坐標軸的分度不同，差異很大。左圖的心理是為了反映個學生間的差異，有圖的信息是為了反映整體情況。撇去圖不看，只看數據，差距不大確實無可比性。 數據可視化是通過處理數據來反映一些問題和規律，而不是將結果誇張化。 有趣的信息圖也是知識獲取的有效途徑 無論數據可視化還是自信息圖，能從有用到有趣的過程，有趣明顯能激勵人讀下去，就是易讀了。 比如，生物存活年限 比如，結合實物場景，生動展現數據。 使用箭頭，創造流動感。 實際應用的數據可視化。 這一類用得最多的是企業機構，信息化部門、數據部門和業務部門了。這些實際生產過程中的數據，需要落實到切切實實地決策和管理中來。比如帆軟報表FineReport以及FineBI搭建的數據可視化分析平台。 利用大屏監視企業全局重點指標。如各業務，如銷售、財務、供應鏈的主題分析 維度切換實現不同角度的數據展示和分析。 最後，題外話。數據可視化已經不滿足於信息的呈現，而更應該落實到有據可循的分析和決策制定中去（如上文講到的實際案例，大家可自行對比）。 假設，領導拿到這份銷售報告，發現這季度的銷售量下滑得厲害，究其原因時，毫無頭緒，還得問銷售經理，如果你在製作這類數據可視化報告的同時，能夠有意識的植入分析的思考，鏈接到各大區銷售情況，各區域銷售成本支出，或者回款滯留情況，項目進展進度等相關的數據報表製作，我認為這才是一份合格的數據可視化報告。

保險是一個非常依賴數據的行業，無論是家財險、車險還是意外險、健康險等等，在各個細分領域都具有廣泛的應用。從承保理賠的全流程來說，市場推廣、客戶承保核保、消費體驗、到理賠續保等環節，從始至終的整個商業智慧流程和保險價值鏈都是由（也應該由）數據驅動的。可以說，數據就是保險行業的血液，而數據分析、數據挖掘、精算等技術手段都能夠幫助實現利潤提升和成本控制。 因此越來越多的保險企業開始關注所謂的「大數據」。然而，並不是只要擁有理想的風帆就能到達美麗的彼岸，對於數據資產的應用也是如此。儘管數據挖掘、機器學習等方法炙手可熱，但其應用實踐卻遠遠落後於真實需求。 首先，國內的保險企業普遍缺乏科學系統的數據管理方法，除了平安、人保等大型險企外，大多數中小規模的公司都不太注重在數據治理方面的投入，眾多業務系統散落在布滿灰塵的伺服器上，這些數據資產就好比地主家的金條和古董，必須要由一個管家來統一收納和管理，這樣地主想買地、蓋房、娶媳婦兒的時候才能更清楚自己有多少錢能花。 其次，術業有專攻，在保險公司裡面，各條線都有業務專家，但是很少有既精通保險業務又擅長數據分析技術的專業人才，有些險企雖然緊跟了時代的步伐招攬了數據專業的人才，但是並沒有為數據人才與業務專家提供溝通感情培養默契的環境。人才也是企業的資產，在很多企業中，兩個部門的同事缺乏有效的溝通和配合，不僅浪費了人員的專業知識，也浪費了企業在戰略規劃中的投入，導致數據項目通常沒有好的效果。 國外的保險行業比國內起步早，保險的數據應用也相對成熟，由於數據的豐富度、數據質量、跨領域的數據整合度的提升，更加精準的分析便水到渠成。圖1 歸納了保險流程各個環節上的分析成熟度變革過程：行銷，產品研發，定價，核保，理賠。整個行業的分析成熟度用圓點標出。讀者朋友們可以藉助此圖評估自己所在條線或領域的分析水平。 在正確評估了本領域或條線數據資產應用現狀的基礎上，本文要與大家分享的重點內容是業務專家與數據人員如何正確溝通數據需求以達到事半功倍的效果。 業務條線的同事可能經常會面臨一個問題，IT或數據條線的同事每年都會在全公司收集數據需求，郵件中也給出了幾十問題來個幫助業務專家歸納本條線與數據的結合點，但是能想到的改善點除了報表製作就是數據取不到之類的問題。這些專業壁壘需要用正確的方法打破，數據資產才能正確的打開。 一、統一需求模板 為什麼要先討論這個問題呢？在需求提出到落地的過程中，最大的挑戰其實來自需求理解，數據人員及IT團隊需要迅速且透徹的理解業務需求，並且在充分考慮各條線需求的基礎上，按公司的戰略目標制定需求落地的優先順序，然後按需要整理相關的數據和功能開發，使用統一的需求模板可以確保提出的需求的標準化和有效性，同時也能節約在項目協同中所有參與者的溝通時間成本。 優質的模板既要能為數據人員或IT團隊提供便於理解的豐富信息，又能保證邏輯簡介清晰，從而避免業務人員面對一堆看不懂的問題不知如何回答。 標準的需求模板里應該包含的信息類別包括： 數據：當前及未來的數據獲取、質量、完整性和即時性需求；功能：提取、整合、可視化等。 指標：需要添加或使用哪些指標組合，如KPI、前導指標、相關性參數等。 分析：當前及未來的功能需求，包括報告、數據報表、數據儀錶、數據挖掘、可視化等。 工具：現有及需要的工具和功能，包括行動端、自助服務等。 培訓與技能：現有及未來的技能需求；培訓平台及培訓課程；功能指導以及實戰經驗交流。 戰略：業務與IT戰略之間的平衡和調整。 FineReport業務分析決策系統 二、業務發現式的需求界定方法 這種方式通常以訪談形式出現，數據人員與業務專家交流業務場景並引導其描述業務需求。通常會以一年為期，在上年底時，業務專家就需要對未來一年的核心任務有所計劃，以及達成這些任務目標所需要的分析功能。有效的溝通還應該包括目前的分析工作中不能覆蓋的空白點和潛在問題。 三、框架式的需求界定方法 在運用這個方法的時候，業務專家需要配合數據人員進行以下工作： 1、列出最主要的業務目標並排序 2、列出為實現這些目標所必須解決的業務問題 3、如果對應的業務問題已經有解決方式，則需要列出明確的工作計劃 4、針對每個業務問題，列出需要用到的數據、使用方式、技術協助等 5、給出用以評價進城的KPI或其他指標 四、應用案例式的需求界定方法 需要業務專家給出與業務目標一致的應用情景假設。在各種假設的情景中確定數據需求與應用點。 核保應用案例——事例 業務目標：核保審核——新業務——自動定標 主要角色：核保員 目標：針對新業務申請進行分類、評估和定價 情境條件：業務流程描述 結果：保單報價與簽發 基本劇情： 1、代理人填寫完承保單申請並將其提交給核保員 2、核保員審閱申請材料，確認是否符合核保條件 3、核保員對申請信息進行核實並從中摘錄信息 4、核保員打出風險評分，核保價格，將其反饋給代理人 5、代理人將報價給到投保人並與其確認是否同意簽約 6、核保員簽發保單及保費賬單，並由代理人轉送申請人 7、投保人繳納保費等。 劇情拓展： 1、申請信息不完整 2、申請人以價格不合適為由拒絕報價 3、申請人在填寫申請表時存在信息隱瞞 4、…… 劇情變形： 1、申請人是團體客戶的一員或有特殊身份，定價時需要有折扣 2、申請人與保險公司還有其他簽約保單，定價時需要有折扣 3、申請人希望分期支付保費 4、申請人希望通過手機完成報價核保 5、…… […]

越來越多的數據，越來越多的需求，越來越多的不滿意 如今，大數據分析軟體和數據分析的概念相當普及，從基層到管理層，從IT到業務，都深知「數據化管理」、「數據決策」的重要性。越多重視，壓力也就越多，導致信息中心和數據部門往往處於進退兩難的狀態： 數據變多，需求變多，工作價值得不到體現，內部疲於應付。 提供了數據，但需求多樣變更極快，無法滿足各方需求，內部怨言層出。 如何做好面向全公司的數據支撐，哪怕只是簡單的報表提供，其實也是一件複雜且考驗思維邏輯的事。 作為曾經一度經歷過的表哥，本著吐槽加總結加吹牛的原則，匯總下我在梳理並重新規劃公司數據支撐體系時的一些思路，紀念下曾經看指標看瞎的某年5月。 管理思維：數據支撐體系不僅僅是指標體系，還有更開闊的管理邏輯 數據報表的工作只是在整理數據嗎？當然不是，數據的整合和展現最終都是為了經營決策的，報表體系的背後邏輯應反映整個公司的經營結果和經營方法。 做報表的，雖然事務工作多，但還是要抬起頭來，系統思考一下，報表的路該怎麼走？ 阿里提出了「小前台，大中台」的概念，實際道理是相通的。報表中台對於報表人員的綜合素質要求很高，既要有寬廣的業務視野，也要有深厚的數據沉澱，輔以溝通協調能力，造詣甚至遠超一般的業務人員。 一旦想清楚這個問題，你就知道你的數據體系必須要和公司目前的經營狀況和當前工作方向緊密聯繫，所以你的數據工作的方向也就呼之欲出了： 方向一：公司目前是什麼樣的基本狀態？——銷售額、利潤、行業份額，用戶規模…… 方向二：公司目前的市場競爭形勢是怎樣的？—— 新增份額、凈增份額，凈收益…… 方向三：就目前形勢，公司需要抓住的用戶群來源在哪裡？——各渠道新增用戶價值轉換率、各渠道用戶價值分層、各渠道投入產出比、會員滲透率、存量用戶重複購買率…… 方向四：就目前形勢，公司推出的核心產品有哪些？——核心產品銷售達成率、核心要產品渠道滲透率、核心產品重複購買率…… 方向五：就目前形勢，公司採用什麼樣的管理方法和工具？—— OKR目標、KPI體系、銷售經理管理指標體系、客戶經理管理指標體系、CRM系統、OA系統、EPR系統…… 在梳理過程中，會發現對應到任何一個整體業務的分析，需要提供的已經遠不只是業務結果那麼簡單，還包括各種管理和執行數據。 簡化思維：數據不是越全越好，主次突出，重點聚焦是王道 確定好數據的大方向後，接下來便是細化分析每個數據方向的具體指標體系，以及確定細分的程度。 這個時候，最容易犯的錯誤便是開始把所有用到的、想到的全部羅列並設計進去，建立一個所謂大而全的內容。我始終認為，真正的報表製作是為企業開發的，業務人員只是報表的需求提出者，因此，還需要去理解報表提出的背景，哪些是這張報表的用戶，你需要尊重提出報表需求的人員，但對於報表開發要有自己的想法和主導權。一味強調廣而全，不僅會讓執行者無法聚焦工作重點，而且會讓數據部門自身工作量大增，吃力不討好。 所以，在明確數據需求的大方向基礎上制定詳細的數據體系時，一定要時刻提醒自己，重點是什麼？ 一、不同的指標要有重點 比如在產品運營指標體系中，如果已開始投放（電商），需要積累數據，重點關注流量指標，例如UV、PV、渠道來源、用戶線索、瀏覽量、產品瀏覽量排行、頁面跳失率、顧客評價指數、轉化率等等。 而如果運營了一段時間，市場已經成熟，首要的任務是通過數據分析提高銷售額。此階段需要重點監測追蹤流量和銷售指標，例如訪客數、瀏覽量、轉化率，以及新增會員數、會員的流失率、客單價、ROI、動銷率、庫存天數、銷售額等。 若行業份額較小，以拓展為主，那除了新增份額、凈增份額常見指標外，新增搶奪指標方面需往下衍生新增用戶存活率、瀏覽用戶轉換率、新增用戶價值分層等細化體系，保有指標設計則相對簡單。 而如果行業份額已經較大，以保有為主，那新增相關指標則相對可以簡單，而保有指標除用戶保有率、會員活躍率等常見指標外，還需往下衍生合約捆綁率，會員忠誠度、積分計劃活躍度等指標。 二、相同的指標要有側重 同樣以用戶保有指標為例，用戶保有率和用戶流失率其實是同樣作用的指標，一方面是選擇其一即可。另一方面是，選擇哪個，其實放到實際使用中，會有微妙的差別。 如果採用用戶保有率指標，往下衍生是業務層面的合約捆綁率、用戶活躍率、會員滲透率等積極導向指標，注重行銷執行。如果現在用戶流失率，往下衍生是用戶觸店但無消費率、用戶沉默率、用戶直流流失率、流失用戶畫像特徵等，導向為預警關懷。 三、指標的細分，不需要過於龐雜 一般而言，過程三級，執行三級，就已經足夠定位問題及全面展現情況。 邏輯關係：不僅僅是分類，更是反映業務之間的關聯 一、數據選擇邏輯： 為什麼業務部門提出一項數據的要求後，往往會接二連三的提出其他數據需求？其實他們也是在試圖嘗試尋找某個數據背後的原因及可能。 在設計報表體系過程中，不僅僅只是分類，而應該考慮到指標間的關聯，在設計過程中就應該加入業務分析的思維，比如分析者看到這個數據會聯想到其他哪些數據來探究原因？ 我在當初利用帆軟報表（FineReport）設計整個報表體系的時候，常用的就是「結果指標——過程指標——執行指標」三層邏輯結構。結果指標由過程指標決定，而過程指標由結果指標決定。 這種邏輯不僅在運營數據上適用，在管理指標上也同樣適用。比如KPI體系是結果，渠道任務目標管理系統是過程，渠道經理/客戶經理監督體系是執行。 二、數據呈現邏輯： 確定好指標內容和指標邏輯後，就是數據呈現了。這方面，之前在如何設計企業內部的數據平台？中就已經總結了，其實就是利用「分析報表—管理報表——基礎類查詢報表」三種層級展示，實現從宏觀到微觀，從上而下定位問題的呈現邏輯。 對於筆者而言，我設計的方式是站在「分析報表—管理報表」維度上，以主題為維度切入，設計全報表。這樣就可以直接從分析報表找到該主題發展的短板，從管理報表上找到導致該短板的主要原因，最後才去分析單報表。 以上是我對於整個報表體系建設的 一點思考感悟，但是實際操作過程中也並沒有這麼理想，仍然需要根據具體情況具體分類具體設計。

當前BAT基本公開了其大數據平台架構，從網上也能查詢到一些資料，關於大數據分析軟體平台的各類技術介紹也不少，但在那個機制、那個環境、那個人才、那個薪酬體系下，對於傳統企業，可借鑒的東西也是有限的。 技術最終為業務服務，沒必要一定要追求先進性，各個企業應根據自己的實際情況去選擇自己的技術路徑。 與傳統的更多從技術的角度來看待大數據平台架構的方式不同，筆者這次，更多的從業務的視角來談談關於大數據架構的理解，即更多的會問為什麼要採用這個架構，到底能給業務帶來多大價值，實踐的最終結果是什麼。 它不一定具有通用性，但從一定程度講，這個架構可能比BAT的架構更適應大多數企業的情況，畢竟，大多數企業，數據沒到那個份上，也不可能完全自研，商業和開源的結合可能更好一點，權當拋磚引玉。 大數據平台架構的層次劃分沒啥標準，以前筆者曾經做過大數據應用規劃，也是非常糾結，因為應用的分類也是橫縱交錯，後來還是覺得體現一個「能用」原則，清晰且容易理解，能指導建設，這裡將大數據平台劃分為「五橫一縱」。 具體見下圖示例，這張圖是比較經典的，也是妥協的結果，跟當前網上很多的大數據架構圖都可以作一定的映射。 何謂五橫，基本還是根據數據的流向自底向上劃分五層，跟傳統的數據倉庫其實很類似，數據類的系統，概念上還是相通的，分別為數據採集層、數據處理層、數據分析層、數據訪問層及應用層。 同時，大數據平台架構跟傳統數據倉庫有一個不同，就是同一層次，為了滿足不同的場景，會採用更多的技術組件，體現百花齊放的特點，這是一個難點。 數據採集層：既包括傳統的ETL離線採集、也有實時採集、互聯網爬蟲解析等等。 數據處理層：根據數據處理場景要求不同，可以劃分為HADOOP、MPP、流處理等等。 數據分析層：主要包含了分析引擎，比如數據挖掘、機器學習、 深度學習等。 數據訪問層：主要是實現讀寫分離，將偏嚮應用的查詢等能力與計算能力剝離，包括實時查詢、多維查詢、常規查詢等應用場景。 數據應用層：根據企業的特點不同劃分不同類別的應用，比如針對運營商，對內有精準行銷、客服投訴、基站分析等，對外有基於位置的客流、基於標籤的廣告應用等等。 數據管理層：這是一縱，主要是實現數據的管理和運維，它橫跨多層，實現統一管理。 1、數據採集層，這是基礎。 離線批量採集，採用的是HADOOP，這個已經成為當前流線採集的主流引擎了，基於這個平台，需要部署數據採集應用或工具。 諸如BAT都是自己研發的產品，一般企業，可以採用商用版本，現在這類選擇很多，比如華為BDI等等，很多企業技術實力有，但起步的時候往往對於應用場景的理解比較弱，細節做工很差，導致做出來的產品難以達到要求，比如缺乏統計功能等，跟BAT差距很大，傳統企業去採購這類產品，要謹慎小心。 一個建議是，當採購產品的時候，除了技術先進性和指標外，更多的應該問問是版本啥時候上線的，是否在哪裡成功部署，是否有足夠多的客戶，如果能做個測試就更好，否則，你就是小白鼠哦，這個坑踩了不少。 能做和做成產品是兩個境界的事情，小的互聯網企業當然也能做出對於自己好用的採集工具，但它很難抽象並打造出一個真正的產品，BAT自研其實形成了巨大的優勢。 實時採集現在也成了大數據平台的標配，估計主流就是FLUME+KAFKA，然後結合流處理+內存資料庫吧，這個技術肯定靠譜，但這類開源的東西好是好，但一旦出現問題往往解決周期往往比較長。 除了用FLUME，針對ORACLE資料庫的報表製作為了實現實時採集，也可以採用OGG/DSG等技術實現實時的日誌採集，可以解決傳統數據倉庫抽全量表的負荷問題。 爬蟲當前也逐漸成為很多企業的採集標配，因為互聯網新增數據主要靠它，可以通過網頁的解析獲取大量的上網信息，什麼輿情分析、網站排名啥的，建議每個企業都應該建立企業級的爬蟲中心，如果它未在你的大數據平台規劃內，可以考慮一下，能拿的數據都不拿，就沒什麼好說了。 企業級的爬蟲中心的建設難度蠻大，因為不僅僅是需要爬蟲，還需要建立網址和應用知識庫，需要基於網頁文本進行中文分詞，倒排序及文本挖掘等，這一套下來，挑戰很大，當前已經有不少開源組件了，比如solr、lucent、Nutch、ES等等，但要用好它，路漫漫其修遠兮。 還有一個就是，如果有可能，筆者建議將數據採集平台升級為數據交換平台，因為其實企業內有大量的數據流動，不僅僅是單向的數據採集，而且有很多數據交換，比如需要從ORACLE倒數據到GBASE，從HBASE倒數據到ASTER等等，對於應用來講，這個價值很大。 既然數據採集和數據交換有很多功能非常類似，為什麼不做整合呢？也便於統一管理，感覺企業的數據交換大量都是應用驅動，介面管理亂七八糟，這也是我的一個建議。 總得來講，建設大數據採集平台非常不易，從客戶的角度講，至少要達到以下三個要求： 多樣化數據採集能力：支援對錶、文件、消息等多種數據的實時增量數據採集（使用flume、消息隊列、OGG等技術）和批量數據分布式採集等能力（SQOOP、FTP VOER HDFS），比基於傳統ETL性能有量級上的提升，這是根本。 可視化快速配置能力：提供圖形化的開發和維護界面，支援圖形化拖拽式開發，免代碼編寫，降低採集難度，每配置一個數據介面耗時很短，以降低人工成本。 統一調度管控能力：實現採集任務的統一調度，可支援Hadoop的多種技術組件（如 MapReduce、Spark 、HIVE）、關係型資料庫存儲過程、 shell腳本等，支援多種調度策略（時間/介面通知/手工）。 2、數據處理層，現在有個詞叫混搭，的確是這樣。 Hadoop的HIVE是傳統數據倉庫的一種分布式替代。應用在傳統ETL中的數據的清洗、過濾、轉化及直接匯總等場景很適合，數據量越大，它的性價比越高。但目前為止看，其支撐的數據分析場景也是有限的， 簡單的離線的海量分析計算是它所擅長的，相對應的，複雜的關聯交叉運算其速度很慢。 一定程度講，比如企業客戶統一視圖寬表用HIVE做比較低效，因為涉及到多方數據的整合，但不是不可以做，最多慢點嘛，還是要講究個平衡。 hadoop到了X000台集群的規模也撐不住了,當前很多企業的數據量應該會超過這個數量，除了像阿里等自身有研發能力的企業（比如ODPS），是否也要走向按照業務拆分Hadoop集群的道路？諸如浙江行動已經拆分了固網、移網、創新等多個hadoop集群。 Hadoop的SPARK的很適合機器學習的迭代，但能否大規模的應用於數據關聯分析，能否一定程度替代MPP，還需要實踐來驗證。 MPP應該來說，是採用分布式架構對於傳統數據倉庫最好的替代，畢竟其實際上是變了種的關係型資料庫，對於SQL提供完整支援，在HIVE做了轉化分析後，數據倉庫的融合建模用它來做性能綽綽有餘，其性價比較傳統DB2更好一點，比如經過實用，Gbase30-40台集群就能超過2台頂配的IBM 780。 MPP現在產品很多，很難做優劣判斷，但一些實踐結果可以說下，GBASE不錯，公司很多系統已經在上面跑了，主要還是國產的，技術服務保障相對靠譜，ASTER還有待觀望，自帶一些演算法庫是有其一些優勢，GreenPlum、Vertica沒用過，不好說。 現在有個說法是MPP最終也要被Hadoop那套框架替代，畢竟諸如SPARK啥的都在逐步穩定和成熟，但在短期內，我覺得還是很靠譜的，如果數據倉庫要採用漸進的演化方式，MPP的確是很好的選擇。 現在諸如中國移動，eBAY等大量公司都在採用這類混搭結構，以適應不同的應用場景，顯然是一種自然的選擇。 大數據平台的三駕馬車，少不了流處理。 對於很多企業來講，其顯然是核武器般的存在，大量的應用場景需要它，因此務必要進行建設，比如在IOE時代不可想像的實時、准實時數據倉庫場景，在流處理那裡就變得很簡單了，以前統計個實時指標，也是很痛苦的事情，當前比如反欺詐實時系統，一天系統就申請部署好了。 只嘗試過STORM和IBM STREAM，推薦IBM STREAM，雖然是商業版本，但其處理能力超過STORM不是一點半點，據說STORM也基本不更新了，但其實數據量不大，用啥都可以，從應用的角度講，諸如IBM這種商業智慧版本，是不錯的選擇，支撐各類實時應用場景綽綽有餘。 流處理集群以流處理技術結合內存資料庫，用以實時及准實時數據處理，基於IBM Streams流處理集群承載公司的實時業務： 3、數據分析層，與時俱進吧。 先談談語言，R和Python是當前數據挖掘開源領域的一對基友，如果要說取捨，筆者真說不出來，感覺Python更偏向工程一點，比如有對分詞啥的直接支撐，R的繪圖能力異常強大。但他們原來都以樣本統計為主，因此大規模數據的支撐有限。 […]

去年8月15日的大停電中，讓台灣島上近半數家庭失去了電力。今年6月開始至今，光是北台灣就已經發生至少4次跳電事件，雖然各地的電力已然回復，但大停電引發的質疑，亦即政府承諾關閉核電廠是否明智的討論，短時間內也不會消失。 保障電力供應穩定到底有多重要？不僅僅是跳電引發的名聲問題、導致居民生活不便，對產業發展也有很大的影響，「一個國家電力如果不充足，要怎麼繼續生產投資？」 保障電力供應穩定到底有多難？發電量充足、發電能源比例、用電預測、設備狀態、故障維修、錯峰用電、價格策略等等任何一個環節都影響著電力的穩定供給。近幾年，隨著IoT物聯網技術在電力行業的應用，大數據中心在保障穩定供電方面大放異彩，通過數據分析合理預測、產電、配電，及時獲取用電、故障數據。 今天，我們來分享某電網公司配用電大數據專案中所採用的多維架構(包含數據架構、業務架構、技術架構等)，旨在為各電力企業和能源企業提供借鑒。 1、前言 2、業務架構 3、數據架構 4、技術架構 5、實施架構 6、示範架構 7、小結 前言 智慧電網(Smart Grid)是以物理電網為基礎，將現代先進的感測測量技術、通信技術、資訊技術、計算機技術和控制技術與物理電網高度集成而形成的新型電網。 電力大數據(Power Big Data)是實現智慧電網的關鍵技術之一，它通過探勘數據之間的關係與規律，提高電網企業在生產、經營、管理等方面的質量與效率。如開展電網設備狀態監測的大數據應用，實現電網設備狀態的智慧監測，實時分析電網線損、配電負載等等。 業務架構 配用電大數據專案的業務架構，是指從業務角度說明配用電大數據專案要做什麼事。此架構不會過多牽涉技術細節，它的重要性要高於其他幾類架構。一般來說，這類架構要在專案啟動前，通過多次的調研、分析、專家研討後方可決定。 上圖的業務架構主要將業務劃分為了五大層次，其中最為關鍵的是數據源層和應用層： 1. 數據源層： 規定配用電大數據專案能從哪些地方獲得數據資源?這是非常重要的一環，尤其是在電網領域。因為當前電力資訊系統中的「網路孤島」現象比較嚴重，要梳理清楚哪些數據能采、哪些數據采上來有意義，是非常不容易的。 2. 數據應用層： 明確配用電大數據能為電力系統實現哪些業務?規劃該層次時，行業化大數據從業人員需要和電力專業的人員進行多次深入地溝通交流。從筆者親身經歷來看，這一層切不可假大空，一定要確保落地。通俗點來說，若這層寫得太虛，可能會把後續開發人員，甚至是自己給坑了… 至於其他幾個層，則是從一個較為宏觀的角度去設計系統組件。一般來說在業務架構的側重點在系統的功能性方面，對於技術細節不過多糾結。 數據架構 電網企業的數據主要包括三類： 1. 電力設備數據： 主要包括電網設備監測數據、設備地理位置數據、設備狀態數據等； 2. 企業管理數據： 主要包括跨單位、跨部門的電網企業職工數據、財務數據等； 3. 企業運營數據： 主要包括客戶資料、客戶用電數據、電費數據等。 但是上述只是一個特粗略的分類。筆者在專案實施過程中發現，數據的分類在每一個環節都需要按照不同標準重新做一次。 為何要這麼麻煩？ 這是因為，[數據類型]+[業務需求] 將決定你選用何種大數據分析軟體組件去處理它。 這裡先以電網的拓撲結構數據為例： 這類數據大都存在電力系統的RDBMS里，那麼我們顯然可以考慮使用Sqoop來做同步；而其後為高效實現電網拓撲分析業務，顯然應將其放至HIVE這類數據倉庫工具里合適。 再以電網設備檢測數據為例： 這類數據由於具有事實性，用Storm或者Spark Streaming來同步就顯然更加合適了；而這類數據有部分業務環境是不需要做太多數據分析的，因此可考慮將其導入到HBase這類NoSQL數據里，實現高效存取。 讀者看到這裡，應該明白了需要時刻思考數據分類的原因了吧？上述兩個例子都屬於電力設備數據，然而它們被處理的方式顯然是不同的。在實際中，我們往往根據當前架構所在層次的屬性來決定使用何種組件來處理數據。個人真心建議針對將來數據特別複雜的情況，可以考慮引入「數據畫像」這個概念，根據不同的處理方式為各類數據打上標籤，以便於管理。 技術架構 總的來說，針對配用電大數據的技術研究可以分為三個層面來展開： 1. 數據集成層面： 研究電力系統中多源數據的分類方式、集成與融合方法，並設計出面向雲環境的多源異構數據集成模型。 2. 基礎架構層面： […]

下面的內容，是筆者在學習和工作中的一些總結，其中概念性的內容大多來自書中，實踐性的內容大多來自自己的工作和個人理解。由於資歷尚淺，難免會有很多錯誤，望批評指正！ 概述 數據倉庫包含的內容很多，它可以包括架構、建模和方法論。對應到具體工作中的話，它可以包含下面的這些內容： 1、以Hadoop、Spark、Hive等組建為中心的數據架構體系。 2、各種數據建模方法，如維度建模。 3、調度系統、元數據系統、ETL系統、可視化系統這類輔助系統。 4、我們暫且不管數據倉庫的範圍到底有多大，在數據倉庫體系中，數據模型的核心地位是不可替代的。 因此，下面的將詳細地闡述數據建模中的典型代表：維度建模，對它的的相關理論以及實際使用做深入的分析。 文章結構 本文將按照下面的順序進行闡述： 先介紹比較經典和常用的數據倉庫模型，並分析其優缺點。 詳細介紹維度建模的基本概念以及相關理論。 為了能更真切地理解什麼是維度建模，我將模擬一個大家都十分熟悉的電商場景，運用前面講到的理論進行建模。 理論和現實的工作場景畢竟會有所差距，這一塊，我會分享一下企業在實際的應用中所做出的取捨。 0x01 經典數據倉庫模型 下面將分別介紹四種數據倉庫模型，其中前三種模型分別對應了三本書：《數據倉庫》、《數據倉庫工具箱》和《數據架構 大數據 數據倉庫以及Data Vault》，這三本書都有中文版，非常巧的是，我只有三本數據倉庫的書，正好對應了這三種理論。 Anchor模型我並不是特別熟悉，放在這裡以供參考。 一、實體關係（ER）模型 數據倉庫之父Immon的方法從全企業的高度設計一個3NF模型，用實體加關係描述的數據模型描述企業業務架構，在範式理論上符合3NF，它與OLTP系統中的3NF的區別，在於數據倉庫中的3NF上站在企業角度面向主題的抽象，而不是針對某個具體業務流程的實體對象關係抽象，它更多的是面向數據的整合和一致性治理，正如Immon所希望達到的：「single version of the truth」。 但是要採用此方法進行構建，也有其挑戰： 1、需要全面了解企業業務和數據 2、實施周期非常長 3、對建模人員的能力要求也非常高 二、維度模型 維度模型是數據倉庫領域另一位大師Ralph Kimall所倡導，他的《The DataWarehouse Toolkit-The Complete Guide to Dimensona Modeling，中文名《數據倉庫工具箱》，是數據倉庫工程領域最流行的數倉建模經典。維度建模以分析決策的需求出發構建模型，構建的數據模型為分析需求服務，因此它重點解決用戶如何更快速完成分析需求，同時還有較好的大規模複雜查詢的響應性能。 典型的代表是我們比較熟知的星形模型，以及在一些特殊場景下適用的雪花模型。 三、DataVault DataVault是Dan Linstedt發起創建的一種模型方法論，它是在ER關係模型上的衍生，同時設計的出發點也是為了實現數據的整合，並非為數據決策分析直接使用。它強調建立一個可審計的基礎數據層，也就是強調數據的歷史性可追溯性和原子性，而不要求對數據進行過度的一致性處理和整合；同時也基於主題概念將企業數據進行結構化組織，並引入了更進一步的範式處理來優化模型應對源系統變更的擴展性。 它主要由：Hub（關鍵核心業務實體）、Link（關係）、Satellite（實體屬性） 三部分組成 。 四、Anchor模型 Anchor模型是由Lars. Rönnbäck設計的，初衷是設計一個高度可擴展的模型，核心思想：所有的擴展只是添加而不是修改，因此它將模型規範到6NF，基本變成了K-V結構模型。 Anchor模型由：Anchors 、Attributes 、Ties 、Knots […]

什麼是核心關鍵指標呢？ 這是一個好問題，不過沒有標準的答案。企業性質不同，所處行業、發展階段不同，關注點當然不同。不過大體可以這樣來劃分。 1、發展階段不同，需求不同 對於一個想要做數據化管理的企業來說，一開始積累數據，比找准營運方向比賣多少貨，賺多少錢更為重要。這個階段主要重點關注流量指標，例如UV、PV、渠道來源、用戶線索、瀏覽量、產品瀏覽量排行、頁面跳失率、顧客評價指數、轉化率等等。類同於互聯網產品，產品投放初期，也需要關注用戶數、訂單數，後續考慮用戶活躍度，回購率，客單價。 對於已經營運了一段時間的企業/產品，首要的任務是通過數據分析提高銷售額，畢竟這才是最終的目的。此階段需要重點監測追蹤流量和銷售指標，例如訪客數、瀏覽量、轉化率，以及新增會員數、會員的流失率、客單價、ROI、動銷率、庫存天數、銷售額等。 對於已經很有規模的電商，利用數據提升整體營運水平，進一步提高效率和利潤非常關鍵。所以重點應放在關鍵節點的指標，除去以上，還有他復購率、流失率、留存率、利潤率、ROL、新客成本等。因為這個時候拉新很困難，因此會員的留存和復購就顯得尤為重要。 綜上，一般情況下，不同階段無論是關鍵性指標還是KPI都要做相應調整。 2、職位不同，關注不同 管理層 結果導向，側重與結果指標，而執行人員側重於過程指標。例如業務執行層會關心各渠道的來源銷售額佔比，管理層也許只關注整體的銷售額，但是銷售市場人員還得關注各渠道的優劣勢，轉化成本，投入產出比，管理層只需要關註銷售額這個結果指標。 所以對於數據分析人員有時候面向不同的人員要說不同的結果，提供不同的數據，說對方關心的話。 【BOSS結果指標的典型】 【銷售經理關注的指標典型】 3、時間不同，側重不同 數據指標可以分為追蹤指標、分析指標和營運指標，營運指標就是績效考核指標。比如銷售追蹤一般是按天、按時段說話，分析一般是以周和月為單位，績效考核常常是以月為主、以年為輔。最熟悉的莫過於常常要寫的周報月報季報。

最近出現了好幾次同樣的對話場景： 問：你是做什麼的？ 答：最近在搞數據倉庫。 問：哦，你是傳統行業的吧，我是搞大數據的。 答：…… 發個牢騷，搞大數據的也得建設數據倉庫吧。而且不管是傳統行業還是現在的互聯網公司，都需要對數據倉庫有一定的重視，而不是談一句自己是搞大數據的就很厲害了。數據倉庫更多代表的是一種對數據的管理和使用的方式，它是一整套包括了etl、調度、建模在內的完整的理論體系。現在所謂的大數據更多的是一種數據量級的增大和工具的上的更新。 兩者並無衝突，相反，而是一種更好的結合。 話說，單純用用Hadoop、Spark、Flume處理處理數據，其實只是學會幾種新的工具，這是搞工具的，只是在數據倉庫中etl中的一部分。 當然，技術的更新往往能領到一個時代的變革，比如Hadoop的誕生，光是深入研究一個大數據組件就要花很大的時間和精力。但是在熱潮冷卻之後，我們更應該考慮地是如何更好地管理和使用自己的數據。 對於數據的從業者來講，要始終重視緊跟技術的變革，但是切記數據為王，在追求技術的極致的時候，不要忘了我們是搞數據的。 文章主題 吐槽完畢，本文主要講解數據倉庫的一個重要環節：如何設計數據分層！，其它關於數據倉庫的內容可參考其它的文章數據倉庫。 本文對數據分層的討論適合下面一些場景，超過該範圍場景 or 數據倉庫經驗豐富的大神就不必浪費時間看了。 數據建設剛起步，大部分的數據經過粗暴的數據接入後就直接對接業務。 數據建設發展到一定階段，發現數據的使用雜亂無章，各種業務都是從原始數據直接計算而得。 各種重複計算，嚴重浪費了計算資源，需要優化性能。 文章結構 最初在做數據倉庫的時候遇到了很多坑，由於自身資源有限，接觸數據倉庫的時候，感覺在互聯網行業裡面的數據倉庫成功經驗很少，網上很難找到比較實踐性強的資料。而那幾本經典書籍裡面又過於理論，折騰起來真是生不如死。還好現在過去了那個坎，因此多花一些時間整理自己的思路，幫助其他的小夥伴少踩一些坑。 1、為什麼要分層？這個問題被好幾個同學質疑過。因此分層的價值還是要說清楚的。 2、分享一下經典的數據分層模型，以及每一層的數據的作用和如何加工得來。 3、分享兩個數據分層的設計，通過這兩個實際的例子來說明每一層該怎麼存數據。 4、給出一些建議，不是最好的，但是可以做參考。 0x01 為什麼要分層 我們對數據進行分層的一個主要原因就是希望在管理數據的時候，能對數據有一個更加清晰的掌控，詳細來講，主要有下面幾個原因： 1、清晰數據結構：每一個數據分層都有它的作用域，這樣我們在使用表的時候能更方便地定位和理解。 2、數據血緣追蹤：簡單來講可以這樣理解，我們最終給業務誠信的是一能直接使用的張業務表，但是它的來源有很多，如果有一張來源表出問題了，我們希望能夠快速準確地定位到問題，並清楚它的危害範圍。 3、減少重複開發：規範數據分層，開發一些通用的中間層數據，能夠減少極大的重複計算。 4、把複雜問題簡單化。講一個複雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。而且便於維護數據的準確性，當數據出現問題之後，可以不用修復所有的數據，只需要從有問題的步驟開始修復。 5、屏蔽原始數據的異常。 6、屏蔽業務的影響，不必改一次業務就需要重新接入數據。 數據體系中的各個表的依賴就像是電線的流向一樣，我們都希望它是很規整，便於管理的。但是，最終的結果大多是第一幅圖，而非第二幅圖。 0x02 怎樣分層 理論 我們從理論上來做一個抽象，可以把數據倉庫分為下面三個層，即：數據運營層、數據倉庫層和數據產品層。 1. ODS全稱是Operational Data Store，操作數據存儲 「面向主題的」，數據運營層，也叫ODS層，是最接近數據源中數據的一層，數據源中的數據，經過抽取、洗凈、傳輸，也就說傳說中的ETL之後，裝入本層。本層的數據，總體上大多是按照源頭業務系統的分類方式而分類的。 例如這一層可能包含的數據表為：人口表（包含每個人的身份證號、姓名、住址等）、機場登機記錄（包含乘機人身份證號、航班號、乘機日期、起飛城市等）、銀聯的刷卡信息表（包含銀行卡號、刷卡地點、刷卡時間、刷卡金額等）、銀行賬戶表（包含銀行卡號、持卡人身份證號等）等等一系列原始的業務數據。這裡我們可以看到，這一層面的數據還具有鮮明的業務資料庫的特徵，甚至還具有一定的關係資料庫中的數據範式的組織形式。 但是，這一層面的數據卻不等同於原始數據。在源數據裝入這一層時，要進行諸如去噪（例如去掉明顯偏離正常水平的銀行刷卡信息）、去重（例如銀行賬戶信息、公安局人口信息中均含有人的姓名，但是只保留一份即可）、提臟（例如有的人的銀行卡被盜刷，在十分鐘內同時有兩筆分別在中國和日本的刷卡信息，這便是臟數據）、業務提取、單位統一、砍欄位（例如用於支撐前端系統工作，但是在數據挖掘中不需要的欄位）、業務判別等多項工作。 2. 數據倉庫層(DW)，是數據倉庫的主體 在這裡，從ODS層中獲得的數據按照主題建立各種數據模型。例如以研究人的旅遊消費為主題的數據集中，便可以結合航空公司的登機出行信息，以及銀聯繫統的刷卡記錄，進行結合分析，產生數據集。在這裡，我們需要了解四個概念：維（dimension）、事實（Fact）、指標（Index）和粒度（ Granularity）。 3. 數據產品層（APP），這一層是提供為數據產品使用的結果數據 在這裡，主要是提供給數據產品和數據分析使用的數據，一般會存放在es、mysql等系統中供線上系統使用，也可能會存在Hive或者Druid中供數據分析和數據挖掘使用。 比如我們經常說的報表製作數據，或者說那種大寬表，一般就放在這裡。 技術實踐 這三層技術劃分，相對來說比較粗粒度，後面我們會專門細分一下。在此之前，先聊一下每一層的數據一般都是怎麼流向的。這裡僅僅簡單介紹幾個常用的工具，側重中開源界主流。 […]