软件外包公司的优势和劣势,郑州网站优化顾问,佛山市做网站的,网站分析欣赏迁移到Apache Spark之前需要了解的5件事 似乎每个人都只是在谈论最热门的新技术#xff0c;而忽略采用它的真正含义。 但这是自然的#xff0c;对吧#xff1f; 新功能和承诺胜过其他一切#xff0c;而艰巨的挑战和决定被抛在一边。 这次不行。 软件架构很难#xf… 迁移到Apache Spark之前需要了解的5件事 似乎每个人都只是在谈论最热门的新技术而忽略采用它的真正含义。 但这是自然的对吧 新功能和承诺胜过其他一切而艰巨的挑战和决定被抛在一边。 这次不行。 软件架构很难权衡取胜是游戏的名称。 在本文中我们想退后一步看看执行从头开始转向Spark的决定的真正含义。 非常感谢Kenshoo的开发人员和系统架构师Tzach Zohar 他在本博文中与我们分享了他的经验。 为什么还要烦恼呢 如果您从一个可以从分布式数据分析中受益的全新项目开始无论是批处理分析还是精简分析Spark都已将其优势确立为MapReduce的最佳实现。 主要是因为它使用内存处理的方式。 否则如果您在一台服务器上获得了所需的吞吐量并且使用的数据不会超出该范围那么最好避免使用分布式的复杂性。 请注意我们甚至一次都没有说过大数据。 哦 此外Spark具有一个很棒且易于使用的机器学习库。 Spark与Hadoop 尽管您的起点很可能是您已经拥有的现有解决方案但这会使事情变得多余。 我们将把重点放在那上面。 在难以应对规模的数据库之上从Hadoop或本地解决方案迁移。 性能的提高最终可以减少硬件成本提高生产力或者实际上只是摆脱尝试做的事情的唯一方法。 最大的好处来自批处理分析的角度因此如果这是您的用例–升级集群将变得更加紧迫。 就Kenshoo而言单服务器MySQL解决方案已绰绰有余。 但是随着公司的发展和几年的过去这已经不够了–每天要处理成千上万条记录数百张表较大记录上的十亿条记录以及TB级的数据。 不再是堪萨斯州了 。 有一点是您无法进行所有优化甚至TokuDB之类的高性能存储引擎也无法实现。 您最终要做的是在类固醇上安装了一个突变MySQL。 在海岸的另一端有Spark公司它解决了各种各样的问题这些新问题却是长期存在的原则并得到社区的Swift采用和许多积极的信号。 1. HDFS与Cassandra与S3 您为Apache Spark选择的存储服务器应该反映出您对系统最看重的东西。 这里的3个常见选项是Hadoop的HDFSApache Cassandra和Amazon的S3。 当数据局部性不是关键时S3适合非常特定的用例。 例如每天运行一次的作业或者实际上不需要任何数据和处理能力来共享机器的任何事情。 没有紧迫的工作。 至于HDFS与Cassandra的问题运行HDFS的硬件成本较低因为它旨在解决更简单的用例。 多低 高达10倍。 主要区别在于HDFS解决了分布式文件系统运行的问题而Cassandra专门设计为高吞吐量键值存储。 尽管成本较高但Cassandra在交互式流数据分析方面处于优势地位–与运行批处理作业相反。 您可以说HDFS喜欢大文件而Cassandra不必加载所有数据仅使用所需的数据即可访问 S3 –非紧急批处理作业。 Cassandra –非常适合流数据分析并且对批处理作业有过高的要求。 HDFS –非常适合批处理作业而不会影响数据局部性。 2.绿地与重构 好吧所以您现在决定迁移到Spark您应该从全新的项目开始还是基于当前应用程序进行重构 每个人都有自己的警告Kenshoo决定放弃绿地之路以重构其当前系统。 该决定缩小为4个因素 避免移动目标场景 –从头开始构建新系统需要花费时间和数月的开发时间。 在此期间旧系统也在发生变化因此您的规范实际上是随时间变化的移动目标。 零差异容限 –新系统应达到与旧系统相同的结果对吗 听起来很简单的过程是一个变相的问题。 经过多年的发展针对特定分析过程的各种怪癖和定制已被硬编码到较旧的应用程序中。 例如某些假设四舍五入的结果以及来自各个客户的请求–已经创建了一个复杂的分析过程很难从头开始重新创建。 代码是唯一的规范 –文档很有可能……不存在。 如果确实存在则很可能不能反映系统的当前状态。 这是您可能与代码中的那些黑角有关的示例 “不应该”发生的事情但是它发生了吗 测试重用 –您当前的测试与较早的实现结合在一起并采用了不同的设置。 这里的另一个任务是重写它们以匹配新的实现。 底线在这种情况下重构而不是完全重新启动是最有意义的。 3.重构挑战 选择重构路径还面临挑战未经测试的旧代码与其他系统组件的紧密耦合以及新体系结构的范式转换。 从类似的Hadoop架构进行切换比在单节点应用程序上进入分布式系统路径更容易。 有许多新的知识要学习要有调整的过程还有很多摩擦。 不论是否新建这都是艰巨的任务但是如果您确定这是值得的–隧道尽头便是一盏灯。 在Kenshoo的案例中他们的任务是从一个拥有8年历史的庞大系统中释放瓶颈聚合器组件。 聚合器偶尔对数据执行批处理并通过不同的键将其分组。 底线在移动之前预先了解您的薄弱环节并确保针对新实施中的关键路径具有解决方案。 4.解决方法 4.1。 核心业务规则至上 重构的主要好处之一当然是代码重用。 构建新系统的第一步是首先遵循核心业务规则并从中创建一个独立的jar。 这些方法被重构为Java静态方法以避免Spark中的序列化问题。 4.2。 Dropwizard指标和复杂的遗留代码 继续前进还记得“不应该发生”的例子吗 Kenshoo使用Dropwizard Metrics计数器进行装配 而且你知道什么。 它确实发生了很多 发生…..“这不应该发生” 底线事实证明使用度量标准来度量遗留代码中的未知数是一个功能强大的工具它可以将“隐藏”功能转变为明确的经过良好记录和经过良好测试的功能。 4.3。 本地模式测试 为了应对测试挑战Kenshoo充分利用了Spark的本地模式并从中汲取了灵感–在新的聚合组件内部创建了一个类似Spark的嵌入式实例。 此外他们然后采用了这个新组件并将其嵌入到旧系统中重用了较早的测试并确保新系统满足所有要求 4.4。 石墨“ diffRecorder” 除了本地模式测试之外最后的领域是测试生产中的实际数据并查看Spark结果是否与旧系统的结果匹配。 为此实现了与Graphite可视化挂钩的“ diffRecorder”。 差异记录器将这两个版本有所不同的每个实际输入表示为Graphite Metric石墨度量并指出与新实现不一致的确切输入。 生成的数据有助于了解需要进行哪些调整以匹配旧系统或发现系统中的隐藏故障。 顺便说一句要了解有关Graphite的更多信息可以查看有关为系统选择最佳Graphite体系结构的文章 。 Kenshoo的Graphite仪表板 5.火花监控 Spark与Graphite进行了很好的集成您可以在其中绘制任何您想要的图形。 除此之外这里的第二个工具是Spark Web UI用于查看您的作业和性能指标。 任何严肃的Spark部署都需要在性能和监视方面投入大量精力。 这可能会成为一个非常棘手的问题您需要熟悉内部结构才能调整系统。 为Spark编写代码很容易但是性能又增加了另一层复杂性。 从这个意义上讲很容易在这里出错并产生错误的代码。 查看这篇文章我们探讨了Taboola的Spark监视架构 以及为什么他们要继续将Takipi添加到其监视堆栈中。 推荐的Spark入门资源 基本文档简短直接可以完成工作。 有关Spark性能调整的更高级的主题主要可以在以前的Spark峰会的录制演讲中找到。 结论 存储重构技术监视测试重用和一致的结果–我们希望您发现所提供的解决方案有用并且知道如何在需要时应用它们。 向新技术的过渡非常困难。 除了学习曲线外它们还使您更容易出错也使您更有可能在半夜接听电话以解决某些关键的生产问题。 针对这种情况我们启动了Takipi对Spark的错误分析 。 我们要再次感谢Kenshoo的Tzach Zohar与我们分享他的经验 翻译自: https://www.javacodegeeks.com/2015/08/apache-spark-5-pitfalls-you-must-solve-before-changing-your-architecture.html
