英语原文共 7 页，剩余内容已隐藏，支付完成后下载完整资料
大数据的未来是JavaScript的？
大数据的未来是...... JavaScript？不，认真听取我们的意见。
作为用于构建面向用户的应用程序的集成技术堆栈，JavaScript已经在前端（浏览器中运行的JavaScript）和后端（在Node.js中运行的JavaScript）方面取得了重大进展。在本文中，我们探讨了在前端（例如数据科学家如何与分析工具交互）和后端（如分布式执行基础架构）中使用JavaScript的想法。未来可能...... JavaScript到处都是？ 鉴于来自任何理智的开发人员对这个问题的预期诱导反应，首先让我们先弄清楚这一点:
JavaScript是一种可怕的语言。
JavaScript在很多方面是可怕的。这里不叙述所有方面，我们只提及WAT，Gary Bernhardt的难以置信的有趣谈话。然而，考虑到他研发这种语言只有10天，我们必须除去JavaScript的创造者Brendan Eich的一些失误。我们确信,无论是他还是其他任何人都没有预期到JavaScript成为如此成功和无处不在。任何地方有浏览器,这里就总有JavaScript。在不久的将来，你将连接冰箱或烤面包机?它可能有一个浏览器的用户界面,这意味着它可能会运行JavaScript。
但我们正在超越自我。我们先简要回顾一下计算历史，看看我们是如何到达这里的。
一个简要的历史
在1990年代中期,Sun Microsystems(2010年被Oracle吞并了)想出了一个聪明的口号,“编写一次,随处运行”,描述了Java提供无缝跨平台开发的承诺。在早期的网络,Java的主要卖点之一是它能够运行在浏览器内通过应用程序,所以你可以把服务器端代码以最小的麻烦移植到客户端。这听起来像一个好主意,但它实际上并没有工作。Java应用程序是笨重的,缓慢的,不安全的。最终，这个世界将他们放到了计算历史的垃圾箱，这至少是今天的历史好奇心。
最后，当然，Java没有问题。尽管今天的时髦语言如Scala和Clojure都在关注，但Java虚拟机（JVM）的更广泛的生态系统在服务器上已经深入人心。 借助Hadoop，Spark，Flink和其他大数据平台，JVM已成为大数据 应用程序事实上的执行环境。在客户端，Java通过Android在全球超过十亿个设备上运行。 尽管它没有实现“一次编写，随处运行” 的承诺，但通过任何标准的Java都是非常成功的。
尽管名称相似（这在很大程度上是一种营销策略），但JavaScript与Java完全无关（除了共享C语法）。它最初设计为非专业程序员的轻量级浏览器内解释语言，但多年来JavaScript已成为Web开发的主要语言，实际上，它的霸权没有受到挑战。事实上，今天的前端开发与HTML，CSS和JavaScript是同义词。一开始，JavaScript仅限于那些愚蠢的“看我可以在浏览器中计算析因”和“哦看我可以用按钮点击脚本来改变页面的背景颜色”。今天，用JavaScript编写的Web应用程序提供了与原生桌面应用程序相媲美的用户体验。例如，Gmail包含超过40万行JavaScript（截至2010年）。
在客户端，JavaScript更接近于提供比以往任何时候都只“编写一次，随处运行”的承诺这一事实。证明了这一事实：富含JavaScript的Web应用程序几乎总是“正常工作”。 他们在英特尔芯片上工作。他们在ARM芯片上工作。他们在 Windows，Linux，Mac和其他操作系统上工作。他们在Firefox，Chrome，Safari和其他浏览器上工作。 他们在台式机，笔记本电脑，平板电脑和手机上工作。 当然，跨平台的Web开发仍然是一个艰巨的努力，无休止的垫片和特殊处理奇怪的不兼容性，但对于普通最终用户而言，体验相当无缝。这是一个非常非凡的壮举。
JavaScript服务器入侵
一段时间以来，我们生活在一个稳定的两极世界。JavaScript在客户端的浏览器中统治，Java在服务器上占据支配地位（虽然有来自PHP，Rails，Python和其他堆栈的竞争）。REST接口用作前端和后端之间平台和语言不可知的连接。这一切都好。
然后，一些开发人员不得不通过探索这个问题来解决这个问题：“如果我们也开始在服务器上运行JavaScript，该怎么办？”服务器端JavaScript是一个可以追溯到1995年的想法，不久之后JavaScript就出现在浏览器中，但没有人们认真对待它，直到2000年代中期，开发人员开始探索这个想法。原因之一：最引人注目的是减少前端和后端开发之间的阻抗失配，特别是构建丰富的交互式Web应用程序。一些挑战是技术性的 - 当最终目标是提供无缝用户体验时，但有些是组织性的，在不同语言和环境之间切换时产生的摩擦，用JavaScript编写所有内容打破团队结构，将开发人员分为前后端团队以及所有相关的孤岛沟通障碍。
随着高性能JavaScript引擎的出现，所有这些都变得切实可行，最引人注目的是Google的开源V8 （https://developers.google.co m/v8/）。一切都与Node.js一起使用，这是用服器端JavaScript的流行的开源运行时环境。
Node.js有许多引人注目的成功案例。2012年，LinkedIn移动平台从后端运行的Ruby on Rails转移到Node.js，并且能够用三个服 器替换30台服务器，以提供相同的流量。5Netflix，PayPal，Uber和其他许多公司Node.js的用户Node.js的开发与当今流行的“微服务”架构很好地衔接，Docker（www.docker.com）的出现简化了部署的许多方面。所有这些技术都很好地结合在一起，为构建面向用户的应用程序提供了一个集成堆栈。
在继续之前，还有另一个值得一提的历史脚注。 除了小应用程 序之外，还有另一个共同努力推动Java到客户端。最初于2006年发布的Google Web Toolkit（GWT; www.gwtproject.org ）是一个允许用户使用Java开发Web应用程序的框架。如果有人记得这件事的话，它会为命运多舛的谷歌浪潮提供动力。对于所有的意图和目的，GWT都是死的。有些人认为，GWT将Java交叉编译为部署在前端的JavaScript，因此Java尝试侵入浏览器的尝试可能最好被描述为特洛伊木马。
JavaScript和大数据
到目前为止，我们（希望）已经确定，面向用户的应用程序，采用纯粹的JavaScript堆栈（前端和后端）是一个相当有吸引力的选择。现在，让我们来看看这篇文章的激进主张 - 在前端和后端都采用JavaScript来处理大数据应用程序也有类似的令人信服的理由。与面向用户的应用程序相比，大数据应用程序是面向内部的，主要由组织的数据科学家使用（也可能通过仪表板提供更高级别的pointy-hair 类型）。 需要说明的是，“前端”是指数据科学家用于访问大型数据集的分析功能的工具，“后端”指的是分布式处理基础设施（例如Hadoop和Spark），它们提供了这些工具能力。
数据科学家的前端是什么？传统上，它只是一个外壳。在过去，这可能是Pig的“Grunt”外壳或Hive外壳;但最近，它可能是Spark壳。良好的旧命令行界面！
然而，变化正在酝酿。基于浏览器的笔记本电脑（如Jupyter; http://jupyter.org）近年来在数据科学家中受到极大的欢迎，原因如下：代码和执行输出的紧密集成将分析过程及其产品提升为一等公民，因为笔记本本身可以被序列化，重新加载和共享。能够操作，重新排列和插入代码片段（在单元格中）与数据科学的迭代本质以及广泛的分析任务很好地匹配。随着基于浏览器的笔记本电脑和可扩展数据分析平台的无缝集成，基于浏览器的笔记本中编写的代码可以在集群上执行，并且结果可以在笔记本电脑中进一步处理。商业Databricks平台代表了一个重大 的预测，即基于浏览器的大数据分析将成为未来的方式。这意味着浏览器可能成为shell。请记住，JavaScript在浏览器中占统治地位。
此外，数据科学的最终产品往往是一个可视化的故事。在很多情况下，这些可视化是互动的，给数据科学家（及其同事，经理，客户等）提供了一个旋转旋钮并拖动滑块来探索数据的机会。换句话说，数据科学的“输出”实际上是一个定制的Web应用程序，它封装了分析结果！目前推荐的可视化工具是D3.js （https://d3js.org）。猜猜看，这也是JavaScript。换句话说，最终大数据也面向用户，只有一组不同的用户。
目前，我们有一个“规范”的大数据分析流水线，它看起来像这样：在数据中心（后端）运行的Spark群集与可能在浏览器中运行的Spark客户端（Scala，Python或R）进行对话（笔记本），以某种方式连接到Web应用程序（交互式D3.js可视化）最终的分析产品。Spark集群与Scala / Python / R之间的连接相当完善，但今天与D3.js的连接可能通过JavaScript对象表示法（JSON）或逗号分隔值（CSV）转储来完成，这很笨拙。为什么不削减中间人，只使用JavaScript？
让我们尝试通过更详细地检查现代数据科学工作流程来改进这一论点，暂时搁置最终的可视化步骤。众所周知，数据科学家的工作，特别是在探索性任务的情况下，是高度迭代的，他们从许多不同的角度“戳”数据。通常，这些任务专注 于一小部分数据，例如，数据仓库可存储六个月的日志数据，但数据科学家只对上周的数据感兴趣。以下是她可以完成任务的一些方法：
（1）她反复查询整个数据集，但是筛选感兴趣的子集。实现低查询延迟完全取决于分析引擎对不需要的工作进行适当的优化，这取决于数据的物理存储（如何进行分区，压缩等）。
（2）她实现了感兴趣的数据。在分析数据库中，这通常涉及到选择临时表或创建物化视图; 在Spark中，这通常涉及将中间结果写入Hadoop分布式文件系统（HDFS）。随后的查询将针对这个较小的数据集提出。
（3）她实现了感兴趣的数据，然后在本地复制数据（例如，她的笔记本电脑）以供进一步操作。这可能涉及在本地运行Spark或将数据转储到本地关系数据库，然后发出其他查询。
所有三种方法都存在问题。首先，分析引擎可能不够高效，无法有效优化查询，或者查询执行速度可能存在固有限制。举一个简单的例子，如果数据集是散列分区的，那么拉取最近的记录可能仍然会涉及大扇出的分布式扫描。经过标准优化（如柱状布局和谓词下推）后，网络延迟和协调开销开始成为瓶颈。
在第二种和第三种情况下，由于分析引擎（如Spark）的启动成本在实际处理时间中占主导地位，因此对物化数据的查询可能不再有效运行。对于某些数据集，使用sed，awk等可能更容易在命令行上进行争夺。根据定义，对小数据集的有效查询并不是大数据处理平台优化的场景。
在第二种情况下，实现临时数据会产生一系列不同的挑战。在分析数据库中，创建实体化视图可能需要提升特权（并非授予所有人），而创建临时表的能力则会带来一系列不同的数据管理难题。例如，谁（数据科学家自己？）或什么（自动化流程？）“清理”了51个表，命名为tmp或test的变体？Spark也是如此：现在查看您的 HDFS主目录并计算所有名为test1，tmp42等的目录。现在尝试记住这些中间结果是如何生成的。
第三种情况有一个尴尬的工作流程的缺点。对于关系数据库，这涉及到数据科学家将数据复制到她的笔记本电脑并在运行其他查询之前在本地摄取数据。 此外，这种方法基本上需要维护两个独立的分析堆栈（一个在客户端，一个在服务器上）。说，她正在她的笔记本电脑上使用Spark的一个新的不稳定分支来测试一项新功能（尚未推出到产品中），但在新分支中，API略有改变。她的组织在Spark上部署的自定义机器学 习库如何运行？集群上运行的版本与笔记本上运行的版本相同？
现在想象一个替代方案：如果我们能够像Spark.js一样，在JavaScript中透明地编写Spark代码，会怎么样？从根本上说，这与PySpark没什么不同，PySpark基于Py4J（www.py4j.org），Py4J是一个使Python程序在Python解释器中运行的桥梁，可以动态访问JVM中的Java对象。同样，Spark.js可以在 Rhino 的帮 助下编写（www.mozilla.org/），一个完全用Java编写的JavaScript的开源实现。
在当前的Spark API中，“collect”和相关的方法实现了一个弹性分布式数据集（RDD），其结果被发送到客户端。在Spark.js中，JVM对象可以透明地转换为本地JavaScript对象，随时可以进行操作并与D3.js无缝集成以进行可视化。 所有这些都可以在浏览器（任何平台上的任何符合标准的浏览器）上运行，也可以在Node.js中运行。
等等，它会变得更好。此时，Node.js已经运行了面向用户的应用程序，对吧？请记住复杂的提取，转换和加载（ETL）管道，以便将日志数据泵入Kafka （HTTP：//kafka.apache组织），最终HDFS？现在可以用JavaScript编写所有用于数据清理、模式转换等的自定义代码。开发人员经常用JSON写日志消息，对吧？请注意JSON中的“J”代表什么！所以，通过JavaScript中的所有内容，您可以保留您已经为面向用户的应用程序所做的工作提供了便利，但可以与数据收集和分析堆栈实现无缝集成。这是从减摩视角和潜在的性能角度来看的一个胜利， JavaScript中的ETL管道可能会减少不必要的数据转换量，从而减少延迟并提高吞吐量。尽管文本JSON作为存储格式并不是特别有效（即使是压缩），但物理布局可以使用Parquet（http://parquet.io）轻松优化，Parquet（http://parquet.io）基本上是围绕J
全文共10275字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[12012]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
