Etu產品發(fā)布 專訪高層深度解析Hadoop
剛才談到了數(shù)據(jù)量的問題，但是事實上數(shù)據(jù)量本身不是數(shù)據(jù)庫，對Oracle數(shù)據(jù)庫來講數(shù)據(jù)量不是問題，用大數(shù)據(jù)主要原因我認為是數(shù)據(jù)類型太復雜？
蔣居裕先生表示：“我剛才說了三個“V”的PPT，是可以畫三個橢圓的?！?/P>
陳昭宇先生先生：“舉一個簡單的例子，很多電信業(yè)都有非常大的數(shù)據(jù)倉庫，數(shù)據(jù)量不是問題，但是問題是這些數(shù)據(jù)庫的數(shù)據(jù)是重合的，一定是從前端設備采集進來的，經過一些結構化的過程，比如通過一些腳本處理這些數(shù)據(jù)。很多電信公司可能有不同的電信應用用的不同的數(shù)據(jù)公司，這些必須要統(tǒng)一，就是極大的問題。有一個問題是數(shù)據(jù)量及時進來，每天錄一次庫，所以報表一天才能看一次，今天看昨天的數(shù)據(jù)。所以如果從數(shù)據(jù)庫觀點來看不是數(shù)據(jù)庫的問題，可是從端到端來看就是有一些問題需要解決。非結構化或者海量數(shù)據(jù)其實Hadoop就是一個很適合的工具。”
查禮先生：“數(shù)據(jù)量也是問題。比如GPS-LBS系統(tǒng)，GPS系統(tǒng)一秒鐘更新一個數(shù)據(jù)，每個人手里都有一個設備，假設我有一個應用，實時跟蹤任何一個人的行為，這個數(shù)據(jù)量非常大。我們做過一個實驗，My-SQL數(shù)據(jù)庫，撐到1000萬以上，慢的不得了了。如果GPS數(shù)據(jù)容易達到這個數(shù)據(jù)量的，每秒鐘發(fā)一個數(shù)據(jù)的。
另外一個場景，現(xiàn)在數(shù)據(jù)計算，一個是數(shù)據(jù)大，另外一個要快。快不是說處理速度快，是整個數(shù)據(jù)生產過程，比如說從一天縮短到秒級，這個事我們做不了，用數(shù)據(jù)庫絕對不可能。因為我今天的PPT時間關系少了一張，就是ETL過程，就是數(shù)據(jù)差距到入庫可以查到時間是一天到兩天，現(xiàn)在改成10秒鐘了。這些都是新的技術，必須要做一些技術上的變革才有可能做到時間間隔從天到秒的變革。”
蔣居裕先生：“大數(shù)據(jù)應用非常強調的應用場景就是提高客戶滿意度。很多電信運營商把傳統(tǒng)的打電話行為數(shù)據(jù)放到數(shù)據(jù)倉庫里，可是因為這個過程越來越多的數(shù)據(jù)，客戶有一個問題，比如現(xiàn)在為什么電話打不通，或者短信發(fā)不出去，打到客服中心，客服中心要一層一層的找客戶的問題出現(xiàn)在哪兒。如果回到處理時間一天才有辦法更新一次，那客戶會定在那里了，客服會說你的原始還沒有處理，我不知道哪出了事情。有時候企業(yè)想象Hadoop能帶給他什么價值的時候，不用想什么應用，光是把做的環(huán)節(jié)有所提高就是很有價值的?！?/P>
陳昭宇先生：“比如電信傳統(tǒng)的帳單計算過程，比如有一些CDR數(shù)據(jù)進來，現(xiàn)在是先算出每一個人的秒數(shù)，總通話的秒數(shù)，配合什么時段、什么費率?，F(xiàn)在臺灣最大的運營商，一個用戶分六批算帳，一個月，每算一個要花6到8個小時，我們做的方式是把從CDR這邊進來，用Hadoop計算秒數(shù)，我們用了大概是12個節(jié)點，150G的數(shù)據(jù)用了（1.5小時）?！?/P>
查禮先生：“現(xiàn)在那么多應用，能把他的用戶體驗從天提高到小時，已經有一大把的事情要做了。比如移動他們自己就有這樣的例子，以前做省一級的經分，原來是小型機，還不能夠用全量數(shù)據(jù)，只能采樣數(shù)據(jù)，現(xiàn)在不用小型機，用一個PC服務器，成本比那個小型機少，用全量數(shù)據(jù)，比那個時間還少，這都是Hadoop能夠做到的?！?/P>
蔣居裕先生：“我們針對中國市場是更能凸顯我們的價值了?；剡^頭來我們現(xiàn)在定義的用戶方案和用戶對象，他們能不能很快的有知覺，我們跟他講的事情，對他來講，什么時候他可以想要開始做了。”
關注我們
