1. 程式人生 > >(轉)我所經歷的大數據平臺發展史(三):互聯網時代 ? 上篇

(轉)我所經歷的大數據平臺發展史(三):互聯網時代 ? 上篇

舉例 不堪 電信 oop poc 這樣的 數據庫 .com 智能

編者按:本文是松子(李博源)的大數據平臺發展史系列文章的第二篇(共四篇),本系列以獨特的視角,比較了非互聯網和互聯網兩個時代以及傳統與非傳統兩個行業。是對數據平臺發展的一個回憶,對非互聯網、互聯網,從數據平臺的用戶角度、數據架構演進、模型等進行了闡述。

前言,本篇幅將進入大家熟知的互聯網時代,數據平臺發展史僅是自己經歷過由傳統數據平臺到互聯網數據平臺發展一些簡單回憶,在這一篇章中將引用部分互聯網數據平臺架構,在這裏僅作案例。

我相信很多從傳統行業轉到互聯網時是各種不適應,適應短則幾個月,長則一年以上。進入到互聯網有種感覺,它是一個擅長制造流行新概念的行業,“數據平臺“,”數據產品“也不幸免。數據平臺這詞 Data PlatForm 也無從考究是從什麽時間點被提出的,僅知道自己剛進互聯網時”數據平臺“ 這個詞狹義代指數據倉庫了。

08 年左右的 Data Platform 還泛指數據倉庫,那時互聯網企業的數據倉庫剛興起沒幾年,在建設思路上還是以傳統數據平臺的第二、三代架構為參照物實施建設的。自己猜測那時很多互聯網企業也是使用 Oracle、IBM、EMC 的軟硬件區做的各類系統的實施,自然數據平臺建設者都是來給電信、移動、制造業等各大數據倉庫實施的甲方、乙方各類牛人。

行業的差異性導致業務不同,影響到數據平臺源(數據源)的差異性、隨著信息化共享與服務的這個“神奇”互聯網行業快速發展,互聯網業務逐漸的重視數據,所以互聯網的從業者在看數據、使用數據的方式每一年也不同、大數據的各種技術也在快速更新中,各方面因素導致了互聯網數據平臺的建設、服務用戶特點、數據模型與非互聯網數據平臺有較為顯著差異。

數據源

做數據的人,從非互聯網進入到互聯網最顯著的特點是面對的數據源類型忽然多了起來,在傳統企業數據人員面對的是結構化存儲數據,基本來自 excel、表格、DB 系統等,在數據的處理技術上與架構上是非常容易總結的,但是在互聯網因為業務獨特性導致了所接觸到的數據源特性多樣化,網站點擊日誌、視頻、音頻、圖片數據等很多非結構化快速產生與保存,在這樣的數據源的多樣化與容量下采用傳統數據平臺技術來處理當然是有些力不從心了(備註:IBM 的科學家分析員道格. 萊尼的一份數據增長報告基礎上提出了大數據的 4V 特性 大數據 4v 特性網上概念很多大家可以問度娘)。

目前最火熱的移動互聯網, 大家都在通過自己的手機、平板去訪問網站、購物等所以每個人都是數據的生產者,移動用戶在使用習慣上呈現移動化、碎片化,以至於業務特性、商業模式比傳統互聯網又有顯著差別, 用戶在不同位置需求是不同的、使用 APP 也是不同的、手機終端類型也是多樣化。這些差異性比較導致移動互聯網的數據與傳統的互聯網時代又產生顯著差異性。

例如買家通過 Pc 購物從瀏覽物品到支付可能在很短時間內完成,但是通過手購物碎片化就顯得多一些,可能在某個空余時間瀏覽物品,保存或放入購物車,等有時間在去做支付。大約在 2009 年到 2012 年之間做用戶行為分析感覺很多原有網頁端拍下物品去支付,逐漸轉為 PC 端下單通過移動端支付。

我在這裏整理一個表格不同時代數據源的差異性(備註可能整理的有點不全):

行業域

非互聯網

互聯網

移動互聯網

數據來源 (相對於數據平臺來講)

結構化各類數據庫 (DB 系統)、結構化文本、Excel 表格等,少量 word

Web、自定義、系統的日誌,各類結構化 DB 數據、長文本、視頻 主要是來自網頁

除了互聯網那些外還含有大量定位數據、自動化傳感器、嵌入式設備、自動化設備等

數據包含信息

CRM 客戶信息、事務性 ERP/MRPII 數據、資金賬務數據 等。

除了傳統企業數據信息外,還含有用戶各類點擊日誌、社交數據、多媒體、搜索、電郵數據等等

除了傳統互聯網的數據外,還含有 Gps、穿戴設備、傳感器各類采集數據、自動化傳感器采集數據等等

數據結構特性

幾乎都是結構化數據

非結構化數據居多

