Spark SQL 是 Spark 生态系统中处理结构化格式数据的模块。它在内部使用 Spark Core API 进行处理，但对用户的使用进行了抽象。这篇文章深入浅出地告诉你 Spark SQL 3.x 的新内容。有了 Spark SQL，用户可以编写 SQL 风格的查询。这对于精通结构化查询语言或 SQL 的广大用户群体来说，基本上是很有帮助的。用户也将能够在结构化数据上编写交互式和临时性的查询。Spark SQL 弥补了 弹性分布式数据集 resilient distributed data sets （RDD）和关系表之间的差距。RDD 是 Spark 的基本数据结构。它将数据作为分布式对象存储在适合并行处理的节点集群中。RDD 很适合底层处理，但在运行时很难调试，程序员不能自动推断 模式 schema 。另外，RDD 没有内置的优化功能。Spark SQL 提供了 数据帧 DataFrame 和数据集来解决这些问题。Spark SQL 可以使用现有的 Hive 元存储、SerDes 和 UDF。它可以使用 JDBC/ODBC 连接到现有的 BI 工具。数据源大数据处理通常需要处理不同的文件类型和数据源（关系型和非关系型）的能力。Spark SQL 支持一个统一的数据帧接口来处理不同类型的源，如下所示。文件：CSVTextJSONXMLJDBC/ODBC：MySQLOraclePostgres带模式的文件：AVROParquetHive 表：Spark SQL 也支持读写存储在 Apache Hive 中的数据。通过数据帧，用户可以无缝地读取这些多样化的数据源，并对其进行转换/连接。Spark SQL 3.x 的新内容在以前的版本中（Spark 2.x），查询计划是基于启发式规则和成本估算的。从解析到逻辑和物理查询计划，最后到优化的过程是连续的。这些版本对转换和行动的运行时特性几乎没有可见性。因此，由于以下原因，查询计划是次优的：缺失和过时的统计数据次优的启发式方法错误的成本估计Spark 3.x 通过使用运行时数据来迭代改进查询计划和优化，增强了这个过程。前一阶段的运行时统计数据被用来优化后续阶段的查询计划。这里有一个反馈回路，有助于重新规划和重新优化执行计划。自适应查询执行（AQE）查询被改变为逻辑计划，最后变成物理计划。这里的概念是“重新优化”。它利用前一阶段的可用数据，为后续阶段重新优化。正因为如此，整个查询的执行要快得多。AQE 可以通过设置 SQL 配置来启用，如下所示（Spark 3.0 中默认为 false）：spark.conf.set(“spark.sql.adaptive.enabled”,true) 动态合并“洗牌”分区Spark 在“ 洗牌 shuffle ”操作后确定最佳的分区数量。在 AQE 中，Spark 使用默认的分区数，即 200 个。这可以通过配置来启用。spark.conf.set(“spark.sql.adaptive.coalescePartitions.enabled”,true) 动态切换连接策略广播哈希是最好的连接操作。如果其中一个数据集很小，Spark 可以动态地切换到广播连接，而不是在网络上“洗牌”大量的数据。动态优化倾斜连接如果数据分布不均匀，数据会出现倾斜，会有一些大的分区。这些分区占用了大量的时间。Spark 3.x 通过将大分区分割成多个小分区来进行优化。这可以通过设置来启用：spark.conf.set(“spark.sql.adaptive.skewJoin.enabled”,true) 其他改进措施此外，Spark SQL 3.x还支持以下内容。动态分区修剪3.x 将只读取基于其中一个表的值的相关分区。这消除了解析大表的需要。连接提示如果用户对数据有了解，这允许用户指定要使用的连接策略。这增强了查询的执行过程。兼容 ANSI SQL在兼容 Hive 的早期版本的 Spark 中，我们可以在查询中使用某些关键词，这样做是完全可行的。然而，这在 Spark SQL 3 中是不允许的，因为它有完整的 ANSI SQL 支持。例如，“将字符串转换为整数”会在运行时产生异常。它还支持保留关键字。较新的 Hadoop、Java 和 Scala 版本从 Spark 3.0 开始，支持 Java 11 和 Scala 2.12。 Java 11 具有更好的原生协调和垃圾校正，从而带来更好的性能。 Scala 2.12 利用了 Java 8 的新特性，优于 2.11。Spark 3.x 提供了这些现成的有用功能，而无需开发人员操心。这将显着提高 Spark 的整体性能。via: https://www.opensourceforu.com/2022/05/structured-data-processing-with-spark-sql/作者：Phani Kiran 选题：lkxed 译者：geekpi 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
#新闻拍一拍# 谷歌和微软在 Chromium 上相爱相杀
谷歌和微软在 Chromium 上相爱相杀微软 Edge 技术可以帮助用户在 Windows 上减少高达 27% 的内存使用，谷歌 Chrome 也开始采用了这项技术。微软对 Chromium 的贡献是巨大的，谷歌也提到了微软做出的贡献。不过两者还在彼此挖墙脚：谷歌会向 Edge 用户使用谷歌搜索、Gmail 和谷歌文档时展示广告，说他们应该切换到 Chrome。微软同样也会告诉 Outlook 用户，他们应该从 Chrome 切换到 Edge。来源：cnBeta.COM拍一拍：原本以为 Edge 采用 Chromium 内核是一种投降，现在看起来，事情似乎不是这样的~微软宣布 WSL2 对 GPU 的初始支持在微软最新发布的 Windows Insider 预览版本中，WSL2 获得了 GPU 计算支持。这意味着 Linux 二进制文件可以利用 GPU 资源，在 WSL 中进行机器学习、AI 开发或是数据科学等工作。最初的 GPU 计算功能将提供两种方案：NVIDIA CUDA 和 DirectML 。来源：开源中国拍一拍：一方面心喜于微软提供越来越强大的功能，另外一方面也担心这种重军投入对开源社区的碾压式优势。Apache Spark 3.0 发布Databricks 上周发布了 Apache Spark 3.0，并将此作为新版 Databricks Runtime 7.0 的一部分。重要变化：与 Spark 2.4 相比，TPC-DS 的性能提升了 2 倍，主要通过自适应查询执行、动态分区修剪和其他优化实现；兼容 ANSI SQL；针对 pandas API 的重大改进，包括 Python 类型提示和额外的 pandas UDF；改进 Python 错误处理，简化 PySpark 异常提醒；调用 R 语言自用户定义函数的速度可提高 40 倍；解决了 Jira 上 3400 多个 issue。详情参见发布说明。红帽和 Fedora 社区共同改进模块化，将应用到 RHEL 9 模块化 Modularity 作为传统 RPM 打包的替代方案，允许某个软件包的多个版本被分发到 Fedora。简单来说，在传统发布策略的基础上，Fedora 仍将推出标准发行版，但同时搭载一组提供流行软件替代版本的模块。RHEL 9 计划于 2023~2024 推出。来源：开源中国拍一拍：这是除了容器技术之外，打包技术的一大进步。
60 TB 数据：Facebook 是如何大规模使用 Apache Spark 的
Facebook 经常使用数据驱动的分析方法来做决策。在过去的几年，用户和产品的增长已经需要我们的分析工程师一次查询就要操作数十 TB 大小的数据集。我们的一些批量分析执行在古老的 Hive 平台（ Apache Hive 由 Facebook 贡献于 2009 年）和 Corona 上——这是我们定制的 MapReduce 实现。Facebook 还不断增加其对 Presto 的用量，用于对几个包括 Hive 在内的内部数据存储的 ANSI-SQL 查询。我们也支持其他分析类型，比如 图数据库处理 （ graph processing ） 和机器学习（Apache Giraph）和流（例如：Puma、Swift 和 Stylus）。同时 Facebook 的各种产品涵盖了广泛的分析领域，我们与开源社区不断保持沟通，以便共享我们的经验并从其他人那里学习。Apache Spark 于 2009 年在加州大学伯克利分校的 AMPLab 由 Matei Zaharia 发起，后来在2013 年贡献给 Apache。它是目前增长最快的数据处理平台之一，由于它能支持流、批量、命令式（RDD）、声明式（SQL）、图数据库和机器学习等用例，而且所有这些都内置在相同的 API 和底层计算引擎中。Spark 可以有效地利用更大量级的内存，优化整个 流水线 （ pipeline ） 中的代码，并跨任务重用 JVM 以获得更好的性能。最近我们感觉 Spark 已经成熟，我们可以在一些批量处理用例方面把它与 Hive 相比较。在这篇文章其余的部分，我们讲述了在扩展 Spark 来替代我们一个 Hive 工作任务时的所得到经验和学习到的教训。用例：实体排名的特征准备Facebook 会以多种方式做实时的 实体 （ entity ） 排名。对于一些在线服务平台，原始特征值是由 Hive 线下生成的，然后将数据加载到实时关联查询系统。我们在几年前建立的基于 Hive 的老式基础设施属于计算资源密集型，且很难维护，因为其流水线被划分成数百个较小的 Hive 任务。为了可以使用更加新的特征数据和提升可管理性，我们拿一个现有的流水线试着将其迁移至 Spark。以前的 Hive 实现基于 Hive 的流水线由三个逻辑 阶段 （ stage ） 组成，每个阶段对应由 entity\_id 划分的数百个较小的 Hive 作业，因为在每个阶段运行大型 Hive 作业 （ job ） 不太可靠，并受到每个作业的最大 任务 （ task ） 数量的限制。这三个逻辑阶段可以总结如下：过滤出非产品的特征和噪点。在每个（entity\_id, target\_id）对上进行聚合。将表格分割成 N 个分片，并通过自定义二进制文件管理每个分片，以生成用于在线查询的自定义索引文件。基于 Hive 的流水线建立该索引大概要三天完成。它也难于管理，因为该流水线包含上百个分片的作业，使监控也变得困难。同时也没有好的方法来估算流水线进度或计算剩余时间。考虑到 Hive 流水线的上述限制，我们决定建立一个更快、更易于管理的 Spark 流水线。Spark 实现全量的调试会很慢，有挑战，而且是资源密集型的。我们从转换基于 Hive 流水线的最资源密集型的第二阶段开始。我们以一个 50GB 的压缩输入例子开始，然后逐渐扩展到 300GB、1TB，然后到 20TB。在每次规模增长时，我们都解决了性能和稳定性问题，但是实验到 20TB 时，我们发现了最大的改善机会。运行 20TB 的输入时，我们发现，由于大量的任务导致我们生成了太多输出文件（每个大小在 100MB 左右）。在 10 小时的作业运行时中，有三分之一是用在将文件从阶段目录移动到 HDFS 中的最终目录。起初，我们考虑两个方案：要么改善 HDFS 中的批量重命名来支持我们的用例，或者配置 Spark 生成更少的输出文件（这很难，由于在这一步有大量的任务 — 70000 个）。我们退一步来看这个问题，考虑第三种方案。由于我们在流水线的第二步中生成的 tmp\_table2 表是临时的，仅用于存储流水线的中间输出，所以对于 TB 级数据的单一读取作业任务，我们基本上是在压缩、序列化和复制三个副本。相反，我们更进一步：移除两个临时表并整合 Hive 过程的所有三个部分到一个单独的 Spark 作业，读取 60TB 的压缩数据然后对 90TB 的数据执行 重排 （ shuffle ） 和 排序 （ sort ） 。最终的 Spark 作业如下：对于我们的作业如何规划 Spark？当然，为如此大的流水线运行一个单独的 Spark 任务，第一次尝试没有成功，甚至是第十次尝试也没有。据我们所知，从 重排 （ shuffle ） 的数据大小来说，这是现实世界最大的 Spark 作业（Databrick 的 PB 级排序是以合成数据来说）。我们对核心 Spark 基础架构和我们的应用程序进行了许多改进和优化使这个作业得以运行。这种努力的优势在于，许多这些改进适用于 Spark 的其他大型作业任务，我们将所有的工作回馈给开源 Apache Spark 项目 - 有关详细信息请参阅 JIRA。下面，我们将重点讲述将实体排名流水线之一部署到生产环境所做的重大改进。可靠性修复处理频繁的节点重启为了可靠地执行长时间运行作业，我们希望系统能够容错并可以从故障中恢复（主要是由于平时的维护或软件错误导致的机器重启所引发的）。虽然 Spark 设计为可以容忍机器重启，但我们发现它在足够强健到可以处理常见故障之前还有各种错误/问题需要解决。使 PipedRDD 稳健的 获取 （ fetch ） 失败（SPARK-13793）：PipedRDD 以前的实现不够强大，无法处理由于节点重启而导致的获取失败，并且只要出现获取失败，该作业就会失败。我们在 PipedRDD 中进行了更改，优雅的处理获取失败，使该作业可以从这种类型的获取失败中恢复。可配置的最大获取失败次数（SPARK-13369）：对于这种长时间运行的作业，由于机器重启而引起的获取失败概率显着增加。在 Spark 中每个阶段的最大允许的获取失败次数是硬编码的，因此，当达到最大数量时该作业将失败。我们做了一个改变，使它是可配置的，并且在这个用例中将其从 4 增长到 20，从而使作业更稳健。减少集群重启混乱：长时间运行作业应该可以在集群重启后存留，所以我们不用等着处理完成。Spark 的可重启的 重排 （ shuffle ） 服务功能可以使我们在节点重启后保留 重排 （ shuffle ） 文件。最重要的是，我们在 Spark 驱动程序中实现了一项功能，可以暂停执行任务调度，所以不会由于集群重启而导致的过多的任务失败，从而导致作业失败。其他的可靠性修复响应迟钝的驱动程序（SPARK-13279）：在添加任务时，由于 O(N ^ 2) 复杂度的操作，Spark 驱动程序被卡住，导致该作业最终被卡住和死亡。 我们通过删除不必要的 O(N ^ 2) 操作来修复问题。过多的驱动 推测 （ speculation ） ：我们发现，Spark 驱动程序在管理大量任务时花费了大量的时间推测。 在短期内，我们禁止这个作业的推测。在长期，我们正在努力改变 Spark 驱动程序，以减少推测时间。由于大型缓冲区的整数溢出导致的 TimSort 问题（SPARK-13850）：我们发现 Spark 的不安全内存操作有一个漏洞，导致 TimSort 中的内存损坏。 感谢 Databricks 的人解决了这个问题，这使我们能够在大内存缓冲区中运行。调整重排（shuffle）服务来处理大量连接：在重排阶段，我们看到许多执行程序在尝试连接重排服务时超时。 增加 Netty 服务器的线程（spark.shuffle.io.serverThreads）和积压（spark.shuffle.io.backLog）的数量解决了这个问题。修复 Spark 执行程序 OOM（SPARK-13958）（deal maker）：首先在每个主机上打包超过四个 聚合 （ reduce ） 任务是很困难的。Spark 执行程序会内存溢出，因为排序程序（sorter）中存在导致无限增长的指针数组的漏洞。当不再有可用的内存用于指针数组增长时，我们通过强制将数据溢出到磁盘来修复问题。因此，现在我们可以每主机运行 24 个任务，而不会内存溢出。性能改进在实施上述可靠性改进后，我们能够可靠地运行 Spark 作业了。基于这一点，我们将精力转向与性能相关的项目，以充分发挥 Spark 的作用。我们使用 Spark 的指标和几个分析器来查找一些性能瓶颈。我们用来查找性能瓶颈的工具Spark UI 指标：Spark UI 可以很好地了解在特定阶段所花费的时间。每个任务的执行时间被分为子阶段，以便更容易地找到作业中的瓶颈。Jstack：Spark UI 还在执行程序进程上提供了一个按需分配的 jstack 函数，可用于中查找热点代码。Spark 的 Linux Perf / 火焰图 （ Flame Graph ） 支持：尽管上述两个工具非常方便，但它们并不提供同时在数百台机器上运行的作业的 CPU 分析的聚合视图。在每个作业的基础上，我们添加了支持 Perf 分析（通过 libperfagent 的 Java 符号），并可以自定义采样的持续时间/频率。使用我们的内部指标收集框架，将分析样本聚合并显示为整个执行程序的火焰图。性能优化修复 排序程序 （ sorter ） 中的内存泄漏（SPARK-14363）（30％ 速度提升）：我们发现了一个问题，当任务释放所有内存页时指针数组却未被释放。 因此，大量的内存未被使用，并导致频繁的溢出和执行程序 OOM。 我们现在进行了改变，正确地释放内存，并使大的分类运行更有效。 我们注意到，这一变化后 CPU 改善了 30％。Snappy 优化（SPARK-14277）（10％ 速度提升）：有个 JNI 方法（Snappy.ArrayCopy）在每一行被读取/写入时都会被调用。 我们发现了这个问题，Snappy 的行为被改为使用非 JNI 的 System.ArrayCopy 代替。 这一改变节约了大约 10％ 的 CPU。减少重排的写入延迟（SPARK-5581）（高达 50％ 的速度提升）：在 映射 （ map ） 方面，当将重排数据写入磁盘时，映射任务为每个分区打开并关闭相同的文件。 我们做了一个修复，以避免不必要的打开/关闭，对于大量写入重排分区的作业来说，我们观察到高达 50％ 的 CPU 提升。解决由于获取失败导致的重复任务运行问题（SPARK-14649）：当获取失败发生时，Spark 驱动程序会重新提交已运行的任务，导致性能下降。 我们通过避免重新运行运行的任务来解决这个问题，我们看到当获取失败发生时该作业会更加稳定。可配置 PipedRDD 的缓冲区大小（SPARK-14542）（10％ 速度提升）：在使用 PipedRDD 时，我们发现将数据从分类程序传输到管道进程的默认缓冲区的大小太小，我们的作业要花费超过 10％ 的时间复制数据。我们使缓冲区大小可配置，以避免这个瓶颈。缓存索引文件以加速重排获取（SPARK-15074）：我们观察到重排服务经常成为瓶颈， 减少程序 （ reducer ） 花费 10％ 至 15％ 的时间等待获取 映射 （ map ） 数据。通过深入了解问题，我们发现，重排服务为每个重排获取打开/关闭重排索引文件。我们进行了更改以缓存索引信息，以便我们可以避免文件打开/关闭，并重新使用该索引信息以便后续获取。这个变化将总的重排时间减少了 50％。降低重排字节写入指标的更新频率（SPARK-15569）（高达 20％ 的速度提升）：使用 Spark 的 Linux Perf 集成，我们发现大约 20％ 的 CPU 时间正在花费探测和更新写入的重排字节写入指标上。可配置排序程序（sorter）的初始缓冲区大小（SPARK-15958）（高达 5％ 的速度提升）： 排序程序 （ sorter ） 的默认初始缓冲区大小太小（4 KB），我们发现它对于大型工作负载而言非常小 - 所以我们在缓冲区耗尽和内容复制上浪费了大量的时间。我们做了一个更改，使缓冲区大小可配置，并且缓冲区大小为 64 MB，我们可以避免大量的数据复制，使作业的速度提高约 5％。配置任务数量：由于我们的输入大小为 60T，每个 HDFS 块大小为 256M，因此我们为该作业产生了超过 250,000 个任务。尽管我们能够以如此多的任务来运行 Spark 作业，但是我们发现，当任务数量过高时，性能会下降。我们引入了一个配置参数，使 映射 （ map ） 输入大小可配置，因此我们可以通过将输入分割大小设置为 2 GB 来将该数量减少 8 倍。在所有这些可靠性和性能改进之后，我们很高兴地报告，我们为我们的实体排名系统之一构建和部署了一个更快、更易于管理的流水线，并且我们提供了在 Spark 中运行其他类似作业的能力。Spark 流水线与 Hive 流水线性能对比我们使用以下性能指标来比较 Spark 流水线与 Hive 流水线。请注意，这些数字并不是在查询或作业级别的直接比较 Spark 与 Hive ，而是比较使用灵活的计算引擎（例如 Spark）构建优化的流水线，而不是比较仅在查询/作业级别（如 Hive）操作的计算引擎。CPU 时间：这是从系统角度看 CPU 使用。例如，你在一个 32 核机器上使用 50% 的 CPU 10 秒运行一个单进程任务，然后你的 CPU 时间应该是 32 * 0.5 * 10 = 160 CPU 秒。CPU 预留时间：这是从资源管理框架的角度来看 CPU 预留。例如，如果我们保留 32 位机器 10 秒钟来运行作业，则CPU 预留时间为 32 * 10 = 320 CPU 秒。CPU 时间与 CPU 预留时间的比率反映了我们如何在集群上利用预留的CPU 资源。当准确时，与 CPU 时间相比，预留时间在运行相同工作负载时可以更好地比较执行引擎。例如，如果一个进程需要 1 个 CPU 的时间才能运行，但是必须保留 100 个 CPU 秒，则该指标的效率要低于需要 10 个 CPU 秒而仅保留 10 个 CPU 秒来执行相同的工作量的进程。我们还计算内存预留时间，但不包括在这里，因为其数字类似于 CPU 预留时间，因为在同一硬件上运行实验，而在 Spark 和 Hive 的情况下，我们不会将数据缓存在内存中。Spark 有能力在内存中缓存数据，但是由于我们的集群内存限制，我们决定类似与 Hive 一样工作在核心外部。等待时间：端到端的工作流失时间。结论和未来工作Facebook 的性能和可扩展的分析在产品开发中给予了协助。Apache Spark 提供了将各种分析用例统一为单一 API 和高效计算引擎的独特功能。我们挑战了 Spark，来将一个分解成数百个 Hive 作业的流水线替换成一个 Spark 作业。通过一系列的性能和可靠性改进之后，我们可以将 Spark 扩大到处理我们在生产中的实体排名数据处理用例之一。 在这个特殊用例中，我们展示了 Spark 可以可靠地重排和排序 90 TB+ 的中间数据，并在一个单一作业中运行了 25 万个任务。 与旧的基于 Hive 的流水线相比，基于 Spark 的流水线产生了显着的性能改进（4.5-6 倍 CPU，3-4 倍资源预留和大约 5 倍的延迟），并且已经投入使用了几个月。虽然本文详细介绍了我们 Spark 最具挑战性的用例，越来越多的客户团队已将 Spark 工作负载部署到生产中。 性能 、可维护性和灵活性是继续推动更多用例到 Spark 的优势。 Facebook 很高兴成为 Spark 开源社区的一部分，并将共同开发 Spark 充分发挥其潜力。via: https://code.facebook.com/posts/1671373793181703/apache-spark-scale-a-60-tb-production-use-case/作者：Sital Kedia, 王硕杰, Avery Ching 译者：wyangsun 校对：wxy本文由 LCTT 组织编译，Linux中国 荣誉推出
Tianhui Michael Li 和 Ariel M’ndange-Pfupfu 将在今年 10 月 10、12 和 14 号组织一个在线经验分享课程：Spark 分布式计算入门。该课程的内容包括创建端到端的运行应用程序和精通 Spark 关键工具。毋庸置疑，云计算将会在未来数据科学领域扮演至关重要的角色。弹性，可扩展性和按需分配的计算能力作为云计算的重要资源，直接导致云服务提供商集体火拼。其中最大的两股势力正是亚马逊网络服务（AWS) 和谷歌云平台（GCP)。本文依据构建时间和运营成本对 AWS 和 GCP 的 Spark 工作负载作一个简短比较。实验由我们的学生在 数据孵化器 （ The Data Incubator ） 进行， 数据孵化器 （ The Data Incubator ） 是一个大数据培训组织，专门为公司招聘顶尖数据科学家并为公司职员培训最新的大数据科学技能。尽管 Spark 效率惊人，分布式工作负载的时间和成本亦然可以大到不能忽略不计。因此我们一直努力寻求更高效的技术，以便我们的学生能够学习到最好和最快的工具。提交 Spark 任务到云Spark 是一个类 MapReduce 但是比 MapReduce 更灵活、更抽象的并行计算框架。Spark 提供 Python 和 Java 编程接口，但它更愿意用户使用原生的 Scala 语言进行应用程序开发。Scala 可以把应用程序和依赖文件打包在一个 JAR 文件从而使 Spark 任务提交变得简单。通常情况下，Sprark 结合 HDFS 应用于分布式数据存储，而与 YARN 协同工作则应用于集群管理；这种堪称完美的配合使得 Spark 非常适用于 AWS 的弹性 MapReduce （EMR）集群和 GCP 的 Dataproc 集群。这两种集群都已有 HDFS 和 YARN 预配置，不需要额外进行配置。配置云服务通过命令行比通过网页界面管理数据、集群和任务具有更高的可扩展性。对 AWS 而言，这意味着客户需要安装 CLI。客户必须获得证书并为每个 EC2 实例创建独立的密钥对。除此之外，客户还需要为 EMR 用户和 EMR 本身创建角色（基本权限），主要是准入许可规则，从而使 EMR 用户获得足够多的权限（通常在 CLI 运行 aws emr create-default-roles 就可以）。相比而言，GCP 的处理流程更加直接。如果客户选择安装 Google Cloud SDK 并且使用其 Google 账号登录，那么客户即刻可以使用 GCP 的几乎所有功能而无需其他任何配置。唯一需要提醒的是不要忘记通过 API 管理器启用计算引擎、Dataproc 和云存储 JSON 的 API。当你安装你的喜好设置好之后，有趣的事情就发生了！比如可以通过aws s3 cp或者gsutil cp命令拷贝客户的数据到云端。再比如客户可以创建自己的输入、输出或者任何其他需要的 bucket，如此，运行一个应用就像创建一个集群或者提交 JAR 文件一样简单。请确定日志存放的地方，毕竟在云环境下跟踪问题或者调试 bug 有点诡异。一分钱一分货谈及成本，Google 的服务在以下几个方面更有优势。首先，购买计算能力的原始成本更低。4 个 vCPU 和 15G RAM 的 Google 计算引擎服务（GCE）每小时只需 0.20 美元，如果运行 Dataproc，每小时也只需区区 0.24 美元。相比之下，同等的云配置，AWS EMR 则需要每小时 0.336 美元。其次，计费方式。AWS 按小时计费，即使客户只使用 15 分钟也要付足 1 小时的费用。GCP 按分钟计费，最低计费 10 分钟。在诸多用户案例中，资费方式的不同直接导致成本的巨大差异。两种云服务都有其他多种定价机制。客户可以使用 AWS 的 Sport Instance 或 GCP 的 Preemptible Instance 来竞价它们的空闲云计算能力。这些服务比专有的、按需服务便宜，缺点是不能保证随时有可用的云资源提供服务。在 GCP 上，如果客户长时间（每月的 25% 至 100%）使用服务，可以获取更多折扣。在 AWS 上预付费或者一次购买大批量服务可以节省不少费用。底线是，如果你是一个超级用户，并且使用云计算已经成为一种常态，那么最好深入研究云计算，自己算计好成本。最后，新手在 GCP 上体验云服务的费用较低。新手只需 300 美元信用担保，就可以免费试用 60 天 GCP 提供的全部云服务。AWS 只免费提供特定服务的特定试用层级，如果运行 Spark 任务，需要付费。这意味着初次体验 Spark，GCP 具有更多选择，也少了精打细算和讨价还价的烦恼。性能比拼我们通过实验检测一个典型 Spark 工作负载的性能与开销。实验分别选择 AWS 的 m3.xlarg 和 GCP 的 n1-standard-4，它们都是由一个 Master 和 5 个核心实例组成的集群。除了规格略有差别，虚拟核心和费用都相同。实际上它们在 Spark 任务的执行时间上也表现的惊人相似。测试 Spark 任务包括对数据的解析、过滤、合并和聚合，这些数据来自公开的 堆栈交换数据转储 （ Stack Exchange Data Dump ） 。通过运行相同的 JAR，我们首先对大约 50M 的数据子集进行交叉验证，然后将验证扩大到大约 9.5G 的数据集。Figure 1. Credit: Michael Li and Ariel M'ndange-Pfupfu.Figure 2. Credit: Michael Li and Ariel M'ndange-Pfupfu.结果表明，短任务在 GCP 上具有明显的成本优势，这是因为 GCP 以分钟计费，并最终扣除了 10 分钟的费用，而 AWS 则收取了 1 小时的费用。但是即使长任务，因为计费方式占优，GPS 仍然具有相当优势。同样值得注意的是存储成本并不包括在此次比较当中。结论AWS 是云计算的先驱，这甚至体现在 API 中。AWS 拥有巨大的生态系统，但其许可模型已略显陈旧，配置管理也有些晦涩难解。相比之下，Google 是云计算领域的新星并且将云计算服务打造得更加圆润自如。但是 GCP 缺少一些便捷的功能，比如通过简单方法自动结束集群和详细的任务计费信息分解。另外，其 Python 编程接口也不像 AWS 的 Boto 那么全面。如果你初次使用云计算，GCP 因其简单易用，别具魅力。即使你已在使用 AWS，你也许会发现迁移到 GCP 可能更划算，尽管真正从 AWS 迁移到 GCP 的代价可能得不偿失。当然，现在对两种云服务作一个全面的总结还非常困难，因为它们都不是单一的实体，而是由多个实体整合而成的完整生态系统，并且各有利弊。真正的赢家是用户。一个例证就是在 数据孵化器 （ The Data Incubator ） ，我们的博士数据科学研究员在学习分布式负载的过程中真正体会到成本的下降。虽然我们的大数据企业培训客户可能对价格不那么敏感,他们更在意能够更快速地处理企业数据，同时保持价格不增加。数据科学家现在可以享受大量的可选服务，这些都是从竞争激烈的云计算市场得到的实惠。via: https://www.oreilly.com/ideas/spark-comparison-aws-vs-gcp作者：Michael Li Ariel M'Ndange-Pfupfu 译者：firstadream 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
Apache Cassandra 数据库近来引起了很多的兴趣，这主要源于现代云端软件对于可用性及性能方面的要求。那么，Apache Cassandra 是什么？它是一种为高可用性及线性可扩展性优化的分布式的联机交易处理 (OLTP) 数据库。具体说到 Cassandra 的用途时，可以想想你希望贴近用户的系统，比如说让我们的用户进行交互的系统、需要保证实时可用的程序等等，如：产品目录，物联网，医疗系统，以及移动应用。对这些程序而言，下线时间意味着利润降低甚至导致其他更坏的结果。Netfilix 是这个在 2008 年开源的项目的早期使用者，他们对此项目的贡献以及带来的成功让这个项目名声大噪。Cassandra 于2010年成为了 Apache 软件基金会的顶级项目，并从此之后就流行起来。现在，只要你有 Cassadra 的相关知识，找工作时就能轻松不少。想想看，NoSQL 语言和开源技术能达到企业级 SQL 技术的高度，真让人觉得十分疯狂而又不可思议的。这引出了一个问题。是什么让它如此的流行？由于采用了亚马逊发表的 Dynamo 论文中率先提出的设计，Cassandra 有能力在大规模的硬件及网络故障时保持实时在线。由于采用了点对点模式，在没有单点故障的情况下，我们能幸免于机架故障甚至全网中断。我们能在不影响用户体验的前提下处理数据中心故障。一个能考虑到故障的分布式系统才是一个没有后顾之忧的分布式系统，因为老实说，故障是迟早会发生的。有了 Cassandra， 我们可以直面残酷的生活并将之融入数据库的结构和功能中。我们能猜到你现在在想什么，“但我只有关系数据库相关背景，难道这样的转变不会很困难吗？”这问题的答案介于是和不是之间。使用 Cassandra 建立数据模型对有关系数据库背景的开发者而言是轻车熟路。我们使用表格来建立数据模型，并使用 CQL （ Cassandra 查询语言）来查询数据库。然而，与 SQL 不同的是，Cassandra 支持更加复杂的数据结构，例如嵌套和用户自定义类型。举个例子，当要储存对一个小猫照片的点赞数目时，我们可以将整个数据储存在一个包含照片本身的集合之中从而获得更快的顺序查找而不是建立一个独立的表。这样的表述在 CQL 中十分的自然。在我们照片表中，我们需要记录名字，URL以及给此照片点赞过的人。在一个高性能系统中，毫秒级处理都能对用户体验和客户维系产生影响。昂贵的 JOIN 操作制约了我们通过增加不可预见的网络调用而扩容的能力。当我们将数据反范式化使其能通过尽可能少的请求就可获取时，我们即可从磁盘空间成本的降低中获益并获得可预期的、高性能应用。我们将反范式化同 Cassandra 一同介绍是因为它提供了很有吸引力的的折衷方案。很明显，我们不会局限于对于小猫照片的点赞数量。Canssandra 是一款为高并发写入优化的方案。这使其成为需要时常吞吐数据的大数据应用的理想解决方案。实时应用和物联网方面的应用正在稳步增长，无论是需求还是市场表现，我们也会不断的利用我们收集到的数据来寻求改进技术应用的方式。这就引出了我们的下一步，我们已经提到了如何以一种现代的、性价比高的方式储存数据，但我们应该如何获得更多的动力呢？具体而言，当我们收集到了所需的数据，我们应该怎样处理呢？如何才能有效的分析几百 TB 的数据呢？如何才能实时的对我们所收集到的信息进行反馈，并在几秒而不是几小时的时间利作出决策呢？Apache Spark 将给我们答案。Spark 是大数据变革中的下一步。 Hadoop 和 MapReduce 都是革命性的产品，它们让大数据界获得了分析所有我们所取得的数据的机会。Spark 对性能的大幅提升及对代码复杂度的大幅降低则将大数据分析提升到了另一个高度。通过 Spark，我们能大批量的处理计算，对流处理进行快速反应，通过机器学习作出决策，并通过图遍历来理解复杂的递归关系。这并非只是为你的客户提供与快捷可靠的应用程序连接（Cassandra 已经提供了这样的功能），这更是能洞悉 Canssandra 所储存的数据，作出更加合理的商业决策并同时更好地满足客户需求。你可以看看 Spark-Cassandra Connector (开源) 并动手试试。若想了解更多关于这两种技术的信息，我们强烈推荐名为 DataStax Academy 的自学课程via: https://opensource.com/life/16/5/basics-cassandra-and-spark-data-processing作者：Jon Haddad,Dani Traphagen 译者：KevinSJ 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出