蚊章汇 - Spark
type: channel
link: https://linuxcn.bwsl.wang/tag/Spark/
items: 用 Spark SQL 进行结构化数据处理
items: #新闻拍一拍# 谷歌和微软在 Chromium 上相爱相杀
items: 60 TB 数据：Facebook 是如何大规模使用 Apache Spark 的
items: AWS 和 GCP 的 Spark 技术哪家强？
items: Cassandra 和 Spark 数据处理一窥

用 Spark SQL 进行结构化数据处理
type: item
date: 2022-05-24T17:30:38+08:00
description: 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/structu…

#新闻拍一拍# 谷歌和微软在 Chromium 上相爱相杀
type: item
date: 2020-06-22T19:24:29+08:00
description: 谷歌和微软在 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 的
type: item
date: 2017-06-23T17:55:00+08:00
description: 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 ） 的数据大小来说，这是现实世界…

AWS 和 GCP 的 Spark 技术哪家强？
type: item
date: 2016-09-30T16:49:00+08:00
description: 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 工…

Cassandra 和 Spark 数据处理一窥
type: item
date: 2016-07-18T01:35:16+08:00
description: 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中国 荣誉推出