# 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（它们也具有开源版本）。