南京大數據meetup

『壹』 Spark與Hadoop MapRece大比拼，誰實力更強

一提到大數據處理，相信很多人第一時間想到的是 Hadoop MapRece。沒錯，Hadoop MapRece 為大數據處理技術奠定了基礎。近年來，隨著 Spark 的發展，越來越多的聲音提到了 Spark。而Spark相比Hadoop MapRece有哪些優勢?
Spark與Hadoop MapRece在業界有兩種說法 ：一是 Spark 將代替 Hadoop MapRece，成為未來大數據處理發展的方向 ;二是 Spark 將會和 Hadoop 結合，形成更大的生態圈。其實 Spark 和 Hadoop MapRece 的重點應用場合有所不同。相對於 Hadoop MapRece 來說，Spark 有點「青出於藍」的感覺，Spark 是在Hadoop MapRece 模型上發展起來的，在它的身上我們能明顯看到 MapRece的影子，所有的 Spark 並非從頭創新，而是站在了巨人「MapRece」的肩膀上。千秋功罪，留於日後評說，我們暫且擱下爭議，來看看相比 Hadoop MapRece，Spark 都有哪些優勢。
1、計算速度快
大數據處理首先追求的是速度。Spark 到底有多快?用官方的話說，「Spark 允許 Hadoop 集群中的應用程序在內存中以 100 倍的速度運行，即使在磁碟上運行也能快 10 倍」。可能有的讀者看到這里會大為感嘆，的確如此，在有迭代計算的領域，Spark 的計算速度遠遠超過 MapRece，並且迭代次數越多，Spark 的優勢越明顯。這是因為 Spark 很好地利用了目前伺服器內存越來越大這一優點，通過減少磁碟 I/O 來達到性能提升。它們將中間處理數據全部放到了內存中，僅在必要時才批量存入硬碟中。或許讀者會問 ：如果應用程序特別大，內存能放下多少 GB ?答曰 ：什麼? GB ?目前 IBM 伺服器內存已經擴展至幾 TB 了。
2、應用靈活，上手容易
知道 AMPLab 的 Lester 為什麼放棄 MapRece 嗎?因為他需要把很多精力放到Map和Rece的編程模型上，極為不便。 Spark在簡單的Map及Rece操作之外，還支持 SQL 查詢、流式查詢及復雜查詢，比如開箱即用的機器學習演算法。同時，用戶可以在同一個工作流中無縫地搭配這些能力，應用十分靈活。
Spark 核心部分的代碼為 63 個 Scala 文件，非常的輕量級。並且允許 java、Scala、Python 開發者在自己熟悉的語言環境下進行工作，通過建立在Java、Scala、Python、SQL(應對互動式查詢)的標准 API 以方便各行各業使用，同時還包括大量開箱即用的機器學習庫。它自帶 80 多個高等級操作符，允許在 Shell中進行互動式查詢。即使是新手，也能輕松上手應用。
3、兼容競爭對手
Spark 可以獨立運行，除了可以運行在當下的 YARN 集群管理外，還可以讀取已有的任何 Hadoop 數據。它可以運行在任何 Hadoop 數據源上，比如 HBase、HDFS 等。有了這個特性，讓那些想從 Hadoop 應用遷移到 Spark 上的用戶方便了很多。Spark 有兼容競爭對手的胸襟，何愁大事不成?
4、實時處理性能非凡
MapRece 更 加 適 合 處 理 離 線 數 據( 當 然， 在 YARN 之 後，Hadoop也可以藉助其他工具進行流式計算)。Spark 很好地支持實時的流計算，依賴Spark Streaming 對數據進行實時處理。Spark Streaming 具備功能強大的 API，允許用戶快速開發流應用程序。而且不像其他的流解決方案，比如Storm，Spark Streaming 無須額外的代碼和配置，就可以做大量的恢復和交付工作。
5、社區貢獻力量巨大
從 Spark 的版本演化來看，足以說明這個平台旺盛的生命力及社區的活躍度。尤其自 2013 年以來，Spark 一度進入高速發展期，代碼庫提交與社區活躍度都有顯著增長。以活躍度論，Spark 在所有的 Apache 基金會開源項目中位列前三，相較於其他大數據平台或框架而言，Spark 的代碼庫最為活躍。
Spark 非常重視社區活動，組織也極為規范，會定期或不定期地舉行與 Spark相關的會議。會議分為兩種 ：一種是 Spark Summit，影響力極大，可謂全球 Spark頂尖技術人員的峰會，目前已於 2013—2015 年在 San Francisco 連續召開了三屆Summit 大會 ;另一種是 Spark 社區不定期地在全球各地召開的小型 Meetup 活動。Spark Meetup 也會在我國的一些大城市定期召開，比如北京、深圳、西安等地，讀者可以關注當地的微信公眾號進行參與。
Spark 的適用場景
從大數據處理需求來看，大數據的業務大概可以分為以下三類 ：
(1)復雜的批量數據處理，通常的時間跨度在數十分鍾到數小時之間。
(2)基於歷史數據的互動式查詢，通常的時間跨度在數十秒到數分鍾之間。
(3)基於實時數據流的數據處理，通常的時間跨度在數百毫秒到數秒之間。
目前已有很多相對成熟的開源和商業軟體來處理以上三種情景 ：第一種業務，可以利用 MapRece 來進行批量數據處理 ;第二種業務，可以用 Impala 來進行互動式查詢 ;對於第三種流式數據處理，可以想到專業的流數據處理工具Storm。但是這里有一個很重要的問題 ：對於大多數互聯網公司來說，一般會同時遇到以上三種情景，如果採用不同的處理技術來面對這三種情景，那麼這三種情景的輸入/ 輸出數據無法無縫共享，它們之間可能需要進行格式轉換，並且每個開源軟體都需要一支開發和維護團隊，從而提高了成本。另外一個不便之處就是，在同一個集群中對各個系統協調資源分配比較困難。
那麼，有沒有一種軟體可以同時處理以上三種情景呢? Spark 就可以，或者說有這樣的潛力。Spark 同時支持復雜的批處理、互操作和流計算，而且兼容支持HDFS 和 Amazon S3 等分布式文件系統，可以部署在 YARN 和 Mesos 等流行的集群資源管理器上。
從 Spark 的設計理念(基於內存的迭代計算框架)出發，其最適合有迭代運算的或者需要多次操作特定數據集的應用場合。並且迭代次數越多，讀取的數據量越大，Spark 的應用效果就越明顯。因此，對於機器學習之類的「迭代式」應用，Spark 可謂拿手好戲，要比 Hadoop MapRece 快數十倍。另外，Spark Streaming因為內存存儲中間數據的特性，處理速度非常快，也可以應用於需要實時處理大數據的場合。
當然，Spark 也有不適用的場合。對於那種非同步細粒度更新狀態的應用，例如 Web 服務的存儲或增量的 Web 爬蟲和索引，也就是對於那種增量修改的應用模型不適合。Spark 也不適合做超級大的數據量的處理，這里所說的「超級大」是相對於這個集群的內存容量而言的，因為 Spark 要將數據存儲在內存中。一般來說，10TB 以上(單次分析)的數據就可以算是「超級大」的數據了。
一般來說，對於中小企業的數據中心而言，在單次計算的數據量不大的情況下，Spark 都是很好的選擇。另外，Spark 也不適合應用於混合的雲計算平台，因為混合的雲計算平台的網路傳輸是很大的問題，即便有專屬的寬頻在雲端 Cluster和本地 Cluster 之間傳輸數據，相比內存讀取速度來說，依然不抵。

