切勿妄談Hadoop，以及4個數據管道打造實踐

時至今日，大數據這個概念已充斥了整個IT界，各種“搭載”了大數據技術的產品，各種用于處理大數據工具更如雨后的春筍觸目皆是。同時，如果某個產品還沒抱上大數據的大腿，如果某個機構還沒搗鼓過基于Hadoop、Spark、Impala、Storm等高大上的工具，更會予以過時黃花的評價。然而，你的數據量真的需要使用Hadoop這樣工具嗎？你業務處理的數據類型真的需要大數據技術來支撐嗎？

既然是大數據，我們首先看“大”，也就是數據的體積。在CSDN極客頭條中，我們可以看到@劉江總編之前分享的一篇文章――“別老扯什么Hadoop了，你的數據根本不夠大”。文章出自有著多年從業經驗的數據科學家Chris Stucchio，紐約大學柯朗研究所博士后，搞過高頻交易平臺，當過創業公司的CTO，更習慣稱自己為統計學者。下面我們一起看他的觀點：

CSDN推薦：歡迎免費訂閱《Hadoop與大數據周刊》獲取更多Hadoop技術文獻、大數據技術分析、企業實戰經驗，生態圈發展趨勢。

Hadoop只是運行某個通用計算的工具，正因為如此，在使用過程中你會受限于多種規則，比如所有計算都必須按照一個map、一個group by、一個aggregate或者這種計算序列來寫。這種束縛就像穿上一層緊身衣，但是正因為Hadoop和大數據是熱詞，世界有一半的人都想穿上緊身衣，即使他們根本不需要。因此，你的數據量真的需要使用Hadoop這類工具嗎？

1. 好幾百M的數據，Excel裝不下！這種級別完全和“大”無關，類似Pandas這樣的工具就可以處理的很好，它可以把幾百M的數據加載到內存，一眨眼功夫Numpy就能完成億次浮點計算。

2. 數據體積高達10G！這種級別的數據仍然稱不上大數據，當下的筆記本的內存都可以添加到16G了，而且許多工具并不是一次性將數據完全加載到內存的。

3. 數據有100GB/500GB/1TB！1個2TB的硬盤才幾百塊，買一塊換上，然后果斷裝PostgreSQL等。

對比Python這樣的腳本，Hadoop在編程方面不存在任何優勢；同時因為跨節點的數據流開銷，Hadoop通常情況下要慢于其他技術，然而如果你的數據超過5TB，那么你真的需要搗騰Hadoop了。

Chris從數據體積上分析了你的數據是否稱得上大數據，是否真的需要使用大數據技術，然而衡量大數據的因素還有Velocity、Variety以及Value，下面我們就一起看MongoDB分享的“大數據除大以外的東西”，下為譯文：

MongoHQ：不要因為大數據背后的利益而貶低其他途徑

回溯20世紀90年代，人們認識到數字化的存儲數據比用紙要廉價的多，當一個東西便宜到一定的地步時，它就成為一個必然的選項。人類就會出于本能的去儲存所有數據，因為“未來我們可能需要它們”，而且儲存已經這么便宜了，為什么不做呢？

而從1990年美國科學家一篇名為 “Saving All The Bits”的文章中發現，那個時候科學家已經不得不面對保存所有數據的挑戰，Peter Denning解釋了NASA保存所有哈勃太空望遠鏡產生數據面臨的挑戰：該設備每天產生的數據需要2500張光盤來存放，這個速度不僅淹沒了網絡和存儲設備的性能，同樣還超出了“人類的理解能力”。但是請不要忽視一點，隨著儲存技術和經濟狀況的發展，這2500張光盤只等價于當下100美元左右的硬盤，而且我們似乎也并不需要儲存一個太空望遠鏡產生的如此大量數據。

大數據的有限價值

今天我們幾乎可以存儲任何具有業務目的明顯的數據，比如信用卡銷售及問卷調查。同時，我們還可以存儲所有業務目的不明顯的數據，比如：用戶在一個網頁上的行為、電纜接線盒中用戶觀看的TV頻道、借助物理網開關燈或者門的行為。但是從價值上看，后一類行為的價值無疑很低。

一筆信用卡交易包含了很多數據，比如：人的信息、地理位置、價值等。在銷售周期中，你會很自然的捕捉這些數據。然而用戶在一個網站上產生的行為顯然不會那么有價值，你可能收集到用戶訪問的URL、閱讀某個頁面花費的時間，但是這些記錄的價值顯然不如信用卡交易那么豐富。當然如果你要給你的用戶分類時，這些記錄還是擁有一定價值的。