非結構化數據居多

數據存儲 / 數據量

主要以 DB 結構化存儲為主,從幾百兆到 百 G 級別

文件形式、DB 形式,流方式、 從 TB 到 PB

文件形式、流方式、DB 範式,非結構化 從 TB 到 PB

產生周期

慢,幾天甚至周為單位

秒或更小為單位

秒或更小為單位

對消費者行為采集與還原

粒度粗

粒度較細

粒度非常細

數據價值

長期有效

隨著時間衰減

隨著時間快速衰減

單位時間內數據聚合度

高度聚合

聚合度低

聚合度很低

技術分享圖片

該圖引用 2013 年“中國數據庫大會大數據的實踐與應用”

數據平臺的用戶

總結下來互聯網的數據平臺“服務”方式叠代演進大約可以分為三個階段。

階段一 :

約在 2008 年 -2011 年初的互聯網數據平臺,那時建設與使用上與非互聯網數據平臺有這蠻大的相似性,主要相似點在數據平臺的建設角色、與使用到的技術上。

技術分享圖片

  • 老板們、運營的需求主要是依賴於報表、分析報告、臨時需求、商業智能團隊的數據分析師去各種分析、臨時需求、挖掘,這些角色是數據平臺的適用方。
  • ETL 開發工程師、數據模型建模、數據架構師、報表設計人員 ,同時這些角色又是數據平臺數據建設與使用方。
  • 數據平臺的技術框架與工具實現主要有技術架構師、JAVA 開發等。
  • 用戶面對是結構化的生產數據、PC 端非結構化 log 等 數據。
  • ELT 的數據處理方式(備註在數據處理的方式上,由傳統企業的 ETL 基本進化為 ELT)。

現在的淘寶是從 2004 年開始構建自己的數據倉庫,2004 年是采用 DELL 的 6650 單節點、到 2005 年更換為 IBM 的 P550 再到 2008 年的 12 節點 Rac 環境。在這段時間的在 IBM、EMC、Oracle 身上的投入巨大 (備註:對這段歷史有興趣可以去度娘:“【深度】解密阿裏巴巴的技術發展路徑“),同時淘寶的數據集群也變為國內最大的數據倉庫集群。

技術分享圖片

技術分享圖片

我當時用 Oracle 搭建的數據倉庫做臨時需求時,一個經過反復優化的 SQL 語句在晚上 9 點放入能夠 Running 淩晨 4 點多而被電話中狂吼的 DBA 給 kill 掉,痛不欲生。

因為快速膨脹的數據量,在 2010 年開始考慮引進 Greenplum 最為主平臺提供強大的計算能力,但沒想到快速爆炸的數據量讓我們在 POC 測試階段就把 Greenplum 的適合業務場景定位清楚了。

隨著 2010 年引入了 hadoop&hive 平臺進行新一代的數據平臺的構建,此時的 Greenplum 因為優秀的 IO 吞吐量以及有限的任務並發安排到了網站日誌的處理以及給分析師提供的數據分析服務。

該階段的數據模型是根據業務的特性采用退化、扁平化的模型設計方式去構建的(備註:將會在模型篇章詳細講解)。

技術分享圖片

階段二:

互聯網的數據平臺除了受到技術、數據量的驅動外,同時還來自數據產品經理梳理用戶的需求按照產品的思維去構建並部署在了數據的平臺上。互聯網是一個擅長制造流程新概念的行業。約在 2011 年到 2014 年左右,隨著數據平臺的建設逐漸的進入快速叠代期,數據產品、數據產品經理這兩個詞逐漸的升溫以及被廣泛得到認可(備註:數據產品相關內容個人會在數據產品系列中做深入分享),同時數據產品也隨著需求、平臺特性分為面向用戶級數據產品、面向平臺工具型產品兩個維度分別去建設數據平臺。