『貳』 如何在雲服務提供商的平台上使用Docker Machine

IBM中國研究院高級研究員陳冠誠主要從事Big Data on Cloud，大數據系統性能分析與優化方面的技術研發。負責和參與過SuperVessel超能雲的大數據服務開發，Hadoop軟硬體協同優化，MapRece性能分析與調優工具，高性能FPGA加速器在大數據平台上應用等項目。在Supercomputing（SC），IEEE BigData等國際頂級會議和期刊上發表過多篇大數據數據處理技術相關的論文，並擁有八項大數據領域的技術專利。曾在《程序員》雜志分享過多篇分布式計算，大數據處理技術等方面的技術文章。以下為媒體針對陳冠誠的專訪：

問：首先請介紹下您自己，以及您在Spark 技術方面所做的工作。

陳冠誠：我是IBM中國研究院的高級研究員，大數據雲方向的技術負責人。我們圍繞Spark主要做兩方面的事情：第一，在IBM研究院的SuperVessel公有雲上開發和運維Spark as a Service大數據服務。第二，在OpenPOWER架構的伺服器上做Spark的性能分析與優化。

問：您所在的企業是如何使用Spark 技術的？帶來了哪些好處？

陳冠誠：Spark作為新一代的大數據處理引擎主要帶來了兩方面好處：

