參加這個會議室一次機緣和巧合，正好我的同事由于私事不能參加，而我目前正負責(zé)百度電商知心項目的數(shù)據(jù)平臺工作，雖然是web工程師出身，但是大會的主題是數(shù)據(jù)，這勾起了我的欲望，因為數(shù)據(jù)平臺的建設(shè)也已經(jīng)大半年了，遇到不少問題，幾乎可以說野路子出身的我，如果再不接收一些大師們的醍醐灌頂，恐怕遲早要摔跤，所以我扛起了我的書包，說走咱就走，風(fēng)風(fēng)火火闖帝都了。
第一天
大概可以分成4個主題——數(shù)據(jù)庫技術(shù)探索、Hadoop技術(shù)實戰(zhàn)和應(yīng)用、數(shù)據(jù)庫性能調(diào)優(yōu)以及陌生的微軟大數(shù)據(jù)戰(zhàn)略分享，總的來說大部分都不太符合對應(yīng)的主題，我為什么要黑呢? 且聽我娓娓道來吧。（PS:第一天大部分是吐槽、第二天和第三天干活比較多學(xué)得東西不少）
首先關(guān)于數(shù)據(jù)庫技術(shù)探索的主題，本以為會宏觀的介紹目前業(yè)界新技術(shù)，給大家漲漲姿勢，讓大家自慚形穢，不要老是吹自己家技術(shù)逼格有多高。。?？墒俏义e了，第一個上的是國家隊中國移動的大拿，噼里啪啦一頓說自己的數(shù)據(jù)平臺用了哪些技術(shù)有多么牛逼，大哥你說的國外都玩爛了，有意思么，我當(dāng)然沒站起來喊出來，我只是默默地在心里吶喊著；第二個嘉賓來自藍色巨人IBM，一個研究生階段特別崇拜的一家公司——現(xiàn)在對它的印象則是臃腫、潛力不大，講的主題是《珠聯(lián)璧合：大數(shù)據(jù)聯(lián)姻數(shù)據(jù)倉庫后》，本來以為這個聯(lián)姻單純只是一個比喻，這半個老外居然還真的就把兩者當(dāng)老公和老婆的關(guān)系說了，居然總結(jié)出這樣一個結(jié)論——結(jié)婚后的家庭情況就像大數(shù)據(jù)，有各種各樣處理不完的事情，需要一個數(shù)據(jù)倉庫來幫忙歸類處理，然后就是說IBM在大數(shù)據(jù)這一塊如何牛逼，又是一頓吹，我無語，對IBM的不好印象又是雪上加霜了。第三個嘉賓不是一個人，而是一開始就擺上了三個沙發(fā)，這次三個人輪流被美女主持人以提問的方式來分享，具體內(nèi)容我就不多說了，大概就是說華為和SAP合作很愉快，華為出硬件、SAP出軟件打造的內(nèi)存計算一體機給北交大的教研使用是多么的有效果，結(jié)論做廣告呢！不過話說這北交大的博士口才還可以，句句旁敲側(cè)擊地贊美之詞，確實牛逼，這一下給在我心中的博士大大點了一個贊，當(dāng)然后續(xù)一位嘉賓的故事，卻又一次把博士黑出了翔！
上午就在一頓廣告中度過，稍微有點失望，但是想想人家組織的人也要收點錢過日子，后面應(yīng)該就是干活了，好得主題是Hadoop技術(shù)實戰(zhàn)和應(yīng)用，我看他們應(yīng)該玩不出新花樣吧。下午比較特殊的是上面講的兩個主題分成了兩個專場，也就是你只能選擇一個主題聽，或者你也可以兩個專場挑著聽，我這次來主要是奔著大數(shù)據(jù)的，所以果斷選擇hadoop，而沒有去數(shù)據(jù)庫調(diào)優(yōu)的專場。
hadoop專場##
不愧是現(xiàn)在風(fēng)風(fēng)火火的hadoop，下午一共5個會議：
- 大云Hadoop平臺及應(yīng)用（移動大拿真能取名字，很給力——大云，莫非是大數(shù)據(jù)和云計算的合合稱？）
- spark運行時模型剖析（--！這么具體，大數(shù)據(jù)實時計算是火到逆天了么？）
- Hadoop生態(tài)技術(shù)在阿里搜索的實戰(zhàn)應(yīng)用（阿里的技術(shù)還是相當(dāng)有魅力的）
4.大數(shù)據(jù)下非結(jié)構(gòu)化數(shù)據(jù)管理系統(tǒng)的設(shè)計及其應(yīng)用案例
5.愛奇藝在Hadoop生態(tài)中大數(shù)據(jù)平臺架構(gòu)與實踐（誰說百度技術(shù)不如阿里和企鵝的，我廠下屬的視頻公司都高大上的好吧，吐槽一下抱歉）
在下不是會議記錄者，無法做到把每一個會議都詳實的描述一番，真要這么做，估計我可以轉(zhuǎn)行了（哈哈，想當(dāng)年小學(xué)作文拿過滿分的，現(xiàn)在真是慚愧--）。言歸正傳，聽我一一總結(jié)吧：
大云平臺#####
大拿介紹：王寶晗（確實含蓄），中國移動研究院“大云”項目組Hadoop技術(shù)專家
電信領(lǐng)域嘛，無論是海量數(shù)據(jù)批處理、大數(shù)據(jù)實時查詢和分析以及數(shù)據(jù)挖掘等方面對hadoop都提出了更多要求，所以移動人們就自己捯飭，搞了一個大云。那這貨長什么樣子呢，先看一下廬山真面目：
大家不要怕哦，會議不到45分鐘，所以含蓄同志也沒法講那么多內(nèi)容，總結(jié)一下主要講的就是以下4個方面，咱們一起來看看：
- 數(shù)據(jù)存儲和計算——hadoop生態(tài)技術(shù)（這詞在這次大會上用爛了，我也引用一把，的確hadoop各個組件完全就是一個生態(tài)圈）
我想用ppt中圖大家更直觀地感受一下：
隨便掃一眼玩過大數(shù)據(jù)的小伙伴們都驚呆了，在我們印象中壟斷企業(yè)技術(shù)都很老，轉(zhuǎn)個頭都要鬧很大動靜的，你瞧瞧就不說YARN、SPARK這種現(xiàn)在剛出來不久的玩意了，看來研究員的同志們的確不是吃干飯的，幫助移動跟上了世界的步伐呢，我覺得一點不夸張，本來我對移動大拿的分享不是很感冒的，一看到這，來勁了，真想點32個贊！這一塊相信大家也都了解是干嘛的，真的不懂百度一下單詞就哦了，我就不廢話了，正所謂知我者謂我心憂，不知我者謂我何求！
- 數(shù)據(jù)倉庫系統(tǒng)
重點介紹了數(shù)據(jù)倉庫系統(tǒng)——HugeTable（比BigTable還要牛逼的節(jié)奏哈），里面還真是包羅萬象，直接上圖：
- 圖計算
圖計算為什么要單獨領(lǐng)出來呢？不也是計算的一種么，人家的圖計算平臺BSP開源了（傳送門），這才是關(guān)鍵，你代碼寫的搓敢開源么，這是需要信心和魄力才能辦到的，關(guān)鍵是人家還不吝嗇，秀出來內(nèi)部處理的結(jié)構(gòu)：
上圖畫很清晰，描述從輸入、任務(wù)、產(chǎn)出一系列的流程，計算階段比較復(fù)雜的各worker之間的同步問題如何解決呢？在往下看一看人家如何解決：
個人覺得這些才是今天含蓄同學(xué)的干貨，其他的一些就不多寫了
spark運行時模型剖析######
大拿：連城（這名字不錯），Intel物聯(lián)技術(shù)研究院研究員
Spark這貨想必搞大數(shù)據(jù)的童鞋們都耳熟能詳了，因為這貨的目的是滅了MR（霸氣）。這貨如果不是用Scala寫的話，而是java ，我估摸著MR早已經(jīng)完敗了，正所謂任何事物都不是完美的，用scala也是考慮到種種問題。在迭代型計算中，相較于傳統(tǒng)MR程序，功能對等的Spark程序往往可以幾分之一的代碼量達到一兩個數(shù)量級的效率提升，這主要得益于RDD的表達能力和Scala語言層面的靈活性，當(dāng)然對應(yīng)著的Spark的運行時模型比傳統(tǒng)的MR要復(fù)雜，若不能深刻理解，很難開發(fā)出高效的應(yīng)用，這也這次主題意義所在 帶領(lǐng)大家剖析spark的運行時模型，切實理清自己的每一行代碼在何時、何地、以何種方式運行、背后又隱藏著怎樣的代價。
為什么說spark實現(xiàn)效率更高？大家看一下同樣是實現(xiàn)單詞計數(shù)的功能，spark語言是如何實現(xiàn)的？
sc.textFile("hdfs://...") .flatMap(_.split(" ")) .map(_ -> 1) .reduceByKey(_ + _) .collectAsMap()
是不是很少，相比mr那復(fù)雜的實現(xiàn)，只能說java的代碼量太大了!
spark要是展開講就太多太多了，感興趣的同學(xué)可以去官網(wǎng)（spark傳送門)
Hadoop生態(tài)技術(shù)在阿里搜索的實戰(zhàn)應(yīng)用######
大拿：王峰 花名：莫問，阿里巴巴高級技術(shù)專家
阿里還是不錯的拿出了不少干貨，這次又把自己的搜索系統(tǒng)給貢獻出來；主要是介紹在阿里全網(wǎng)商品搜索業(yè)務(wù)場景下，闡述我們?nèi)绾卫貌U展Hadoop和HBase，從而搭建一整套海量商品存儲系統(tǒng)和實時商品處理系統(tǒng)。
大概分為四塊來說
-
阿里搜索離線技術(shù)平臺
這直接上圖最直觀，看看技術(shù)平臺長什么樣子吧
-
阿里全網(wǎng)商品搜索系統(tǒng)架構(gòu)
-
阿里全網(wǎng)商品實時處理流程
HQueue是基于Hbase實現(xiàn)的一個Queue，它主要有以下特性：
?讀寫高性能（新消息都在MemStore + 順序存儲）
?消息持久化存儲，丌丟失（HFile + HLog）
?消息支持TTL設(shè)定，自勱清理過期消息（HBase TTL）
?消息支持主勱拉和訂閱兩種模式（HBase Client Wrapper + Coprocessor）
?服務(wù)支持勱態(tài)負載均衡（HBase Load Balance）
?服務(wù)支持快速Failover (HBase MTTR)
?支持多語言客戶端（擴展HBase Thrift Server）
?可不Hadoop計算平臺無縫對接（HQueueInputFormat/OutputFormat）
?可復(fù)用HBase集群直接部署管理，無需獨立硬件（HQueue Shell）
IStream則是阿里搜索分布式計算技術(shù)體系中的一員（另外兩個分別是批量處理計算模型MapReduce/Spark迭代計算模型），它是主打流計算。然后是這三個貨都統(tǒng)一由Hadoop Yarn管理。它的主要特性有：
?計算和存儲層分離，可靈活搭配消息隊列
?計算拓撲開放，可以根據(jù)業(yè)務(wù)變化勱態(tài)調(diào)整
?具備流處理進度管理能力，進度可視化以及監(jiān)控報警
?具備彈性調(diào)度能力，可根據(jù)進度勱態(tài)調(diào)整計算資源數(shù)量
?服務(wù)Metrics自勱記錄到OpenTSDB中，可WebUI查看
?類似MR Streaming方式，支持多語言編程
?可不MR等模型共享Hadoop集群，無需單獨集群部署
比較遺憾的是大拿沒有講到這些數(shù)據(jù)是怎么被用來做搜索的，畢竟時間有限吧，分享了一些搜索系統(tǒng)的底層實現(xiàn)也讓我們受益匪淺了。
大數(shù)據(jù)下非結(jié)構(gòu)化數(shù)據(jù)管理系統(tǒng)的設(shè)計及其應(yīng)用案例######
大拿：李銀松 北京拓爾思信息技術(shù)工程師
這個就是來宣傳自己公司產(chǎn)品的了，主要就是TRS結(jié)合20多年非結(jié)構(gòu)化信息智能處理研發(fā)經(jīng)驗，吸取Hadoop、MPP、NoSQL、Solr等開源軟件的思想，融合檢索引擎、多引擎機制、分布式并行計算和多副本機制、對等點機制、新型列數(shù)據(jù)存儲機制、自然語言處理等先進技術(shù)的產(chǎn)品介紹，這個就不多說了，因為就是宣傳，基本沒有干貨--#
愛奇藝在Hadoop生態(tài)中大數(shù)據(jù)平臺架構(gòu)和實踐######
大拿：孫琦 愛奇藝分布式計算資深工程師
盡管是同一個大老板下面的，那我也得實事求是的說，整個節(jié)奏先抑后揚，一開始也是宣傳，后面才漸入佳境。我就直接上干貨了：
咱們先來看一下愛奇藝是怎么玩Hadoop的。
*數(shù)據(jù)格式：ProtoBuf、JSON為主，統(tǒng)一數(shù)據(jù)定義，以便數(shù)據(jù)共享
*批處理以Hive作業(yè)為主
*Storm、Spark實時計算資源托管在Mesos或Openstack虛機之上
*大部分HBase應(yīng)用是為離線計算服務(wù)
*作業(yè)提交管理：入口機 + 專用提交系統(tǒng)
*系統(tǒng)監(jiān)控：傳統(tǒng)監(jiān)控 (Nagios, Zabbix) + Metrics數(shù)據(jù)聚合
*成本審計：貨幣化度量項目組開銷
Hadoop: HDFS HA也是基于雙NameNode節(jié)點實現(xiàn)。
使用案例1：基于虛擬化Storm應(yīng)用：
使用案例2：基于Mesos的云端應(yīng)用：
PS: Mesos是一個開源集群資源管理和調(diào)度系統(tǒng)， 類似的系統(tǒng)有Google的Borg、Omega、騰訊的torca、Hadoop的YARN等， 這類系統(tǒng)的目的是在一個集群上支持多種計算模型， mesos目前支持hadooop， MPI， TorQue， Spark 。
想不到自己總結(jié)一下，干貨還是不少，后續(xù)還需要展開著一一攻克，童鞋們一起加油吧，學(xué)海無涯苦作舟，第一天就到此為止了，后面還有兩天，分別我關(guān)注的主題是Nosql&NewSQL和數(shù)據(jù)倉庫，敬請期待吧。
