企業資料分析工作的任務、工具及挑戰

大資料時代，資料已經成為戰略資源。資料分析已經成為越來越多企業的帳略要務。其中，掌握前沿科技的大型IT企業在資料的分析和利用上走在了時代的前列。

筆者浸淫IT業十餘年，近年曾專注於資料分析平臺研發和資料分析，對企業內部以業務為驅動的資料分析工作的現狀和未來趨勢有一定的瞭解和思考，在此與大家分享。

本場Chat只有文章，沒有交流。

大資料時代，資料已經成為戰略資源。掌握前沿科技的大型IT企業在資料的分析和利用上走在了時代的前列。

筆者浸淫IT業十餘年，對資料分析技術及其未來趨勢有一定的瞭解和思考，在此與大家分享。

鑑於大型IT企業是資料分析工作的早期天使客戶和許多具體技術、工具的發源地，我們主要針對大型IT企業來做一些分析。

---

0. 澄清基本概念

為了不在後面討論中因概念不清產生誤解，我們首先給出幾個定義：

I.大型IT企業：指對外提供IT相關的軟硬體產品及服務的公司，員工至少在萬人以上。

II.資料平臺：指大型IT企業用來為自身服務為主，擔負資料儲存、處理、分析業務和軟硬體綜合。主要針對內部服務，不對外開發。

III.資料分析：此處的資料分析師廣義的，包括一切基於資料得出的insights的行為，包括統計分析、機器學習建模和預測等。

1. 大型IT企業開展對內資料業務的驅動力

就目前而言，IT企業針對自身的資料分析業務可以分為廣告和非廣告兩類。對大多數企業而言，除了廣告之外的資料業務，並不能直接帶來可以量化的收入。

但是，無論當前資料分析的結果為企業的現金流做了多少貢獻。資料為王的思想已然佔據了眾多前沿企業間的頭腦。資料是礦山，insights是金子，有了礦山才能有金子，有了礦山，終究會有金子。

因此，開發資料業務最主要的驅動力，實際是對資料業務未來前景的積極預估。

主要應用有（除廣告之外）：

• 使用者畫像——越來越多的企業開始觀眾使用者畫像，畢竟知己知彼百戰不殆，賣東西先得了解買主。
• 客戶保持——預測哪些現有客戶可能棄用產品或服務，即使採取措施挽留之。
• 產品使用分析——DAU，MAU，PV，UV，CTR等等，這些看起來都是些簡單的統計數字，但卻是反應產品被使用情況的重要指標。
• 產品推薦、銷量預測
• 銷售指標……等等

具體到某一種應用，看似並不複雜，有些有成熟的方法可以用來訓練模型，還有些根本就是統計指標。似乎並不需要什麼高深的演算法背景。

但一旦涉及實際，就不像看起來那麼簡單了。即使是統計指標，也不像想象得那樣，隨便run幾個sql query就能得出來。

對於大型分散式系統，不同模組的訪問log都有可能分佈在不同的cluster上，單純收集每日全域性log就是一個複雜工作，更別說之後的合併、去重、聚合等工作。

因此，大型企業的資料分析不是做個excel表，安裝一個免費mysql能夠解決的，而是需要專門的大型資料分析平臺。

2. 資料分析平臺通用架構

常見的資料分析平臺，至少包括資料儲存、處理和分析三個部分。

2.1 資料儲存

資料儲存不必解釋，是一定必要的。但是如何備份是一個很重要的問題。假設：某公司一年產生上千PB的資料。按照單純資料的儲存費用1美元/GB年計算，存1TB一年就是1000美元，一PB就是100萬，1000PB就是10億。如果就是簡單的使用hadoop的預設配置，每份資料都存3份，那麼，這個實際產生資料x 3的體量將有多大？有將有多大的cost？

這是儲存層的挑戰。為了解決這個問題，一方面從硬體層面力圖降低儲存介質的價格，比如近年來冷儲存的提出，就是針對運維費用。另一方面就是尋找備份演算法。例如，yahoo專門研發了一種圖片儲存演算法，邏輯上是11個備份，但是size只有原size的1.x倍。

2.2 資料處理

資料處理傳統上叫ETL、EDW，主要指資料的清洗、遷移和格式化。大資料平臺，由於應用範疇不同，自然多種多樣，源資料包括結構化資料和非結構化資料。但是如果資料真的是“大資料”（符合4V特徵）的話，即使本身收集上來的資料是結構化的，也往往需要二次處理，轉換format或schema。

資料處理層所需技術相對簡單，然而挑戰在於對於資料的理解。如果不知道這個收集上來的log檔案裡面要提取出多少欄位，每個欄位對應資料來源中的哪個部分，則資料提取完全不能進行。這就要求進行資料處理的人必須同時具備對業務的瞭解。

2.3 資料分析

資料分析是資料中尋找價值的關鍵步驟。資料分析工作本身還處於初級階段。除了一些簡單的統計計算，大多數資料還是隻能交給分析人員，進行沒有特別針對性的探索，效果難以得到保證。