相比於MapRece在性能上得到了很大提升。

在一個統一的平台上將批處理、SQL、流計算、圖計算、機器學習演算法等多種範式集中在一起，使混合計算變得更加的容易。

問：您認為Spark 技術最適用於哪些應用場景？

陳冠誠：大規模機器學習、圖計算、SQL等類型數據分析業務是非常適合使用Spark的。當然，在企業的技術選型過程中，並不是說因為Spark很火就一定要使用它。例如還有很多公司在用Impala做數據分析，一些公司在用Storm和Samaza做流計算，具體的技術選型應該根據自己的業務場景，人員技能等多方面因素來做綜合考量。

問：企業在應用Spark 技術時，需要做哪些改變嗎？企業如果想快速應用Spark 應該如何去做？

陳冠誠：企業想要擁抱Spark技術，首先需要技術人員改變。是否有給力的Spark人才會是企業能否成功應用Spark最重要的因素。多參與Spark社區的討論，參加Spark Meetup，給upstrEAM貢獻代碼都是很好的切入方式。如果個人開發者想快速上手Spark，可以考慮使用SuperVessel免費的Spark公有雲服務，它能快速創建一個Spark集群供大家使用。

問：您所在的企業在應用Spark 技術時遇到了哪些問題？是如何解決的？

陳冠誠：我們在對Spark進行性能調優時遇到很多問題。例如JVM GC的性能瓶頸、序列化反序列化的開銷、多進程好還是多線程好等等。在遇到這些問題的時候，最好的方法是做好Profiling，准確找到性能瓶頸，再去調整相關的參數去優化這些性能瓶頸。

另一方面，我們發現如果將Spark部署在雲環境里（例如OpenStack管理的Docker Container）時，它的性能特徵和在物理機上部署又會有很大的不同，目前我們還在繼續這方面的工作，希望以後能有機會跟大家繼續分享。

問：作為當前流行的大數據處理技術，您認為Spark 還有哪些方面需要改進？

陳冠誠：在與OpenStack這樣的雲操作系統的集成上，Spark還是有很多工作可以做的。例如與Docker Container更好的集成，對Swift對象存儲的性能優化等等。

問：您在本次演講中將分享哪些話題？

陳冠誠：我將分享的話題是「基於OpenStack、Docker和Spark打造SuperVessel大數據公有雲」：

隨著Spark在2014年的蓬勃發展，Spark as a Service大數據服務正成為OpenStack生態系統中的新熱點。另一方面，Docker Container因為在提升雲的資源利用率和生產效率方面的優勢而備受矚目。在IBM中國研究院為高校和技術愛好者打造的SuperVessel公有雲中，我們使用OpenStack、Docker和Spark三項開源技術，在OpenPOWER伺服器上打造了一個大數據公有雲服務。本次演講我們會向大家介紹如何一步一步使用Spark、Docker和OpenStack打造一個大數據公有雲，並分享我們在開發過程中遇到的問題和經驗教訓。

問：哪些聽眾最應該了解這些話題？您所分享的主題可以幫助聽眾解決哪些問題？

陳冠誠：對如何構造一個大數據雲感興趣的同學應該會對這個話題感興趣，開發SuperVessel的Spark as a Service服務過程中我們所做的技術選型、架構設計以及解決的問題應該能對大家有所幫助。（來源：CSDN）

『叄』 Docker生態會重蹈Hadoop的覆轍嗎

