# DataSift 體系結構：每秒進行 120,000 條推文的實時數據挖掘 > 原文： [http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html](http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html)  我記得 Twitter 首次開放他們的消防水帶時的興奮。 作為 Twitter API 的早期采用者，我可以輕松想象可以對所有這些數據執行的一些很酷的事情。 我還記得在大數據領域，數據是有代價的，而對于像我這樣的小魚來說，代價太高了，我對此感到失望。 這就像第一次學習，不會有 BigData 圣誕老人。 盡管有一段時間，我很高興思考如何處理所有數據。 這是一個令人著迷的問題。 您必須能夠可靠地使用它，對其進行規范化，將其與其他數據合并，在其上應用功能，對其進行存儲，進行查詢，對其進行分發，然后再將其貨幣化。 大部分都是實時的。 而且，如果您試圖創建一個平臺，以允許整個 Internet 對防火墻執行相同的操作，則挑戰將成倍增加。 DataSift 處于創建這樣的煙火，數據斬波機器的令人興奮的位置。 您會看到，DataSift 已從 Twitter 購買了多年的重新組織權，這使他們可以訪問完整的 Twitter 消防水帶，并能夠將其子集轉售給其他各方（可能是任何人），但主要目標當然是企業。 [Gnip](http://gnip.com/) 是唯一擁有這些權利的其他公司。 DataSift 是由 DataSift 的創始人兼首席技術官 Nick Halstead 在 [TweetMeme](http://tweetmeme.com/) 的經驗基礎上創建的，HTHT 是一種流行的實時 Twitter 新聞聚合器，一次可以處理每天 11 億的頁面瀏覽量。 TweetMeme 以發明社交信號機制而著稱，該機制被稱為“ retweet”，帶有“ retweet”按鈕，這個想法來自更早的名為 [fav.or.it](http://www.webonorme.net/blogging/launched-favorit-nick-halstead.htm) 的創業公司。 想象一下您是否會在*之前的某個時間像在整個虛擬地方貼上*按鈕一樣。 因此，大規模處理 TweetMeme 對 DataSift 的員工來說并不是什么新鮮事，而面臨的挑戰是將這種經驗轉變為 Internet 規模的平臺，以便其他人也可以做同樣的事情。 那是一個多年的冒險之旅。 DataSift 將自己定位為實時數據挖掘平臺。 這里的平臺角度確實是帶回家的關鍵信息。 他們正在追求用于處理實時流的真正平臺策略。 TweetMeme 雖然取得了成功，但它并不是一家[十億美元的公司](http://www.youtube.com/watch?v=MowmiwavILM)，但是 BigData 平臺可以發展到如此之大，這就是他們前進的方向。 尼克（Nick）的貨幣報價突出了霓虹燈的邏輯：“按鈕上沒有錢，數據上有錢。” 平臺游戲背后的部分策略是，通過圍繞您的核心價值主張構建巨大的技術護城河，從而成為老牌玩家。 當其他人來敲門時，由于您進入的技術壁壘過高，他們無法越過您的護城河。 這就是 DataSift 試圖做的。 護城河上的吊橋更適合使用 Twitter 的 firehose，但真正的強大之處在于他們正在嘗試創建的 Google 質量實時數據處理平臺基礎架構。 DataSift 的真正創新在于創建一個 Internet 規模的過濾系統，該系統可以快速評估非常大的過濾器（認為 Lady Gaga 的追隨者規模），并結合虛擬化帶來的經濟效益，在這種情況下，擁有更多客戶的客戶可以分享資源，因此您賺得更多的錢。 他們如何使所有這些魔術發生？ 讓我們來看看... Site: [http://DataSift.com](http://DataSift.com) ## 信息來源 * 本文末尾列出的文章和視頻。 * 主要來源是對以下人員的采訪： [Nick Halstead](http://datasift.com/user/nickhalstead) ，DataSift 的創始人兼 CTO; [DataSift 的首席架構師 Lorenzo Alberton](http://www.alberton.info/) 。 ## 統計資料 * 您無法獲得整個 Twitter 的水火。 如果這樣做，每千條推文將收取 10 美分的費用。 每天有 2.5 億條推文。 每天需要 2 萬 5 千美元的許可費用。 * 936 個 CPU 內核 * 每臺服務器支持 16,000 個數據流 * 每天處理整個 Twitter Firehose 250+百萬條推文。 相比之下，Visa 說，在 2007 年，他們處理了 276.12 億筆交易，估計在一天中最繁忙的 8 小時內每秒處理 2100 筆交易。 這些都是完整的交易。 * 當前峰值每秒傳遞 120,000 條推文（260Mbit 帶寬） * 執行 250+百萬次情感分析，延遲不到 100 毫秒 * 每天通過平臺傳輸 1TB 的增強數據（包括性別，情感等） * 數據過濾節點最多可以處理 10,000 個唯一流（每秒流過 8000+條推文的峰值） * 可以實時對 10,000,000 個以上的用戶名列表進行數據查找 * 鏈接增強每天執行 2700 萬個鏈接解析+查找，以及 15+百萬個完整的網頁聚合。 * 30 名員工 * 4 年的發展 ## 平臺 [ ### 使用的語言 * C ++用于關鍵性能組件，例如核心過濾引擎（自定義虛擬機） * 用于站點的 PHP，外部 API 服務器，大多數內部 Web 服務以及定制的高性能作業隊列管理器。 * Java / Scala，用于與 HBase 通信，Map / Reduce 作業以及處理來自 Kafka 的數據 * Ruby 為我們的廚師食譜 ### 資料儲存庫 * SSD 驅動器上的 MySQL（Percona 服務器） * HBase 集群（當前，約 30 個 hadoop 節點，400TB 存儲） * Memcached（緩存） * Redis（仍用于某些內部隊列，但可能很快將被撤消） ### 消息隊列 * 0mq（來自最新的 alpha 分支的自定義版本，已進行一些穩定性修復，以使用發布者端過濾），并用于不同的配置中： * PUB-SUB 用于復制/消息廣播； * PUSH-PULL 用于循環工作負載分配； * REQ-REP 用于不同組件的運行狀況檢查。 * Kafka（LinkedIN 的持久性和分布式消息隊列），用于高性能持久性隊列。 * 在這兩種情況下，他們都與開發人員合作，并提供錯誤報告/跟蹤/修復/客戶端庫。 ### CI / Deployments * 每 5 分鐘（如果有更改）從 Jenkins 的回購中提取所有代碼（無論使用哪種語言），并使用幾種 QA 工具自動進行測試和驗證。 * 每個項目都以 RPM 的形式構建和打包，然后移至 dev 軟件包倉庫。 * 多個環境（開發，集成，QA，分段，生產）或不同的策略和測試級別。 * Chef 自動執行部署和管理配置。 ### 監控方式 * 所有服務都會發出 StatsD 事件，這些事件與其他系統級檢查結合在一起，添加到 Zenoss 中并與 Graphite 一起顯示。 ## 圖片中的建筑 DataSift 為其整體架構創建了一張很棒的圖片。 這是一個小版本，要查看完整版本，請在處轉到[。](http://farm8.staticflickr.com/7159/6408735793_0fa14eedf6_o.png)  * 該圖分為兩半：左邊的所有內容都是數據處理，右邊的所有內容都是數據傳遞。 系統中運行 40 多種服務，其中包括：許可證服務，監視服務，限制服務等。 * 整個系統有許多不同的擴展挑戰，必須幾乎同時解決：處理 firehose，低延遲的自然語言處理和推文上的實體提取，低延遲的推文內聯增強，低延遲處理非常大的單個過濾器 ，對來自大量客戶的大量復雜過濾器進行低延遲評估，鏈接解析和緩存，并通過保留每天發送的 1TB 數據來保留防火墻的歷史記錄，從而可以根據 firehose，實時計費，實時身份驗證和授權，可讓客戶了解其流狀態的儀表板，將過濾器結果流式傳輸到數千個客戶端，監視每個機器，每個過濾器和每個子系統，負載和性能測試， 網絡流量和服務之間的消息傳遞以低延遲的容錯方式。 * 我們不會涵蓋它們所做的每一行或每一行，但我們將重點介紹。 ## 基本思路 * **全部的要點**： * **數據訪問**的民主化。 消費者可以自己進行數據處理和分析。 如果他們愿意，一個人應該能夠確定哪種早餐谷物得到的推文最多，處理數據，制作圖表并將其出售給品牌。 有了一個可能的平臺，而如果您必須建立自己的 tweet 處理基礎架構，那幾乎是不可能的。 * **作為數據**服務的軟件。 將信用卡放入一個小時或幾個月的數據中。 Amazon EC2 模型。 收取使用費用。 沒有巨大的注冊期或費用。 可以是小型或大型播放器。 * **您確實不需要大數據，需要洞察力**。 現在我們如何處理數據？ 自己創建見解的工具。 數據毫無價值。 數據必須在上下文中使用。 * 這個想法是**創建一個全新的應用程序**，這是 Twitter API 所無法提供的。 * [ETL](http://en.wikipedia.org/wiki/Extract,_transform,_load) （提取，轉換，加載）。 可以將 DataSift 視為一種 [ETL](http://en.wikipedia.org/wiki/Extract,_transform,_load) 樣式的系統，將實時數據流作為輸入，將應用程序作為輸出。 * **提取** * 數據是從多個來源讀取的，但是目前主要吸引 Twitter 的 firehose 許可訪問。 Twitter 是 Twitter 的所有公開推文。 您還可以訪問 Digg 和 MySpace 數據。 * 身份不是在不同的數據源之間建立的，但是它們會規范化所有數據，因此您可以知道用戶名的位置，從而可以匹配身份。 * **轉換** * 數據從防火墻中提取出來并進行標準化。 Twitter 數據具有高度維度，具有 [30 個屬性和](http://www.readwriteweb.com/archives/this_is_what_a_tweet_looks_like.php)屬性，您可以訪問所有這些屬性。 這些屬性包括地理位置，名稱，配置文件數據，推文本身，時間戳，關注者數量，轉發數，已驗證的用戶狀態，客戶端類型等。 * 實體提取和自然語言處理應用于推文。 例如，確定語言，并在元數據中提供該結果。 * 當一條 tweet 進入時，他們必須查詢 5 種不同的服務才能用更多數據擴展 tweet。 包括情緒分析，性別檢測和 Klout 得分。 * 解析每個鏈接并提取內容，以便可以將過濾器應用于內容和鏈接本身。 * 他們計劃隨著時間的流逝增加更多的服務。 * 在過濾過程發生之前，數據已被詳細闡述。 * **過濾** * 您無法支付全部費用，因此使用了一種相對簡單的聲明性語言，稱為 [CSDL](http://dev.datasift.com/csdl) ，以過濾掉不需要的 Tweets 并保留您想要的 Tweets。 * 過濾器如下所示： *interact.content 包含“ apple”，而 interaction.content 包含“ orange”* * 與過濾器匹配的所有推文形成一個流。 每個流都分配有一個標識符，該標識符看起來像“ 4e8e6772337d0b993391ee6417171b79” * 隨處可見對話流。 流是應用于輸入的 CSDL 過濾器的輸出。 通過過濾器，您可以創建您感興趣的事件流。 * 流標識符包含在規則中，以進一步限定流中應包含哪些推文。 規則以過濾器和其他規則為基礎：*規則“ 4e8e6772337d0b993391ee6417171b79”和 language.tag ==“ en”* * 可擴展篩選是 DataSift 的主要創新。 他們使用編譯器在整個集群中高效地調度過濾器。 他們花了 3 年時間開發了可伸縮的規則評估解決方案。 * 規則由過濾器的[組合組成，可以包含 1000 千個潛在的數百萬項。 可以在數百臺計算機上計劃一次評估數百萬條規則。 規則可以重復使用并按層次排序。](http://blog.datasift.com/wp-content/DataSift-Introduction-Webinar-small.pdf) * 過濾器包括正則表達式，例如，您可以基于配置文件中的文本過濾掉推文。 有許多不同的目標和運算符。 * **加載** * 外部應用程序可以通過 REST API，HTTP 流或 Websocket 訪問與過濾器匹配的推文。 * 客戶端庫適用于：PHP，Ruby，C＃，Java，Node.js。 自己保存編寫 HTTP 請求。 * 您收到的是 JSON 對象，其中包含所有數據的規范化，完全增強格式。 您會在信息流中獲取性別，地理位置，興趣點，國家/地區，作者，推文，關注者數量，Klout 得分等。 每個消息最多有 80 個字段。 * **應用程序** * 應用程序通過一種出口策略接收一個詳細闡述的 JSON 對象。 DataSift 只是篩分，它不會烘烤。 因此，如果您希望使用默認轉換之外的 tweet 來完成某些工作，則必須編寫一個應用程序來完成。 * 不能保證以任何順序發送推文，也不能保證您看到有史以來發送的所有推文。 應用程序必須在聚合/采樣的基礎上工作。 * **結算** * 計費以稱為 **DPU** s 的神奇單位表示-數據處理單位。 每個過濾器都分配有一個 DPU。 每 DPU 每小時收費 20 美分。 您可以運行的最便宜的是 1 個 DPU，一整個月運行一個流將花費 150 美元。 * 這個想法是，您使用的資源越多，您應該支付的費用就越多。 * **開發** * 寄存器。 查看[示例流](http://datasift.com/solutions/prebuiltstreams/)。 * 學習 [CSDL](http://dev.datasift.com/csdl) 。 寫你的過濾器。 * [在線預覽](http://console.datasift.com/)過濾器，以查看獲得的結果的質量。 他們不僅返回原始數據。 他們有一個流瀏覽器，它具有地圖視圖，詞云視圖以及顯示情感和性別的圖表等。 * 微調。 獲得所需的結果，并查看 DPU，看您是否負擔得起。 * 使用您選擇的 API 收集數據并對其進行處理。 您如何處理數據取決于您自己。 您可以實時內聯處理。 也許顯示一些圖形。 將其存儲在您自己的數據庫中以進行后期處理。 ## 關鍵思想 ### 用例 考慮到大多數推文在每個人看來都是多么愚蠢，幾乎很難想象它們具有共同的價值，因此看看人們可能希望將這些系統用于什么的目的是很清醒的： * 廣泛的趨勢是將數據集合并在一起。 將筒倉數據集整合在一起，以獲得更好的見解。 將社交媒體數據與客戶數據進行大規模合并，您可以開始看到行為模式與兩個數據集之間的見解之間的相關性。 * 策展，監視，警報。 * 跟蹤：電視節目，政治，天氣，感冒等 * 金融。 查看人們對公司的反應。 * 每個人買什么？ 在逐月范圍內尋找廣泛的趨勢。 * 使用 Google 搜索來自世界各地所有星巴克附近擁有 500 多個關注者的文字推文。 * 減災。 知道需求在哪里。 * 將所有百思買的位置放到規則中，這樣您就可以在百思買中查看推文，而不必知道使用井號來自百思買的推文。 適用于任何事件或位置。 * 策劃新聞。 查看具有一定數量轉推的信息源。 看主題說是否技術。 全部實時，以毫秒為單位。 小牛肉通常的混合加上深奧的味道。 如何使用此電源取決于您。 ### 實時只有遠距離的后果 DataSift 作為實時過濾系統的性質具有深遠的影響。 請記住，它沒有內存。 它沒有歷史。 您沒有看到可以在任何方向進行迭代的有序流。 您正在從防火墻上獲取實時數據。 這些推文指向過濾器，通過過濾器，然后像夜晚一樣消失了。 這是一個采樣模型。 您無法認為您正在消耗整個流。 任何希望按順序查看帳戶中所有推文的應用程序都將無法正常工作。 面向的應用程序類型是可以準確采樣高度針對性的數據的應用程序。 例如，如果您想使用 DataSift 將 Twitter 用作消息總線來構建實時控制系統，則它將無法正常工作。 您不能保證可以看到一個帳戶中的每個命令，也不能保證這些命令的順序正確。 您可以解決的問題類型是創建一個過濾器，該過濾器將在 10 秒內提及 100 次“地震”一詞時觸發。 然后，您可以使用地理位置信息來確定發生地震的位置。 不需要任何鳴叫順序，也就可以看到每條鳴叫。 這是另一種心態。 ### 僅過濾器具有遠距離后果 讓我感到驚訝的是，DataSift 僅是一個實時過濾引擎（因此名稱中帶有“ sift”一詞）。 合作伙伴應提供更高級別的服務。 我期望 DataSift 成為一個有狀態的細分平臺，使人們能夠回答“居住在美國的 18-24 歲男性有多少？”之類的問題。 DataSift 不計數，因此它不能具有細分平臺的滑動窗口計數功能。 這是因為它是**無狀態**的結果。 從技術上講，DataSift 也無法識別年齡段，這主要是因為 Twitter 具有相當貧乏的個人資料功能。 DataSift 將 Firehose 存儲在 HBase / Hadoop 中，以進行離線分析，但這不是實時的。 因此，您必須將頭圍繞過濾器模型。 在 DataSifts 的平臺上無法執行任何應用程序邏輯。 沒有存儲過程。 可以通過諸如情感分析之類的增值服務在線增加推文，但這是一個高度結構化和受限的過程，而不是您的應用程序。 而且，如果您期望使用某種管道模型，那么也可以。 流無法通過一系列換能器通過管道進行編織。 之所以說 DataSift 是有原因的。 DataSift 是高度復雜且可擴展的過濾器系統。 它過濾掉了 firehose 中的 tweet，以創建針對性強的 tweet 流，供您在單獨的應用程序中進行處理。 他們的工作是使數據深入到執行分析所需的 tweet 的橫截面。 數據進入并根據規則進行匹配，如果不匹配，則將其丟棄，如果匹配，則將其放入您的存儲桶中。 過濾器就像一個手套，只有最值得的通過。 僅過濾器模型的驅動程序是： **firehose scale 和低延遲**。 消防水帶以很高的速率產生事件。 您將如何構建一個互聯網擴展平臺，該平臺可將應用程序邏輯折疊成潛在的數百萬客戶？ 您如何做到這一點，并建立一個可以保持低延遲保證的端到端系統？ 你不能 你能做什么？ 評估大型過濾器。 快速。 下一節將對此進行更多介紹。 ### **過濾引擎** * **當人們想到過濾器時，他們可能會想到 SQL select 語句，這些語句出于性能原因不建議使用大的“ where”子句。 DataSift 采用相反的方法，它們假定了非常多的過濾條件集，并且使評估具有可擴展性和效率。 他們的目標示例包括監視世界上每個星巴克的所有推文，或將 Lady Gaga 的關注者列表加載到過濾器中。 過濾器中可能有數百萬個術語，它們是實時評估的。** * **如此規模的過濾需要使用其他方法。 他們** 從他們在 TweetMeme 所做的工作開始。 核心過濾器引擎使用 C ++，稱為“ Pickle Matrix”。 * 三年多來，他們已經開發了編譯器和自己的虛擬機。 我們不知道他們的技術到底是什么，但可能類似于帶有查詢重寫的[分布式復雜事件處理。](http://www.doc.ic.ac.uk/~migliava/papers/09-debs-next.pdf) * 編譯器采用過濾器并以 Manager 和 Node 服務器為目標群集。 經理的工作是確定規則是否在其他任何地方加載，以及是否可以放置在高度優化的地方，例如靠近運行類似流的其他人。 Node 的工作是在規則上發布推文，獲取匹配項列表，然后將匹配項推入管道。 * 他們具有巧妙的算法來消除工作負載的重復數據，因此可以盡可能多地共享規則。 每個過濾器都不是孤立運行的。 過濾器形成一個共享空間。 如果有一個僅針對 Lady Gaga 引用進行過濾的過濾器，則該過濾器將在每個推特上運行一次，并使用同一過濾器在所有規則之間共享結果。 要完成這項工作，需要非常聰明的編譯器和調度算法。 回報是驚人的。 不再持續運行重復的過濾器，它們僅運行一次。 * 規則可以是分層的，編譯器很聰明地嘗試將它們放在一起，以便它們共享規則評估。 如果節點已經有一個規則，那么它將吸引使用該規則的過濾器。 該規則僅對節點上的所有篩選器運行一次。 * 這是一種虛擬化方式。 通過將多個客戶的工作負載組合在一起，他們可以利用過濾器中的任何共性。 即使每個操作只運行一次，DataSift 也會為每個操作付費。 例如，如果共享一個正則表達式，則僅運行一次。 它無法始終以這種方式工作，也許節點已加載，因此無法使用其他客戶端，因此它必須在另一臺計算機上運行。 * 整個配置在運行時可以動態更改。 他們的調度算法一直在關注監視數據。 如果等待時間超過閾值，則將重新配置系統。 * 過濾器會立即在內存中處理。 例如，每臺服務器可以運行 10,000 個流。 * 節點具有規則緩存，因此可以共享它們。 * 編譯器支持短路以優化濾波器。 * 例如，如果一個正則表達式大于整個機器，則它們將自動在節點之間進行負載平衡。 請記住，大型過濾器是預期的標準。 如果要對 Lady Gaga 的所有關注者進行過濾，則過濾器的可伸縮性必須是核心功能。 * 篩選引擎已分片。 每個分片都接收完整的流水線，并且所有分片都將處理每個``交互''（即``tweet''或``FB status''或``blog post''），整理其結果后再發送到下游。 * 單個分片中的 N 個節點中的每個節點（都是彼此的副本）以循環方式接收到 1 / N 的軟管。 * 因此，假設有 2 個分片，每個分片 3 個節點，則每個分片上將找到 50％的過濾器。 分片中的每個節點都將接受軟管的 1/3（并且上面將有 50％的過濾器）。 它將是該碎片中其他節點的副本。 * 因此，如果加載了非常重的過濾器，則可以通過將更多的節點添加到重規則加載到的分片中來平衡，從而減少單個節點必須處理的消防水帶數量。 * 到目前為止，還沒有單個過濾器對于單個節點來說太沉重，但是他們正在考慮拆分過濾器處理，因此先對子謂詞進行大規模處理，然后再對所得的過濾器進行單獨處理。 他們已經針對嵌入式規則進行了此操作（例如，給定一個過濾器，例如“讓我獲取所有包含'apple'AND 匹配規則 XYZ 的推文”，過濾器 XYZ 會分別處理）。 * 客戶需要大力推動創建可重用的公共規則，以鼓勵數據流的可重用性。 人們可以按照自己的規則使用任何公共流。 例如，某人可能制作了一個骯臟的單詞過濾器來創建流。 您可以使用它來構建該流。 每個人都共享同一流，因此，如果有 1000 個用戶使用臟字過濾器，則該過濾器不會得到 1000 次評估。 該過濾器將為每個人進行一次評估，非常高效。 ### 每個推文的增強管道 推文增加了第三方數據集。 使這些擴充具有低延遲是一個主要的痛點。 * 當一條 tweet 進入時，他們必須查詢 5 種不同的服務才能用更多數據擴展 tweet。 例如，Klout 有 1 億個 Twitter 個人資料，因此它們在內部針對 Klout 數據庫的本地副本執行數據庫請求。 他們將數據集帶入系統，而不是通過 Internet 進行 API 服務調用。 * 為了將數據集引入他們的系統，他們需要建立緊密的伙伴關系。 他們的情緒分析引擎已獲得許可，快速，可集群化，并且適合于每天處理 5 億次點擊，且延遲低。 * 每個服務必須具有< 100 毫秒的響應時間。 500 毫秒后，它就會被丟棄。 * 每 10 條推文中就有 1 條是鏈接。 這樣他們就可以獲取內容，并根據您的內容進行過濾。 因此，如果提及某個品牌，則可以根據實際內容進行解析，以找出所有含義。 ### 沒有云為他們 * AWS 曾用于生成測試流量，但對于分布式應用程序，他們認為 AWS 太有限了，尤其是在網絡中。 當節點連接在一起并且需要彼此通信時，AWS 的表現不佳。 沒有足夠低的延遲網絡。 他們的客戶關心延遲。 * 他們必須注意一些細節，例如如何設置交換機以及如何通過主負載均衡器路由它們。 * 從 Twitter 了解有關使用自定義數據包大小的信息。 他們正在使用巨型幀。 * 由于規模的原因，Twitter 可能會在未來細分市場。 * 他們與 Twitter 的聯系是通過 Internet 進行的，沒有對等關系。 ### 平臺意味著開放 * 首先構建一個 API，然后在該 API 上構建網站。 您可以使用 GUI 制作自己的導入工具，這些工具很酷。 * 目的是通過讓開發人員將 DataSift 嵌入其應用程序來使其不可見。 這是一個平臺，該平臺的工作是消除處理海量數據的難題。 其他人可以在其他系統中建立橋梁。 DataSift 希望專注于過濾和數據處理。 讓其他人提供 GUI 等。 ### 開票 * 負擔得起的實時計費產品不存在，因此它們構建了自己的產品。 面臨的挑戰是使人們對實時計費解決方案感到滿意。 * 客戶是實時計費的。 您可以查看您的儀表板，以了解正在花費什么。 亞馬遜和 Google App Engine 的經驗表明，這是系統中非常重要且非常棘手的部分。 錢就在這里。 * 他們使用稱為 DPU 的定義單位-數據處理單位進行收費。 您讓他們使用的資源越多，過濾器的成本就越高。 * 每個過濾器都分配有一個 DPU。 * 每 DPU 每小時收費 20 美分。 10 DPU 過濾器的價格為 2 美元/小時。 * 您可以運行的最便宜的是 1 個 DPU，一整個月運行一個流將花費 150 美元。 * 在 1 萬個地理位置上進行過濾將非常昂貴。 查找一個正則表達式會很便宜。 * 正則表達式很便宜，但是時間越長，處理時間就越長，這意味著它們更昂貴。 地理多邊形的處理相當復雜。 一長串關鍵字非常便宜，因為它們使用散列。 詞組匹配和近詞匹配稍微貴一些。 * 這樣做的想法是，與為不需要的數據支付許可費用相比，過濾盡可能小的數據集要便宜得多。 * 如果您運行 10,000 個數據流，但最終只占到了 Firehose 的 50％，但是他們不只是出售了 50％的 Firehose，而沒有數據處理，因為這與他們的平臺無關。 * 他們希望客戶盡可能詳細地描述他們想要從過濾器中獲取的數據。 * 由于 Twitter 上有 50 至 50 位男性和女性之間的對等關系，因此，所有男性都將占流水線的 50％或 1.25 億條推文。 為男性制作的所有推文創建過濾器并不是一件容易的事。 這將是非常昂貴的。 您要做的就是查看用例。 您是銀行嗎？您是藥店嗎？要弄清楚您對什么感興趣。 要盡可能具體。 一些公司每天只會發送一條推文。 每天 2.5 億條推文中，問題是如何創建過濾器以獲取所需的兩個或三個。 * 客戶可以設置閾值，以便他們可以決定每天花費多少。 您不想運行會在幾秒鐘內耗盡預算的流。 * 為了準確計費，系統具有廣泛的監視功能。 儀表板顯示整個平臺的運行狀況。 可以看到系統中任何點之間的流程，每個點之間的延遲。 所有服務器的運行狀況，吞吐量，流量變化都可能突出問題。 ### 輸出側 * 真正的痛點是輸出端。 您如何將推文從中心位置傳遞到用戶所連接的正確服務器上？ 最終使用 0mq。 使用發布和訂閱可以大大減少內部網絡流量，延遲和軟件復雜性。 他們現在幾乎在任何地方都使用它。 非常靈活 為了獲得高可用性，它們廣播給幾個聽眾。 * 嘗試了幾種技術來移動數據。 最初在所有地方都使用 HTTP，但這太慢了，并且具有很高的代碼復雜性。 然后他們嘗試使用 Redis 作為隊列，雖然速度更快，但是無法處理規模。 他們每天通過 0mq 發送數十億條消息。 * Node.js 在其前端使用，用于 HTTP 流和 Web 套接字連接的端點。 Node.js 的強大功能令人驚訝，它可以進行網絡數據傳遞。 該層很簡單，它只是將數據直接傳遞，將套接字插入套接字。 他們為 Node 構建了自己的多線程模型。 * 事件系統的問題是知道您為什么收到事件，以便可以將其分派到正確的處理邏輯。 例如，同一條 Tweet 可以匹配性別規則和臟話規則，并且每種情況下，Tweet 的處理方式必須不同。 DataSift 有幾種方法可以使這項工作完成，但是它們具有非常智能的標記功能。 一旦子過濾器匹配，就可以對該事實進行標記并在元數據中傳遞。 該引擎允許您創建規則的任何層次結構，以便可以將規則結合在一起，然后使用標記來創建類別。 ### 測驗 * EC2 用于生成流量。 防火墻為 60 Mbps。 * 為了測試他們的系統，他們一次要運行相當于 11 臺消防車的系統。 1000 個流，每個消防站的 1％將其傳送到 1000 個連接。 他們遇到的瓶頸是托管提供商的網絡帶寬，而不是平臺。 ### 將溪流匯入湖中 DataSift 還支持非實時處理。 HBase 中存儲了兩個主要的推文集合： * 過濾器可以具有偵聽器，因此推文直接存儲在 HBase 中，允許以后下載數據。 可以安排流的錄制，然后稍后瀏覽/使用它。 * 錄制整個消防水帶是一項巨大的技術挑戰。 在兩個月內，他們將使人們可以在存儲在 HBase / Hadoop 中的持久性版本的 firehose 上運行其篩選器。 這個想法是能夠對您感興趣的任何方面進行分析。 擴充所有數據后，每天通過該平臺的數據總計將增加 1 TB，因此要存儲大量數據。 ### 你如何賺錢？ 作為開發人員，我一直對如何使用平臺和服務為開發人員（不僅是創造者）賺錢感興趣。 我的角度是，如果您在通過收取足夠的錢來賺錢的服務之上構建服務，是否可以構建有利可圖的服務，或者成本太高，或者您是否真的必須將高價值目標定為高 保證金產品證明成本合理？ 換句話說，例如，TweetMeme 可以基于 DataSift 獲利嗎？ 建立或購買問題始終是一個棘手的問題。 * **內部使用**。 如果您是使用 DataSift 來了解自己的產品的企業，那么您所獲得的任何價值都可以證明其成本是合理的。 這很簡單。 * **服務**。 DataSift 認為自己可以提供商品化的數據交付，并且其成本只是從 Twitter 獲取數據和開發人員所需時間來處理這些數據所需的基礎結構成本的一小部分。 據他們估計，要建立一個像 Radian6 這樣的社交監控服務，需要在系統上花 3 個月的時間。 您只需要專注于界面。 數據收集和處理部分得到處理。 如果您能找到合適的市場，那將具有很大的價值。 * [App Store](http://blog.datasift.com/2010/11/02/datasift-app-store/) 。 DataSift 計劃為第三個部分開發人員提供一個應用程序商店。 * **增強服務**。 DataSift 將支付服務費用以作為其擴充渠道的一部分。 該模型是收益分成。 如果有人使用像 Klout 這樣的平臺，他們將收益分享給他們。 問題是找到可以擴展到 Twitter 級別的合作伙伴。 ## 得到教訓 * **平臺和生態系統的力量。** 如果平臺策略執行得當，它將成為進入市場的巨大障礙。 它也是觀察下一波趨勢發展的最高觀察站。 這是[創新/杠桿/商品化](http://www.youtube.com/watch?v=Y_F6nFIp_dA)模型。 DataSift 已經擁有 LinkSift 之類的域名，因此這是該大計劃的一部分，該計劃是使用他們的底層平臺來提供更高價值的服務，以他們從平臺市場中收集的情報為指導。 * **按鈕沒有錢，數據沒有錢。** 跟隨錢**。** 您現在正在做的事情可能不在錢中，但是它可以指導您找到錢的地方。 * **質量勝過廢話。** 趨勢是發布幾乎不可行的軟件，然后使用用戶反饋迭代地對其進行改進。 DataSift 沒有走這條路。 他們從一開始就發布了復雜的可擴展產品，其原因有兩個：1）他們在 TweetMeme 的經驗基礎； 2）他們不覺得自己可以從小做起并立即重新構建。 * **從結構上來說，無國籍狀態是一個巨大的勝利。 DataSift 僅是實時的，因此不必在內存中保留很多狀態，也不必擔心按順序傳遞事件而不會丟失甚至不會容忍任何錯誤。 計時是他們的痛點，可以降低端到端的延遲。 當然，這將狀態負擔推給了應用程序開發人員。** * **從別人的錯誤中學習。** 當 Twitter 從 TweetMeme 許可了轉發技術時，他們實際上并沒有重用 TweetMeme 的代碼。 Twitter 從該代碼中學到了知識，并將 TweetMeme 用作咨詢服務，這有助于 Twitter 在發布時立即進行轉發。 相反，當 DataSift 學習如何處理防火墻時，DataSift 可以從 Twitter 犯下的所有早期錯誤中吸取教訓，因此 DataSift 可以在發布時正確解決。 * **服務**。 從一開始就很難使用服務進行設計。 他們從一開始就擁有一個體系結構，但是如何連接這些服務，如何使這些服務冗余，如何使這些服務響應故障以及如何在某件事失敗的情況下使一切都不會失敗-所有這些類型的問題都有 一直是痛點。 將組件劃分為服務是解決這些分布式編程問題的關鍵。 服務還使每個組件都可以獨立擴展。 * **消息系統**。 以 0mq 為核心的消息傳遞系統將服務聯系在一起并實現可靠性。 它的工作非常出色。 比使用 HTTP 好 1000 倍。 他們喜歡不同通信模式（發布-訂閱，請求-響應等）的靈活性。 HTTP 在性能和使用它所需的代碼量方面都有太多開銷。 只需將消息傳遞到需要處理的代碼即可。 它使接口保持異步，解耦和基于隊列而不是阻塞。 * **連接管理**。 實時流的最大瓶頸之一是如何處理連接和斷開連接。 他們從 Twitter 中學到了很多東西。 建立連接時，它會觸發大量下游活動來激活連接，例如身份驗證，驗證流請求，確定負載，計費服務，審計跟蹤等。每秒能夠運行數千個連接/斷開連接是一個挑戰。 從 PHP 重寫為 C ++，并使其成為多線程。 * **將常用案例折疊到平臺**中。 在他們的人員期間，他們喜歡在列表中加載數百萬的人員。 就像 Lady Gaga 的所有追隨者一樣。 指向列表并將其自動下載到規則中。 * **指標比記錄**更重要。 記錄中總是會填滿您不使用的內容。 能夠為超出范圍的指標創建警報更加有效。 當指標觸發對問題的意識時，您可以查看日志。 * **遵循 Salesforce 和 Amazon 模型**。 他們是一個按需云平臺，它們將在開始的基礎上構建層。 因此，DataSift 是引擎，他們將制造其他產品，如 UserSift 和 LinkSift。 * **易貨**。 不必花錢。 通過物物交換引導。 他們獲得了贊助。 他們出售了舊域名，以資助購買新域名。 * **將一種產品的經驗轉化為另一種**。 TweetMeme 使用基于 RSS 提要的 fav.or.it 基礎結構。 這使 TweetMeme 得以快速開發。 同樣，構建 TweetMeme 的經驗使跳轉到 DataSift 變得容易得多。 他們從 TweetMeme 學習了可伸縮性，并建立了一流的工程團隊。 * **一切都至關重要**。 例如，他們在整個網絡設備中都遇到幀緩沖區大小的問題。 他們發現，開放 HTTP 流連接比簡單的 REST 調用更難擴展，因為它帶來了網絡中的許多潛在問題。 當他們使用 REST API 時，他們沒有看到這些問題。 從我的采訪，閱讀和查看十幾個其他采訪中，我對 DataSift 的思維和努力質量印象深刻。 我不知道它是否當然會成功，或者是否會成功，但是如果我失敗了，那是因為缺乏專業精神。 企業家轉變為 VC 的 Mark Suster 解釋說，他對 DataSift 的投資是[在 Twitter 生態系統](http://www.bothsidesofthetable.com/2011/07/10/why-im-doubling-down-on-the-twitter-ecosystem/)上的投入增加了一倍。 我認為這是錯誤的觀察方式。 DataSift 可以快速輕松地與任何流一起使用。 也許更好的方法是將 DataSift 加倍。 ## 相關文章 * [這篇關于黑客新聞](http://news.ycombinator.com/item?id=3292604)的文章 * [具有查詢重寫功能的分布式復雜事件處理](http://www.doc.ic.ac.uk/~migliava/papers/09-debs-next.pdf)，作者：Nicholas PoulSchultz-M?ller，Matteo Migliavacca，Peter Pietzuch * [推文可以告訴您什么](http://www.readwriteweb.com/archives/what_a_tweet_can_tell_you.php)，作者：Marshall Kirkpatrick * [Gnip 和 DataSift 有什么區別？](http://www.quora.com/What-is-the-difference-between-Gnip-and-DataSift) * [DataSift 鏈接分辨率]( http://www.youtube.com/watch?v=JAN47Hw6o8w) * [可擴展性的藝術-管理增長](http://www.alberton.info/talks/show/id/3)，作者：Lorenzo Alberton * [有關“類固醇軌道：” DataSift]( http://www.youtube.com/watch?v=X7aiKaCi8O8) 的更多詳細信息-采訪 Robert Scoble * [DataSift 的定價是否會對初創企業起到威懾作用？](http://www.quora.com/Is-DataSifts-pricing-a-deterrent-for-startups) * [在 Twitter 提要之上的應用程序的基礎架構（帶寬）有多昂貴？](http://www.quora.com/How-expensive-is-the-infrastructure-bandwidth-of-an-app-on-top-of-Twitter-feeds) * [問&答：尼克·霍爾斯特德（Nick Halstead）使用 Datasift](http://www.wired.co.uk/news/archive/2011-10/12/nick-halstead-mining-twitter ) 挖掘 Twitter 的火喉。 * 要點：[將 Paul S. Watson 的 DataSift Twitter 交互流記錄到 Google Fusion Table](https://gist.github.com/1389349) 中 * [新的 DataSift 首席執行官表示，Twitter 的未來在于數據，而非廣告](http://www.themediabriefing.com/article/2011-11-17/the-future-of-twitter-is-in-data-not-advertising-says-new-datasift-ceo) * [Twitter 是一個信息流，但它也是一個蓄水池](http://gigaom.com/2011/11/17/twitter-is-a-stream-but-its-also-a-reservoir-of-data)，作者：Mathew Ingram * [DataSift API 演示](http://www.slideshare.net/nickhalstead/datasift-api) * [Cassandra vs HBase](http://skillsmatter.com/podcast/home/cassandra-hbase) ，作者：尼克·特爾福德（Nick Telford）（DataSift 平臺架構師） * [Twitter 上的 DataSift 開發](https://twitter.com/#!/datasiftdev) * [第四次 DataSift 網絡研討會視頻，“目標”](http://blog.datasift.com/2011/07/28/fourth-datasift-webinar-video-%E2%80%9Ctargets%E2%80%9D/) * [MediaSift / DataSift（Genesys Guru 的作者）](http://genesysguru.com/blog/blog/2011/05/27/mediasift-datasift/) * [為什么我在 Twitter 生態系統上加倍關注](http://www.bothsidesofthetable.com/2011/07/10/why-im-doubling-down-on-the-twitter-ecosystem/)，作者：Mark Suster * [在 Mozilla 音樂節](http://blog.pusher.com/2011/11/3/ways-to-use-pusher-at-the-mozilla-festival)上使用 Pusher 的方法，Phil Leggetter * [10 個高流量流的 IPTraf 統計信息的視頻](http://www.twitvid.com/QQK7M)-這是使用 10 個流進行的測試-一臺服務器的吞吐量約為 3Mb / s。 感謝您發布此信息。 他們龐大的過濾框架聽起來非常令人印象深刻。 謝謝，這是一篇有趣的文章。 我有一些關于數字的查詢： -您說他們每天處理 250+百萬條推文，每秒不到 3k。 當有關碧昂斯的嬰兒的消息傳出時，Twitter 的峰值每秒不到 9000 條。 那么每秒 12 萬條推文的峰值來自何處？ -每 1000 條推文 10c 似乎太糟糕了，這筆費用還包括結果權嗎？ 如果是這樣，您對完全訪問沒有轉售權的費用有任何想法。 謝謝！ 感謝您使用 0mq 并作出貢獻。 有了這些類型的數據流和量度指標，它肯定會得到“真正的”鍛煉！ 我想這種壓力也會很快消除錯誤！ 非常好寫托德。 我一直在與 DataSift 一起工作，因為他們在 Alpha 階段完成了一個我正在為客戶準備的項目，該項目很快就要出爐了（幾周）。 他們做得很好，這是一個令人印象深刻的平臺，可以肯定它具有巨大的潛力。 有一些優點和缺點，但您要指出其中的一些優點（有些卻不知道），但總體而言，我很喜歡使用該服務，并且愿意承擔這種情況下的早期采用者的風險。 干杯， 肯特郡 Thanks it is an interesting article. I have a couple of queries about numbers though: - You said that they process 250+ million tweets per day, which works out to be just under 3k per second. Twitter had a peak of just under 9k tweets per second when the news about Beyonce's baby broke. So where does the peak of 120k tweets per second come from? - 10c per 1000 tweets seems like an awful lot, does this fee include result rights as well though? If so do you have any ideas about the fees for full access without resale rights. Thanks! 非常感謝您發表這篇深入的文章，非常感謝您描述整個公司的方式，從技術細節到業務建議。 您是否想在 4 年后寫一份跟進報告？ 考慮到他們所面臨的所有挑戰，看看他們如何擴展其體系結構和/或流目錄非常有趣。 +