# Medialets 體系結構-擊敗艱巨的移動設備數據 > 原文： [http://highscalability.com/blog/2011/3/8/medialets-architecture-defeating-the-daunting-mobile-device.html](http://highscalability.com/blog/2011/3/8/medialets-architecture-defeating-the-daunting-mobile-device.html)  移動開發人員面臨著巨大的擴展問題：對來自數百萬個設備的大量連續遙測數據流進行有用的處理。 這是一個非常好的問題。 這意味著智能手機的銷售終于實現了他們的命運：[在銷售領域屠宰 PC](http://www.mobiledia.com/news/81680.html) 。 這也意味著移動設備不再只是簡單的獨立應用程序的容器，它們正成為大型后端系統的主要接口。 盡管開發人員現在在客戶端進行移動開發，但他們面臨的下一個挑戰是如何對那些棘手的后端位進行編碼。 目前面臨同樣問題的公司是 [Medialets](http://www.medialets.com/) ，這是一種移動富媒體廣告平臺。 他們所做的是幫助發布商制作高質量的互動廣告，盡管就我們的目的而言，他們的廣告內容并不那么有趣。 對于他們的系統，我確實感到非常有趣的是他們如何解決克服移動設備數據泛濫的問題。 每天，Medialets 都需要處理數十億個新對象，這些對象嵌入了數百萬兆個原始事件數據流中，而這些數據又是從數百萬個移動設備流入的。 所有這些數據必須是：在移動設備上生成的； 通過長時間斷開連接而中斷的有損連接進行傳輸； 緊縮 提供給報告系統； 反饋到必須能夠在幾毫秒內響應請求的控制系統中。 這將成為具有移動設備的系統的常見范例。 問題是，如何實現它？ 現在很有趣。 為了幫助我們更多地了解 Medialets 的工作原理，Medialets 服務器平臺的工程經理 Joe Stein 很友好地向我介紹了他們在做什么。 Joe 還運行了一個出色的 Hadoop 播客和博客，名為 [All Things Hadoop](http://allthingshadoop.com/) ，請查看。 Joe 在這個問題上做了很多工作，并且對如何使用諸如 Hadoop，MySQL，HBase，Cassandra，Ruby，Python 和 Java 之類的工具構建有效的移動數據處理器有一些很棒的想法。 ## 現場 * [http://www.medialets.com](http://www.medialets.com/) -主頁。 * [http://www.medialytics.com](http://www.medialytics.com/) -用于分析來自應用程序事件的見解儀表板。 ## 什么是 Medialets？ Medialets 將富媒體廣告投放到 iPhone，iPad 和 Android 等移動設備。 富媒體意味著廣告可以是使用 SDK，事件生成和廣告功能嵌入的復雜應用程序。 這個想法是，廣告可以在平臺內運行，而不是 being 腳的 adsense 型廣告，它們可以完全互動，同時提供與電視相同的品牌質量，但在移動設備上除外。 應用程序可以讓您做一些事情，例如搖動設備或與 Michael Strahan 玩足球比賽。 所有這些活動都會生成必須流回其服務器場以進行處理的數據。 除了廣告外，他們還為發布商提供非常詳細的基于[應用程序的分析](http://www.medialytics.com/)。 要查看其廣告的示例[，請點擊此處](http://www.medialets.com/showcase)。 ## 統計資料 * 每天有 2-3 TB 的新數據（未壓縮）。 * 每天創建數百億個分析事件。 事件表示有人搖晃，關閉，旋轉等應用程序。 * 200 多個高級應用程序在數以千萬計的移動設備（iPhone，iPad 和 Android）上運行。 * 已經處理了超過 7,000 億個分析事件。 * 在典型的 MapReduce 作業中，每秒可以處理超過一百萬個事件 * 通常在 [www.medialytics.com](http://www.medialytics.com/) 中可以從移動設備收到數據 * 總共約有 100 臺服務器。 * 移動電話正在增長。 智能手機[的銷售量首次超過了個人電腦](http://www.mobiledia.com/news/81680.html)的銷售量，而 Medialets 的銷售量卻在增長。 iPhone，iPad 和 Android [設備在 2010 年第四季度增長了近](http://www.medialets.com/medialets-data-spotlight-mobile-rich-media-momentum-q4-2011/) 300％。Android 繼續增長市場份額，但 iOS 仍占據著高端手機庫存的主導地位。 * 有十幾個人在從事工程，主要是在客戶端和 Medialytics 上。 基礎架構團隊為 1-2 人。 ## 基礎設施 * 在四核 x 16GB / 1TB 上運行的 Ad Server 實例 * 16 核心 x 12 GB（含 10TB）的事件跟蹤服務器 * 事件處理，作業執行，日志收集&聚合對每個 16 核 24GB RAM / 6TB 空間進行預處理 * 日志收集&匯總了預處理和后處理。 Hadoop 群集節點各有 16 個核心 x 12GB RAM（含 2x2TB（JBOD））。 * [www.medialytics.com](http://www.medialytics.com/) 各種配置都具有 16 個內核，從 12 到 96GB RAM 帶有 1-2TB ## 開源系統&生產工具 * 的 Linux * 滅螺 * 雄貓 * 的 MySQL * 阿帕奇 * 乘客 * 收益率 * 記憶快取 * 德語 * Hadoop 的 * 豬 * 納吉奧斯 * 神經節 * 走 * 吉拉 ## 語言能力 * C / C ++-廣告服務器 * Java-數據轉換 * Ruby-很多服務器端 Ruby。 Ruby 可能比 C ++更多，但更多地轉向了 Python。 * Python-許多 MapReduce 正在使用 [Python 流](http://allthingshadoop.com/2010/12/16/simple-hadoop-streaming-tutorial-using-joins-and-keys-with-python/)移入 Python。 * 階梯 * 重擊 ## 建筑 * 該系統構建了幾年，主要使用定制軟件，盡管他們使用 Hadoop 來承擔分析方面的繁重任務，并使用 MySQL 作為數據庫。 定制軟件在開始時就需要擴展，但是隨著這些產品的發展，他們現在正在考慮使用更多現成的產品。 * 該系統是實時的，因為隨著數據的滴入，報表中的數據將盡可能快且盡可能真實。 * 不是基于云的。 它們在物理硬件上運行。 他們無法在云中的多租戶環境中完成所需的工作。 具有 16 個核和 TB 級磁盤空間的計算機幾乎是不夠的。 他們花費大量時間來構建軟件，以充分利用硬件，磁盤 IO，CPU，并行處理的優勢，并充分利用內存。 * 他們所做的一切（幾乎）都是異步的。 您無需連接到網絡即可查看廣告或讓他們捕獲分析。 廣告可以在廣告系列開始之前幾周投放（預定），您也可以乘坐地鐵，仍然可以看到廣告。 廣告期間收集的數據最終會傳遞到服務器端。 * 發布者負責構建應用程序，并集成到 Medialets SDK 中。 該 SDK 特別適用于分析和廣告。 當他們想要運行分析或在廣告位中運行廣告時，他們使用 Medialets 的工具。 * 共有三個基本子系統：廣告投放，事件處理和報告。 * 服務器分為以下幾層： * 前向層： * 廣告投放層-專為運行廣告服務器而設計。 * 跟蹤層-處理數據轉儲和數據加載。 * 異步處理層： * Hadoop 集群-在其自己的服務器集上運行。 * Java 和 Ruby 流程-接收傳入的數據，并將數據轉換為 Hadoop 可用的形式，以進行不同的聚合。 * 使事情保持精簡和卑鄙，并僅根據需要提供盡可能多的冗余。 * 硬件是根據軟件的功能進行配置的。 并非所有機器都是高端或低端。 系統的不同部分具有不同的硬件需求。 * 響應廣告服務請求時，磁盤 IO 或計算量很少。 有一個 C ++服務在靜態內存上進行查找。 因此，廣告投放機具有大量內存和低端處理器。 * 在有數據接收的地方，它們有許多套接字阻塞并寫入磁盤，因此它們只需要很少的內存。 * Hadoop MapReduce 層需要您提供的所有功能。 * 事件處理流程如下所示： * 移動設備上的應用程序會生成事件。 有應用程序事件，廣告事件和自定義事件。 定制事件可以由應用程序創建為鍵-值對，它們將在此基礎上聚合，而無需定制編碼。 * 跟蹤服務器接收事件并將其寫入對象的日志文件。 這些文件表示收集事件數據的時間快照，例如 7 分鐘。 * Java 服務器讀取這些文件，解壓縮它們并通過一系列線程池運行對象，以便將它們轉換并與所有必要的元數據合并。 不同的流程將拾取不同的事件類型并對其進行處理。 * 上一步創建一個新文件，其中該事件在與元數據合并后現在已完成。 該新文件被推送到 HDFS（Hadoop 使用的文件系統）中。 * MapReduce 在這些 HDFS 文件上運行以對數據進行重復數據刪除。 重復數據刪除發生后，數據集是干凈的。 * MapReduce 作業生成數據，然后將其導入到分析 UI 可提供給客戶的數據庫中。 運行數十種不同類型的聚合。 通過 Medialytics 提供了標準指標，可以從廣告和應用報告的角度顯示應用的運行狀況。 它們沿著許多不同的維度進行匯總，例如，按設備和平臺進行匯總。 其中一些數據是對廣告投放系統的反饋。 * 數據復制是移動設備和異步系統上的關鍵設計點。 * 手機操作系統無法保證應用程序會獲得時間來生成事件。 在 OnClose 掛鉤中，發布者將運行一些清除邏輯，Medialets 具有一些清除邏輯，然后將事件寫入服務器，這需要花費幾毫秒的時間來響應，然后本地應用程序必須更新本地數據庫。 即使這是一個快速的旅程，您仍處于 15 毫秒的窗口中，在該窗口中，操作系統無法保證所有功能都將執行。 操作系統可能會終止進程或崩潰。 根據失敗發生的位置，這將導致重播事件重復。 iPhone 的新后臺功能使記帳變得復雜。 如果某個應用程序在后臺運行了 30 秒或更短的時間，則仍被認為是同一次運行。 有很多變化。 * 關機 3 個月的手機仍然可以輸入數據。 他們必須能夠知道自己是否曾經看過這些數據，如果不經常使用應用程序，這種情況很常見。 * Hadoop 用于計算指標和聚合，但也用于重復數據刪除。 在處理數據時，他們每秒查看超過一百萬個事件以對數據進行重復數據刪除。 他們每天都會收到 100 億個事件。 他們必須查看每個事件并確定是否：1）他們之前看過事件； 2）他們是否要在他們正在處理的數據集中再次看到該事件。 使用 MapReduce 可以將數據分散在一堆服務器上，這意味著您直到減少所有重復數據的所有工作后才真正知道。 * 廣告 * 某些類型的事件數據是實時流回的。 對于另一類數據，必須在創建事件之前打開和關閉事件。 例如，要知道某人一天使用一次應用的次數，必須有一個打開事件和一個相應的關閉事件。 * 移動世界中的用戶確實是獨一無二的。 在 Internet 世界中，除非已登錄，否則幾乎無法量化用戶。 電腦被很多人使用，您無法真正確定誰在使用設備。 像電話這樣的物理設備通常由一個人使用，因此，基于設備的聚合實質上就是基于用戶的聚合。 * 他們可以收集不同維度的統計數據，例如轉化數據。 他們可以告知某人從該操作系統的版本升級到另一版本需要多長時間。 誰是不同類型的人？ 然后，他們可以將其覆蓋到他們擁有的不同類型的應用程序中。 * 廣告既可以是品牌廣告也可以是直接響應廣告，兩者混合。 例如，當電影廣告被點擊而不是去網站時，它可以從設備中調出本地應用程序。 這樣您就可以在應用程序中直接購買門票。 具有不同的攔截器并具有創建豐富的用戶體驗的能力，從而可以通過新方式將交互流貨幣化。 * 啟動應用程序后，應立即顯示廣告。 異步用于將數據推送到服務器，但可以同步投放廣告。 許多應用程序在打開時都會看到贊助商徽標，并且必須立即提供。 第一個 onload 調用是獲取廣告的同步調用。 他們的廣告投放系統可以在 200 毫秒內以 3％的差異投放廣告。 * 由于它們將數據存儲在[壓縮序列文件](http://blog.mgm-tp.com/2010/04/hadoop-log-management-part2/)中，因此節省了 70％-80％的存儲成本。 * HDFS 具有序列文件格式。 壓縮可以基于行或塊進行。 假設您有一個包含 10 個塊的序列文件，并且一個塊定義為將進入映射器的數據（對于 MapReduce）。 如果壓縮是在塊級別上，并且有 10 個塊，則可以將這 10 個塊并行推送到映射器，HDFS 將自動處理所有解壓縮和流傳輸。 * 可將來自 reducer 的數據存儲在序列文件中，例如它是重復數據刪除過程的結果，或者可以以未壓縮的格式存儲，可以將其加載到另一個數據庫中。 * 許多人不壓縮數據。 要使用 Hive，必須解壓縮數據，以便您可以與之交互。 這取決于您要花多少錢以及您希望在哪里發揮系統效率低下的作用。 * 將大量數據以未壓縮格式存儲在磁盤上是一個弊端。 他們有選擇地決定使用哪種格式，具體取決于與將數據保留在磁盤上多長時間相比，解壓縮階段是否值得承擔這些開銷。 * 工作執行系統 * 內置 Ruby，然后再提供合適的現成系統。 * 他們建立了作業處理系統來實施工作流處理。 工作流是一組具有不同任務和步驟并針對不同事件進行操作的作業。 必須以許多不同的方式處理應用程序數據，并且結果必須進入幾個不同的系統，一些進入表，有些進入其他報告系統。 所有這些都是自動化和腳本化的。 * 聚合數據存儲在 MySQL 中，供發布者和廣告商查看。 它們達到了可以分片的極限。 他們正在研究 MongoDB 和 GridFs（屬于 MongoDB）。 * GridF 看起來可以很好地存儲，擴展和提供其媒體文件，這使他們考慮使用 MondoDB 來存儲聚合結果集。 * 他們還在尋找 Cassandra 和 HBase 來存儲其匯總結果集。 他們會考慮將相同的基礎結構也用于其跟蹤和事件捕獲服務器，這些服務器目前完全是自定義編寫的。 * Cassandra 看起來很有吸引力，因為它可以跨多個數據中心工作。 他們將使用此功能在同一個 dacenter 中擁有多個集群，并在一個集群中進行寫操作，而在另一個集群中進行讀操作，因此不同的流量負載不會互相影響。 他們不想混合使用不同類型的流量，因此他們不想在同一臺計算機上執行 MapReduce 作業，從 HBase 寫入和從 HBase 讀取。 * HBase 是一種有吸引力的選擇，因為它們已經將大量數據寫入 HDFS，以至于那些文件在 HBase 中可用將令人興奮。 他們在 fsync 方面存在可靠性方面的擔憂，以確保將數據寫入磁盤，但是這些擔憂已在最近的發行版中得到解決。 HBase 不允許按不同用途對數據進行分區，這對 Cassandra 來說是有吸引力的，因為 Cassandra 支持在群集中具有不同種類的機架。 * 由于他們已經在使用 HDFS，因此在處理完所有數據后將所有數據移入 Cassandra 并不吸引人，這會使他們的硬盤需求增加一倍。 * 他們喜歡[協處理器](http://highscalability.com/blog/2010/11/1/hot-trend-move-behavior-to-data-for-a-new-interactive-applic.html)的想法，因此不必在網絡上移動數據。 每個作業為 2-3 TB，因此真正實現并行化而無需移動數據非常有吸引力。 * [TTL 刪除在 Cassandra 中的](http://www.quora.com/Which-NoSQL-stores-have-good-support-for-LRU-or-TTL-semantics-in-storage)非常吸引人。 Cassandra 可以輕松處理其寫負載，因此可以用來存儲傳入的事件。 然后，所有工作流程都可以從 Cassandra 中取出移動數據，將其與其他數據庫中的元數據合并，以創建完全連接的對象，然后可以將其寫入 HBase，然后可以進行 MapReduce 聚合并寫入結果 到 MongoDB。 * 另一種重復數據刪除設計是將其全部寫入 HBase，然后選擇最后一個作為贏家。 一旦這些系統就位，他們將重新考慮一些現有流程，以了解如何利用它們。 * 為了確定他們是否應該保留現有軟件，遷移到另一個數據庫還是使用 MySQL，進行了大量的原型嘗試。 他們可能最終會使用 MongoDB，Cassandra 和 HBase，他們只是想為正在構建的新產品找到正確的功能組合，并弄清楚它們如何能夠繼續擴展而不會占用大量開發人員時間。 * AdServer 用 C ++編寫 * 該層提供了標準的廣告投放時間安排功能，因此可以將廣告映射到廣告位，旋轉廣告，定位廣告等。定位可以基于平臺，分辨率，地理位置和其他尺寸。 * 有一個用于數據庫數據的對象緩存，用于制定廣告投放決策。 * 99％的時間緩存足夠，而他們有 1％的時間訪問數據庫。 * 讀取時間只有幾微秒，但當必須訪問數據庫時，讀取時間會增加到 200 微秒。 * 還負責安排廣告投放進度，以便可以在應用的整個生命周期內投放廣告系列。 例如，如果某個應用每天運行一百萬次，而該廣告系列獲得了一百萬次展示，則他們不想在一天內耗盡它。 假設廣告客戶希望廣告系列投放一個月。 廣告服務器查看分析數據，然后提出費率請求，以計算應投放的步伐廣告。 * 許多決定都是預先計算的。 人將放置目標，說出應在何處顯示添加項。 * 諸如地理分布之類的決策是動態計算的。 例如，如果您要投放一組廣告印象，則需要一些去加拿大，一些去美國。 * Java 服務器 * 將元數據與傳入的數據集連接起來。以 95％的命中率從緩存中提取元數據。 例如，當他們有一個新的廣告上線時，他們將訪問數據庫。 * 進入數據庫后，他們希望盡可能樂觀，并盡可能減少線程的中斷，因此在進行非常繁重的讀取操作和寫入次數很少時，它們使用原子變量和 CAS（比較并設置）。 此開關將性能提高了 15％-20％，因為它們不再阻止寫入。 * 他們對讀取的數量進行了基準測試，發現 Mutex 花了很長時間。 信號量最終阻止了作者。 假設有 10 個線程，其中 9 個可以讀取，因此沒有線程會阻塞，但是第 10 個線程必須寫入，它將阻塞所有線程。 與循環執行比較和設置相比，這增加了延遲，并且效果不佳。 這是有可能的，因為它們不斷處理 JVM 內某些被阻止的千兆字節數據。 * 使用[并發備注模式](http://javathink.blogspot.com/2008/09/what-is-memoizer-and-why-should-you.html)創建用于處理緩存請求的線程池。 緩存是一個池，將在需要時加載數據。 負載使用 CAS 來阻止正在發生的實際讀取。 * [SEDA](http://www.eecs.harvard.edu/~mdw/proj/seda/) 用于通過所有不同的轉換處理數據。 每個線程池對一塊數據執行狀態轉換，然后將數據轉發到另一個線程池以進行下一個轉換。 例如，第一步是從磁盤讀取數據并將其序列化到對象陣列上。 這些操作對延遲不敏感。 * 使用 Ruby * 使用 Ruby 時，必須有效地實現真正的多進程功能。 * [Rinda](http://en.wikipedia.org/wiki/Rinda_(Ruby_programming_language)) 用于在分支過程之間創建并發。 有時使用數據庫進行協調。 * 這隱藏了解釋程序常見的任何內存泄漏問題或綠色線程問題。 * 監控方式 * 內部工具和 Nagios 的混合。 * 與 Ganglia 跨所有不同層級對自己的日志進行大量趨勢分析。 * 他們采取了非常主動的監視方法，并花費了大量的 R & D 努力，因此他們可以在發生問題之前就知道他們有問題。 * 趨勢式飼料進入他們的監測。 如果他們的一臺廣告服務器在 10 毫秒內停止響應，在一秒鐘內響應超過 1 或 2 個請求，則他們需要知道這一點。 * 如果請求延遲平均要從 200 毫秒增加到 800 毫秒，那么他們想知道。 * 它們記錄了很多日志，因此通過日志進行問題調試。 ## 得到教訓 * ****將數據轉化為產品**。** Development 知道他們擁有的數據。 該知識可用于幫助產品團隊創建新產品以銷售給客戶。 R & D 與業務之間始終存在很大的差距。 幫助企業與 R & D 的工作保持一致。 讓他們了解 Hadoop 的功能，處理數據的速度以及處理數據的速度。 新的轉化歸因產品就是一個很好的例子。 如果用戶看到靜態廣告，點擊它并下載該應用程序，則可能不是導致該轉化的唯一原因是靜態廣告。 例如，如果用戶在前一天（或兩周前）體驗了富媒體廣告，則根據發布者可配置的標準，該廣告將為轉化分配一定的功勞。 只有強大的數據處理基礎架構才能實現這種功能。 如果沒有 R & D 知道這種功能甚至是可能的，那么就不可能開發出這些新型的高附加值產品并將其出售給客戶。 * **探索新工具**。 這是一個由新工具組成的復雜世界。 所有這些新技術使知道在何處放置功能具有挑戰性。 一個功能可以通過很多不同的方式完成，并且根據工具（HBase，Cassandra，MongoDB）的不同而有所不同。 重復數據刪除是否仍應在 MapReduce 中完成還是應使用協處理器完成？ 通過支持兩個不同的數據庫值得將磁盤加倍嗎？ 按使用模式對數據進行分區是真的還是獲勝，或者所有流量模式都可以在同一系統上工作？ 對您的選項進行原型設計，并考慮您的體系結構如何隨每個新工具（單獨工作或一起工作）而變化。 * **主動監視和規劃容量**。 將監視數據轉變為基礎架構規劃。 如果您不這樣做，那您將只保留消防問題。 建立主動警報和趨勢數據，以便即使在成為警告之前，您也可以看到它的到來。 有時您只需要另一個服務器。 更多數據僅意味著更多服務器。 這是做生意的成本。 知道要放置在哪個服務器以使所有不同的數據流正常運行的技巧就在于此。 比較 CPU 和負載的趨勢，并真正看一下整個基礎架構并基于此基礎制定計劃，這一點很重要。 * **從產品運營角度來看數據**。 查看新的應用程序，看看它們與以前已實現的功能有何相似之處，以弄清您如何擴展。 僅僅因為有一個新應用程序并不意味著需要添加新的廣告服務器，新的數據節點和新的跟蹤服務器。 這取決于。 許多不同的廣告會發出少量的廣告請求，但發送的數據卻非常荒謬。 趨勢日志可查看數據中的峰值，并查看延遲與峰值之間的關系。 這告訴您系統的不同部分在何處以及如何擴展。 ## 相關文章 * Joe Stein 的 [AllThingsHadoop Twitter Feed](http://www.twitter.com/allthingshadoop) * [大規模解決大數據問題](http://www.medialets.com/tackling-big-data-problems-at-scale/) * 已發布 2010 年第四季度移動人物 [http://www.medialets.com/medialets-data-spotlight-mobile-rich-media-momentum-q4-2011/](http://www.medialets.com/medialets-data-spotlight-mobile-rich-media-momentum-q4-2011/) * [Hadoop，BigData 和 Cassandra 與 Jonathan Ellis 在一起](http://allthingshadoop.com/2010/05/17/hadoop-bigdata-cassandra-a-talk-with-jonathan-ellis/)-HBase 適用于 OLAP，Cassandra 適用于 OLTP * [Twitter 的計劃分析 1000 億條推文](http://highscalability.com/blog/2010/2/19/twitters-plan-to-analyze-100-billion-tweets.html) 真的很棒。 對團隊嘗試使用可用的批處理工具（如 MapReduce）構建自己的實時分析體系結構所面臨的各種挑戰的深入了解。 在 Cloudscale，我們 100％專注于提供實時分析平臺，該平臺不僅是世界上最快的大數據架構，而且可以在具有 10GigE 網絡的商品 Amazon 云集群上運行。 現在，在大數據分析領域處于領先地位的公司可以替代 Medialets 英勇采用的“自己動手”方法，并在此具有高度可擴展性。 隨著實時分析繼續迅速成為主流，本文將成為爆炸性增長的 Web 公司和企業的關注焦點，這些公司正面臨著同樣艱巨的挑戰，并正在尋找工具，技術和方法。 平臺來幫助他們。 真好！ 非常詳細和有用。 對于 mysql 替換，我建議您查看 Infobright（www.infobright.com）。 它是一個柱狀 mysql 插件引擎，可以很好地替代 mysql（它們也具有開源版本）。