一、Docker的興起和Hadoop何其相似
2015年說是Docker之年不為過，Docker熱度高漲，IT從業人員要是說自己不知道Docker都不好意說自己是做IT的。2016年開始容器管理、集群調度成為熱點，K8s開始成為熱點。但這一幕和2013年的Hadoop大數據何其相似，當年你要說自己不知道大數據，或是知道大數據不知道Hadoop，那必然招來鄙視的眼光。
雲計算喊了這么久，從來沒有像Docker這么火過，究其原因不外乎兩條：
1、開發者能夠用Docker，開發者要一個開發環境，總會涉及到種種資源，比如資料庫，比如消息中間件，去裝這些東西不是開發人員的技能，是運維人員的技能。而用Docker去Pull一個mySQL鏡像,或是Tomcat鏡像，或是RabbitMQ鏡像，簡易輕松，幾乎是零運維。做好了應用代碼，打一個Docker鏡像給測試或是運維人員，避免了從前打個程序包給測試或是運維人員，測試或運維人員要部署、配置應用，還得反反復復來麻煩開發人員，現在好了，丟個Docker鏡像過去，讓運維人員跑鏡像就可以，配置在鏡像里基本都做好了。
這正好滿足了DevOps的要求，所以DevOps也一下熱起來了。開發者是一個巨大的市場，是海量的個體，通過類似於病毒式的傳銷，Docker一下在開發者中熱起來了。
2、鏡像倉庫和開源，誰都可以用，Docker鏡像庫非常豐富，誰做好一個鏡像都可以往公有倉庫推送，開發人員需要一個環境的時候，可以到Docker鏡像倉庫去查，有海量的選擇，減少了大量無謂的環境安裝工作。而通過開源，又開始大規模傳播。
我們再來回顧看看2010-2013年，大數據的名詞火遍大江南北，各行各業都在談大數據，但是落到技術上就是Hadoop，還記得2012年的時候，和Hadoop沒啥毛關系的VMWare也趕緊的做了一個虛機上部署Hadoop的serengeti，誰家產品要是和Hadoop不沾點邊，不好意思說自己是IT公司。Hadoop當年的熱度絕對不亞於2014-2015的Docker。而且時間上有一定的連續性，2014年開始，Hadoop熱度達到頂點，開始逐漸降溫，標志事件就是Intel投資Cloudera。而Docker是從2014年開始熱度升高的。
再看Hadoop為何在2010年前後開始熱起來，之前的大數據都是數據倉庫，是昂貴的企業級數據分析並行資料庫，而Hadoop是廉價的大數據處理模式，通過開源和X86廉價硬體，使得Hadoop可以大規模使用，而互聯網時代產生的海量數據雖然垃圾居多，但是沙裡淘金，也能淘出點價值，Hadoop正好迎合了這兩個需求，雖然Hadoop的無論是功能還是性能遠比MPP資料庫差，但做簡單的數據存儲、數據查詢、簡單數據統計分析還是可以勝任的，事實上，到目前為止，大多數的Hadoop應用也就是數據存儲、數據查詢和簡單的數據統計分析、ETL的業務處理。
Docker和Hadoop的熱起來的原因不同，但是現象是差不多，開源和使用者群體大是共同要素。
二、Hadoop從狂熱走向了理性
Hadoop最熱的時候，幾乎就是要replace所有資料庫，連Oracle也面臨了前所未有的沖擊，甚至Hadoop成了去IOE的Oracle的使命之一。在狂熱的那個階段，客戶怎麼也得做一兩個大數據項目，否則會被同行瞧不起，各IT廠商也必須推出大數據產品，否則可能成為IT過時的典範，這不IBM成立了專門的大數據部門，打造了一個以Hadoop為核心的龐大的大數據解決方案。
Intel雖然是做晶元的，但是大數據必須摻和，成立大數據部門，做Intel Hadoop 。連資料庫的老大Oracle也憋不住了，做了個大數據一體機。
任何曾經狂熱的新技術都會走向理性，Hadoop也不例外，只不過，這個進程還比較快。隨著大數據的大躍進，隨著Hadoop的應用越來越多，大家發現在被誇大的場景應用大數據效果並不好，只在特定場景有效，Hadoop進入理性發展階段，比如一開始Hadoop據取代MPP資料庫，取代數據倉庫，取代Oracle，完美支持SQL等等均基本成為泡影。這其實本來是一個常識，任何技術都有其應用場景，誇大應用場景，任意擴展應用場景只會傷害這個技術的發展。
「這和目前無限誇大Docker的應用場景有異曲同工之妙，比如Docker向下取代虛擬化，Docker向上取代PaaS之類，幾乎成了雲計算的唯一技術，這種論調一直充斥各種Meetup/論壇。雖然技術從誇大到理性需要時間，但是理性不會總是遲到。
Hadoop技術在發展，大數據的相關技術也在發展，Hadoop一直被詬病的處理速度慢，慢慢的被Spark/Storm等解決，特別在流數據處理領域。
所以，時至今日，人們對Hadoop的態度趨於理性，它只適合在特定場景使用，可是，當初那些在Hadoop不太適用的場景使用了Hadoop的客戶交了學費的事情估計沒人再提了。Docker估計也是一樣的，總有在誇大的場景中交學費的客戶，可是只是客戶沒眼光嗎?和無限誇大某種技術的佈道師無關么?
再反觀大數據和Docker在全球的發展，在美國，無論是Hadoop和Docker並沒有像國內這么狂熱過。Hadoop技術來源於Google，成型於Yahoo(DougCutting)，而炒作卻是在國內。同樣，Docker也在走這么個流程，在美國沒有這么多的Docker創業公司，主要就是Docker，然後各大廠商支持，創業公司和創投公司都知道，沒有自己的技術或是技術受制於人的公司不值得投資，既然Docker一家獨大，再去Docker分一杯羹會容易嗎?
而國內二三十家的Docker創業公司，沒有一家能對Docker/K8s源碼有讓人醒目的貢獻(反倒是華為在K8s上有些貢獻)，但是都在市場上拼嗓門，不是比誰的技術有潛力最有市場，而是比誰最能佈道誰嗓門大，誰做的市場活動多，某Docker創業公司據說80%的資金用在市場宣傳、Meetup上，而且不是個別現象，是普遍現象。反應了某些Docker創業者的浮躁心態。