然而當下存儲的成本已經越來越少了，你的數據越多，你就可以從數據分析趨勢中獲得更多的價值。每條TV頻道轉換的信息確實無關緊要，但是如果你把這些數據與調度機廣告數據放到一起將其視為一個聚合數據集，你將可以清楚的知曉用戶的行為，這些數據將給廣告者和程序設計人員提供有價值的見解。

同樣，智能家庭系統中收集到的信息價值就更低了，你可能只會得到一些事件和狀態信息，同時系統可能產生大量的數據，價值必須通過大量的篩選、過濾等處理才能體現。大數據最大的挑戰就是從大量的碎片項中獲取信息，也可能是使用許多具有豐富價值的數據做依托，然后從中剝絲抽繭，尋找真知。需要注意的是，這并不是大海撈針，而是從一堆針中給一些針定性。

Hot Data vs. Big Data

造成需要大數據的原因是，你不僅擁有大量的數據，同樣擁有大量訪問這些數據的請求，而Big Data看起來能滿足這個需求。

BigData的數據更傾向于冷數據，也就是你不會經常訪問的數據，除了分析之外可能不會再次被使用。它可能很快被新鮮的冷數據代替，而新的冷數據又會產生新的分析，但是Big Data的范圍需要與熱數據分開，因為將兩個需求混合得到的結果必然低于預期，這樣一來冷數據與熱數據的分析必然都差強人意。無論如何區分冷熱數據都是個好的思想，不管是存儲還是應用程序都應該區別對待。但是總有一些人不分場景為用戶提供Big Data這個“仙丹”。

因此，請重視你的數據，分清楚數據的類型，以業務為需求，不必要將所有的數據混合到一起去打造1個大數據。

以“云計算大數據 推動智慧中國 ”為主題的  第六屆中國云計算大會 將于5月20-23日在北京國家會議中心隆重舉辦。產業觀察、技術培訓、主題論壇、行業研討，內容豐富，干貨十足。票價優惠，馬上  報名 ！ 

對于MongoDB的官博，Hakka Labs的創始人Pete Soderling在博文給以了回應。首先，他肯定了隨著時間延續儲存成本遞減這條。其次，他還補充了兩點，更多開放API造成用戶數據太多以及公司們幕后操作的“數據共享”。隨后，Pete則給出了自己的看法，下為譯文：

Pete：無論大、小、熱、冷，你的數據需要1條強健的數據處理管道

不可否認，你們說的有一定的道理，但是重要的是，在過去幾年中，那些具有前瞻性的公司都做了一件非常重要的事――設計一個健壯的數據處理管道去收集、聚合級處理它們不斷增長的數據。之所以這么做，最主要的原因就是用一種固定的方式分析數據之間的關系，就像MongoHQ說的在一堆針中給一些針定性，如果不這么做的話，這些關系必將消失。

但是這同樣提出了一個問題，什么樣的處理管道才是健壯的？簡單的把數據扔入Hadoop顯然不是，這里分享來自Stripe、Tapad、Etsy及Square的例子，一探現實世界中的數據管道：

1. Stripe的處理方式

Stripe的Avi Bryant為我們分享了如何建立一個健壯的數據管道：

Stripe從多個數據源將數據灌入HDFS，它們中許多都是無結構或者半結構化的服務器日志，比如：JSON或者BSON文檔。在任何情況下，第一步都是轉換成結構數據，我們習慣使用Thrift來定義邏輯結構，使用Parquet作為磁盤持久化格式。

之所以選擇Parquet，因為它是一個有效的列存儲格式，原生支持Cloudera的Impala查詢引擎，可以快速的關系訪問數據獲取ad-hoc Reporting。同時，Parquet和Thrift的組合使用還有另一個好處――方便Twitter Scalding框架的有效使用，它可以用作復雜的批處理。

下一個步驟則是“denormalization”：為了保持分析作業和查詢的快速執行，我們經常會提前做join，在Scalding中，將新的數據集寫入Thrift格式。同時，我們會做大量的數據優化和注解，比如：地理編碼IP地址、分析用戶代理、清理缺省值等。

在許多情況下，這么做會導致嵌套結構模式，便于Scalding的處理以及Parquet的儲存，然而卻不便于Impala的查詢。為此，我們設計了一個簡單的工具，可以將任意的 Parquet嵌套數據轉換成單一結構，同時我們會為每個數據源運行這樣一個副本，以方便Impala的查詢，我們期望未來版本的Impala可以移除這個多余的步驟。