對於這些挑戰，開展資料業務早的公司，相應的平臺和技術是在針對自身業務的過程中慢慢發展起來，部分公司選擇是將平臺外包或者自己開發針對自身業務的定製功能。相對於前兩者，資料分析師一個業務針對性更強的步驟，因此更難採用通用方法或手段解決，更加依賴企業自身的積累。

3. 資料分析平臺開源框架

3.1 開源框架

目前，就國內而言，談到資料分析相關的開源框架，總不能忽略下面三個：

• hadoop：batch，mapReduce
• storm：streaming
• spark：batch + streaming

這些開源框架的共同特點是把重點放在平行計算框架上，關注的是job latency, load balance和fault recovery，對於資源分配、使用者管理和許可權控制幾乎不考慮。它們基於的假設是:所有使用者都一樣，平權，所有使用者都能用所有的機器以最快的可能完成所有工作。

3.2 開源框架的侷限

而在大型企業內部，不同部門，同一部門的不同job，絕對不是平權的。不同部門之間，也有很多私密的資料，不讓別人訪問。不同使用者的許可權也是不一樣的。對於計算資源的需求，因為不同job的優先順序不同，也要求予以區別。

在這種需求之下，催生了一些第三方，專門提供hadoop等開源框架的資源、許可權管理產品或者服務。hadoop在升級到2以後，也考慮一些資料隔離的問題。

但其力度，恐怕難以滿足大多數大型企業的要求。這也是使用開源框架的無奈。使用開源產品的商業發行版，也是一種辦法。不過始終是不如企業原生系統在這方面的支援。

3.3 企業原生框架

確實也有些企業獨立開發了全自主（不基於開源產品）的僅限於內部使用的分散式資料處理平臺。在使用者管理，資料訪問許可權，儲存、運算資源管理等方面很下功夫。

例如：要求每個使用者在提交job前必須先申請token，有多少token，就有多少計算量。不同資料儲存路徑之間的許可權完全單獨管理，使用者也要實現申請許可權。

但是開發這樣的系統意味著企業必須具備非常強大的研發能力，並能承擔得起巨大的人力等資源的消耗。而且相對於開源系統已經實現的功能，難免有重複造輪子之嫌，即使是大型企業，也很少選取這種方案。

4. 大型IT企業資料業務的挑戰

4.1 通用挑戰：意識、技術和人才

4.1.1 意識

意識主要是指決策層的思想意識——資料對於企業發展是否真的必要？這一點在很多管理者腦子裡還是存疑的，他們目前所處狀態很多是：聽說資料這東西有用，人家都在搞，所以我們也要搞，至於是不是真有用，搞出來看看再說。

如果只是採用遊戲或者試探態度，必然影響發展程式。但這也是沒辦法的事情，所有新事物都必須經歷這一過程。

4.1.2 技術

技術指目前資料分析的技術，基本是採用新框架逆流支援舊介面的策略。曾經有一篇文章，名叫《NoSQL？NO，SQL》，說的就是這個。包括spark回頭支援SQL，也是如此。

明明我們分析的是非結構化資料，但是因為高階演算法的問題，卻連mapReduce都放棄了，索性回到SQL時代。為了讓更多人用的舒服，不去開發針對非結構化資料的新方法，而是反過來，向下相容結構化。個人認為這是一種逆流。這樣做則永遠無法避免巨大的資料處理工作。

4.1.3 人才

“資料科學家”這個詞大家肯定都知道。可是，這個職位其實很模糊，不同公司，甚至同一公司的不同部門之間對這一職位的定義相差甚遠。有些資料科學家是學數學的博士，有些是以前做BI的，有些是PM轉行的，水平參差不齊。

所以，恐怕在相當長的時期裡，這會是一個門檻低，要求高的職位。很難短時間內批量湧現出優秀者。

4.2 特有挑戰：產品align

產品align是說每個產品的資料分析結果可以互相對比，也就是要求其定義和實現都一致。對於一個產品眾多的大企業而言，要求不同產品、流水線的分析報告具有可比性，這是一個很常見的需求。但是由於現在大多數企業中資料分析不是由一個部門統一管理，各個產品部門各自為戰，結果導致在align的過程中互相牽制，進而拉低了所有產品的分析水平。

這樣的挑戰有賴於企業總體資料策略的制定和執行。而整體策略的制定和執行又有賴於前面所說的三點通用挑戰，環環相扣，顯然不能一蹴而就。

5. 大企業資料工作的發展趨勢

早期的資料分析工作，在實踐層面基本採用批處理模式。隨著業務的發展，對於其實時或者準實時(NRT)的需求越來越多。提供latency極短的增量分析和流式服務是眾多企業資料分析工作的當務之急。

從長遠考慮，真正擁有資料的是大企業，未來，大企業在資料的分析利用上，也必將全面勝出小企業。

不過，處於不同成熟階段的大公司突破點各不同。有些技術先行，在分析方法和工具上成為領軍。另一些則傾向資料管理和治理，在管理層面上，在策略、條例的制定上為整個社會提供先進經驗。

---

本文首發於GitChat，未經授權不得轉載，轉載需與GitChat聯絡。

閱讀全文: http://gitbook.cn/gitchat/activity/59edfeb7991df70ecd5a2fd0

一場場看太麻煩？成為 GitChat 會員，暢享 1000+ 場 Chat ！點選檢視