『肆』 區塊鏈就業薪資大概是多少

最近這兩個月，整個加密貨幣市場行情波動很大，有人笑有人哭，有人覺得是牛市來了，有人認為是短期高點。

USDT持續增發，喊單社區不斷擴大，Meetup一場接一場，微博熱搜來了又來。

整個行業似乎像迴光返照一般，來了一次又一次的過山車。
驚嘆著，寂寥著，慶幸著，後悔著。
一次又一次沖擊著行業內外的情緒。

直到今天，比特幣24小時跌幅達11.52%，期貨24小時內爆倉高達4.4億美元。
1. 最近正在面試的朋友和我說，行業內某個公鏈項目，大概平均3個月一次大規模的人員流動，基本上每天都有新人來，每天都有舊人走。再深入一問，大多都是做些基礎崗位，在行業里湊個熱鬧的。

對於運營的理解，基本停留在拉個微信群做客服、上傳文章和做個無人問津的、數據拿不出手的小活動。

去年底，前年參與的某個公鏈項目方的客服人員離職，這個聲明來自海外的項目一下子連個會說國語的都沒有了，好像現在官網都打不開了。
半年後再見面，發現他又從上一家一個DAPP公司離職了，現在是某個項目方的某某總監。（作者：貓Buboo，區塊鏈行業運營/前新浪高級運營/Odaily星球日報特邀作者/金色財經專欄作者）
美其名曰，「追逐風口。」

攤手。
沒有掌握專業技能的人員流動，估計離開區塊鏈行業就找不到工作了吧。

2. 前陣子和一個在區塊鏈公司做前端的朋友吃飯，他現在窮困潦倒。
原來是去年加倉公司的幣卻被深套，老闆還在不斷打雞血，如何看好這個項目雲雲。

對於區塊鏈行業的未來，我們是怎麼看的；對於這個項目的前景，又是怎麼准備籌劃的；我們的夢想是星辰大海，我們要改變XX…

（估計散戶正在OS：不拉盤都是垃圾）

扶額。

一年後老闆也離職了。

很魔幻，區塊鏈沒有夢想。

3. 之前帶過一個實習生，就那種做個內容分發都能磨蹭做三天那種。剛入行賺了幾筆後信心滿滿直接辭職不工作了，專門做合約。起起落落後一統計，不僅沒有賺錢，還倒欠了一堆債務。

於是出來重新找工作了，開價14K。

一個新生的行業有太多的混水摸魚之輩，每個身在期間的人都有自己賺錢的門路。有不少沖著這個行業的高薪資而來，有不少沖著這個行業不透明而來，各自看準一個點就一頭扎進去了。

時間是你的朋友還是你的敵人，恐怕只有你自己知道。

4. 有個高中同學年後入職了一家項目方，一周前和我喝酒的時候吐槽道，負責人以為做出來了項目用戶自然就會來，用戶沒有那肯定是運營不給力。

開什麼玩笑。
都9102年了，思維怎麼還在1997年？

好，實在不行就開始刷量了，動不動就一個月10萬活躍用戶，PR稿在圈內滿天飛。

這些數據做什麼用的？「拉盤啊。」

