这是一篇来自Sharethrough的朋友的客座博客文章，介绍了他们对apachespark的使用是如何不断扩大的。业务挑战Sharethrough是一家广告技术公司，它向出版商和广告商提供本地的、在线的广告软件。原生的、在feed中的广告被设计成与他们所居住的网站的形式和功能相匹配，这在中断式广告效果较差的移动设备上尤为重要。对于出版商来说，在feed上赚钱已经成为他们移动网站和应用程序的主要收入来源。对于广告商来说，与打断横幅广告相比，提要内广告已经被证明能推动更多的品牌提升。Sharethrough的发布者和广告客户技术套件能够优化广告的格式，以便在内容发布者网站和应用程序上无缝放置。这包括四个主要步骤：瞄准正确的用户，为目标优化创意内容，对内容质量评分，允许广告商在实时拍卖中对实际广告投放进行竞标。这四个步骤都是优化广告客户营销投资回报的必要步骤。但这需要以下三个方面的实时能力：创造性优化：从缩略图、标题、描述等各种各样的变体中选择性能最好的内容变体。花销跟踪：广告客户希望根据参数和预算，自动调整（广告用语为"程序化"）实时竞价算法，以实现其竞选目标。Sharethrough平台的一个必要功能是提供内容参与如何消耗广告预算的实时调整。运营监控：当预期行为超出积极或消极规范（例如奥斯卡颁奖典礼期间的交通高峰或降低开支）时，需要及时理解和解决这些问题，以回答"这一事件是预期的和/或可接受的吗？"更好的创意内容和最佳布局转化为更好的消费者参与度和更高的转化率，但Sharethrough需要实时衡量这些优化对业务的影响。技术挑战Sharethrough在Spark之前使用的技术无法适应满足这三个目标所需的短反馈周期。在2010年从Amazon Elastic MapReduce迁移之后，我们在Amazon Web服务上部署了Hadoop的Cloudera发行版，主要用于诸如提取、转换和加载（ETL）等批处理用例。这些批处理运行用于全天间歇性的性能报告和计费，延迟的顺序是小时，而不是分钟。在2013年推出我们的新平台之后，Hadoop显然不太适合Sharethrough日益增长的实时需求。Sharethrough的数据处理管道依赖于apacheflume，根据默认的HDFS块大小以64MB的增量将web服务器日志数据写入HDFS。Sharethrough定期运行一组MapReduce作业，结果输出使用Sqoop写入数据仓库。此设置产生的洞察力延迟超过一小时。Sharethrough无法在这些现有批处理工作流允许的时间之前更新模型。这意味着广告商不能确定他们是否已经优化了内容投资的回报，因为任何决策都是在几小时前做出的。解决方案2013年年中，我们转向了apachespark，尤其是Spark流，因为我们需要一个实时处理点击流数据的系统。在2014年Spark峰会上，我强调了选择Spark的原因："我们发现Spark Streaming非常适合我们，因为它很容易集成到Hadoop生态系统中，功能强大的功能编程API，与我们现有批处理工作流的低摩擦互操作性，以及广泛的生态系统认可。"Spark与我们现有的Hadoop投资兼容。这意味着现有的HDFS文件可以用作Spark计算的输入，Spark可以使用HDFS进行持久存储。同时，Spark使缺乏对Hadoop各种元素的理解的开发人员很容易变得富有成效。虽然Spark与Hadoop集成，但它不需要了解HDFS、MapReduce或各种Hadoop处理引擎。在Sharethrough，很多后端代码都是使用Scala编写的，因此很自然地融入了Spark，因为Spark支持scalaapi。这使得我们的开发人员能够在实际的业务逻辑和数据管道的级别上工作，以指定必须发生的事情。然后Spark会找出如何实现这一点，协调较低级别的任务，如数据移动和恢复。由于使用了Spark API，结果代码非常简洁。我们现在正在使用Spark进行流式处理，但同时使用Spark进行批处理的机会对我们非常有吸引力。Spark提供了一个跨批处理和实时工作负载的统一开发环境和运行时，允许批处理和流式作业之间的重用。这也使得在一次分析中结合实时数据和历史数据变得更加容易。最后，Spark提供的社区支持非常有用，从邮件列表和代码贡献者生态系统一直到Cloudera、MapR和Datastax等提供专业支持的公司。详细部署Sharethrough在10个awsm1.xlarge节点上运行Spark，每天消耗200gb，并使用Mesos进行集群管理。遵循Lambda架构的原则，Sharethrough使用Hadoop作为其架构的批处理层，我们称之为"冷路径"，Spark用于"热路径"实时层。在热路径中，Flume将所有的clickstream数据写入RabbitMQ。接下来，Spark以5秒的（可配置）批处理大小从RabbitMQ读取。结果输出更新了运行我们业务的预测模型。端到端处理在几秒钟内完成，包括Spark处理时间和Flume将数据传输到RabbitMQ所用的时间。由于API的一致性，我们的工程师在本地以简单的批处理模式进行设计和测试，然后在生产中使用流模式运行相同的作业。这使得系统能够实现实时投标所需的优化。接下来，我们的目标是使用Amazon Kinesis简化数据管道的上游组件。Kinesis将取代现有的排队系统，如RabbitMQ，通过连接到所有资源，如web服务器、机器日志或移动设备。Kinesis将形成一个中心枢纽，所有应用程序（包括Spark）都可以从中获取数据。Spark对Kinesis的支持是在2014年9月的Spark 1.1版本中添加的。实现的价值Spark实现了我们的业务目标，即改进创造性优化、支出跟踪和运营监控。Spark使广告更容易按预算投放，这对于可能只持续几天的广告活动尤为重要。可以实时跟踪支出并调整运营问题。例如，如果Sharethrough发布的代码在某些第三方站点上无法很好地呈现，那么现在可以检测到并立即修复。但Spark也为我们的技术团队创造价值。工程师可以比以前更快地进行实时实验并从中学习。代码重用和测试是另一个显著的好处。由于Spark具有更高的抽象级别和统一的编程模型，Sharethrough只需替换几行代码，就可以更轻松地重用一个作业中的代码，以模块化的方式创建另一个作业。这使得代码看起来更干净，更易于调试、测试、重用和维护。此外，我们可以使用单个分析群集来提供实时流处理和批处理分析工作流，而无需支持具有不同延迟要求的两个不同群集的操作和资源开销。要了解更多信息：https://www.youtube.com/watch？v=0QXzKqMPgWQ&index=2&list=PL-x35fyliRwimkfjeg9CEFUSDIE1F7qLS免费试用Databricks。今天就开始吧