# 大，小，熱還是冷-條帶，Tapad，Etsy 和 Square 的健壯數據管道示例 > 原文： [http://highscalability.com/blog/2014/3/24/big-small-hot-or-cold-examples-of-robust-data-pipelines-from.html](http://highscalability.com/blog/2014/3/24/big-small-hot-or-cold-examples-of-robust-data-pipelines-from.html) [](http://surf.transworld.net/1000104592/features/the-10-best-surf-photos-in-the-history-of-transworld-surf/) *這是 [Hakka Labs](https://twitter.com/petesoder) 的創始人 [Pete Soderling](https://twitter.com/petesoder) 的[訪客轉發](http://www.hakkalabs.co/articles/big-small-hot-cold-data-needs-robust-pipeline)，創建了軟件工程師成長的社區。* 針對 MongoHQ 最近發表的題為“ [您沒有大數據](http://blog.mongohq.com/you-dont-have-big-data/)”的帖子，我通常會同意作者的許多觀點。 但是，無論您稱其為大數據，小數據，熱數據還是冷數據-我們都有能力承認*更多*數據將保留下來-這是由于許多不同的因素造成的。 如本文所述，可能主要是由于存儲成本隨著時間的推移而降低。 其他因素包括對開放 API 的訪問，在線上不斷增長的消費者活動的數量，以及公司相互“共享”數據時在幕后形成的（主要是）幕后發展的大量其他激勵措施。 （您知道[他們這樣做](http://www.theguardian.com/business/2013/jun/24/barclays-bank-sell-customer-data)，對吧？） 但是，過去兩年來我學到的最重要的事情之一是，對于具有遠見卓識的公司而言，開始設計更強大的數據管道以收集，匯總和處理不斷增長的數據量至關重要。 這樣做的主要原因是能夠以一致的方式準備好看似神奇的類似量子的操作的數據，這些操作可以推斷數據之間的關系，否則這些關系肯定不會引起注意-在引用的文章中巧妙地描述為“ 從針頭堆中確定針頭的性質。” 但這提出了一個問題-精心設計的數據管道的特征是什么？ 您難道不可以將所有數據都放入 Hadoop 并稱之為一天嗎？ 正如許多工程師所發現的那樣-答案是巨大的“不！” 我們匯總了 Stripe，Tapad，Etsy & Square 的智能工程師的四個示例，這些示例展示了您實際上可以在野外看到的一些實際數據管道的各個方面。 ## **Stripe 如何做到？** 我們在 [Stripe](http://www.hakkalabs.co/companies/stripe) 上與 Avi Bryant 進行了交談，后者為我們很好地描述了 Stripe 進行數據管道構建的方式。 > Stripe 從各種來源向 HDFS 饋送數據，其中許多是非結構化或半結構化的 > -例如服務器日志或 JSON > 和 BSON 文檔。 在每種情況下，第一步都是將 > 轉換為結構化格式。 我們已經標準化了使用 Thrift 來定義 > 的邏輯結構，并使用 Parquet 作為磁盤上的存儲 > 格式。 > > 我們選擇 Parquet 是因為它是 Cloudera Impala 查詢引擎固有的高效列格式 > ， > 使我們可以快速關聯數據訪問臨時報告。 > Parquet 和 Thrift 的組合也可以有效地使用，并且 > 可以從 Twitter 的 Scalding 框架中慣用，這是我們為復雜批處理選擇的 > 工具。 > > 下一階段是``非規范化''：為了保持我們的分析工作和 > 查詢快速，我們會在 Scalding 中提前進行最常見的聯接， > 寫入新的 Thrift 模式集。 同時，我們進行了大量的 > 增強和注釋數據：例如，對 IP > 地址進行地理編碼，解析用戶代理字符串或清除丟失的值。 > > 在許多情況下，這會導致結構具有嵌套結構， > 在 Scalding 中效果很好，并且哪個 Parquet 很高興存儲，但是 > 目前 Impala 無法查詢。 我們開發了一個簡單的工具 > ，該工具可將任意嵌套的 Parquet 數據轉換為等效的 > 扁平化架構，并在必要時使用它來 > 維護每個數據源的并行副本以供 Impala 使用。 > 我們期待著 Impala 的未來版本，該版本可能會刪除 > 這個額外的步驟。 ## **Tapad 的數據管道** [Tapad](http://www.hakkalabs.co/companies/tapad) 是紐約市的一家廣告技術公司，在過去幾年中，其流量和數據均實現了大幅增長。 因此，我聯系了他們的 CTO [Dag Liodden](http://www.hakkalabs.co/engineers/dag-liodden) ，以了解他們如何構建數據管道以及他們使用的一些策略和工具。 用達格的話來說，這是他們的做法： * 所有攝取的數據都以 pub-sub 方式流過消息隊列（我們使用 Kafka 并每小時通過它推送多個 TB 數據） * 所有數據均使用支持架構演進的一致的非規范化架構進行編碼（我們使用 Avro 和 Protocol Buffers） * 我們的大多數數據存儲都從消耗消息隊列的流程進行實時更新（將熱數據推送到 Aerospike 和 Cassandra，將實時可查詢的數據推送到 Vertica，并且原始事件通常存儲有來自 Aerospike 集群的數據， 在 HDFS 中） * 高級分析和數據科學計算通常在 HDFS 中對非規范化數據執行 * 實時更新始終可以通過脫機批處理作業復制到 HDFS 存儲的數據上。 我們努力使我們的計算邏輯，使其可以在流中*和*以批處理 MR 模式運行，而無需進行任何修改 他指出，最后一點使他們可以隨意更改其流計算，然后用更新的預測回填其他數據存儲。 Dag 還解釋了在存儲方面使用多種類型的數據技術背后的“原因”，并解釋了它們中的每一個都有其自己的特定“最佳位置”，這使其對它們具有吸引力： * Kafka：高吞吐量并行發布訂閱，但寬松的傳遞和延遲保證，有限的數據保留和無查詢功能。 * Aerospike：按鍵（我們擁有 32 億個鍵和 4TB 復制數據），跨數據中心復制，高可用性但查詢功能非常有限，按鍵具有極快的隨機訪問讀/寫性能 * Cassandra：中等的隨機訪問讀/寫性能，原子計數器和數據模型，非常適合時間序列存儲。 靈活的一致性模型和跨數據中心復制。 * HDFS：高吞吐量和廉價的存儲。 * Vertica：快速和強大的即席查詢功能，用于交互式分析，高可用性，但不支持嵌套的數據結構，多值屬性。 基于存儲的定價使我們限制了我們在此處放置的數據量。” ## **Etsy 如何處理數據** 再舉一個例子，我們聯系了 [Etsy 的](http://www.hakkalabs.co/companies/etsy)數據團隊的工程經理 Rafe Colburn，并詢問他們如何處理他們的管道。 這是 Rafe 的獨家新聞： > Etsy 的分析渠道不是特別線性。 它從我們的工具開始，它由一個事件記錄器組成，該事件記錄器在瀏覽器中運行，而另一個事件記錄器可以從后端調用。 兩者都 ping 一些內部“信標”服務器。 > > 實際上，我們使用良好的舊 logrotate 程序將生成的 Apache 訪問日志在達到一定大小時運送到 HDFS，并使用 Hadoop 處理它們。 我們還將每晚對生產數據（駐留在 MySQL 中）進行快照，并將其復制到 HDFS 中，以便我們可以將點擊流數據添加到事務數據中。 > > 通常，我們會將 Hadoop 作業的輸出發送到 Vertica 數據倉庫，在該倉庫中我們也復制生產數據，以進行進一步分析。 我們使用這些數據來提供我們自己的報告和分析工具。 > > 對于 [etsy.com](http://etsy.com/) 上使用從 Hadoop 作業生成的數據的功能，我們有一個自定義工具，該工具獲取作業的輸出并將其存儲在分片的 MySQL 集群中，可以在該集群上進行大規模訪問。 今年，我們正在考慮將 Kafka 集成到管道中，以將數據從我們的工具移至 Hadoop（以及流分析工具），并將數據從我們的分析平臺發送回公共站點。 ## **Square 的方法** 擁有復雜數據管道的公司的另一個示例是 [Square](http://www.hakkalabs.co/companies/square) 。 我們與他們的工程經理之一 [Pascal-Louis Perez](http://www.hakkalabs.co/engineers/pascal-louis-perez) 取得了聯系，他們為我們提供了他們的管道架構的戰略視圖。 由于支付在整個系統中的重要性，Square 已在整個數據管道中擴展了“對帳”的概念； 每個轉換數據必須能夠被審核和驗證。 據 Pascal 稱，這種方法的主要問題在于擴展規模可能具有挑戰性。 對于收到的每筆付款，“大約需要 10 到 15 個會計分錄，對帳系統的規模因此必須比處理的帳目規模大一個數量級，而處理的帳目已經非常大。” Square 解決此問題的方法利用流處理，這使他們可以將相應的數據域映射到不同的流。 用 Pascal 的話來說，“流表示將數據流水線與數據源的多樣性區分開的第一層抽象。下一層是將多個流之一組合在一起并產生一個或多個流的運算符。一個示例運算符是” “匹配器”，它接收兩個流，從中提取相似種類的密鑰，并根據匹配條件產生兩個流。 Pascal 指出，流處理和基于流的運算符的系統類似于關系代數及其運算符，但是在這種情況下，它是實時的并且具有無限關系。 很明顯，將數據塞入 Hadoop 并不會為您提供這些功能！ 有趣的例子特別時髦。 在前端，您會看到藝術家和手工藝人像在線公開市場一樣出售其商品。 可以很好地了解后端的工作方式。 這是一個非常有用的技術概述，它對我來說是個新名詞-數據管道如何工作。 我最近一直在使用 [TitanDB](http://thinkaurelius.github.io/titan/ "TitanDB") 和 hbase 來處理圖形方面，您可以在此處閱讀[，盡管它不是真實的示例。](http://tjadclark.com/blog/article/11-big-data-putting-it-in-a-graph "Big data in a graph") 看到在現實世界中有使用 HBase 的用例，這使我對將來使用 HBase 的決策更有信心。