在這里，數據造假是各自心裡清楚的常態。
你可以看到一個UV不到3000的媒體，平台的文章閱讀量可以數十萬；你可以看到一則消息刷屏你的朋友圈，除此之外沒有一個人會留意，甚至是完全不知道；你可以看到就一個微信群不到500用戶的項目，IEO後市值2個多億。（作者：貓Buboo，區塊鏈行業運營/前新浪高級運營/Odaily星球日報特邀作者/金色財經專欄作者）

好像離錢很近，一個季度的流水幾千萬美金，一個月的利潤高達幾個億。
又好像離錢很遠，因為這些和你都沒有什麼關系。

別說什麼區塊鏈革命，也別說區塊鏈騙局，更不要說區塊鏈是階層晉升的最後機會。
拋開只有少部分人真正看得懂的、真正擁有的技術，你要做的，是認清自己在這個行業的定位。

區塊鏈的故事很多，但你只是一個普通人。

想做韭菜，請直接打錢，別浪費時間和精力。

想在這個行業深扎，請腳踏實地。
做點實事，對得起自己的時間。

『伍』 國內的大型區塊鏈公司都有哪些

國內的大型區塊鏈公司有新晨科技、銀江股份、文化長城、廣電運通、恆生電子等。

1、新晨科技

公司現主營是應用軟體開發業務、軟硬體系統集成業務和專業技術服務業務。近年新晨科技在創新方面嘗試較為大膽，公司在雲計算、大數據、人工智慧以及區塊鏈等新技術在金融行業的應用均取得一定進展。基於區塊鏈技術的國內信用證業務系統已經成功在銀行上線，並有望逐步成為公司軟體解決方案業務新的增長點。

2、銀江股份

公司主要向交通、醫療、建築等行業用戶提供智能化系統工程及服務。《英才》曾對銀江股份進行過多次跟蹤報道。這家企業最近幾年向智慧城市方面做深入發展，涉及領域包括交通、醫療、建築、環境、能源、教育、金融等城市居民生活的方方面面。

公司是國家規劃布局內重點軟體企業、國家火炬計劃重點高新技術企業、中國軟體業務收入前百家企業、浙江省百強高新技術企業、福布斯(Forbes)2010年中國最具潛力中小企業100強、改革開放30年中國信息化建設傑出貢獻單位，是國內行業內綜合業務資質等級最高且種類最齊全的公司之一。

5、恆生電子

2016年6月1日，金融區塊鏈合作聯盟深圳成立，恆生電子是25個發起成員之一運用區塊鏈技術實現基於聯盟鏈的數字票據系統。

『陸』 美國大數據工程師面試攻略有哪些

如果說矽谷成功是有原因的，我覺得有兩點。地理位置是得天獨厚吸引大量人才，這里有Stanford和加州州立高校提供智力庫的支持，在矽谷可以看到來自全世界的最聰明的人，中國人，印度人，猶太人構成這些Engineer的主力。雖然國內做技術自嘲為碼農，但在矽谷成為一個優秀工程師還是收獲頗豐。另一方面創業是一個永恆的話題，在Stanford有個說法空氣中都飄揚中創業的味道，一些早期員工通過上市套現又積累經驗成了天使投資，Y Combinator，各種技術forum，meetup，創業導師，都很活躍。資本的力量功不可沒，早年VC通過投資，收購，上市放大形成一個雪球效應。大家總喜歡問什麼是next big thing，哪一個是下一個facebook，下一個musk，根據統計10年能成就一個千億以上的公司，目前這個進程正在縮短。它坐落於美國加州，從聖何塞到舊金山的狹長地帶，中間是San francisco bay，簡稱灣區。它的由來是這邊有計算機核心處理器中離不開的硅，30年來，矽谷就發展成為無數技術性創業公司的搖籃。在20多年前，就有很多硬體公司的輝煌Intel，Oracle，Apple，Cisco成功上市，10年前，互聯網的興起，造就了Yahoo，Google，Ebay的神奇，而如今Tesla，Facebook，Twitter，Linkedin正扶搖直上，成為美股高科技股的領頭羊。這些公司的市值從幾十billion到幾百billion，PE從負數到上千。瘋狂的估值背後也改變了世界。我個人熱愛大數據，在矽谷這也是大家津津樂道的，有個笑話，其實大家還是興趣驅動就好，不要那麼功利，大數據技術涉及太多，平常工作中也是慢慢積累，有無數的坑和技術細節需要克服。並不是說那個技術最熱就要用哪個。

『柒』 大數據要怎麼自學，該不該學！