技術分享圖片

  • 企業各個主要角色都是數據平臺用戶。
  • 各類數據產品經理(偏業務數據產品、偏工具平臺數據產品)推進數據平臺的建設。
  • 分析師參與數據平臺直接建設比重增加。
  • 數據開發、數據模型角色都是數據平臺的建設者與使用者(備註:相對與傳統數據平臺的數據開發來說,逐漸忽略了數據質量的關註度,數據模型設計角色逐漸被弱化)。
  • 用戶面對是數據源多樣化,比如日誌、生產數據庫的數據、視頻、音頻等非結構化數據。
  • 原有 ETL 中部分數據轉換功能逐漸前置化,放到業務系統端進行(備註:部分原有在 ETL 階段需要數據標準化一些過程前置在業務系統數據產生階段進行,比如 Log 日誌。 移動互聯網的日誌標準化。

互聯網企業隨著數據更加逐漸被重視分析師、數據開發在面對大量的數據需求、海量的臨時需求疲憊不堪,變成了資源的瓶頸,在當時的狀態傳統的各類的 Report、Olap 工具都無法滿足互聯網行業個性化的數據需求。開始考慮把需求固定化變為一個面向最終用戶自助式、半自助的產品來滿足快速獲取數據 & 分析的結果,當總結出的指標、分析方法(模型)、使用流程與工具有機的結合在一起時數據產品就誕生了(備註:當時為了設計一個數據產品曾經閱讀了某個部門的 2000 多個臨時需求與相關 SQL)。

技術分享圖片

數據產品按照面向的功能與業務可以劃分為面向平臺級別的工具型產品、面向用戶端的業務級數據產品。按照用戶分類可以分為面向內部用戶數據產品,面向外部用戶個人數據產品、商戶(企業)數據產品。

面向平臺級別有數據質量、元數據、調度、資管配置、數據同步分發等等。(備註:關於數據產品的發展與數據產品體系更多內容,請關註個人寫作“數據產品系列”)。

技術分享圖片

約 2010-2012 年的平臺結構

技術分享圖片

約 2012-2013 年的平臺結構

技術分享圖片

階段三:

互聯網業務的快速發展、大家已經從經營、分析的訴求重點轉為數據化的精細運營上,隨之而來的面臨創新壓力、如何做好精細化運營,數據平臺的用戶其聚焦在無法快速的響應日常需求其表現為做數據的已經無法滿足當前業務日益增長的數據需求、運營上精細化已經對數據的粒度要求由高匯總逐漸轉為過程化細粒度明細數據。

隨著數據應用的深入,用數據往往不知道數據的口徑與來源,加工數據的不知道業務含義,不同部門口徑又是不一樣,有的從交易來、有的從賬務來。這裏數據使用與數據加工上就出現了”斷層”。有時在層級與功能部門前邊也可能存在一個斷層,對數據價值的內在衡量是不一樣的,角色不一樣,對於數據價值的的看法也就不同。

由於以上的種種問題,用數據的一些角色(分析師、運營或產品)會自己參與到從數據整理、加工、分析階段。當數據平臺變為自由全開放,使用數據的人也參與到數據的體系建設時,基本會因為不專業型,導致數據質量問題、重復對分數據浪費存儲與資源、口徑多樣化等等原因。此時原有建設數據平臺的多個角色可能轉為對其它非專業做數據人員的培訓、咨詢與落地寫更加適合當前企業數據應用的一些方案等。例如原有的數據產品會加入更多的在原有的數據建設中才有的一些流程讓用戶來遵守(統一的數據搜集、數據標準化的前置)。舉例 Log 埋點產品化、自動 Report 的過程規範化(舉例說明:原有一些運營自己建立的一些報表可能 sql 有問題就直接放入報表生成器中了。更改流程第一步現在 MQ 中驗證完畢口徑後,通過元數據解析進入到報表生成器中)、基於元數據驅動的 ETL 流程化等等,因為偏自助式、服務化的一些數據產品建立也將會導致數據平臺叠代的演進。

技術分享圖片

  • 給用戶提供的各類豐富的分析、取數的產品,簡單上手的可以使用。
  • 原有 ETL、數據模型角色轉為給用戶提供平臺、產品、數據培訓與使用咨詢。
  • 數據分析師直接參與到數據平臺過程、數據產品的建設中去。
  • 用戶面對是數據源多樣化,比如日誌、生產數據庫的數據、視頻、音頻等非結構化數據。

在互聯網這個大數據浪潮下,2016 年以後數據平臺是如何去建設?如何服務業務?

技術分享圖片

企業的不同發展階段數據平臺該如何去建設的?這個大家是可以思考的。但是我相信互聯網企業是非常務實的,基本不會采用傳統企業的自上而下的建設方式,互聯網企業的業務快速變與叠代要求快速分析到數據,必須新業務數據叠代,老業務數據快速去雜。敏捷數據平臺或許是種不錯的選擇方法之一吧!

下一篇將是本系列的最後一篇,互聯網數據平臺下的數據建模(備註:是數據倉庫模型)。

關於作者

松子(李博源) 自由撰稿人,數據產品 & 數據分析總監。2000 年開始數據領域,從業傳統制造業、銀行、保險、第三方支付 & 互聯網金融、在線旅行、移動互聯網行業 ; 個人沈澱在大數據產品、大數據分析、數據模型領域;歡迎關註個人微信訂閱號:songzi2016。


感謝杜小芳對本文的審校。

給 InfoQ 中文站投稿或者參與內容翻譯工作,請郵件至[email protected]。也歡迎大家通過新浪微博(@InfoQ,@丁曉昀),微信(微信號:InfoQChina)關註我們。

(轉)我所經歷的大數據平臺發展史(三):互聯網時代 ? 上篇