2. Tapad的數據管道

Tapad從事的是廣告技術業務，數年內已積累了豐富的流量及數據增長應對經驗。為了了解他們的數據管道，Pete特意接觸了Tapad的CTO Dag Liodden，以下是他口中的經驗：

• 所有傳入的數據流都會以pub-sub的形式進入一個信息隊列（我們使用Kafka，并每小時給它推送TB級的數據）
  
• 所有數據都會被處理成denormalized結構模式，并且支持模式的演變（我們使用Avro和Protocol Buffers）
  
• 在信息隊列處理過程中，所有的數據儲存都會被實時更新（熱數據被推送給了Aerospike和Cassandra，實時數據查詢一般通過Vertica存儲，原始事件則會與Aerospike集群中的數據整合儲存在HDFS中）
  
• 深度分析及數據科學計算通常存儲HDFS中，以denormalized數據為主。
• 在HDFS上存儲的數據離線處理結束后，系統可以保持數據的實時更新。我們一直致力于計算邏輯的研究，從而實現數據可以在批處理和流處理系統間無縫的使用。
  

• Kafka：高吞吐量的pub-sub，但是在交付和延時上表現一般，限制了數據持久并且缺乏查詢能力。
• Aerospike：非常快的隨機讀寫訪問能力，通過鍵（我們有32億的鍵以及4TB的數據），跨數據中心備份，可用性很高但是查詢性能受到限制。
• Cassandra：中等程度的隨機讀寫訪問性能，原子計數和數據模型讓它非常適合時間序列數據存儲。靈活的一致性模式，并且擁有跨數據中心備份能力。
  
• HDFS：高吞吐量，廉價的存儲。
  
• Vertica：快速而強大的ad-hoc查詢能力，適用于交互式分析，高可用性，但是不支持嵌套數據結構及multi-valued屬性，基于存儲的收費讓我們不得不控制使用。
  

3. Etsy處理數據的方式

通過Etsy數據團隊技術經理Rafe Colburn，我們了解到了Etsy的數據處理方式：

Etsy的數據管道并不是標準的線狀，它開始于我們的測試裝備――1個運行在瀏覽器的事件記錄器以及1個從后端調用的事件記錄器，兩個記錄器都會ping一些內部的“beacon”服務器。

當Apache訪問日志到一定的大小時，我們會使用1個logrotate程序將它持久化到HDFS系統。我們夜間還會給生產環境數據（儲存在MySQL中）做了快照，同時會復制到HDFS，因此，我們可以將clickstream數據整合到事務數據中。

我們通常將Hadoop作業結果傳送給Vertica數據倉庫，這里同樣會給生產數據做備份用以深度挖掘，我們會將這些數據傳送給自主研發的報表和分析工具。

鑒于etsy.com的特性，我們使用的數據通常來自Hadoop作業，我們有一個定制化工具會取得作業的輸出結果，并將它儲存在MySQL（已分片）集群，在這里我們可以規模化的訪問。本年度我們將考慮整合Kafka，這樣我們就可以將數據從儀表中轉移到Hadoop（以及流處理工具），同時也可以將數據從分析平臺發送到外網上。

4. Square的分析方式

Square數據管道設計的非常復雜，在接觸到技術經理Pascal-Louis Perez后，他為我們分享了Square的數據管道架構戰略視圖：

鑒于系統中支付流的重要性，Square將“reconciliation”這個概念貫穿了整個數據管道系統，驗證每個數據轉換的正確性。通過Pascal了解到，這種方法最大問題就是規模問題。對于每次付款收訖都會產生“10-15個核算實體，協調系統同樣需要”，一次交易產生的操作已經夠多了。Square的方法是使用流處理系統，這就允許為不同流映射不同的數據域。（更多詳情見下方傳送門）

相關鏈接：

別老扯什么Hadoop了，你的數據根本不夠大

You don’t have Big Data…

Big, Small, Hot or Cold - Examples of Robust Data Pipelines from Stripe, Tapad, Etsy and Square（審校/魏偉）

以“云計算大數據 推動智慧中國 ”為主題的  第六屆中國云計算大會 將于5月20-23日在北京國家會議中心隆重舉辦。產業觀察、技術培訓、主題論壇、行業研討，內容豐富，干貨十足。票價優惠，馬上  報名 ！ 

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