如果您有java基礎，或是一定的工作經驗的話，那您自學我是支持的，如果您是版小白，零基礎話權，不建議您這樣學習的。
大數據要學的東西很雜，學習起來也很有難度，您選擇自學大數據，很多的問題都超出您的解決能力范疇，換句話說，您選擇自學大數據，那麼在學習中有很多您沒有辦法解決的問題會時不時的冒出，影響你學大數據的信心，也許你是越挫越勇型，但是很多的時候無疑就是在浪費你的時間。
自學大數據很多的時候就是遇到瓶頸，並且出現最多的就是你您每天忙碌日復一日的學大數據，但就是沒有相應的成效。而大數據培訓則不同，一定是要出效果的，不然你花那麼多的培訓費用是為了什麼呢?大數據培訓也深知這一點，一定會想盡辦法確認您的學習效果，比如多多增加項目訓練、找優秀的大數據培訓老師等等途徑。

d

『捌』 大數據分析界的「神獸」Apache Kylin有多牛

1.Apache Kylin是什麼？

在現在的大數據時代，越來越多的企業開始使用Hadoop管理數據，但是現有的業務分析工具（如Tableau，Microstrategy等）
往往存在很大的局限，如難以水平擴展、無法處理超大規模數據、缺少對Hadoop的支持；而利用Hadoop做數據分析依然存在諸多障礙，例如大多數分析
師只習慣使用SQL，Hadoop難以實現快速互動式查詢等等。神獸Apache Kylin就是為了解決這些問題而設計的。

Apache Kylin，中文名麒（shen）麟（shou） 是Hadoop動物園的重要成員。Apache
Kylin是一個開源的分布式分析引擎，最初由eBay開發貢獻至開源社區。它提供Hadoop之上的SQL查詢介面及多維分析（OLAP）能力以支持大
規模數據，能夠處理TB乃至PB級別的分析任務，能夠在亞秒級查詢巨大的Hive表，並支持高並發。

Apache
Kylin於2014年10月在github開源，並很快在2014年11月加入Apache孵化器，於2015年11月正式畢業成為Apache頂級項
目，也成為首個完全由中國團隊設計開發的Apache頂級項目。於2016年3月，Apache
Kylin核心開發成員創建了Kyligence公司，力求更好地推動項目和社區的快速發展。

Kyligence是一家專注於大數據分析領域創新的數據科技公司，提供基於Apache
Kylin的企業級智能分析平台及產品，以及可靠、專業、源碼級的商業化支持；並推出Apache Kylin開發者培訓，頒發全球唯一的Apache
Kylin開發者認證證書。

2.Kylin的基本原理和架構

下面開始聊一聊Kylin的基本原理和架構。簡單來說，Kylin的核心思想是預計算，即對多維分析可能用到的度量進行預計算，將計算好的結果保
存成Cube，供查詢時直接訪問。把高復雜度的聚合運算、多表連接等操作轉換成對預計算結果的查詢，這決定了Kylin能夠擁有很好的快速查詢和高並發能
力。

上圖所示就是一個Cube的例子，假設我們有4個dimension，這個Cube中每個節點（稱作Cuboid）都是這4個dimension
的不同組合，每個組合定義了一組分析的dimension（如group
by），measure的聚合結果就保存在這每個Cuboid上。查詢時根據SQL找到對應的Cuboid，讀取measure的值，即可返回。

為了更好的適應大數據環境，Kylin從數據倉庫中最常用的Hive中讀取源數據，使用
MapRece作為Cube構建的引擎，並把預計算結果保存在HBase中，對外暴露Rest
API/JDBC/ODBC的查詢介面。因為Kylin支持標準的ANSI
SQL，所以可以和常用分析工具（如Tableau、Excel等）進行無縫對接。下面是Kylin的架構圖。

說到Cube的構建，Kylin提供了一個稱作Layer Cubing的演算法。簡單來說，就是按照dimension數量從大到小的順序，從Base
Cuboid開始，依次基於上一層Cuboid的結果進行再聚合。每一層的計算都是一個單獨的Map Rece任務。如下圖所示。

MapRece的計算結果最終保存到HBase中，HBase中每行記錄的Rowkey由dimension組成，measure會保存在
column
family中。為了減小存儲代價，這里會對dimension和measure進行編碼。查詢階段，利用HBase列存儲的特性就可以保證Kylin有
良好的快速響應和高並發。

有了這些預計算的結果，當收到用戶的SQL請求，Kylin會對SQL做查詢計劃，並把本該進行的Join、Sum、Count Distinct等操作改寫成Cube的查詢操作。

Kylin提供了一個原生的Web界面，在這里，用戶可以方便的創建和設置Cube、管控Cube構建進度，並提供SQL查詢和基本的結果可視化。

根據公開數據顯示，Kylin的查詢性能不只是針對個別SQL，而是對上萬種SQL 的平均表現，生產環境下90%ile查詢能夠在在3s內返回。在上個月舉辦的Apache Kylin

Meetup中，來自美團、京東、網路等互聯網公司分享了他們的使用情況。例如，在京東雲海的案例中，單個Cube最大有8個維度，最大數據條數4億，最
大存儲空間800G，30個Cube共占存儲空間4T左右。查詢性能上，當QPS在50左右，所有查詢平均在200ms以內，當QPS在200左右，平均
響應時間在1s以內。

北京移動也在meetup上展示了Kylin在電信運營商的應用案例，從數據上看，Kylin能夠在比Hive/SparkSQL在更弱的硬體配置下獲得更好的查詢性能。 目前，有越來越多的國內外公司將Kylin作為大數據生產環境中的重要組件，如ebay、銀聯、網路、中國移動等。大家如果想了解更多社區的案例和動態，可以登錄Apache Kylin官網或Kyligence博客進行查看。

3.Kylin的最新特性

Kylin的最新版本1.5.x引入了不少讓人期待的新功能，可擴展架構將Kylin的三大依賴（數據源、Cube引擎、存儲引
擎）徹底解耦。Kylin將不再直接依賴於Hadoop/HBase/Hive，而是把Kylin作為一個可擴展的平台暴露抽象介面，具體的實現以插件的
方式指定所用的數據源、引擎和存儲。

開發者和用戶可以通過定製開發，將Kylin接入除Hadoop/HBase/Hive以外的大數據系統，比如用Kafka代替Hive作數據源，用
Spark代替MapRece做計算引擎，用Cassandra代替HBase做存儲，都將變得更為簡單。這也保證了Kylin可以隨平台技術一起演
進，緊跟技術潮流。

在Kylin
1.5.x中還對HBase存儲結構進行了調整，將大的Cuboid分片存儲，將線性掃描改良為並行掃描。基於上萬查詢進行了測試對比結果顯示，分片的存
儲結構能夠極大提速原本較慢的查詢5-10倍，但對原本較快的查詢提速不明顯，綜合起來平均提速為2倍左右。

除此之外，1.5.x還引入了Fast
cubing演算法，利用Mapper端計算先完成大部分聚合，再將聚合後的結果交給Recer，從而降低對網路瓶頸的壓力。對500多個Cube任務
的實驗顯示，引入Fast cubing後，總體的Cube構建任務提速1.5倍。

目前，社區正在著手准備Apache Kylin 1.5.2版本的發布，目前正處於Apache Mailing list投票階段，預計將會在本周在Kylin官網發布正式下載。

在本次的1.5.2版本中，Kylin帶來了總計
36個缺陷修復、33個功能改進、6個新功能。一些主要的功能改進包括對HyperLogLog計算效率的提升、在Cube構建時對Convert
data to hfile步驟的提速、UI上對功能提示的體驗優化、支持hive view作為lookup表等等。

另一個新消息是Kylin將支持MapR和CDH的Hadoop發行版，具體信息可見KYLIN-1515和KYLIN-1672。相應的測試版本是MapR5.1和CDH5.7。

UI上提供了一個重要更新，即允許用戶在Cube級別進行自定義配置，以覆蓋kylin.properties中的全局配置。如在cube中定義kylin.hbase.region.count.max 可以設置該cube在hbase中region切分的最大數量。

另
一個重要的功能是Diagnosis。用戶經常會遇到一些棘手的問題，例如Cube構建任務失敗、SQL查詢失敗，或Cube構建時間過長、SQL查詢時
間過長等。但由於運維人員對Kylin系統了解不深，很難快速定位到root cause所在地。我們在mailing
list里也經常看到很多用戶求助，由於不能提供足夠充分的信息，社區也很難給出一針見血的建議。

當用戶遇到查詢、Cube/Model管理的問題，單擊System頁面的Diagnosis按鈕，系統會自動抓取當前Project相關的信息並打包成
zip文件下載到用戶本地。這個包會包含相關的Metadata、日誌、HBase配置等。當用戶需要在mailing
list求助，也可以附上這個包。