Apache Spark

本文作者 李超 阿里云智能 资深技术专家 编者按 伏羲（Fuxi）是十年前最初创立飞天平台时的三大服务之一（分布式存储 Pangu，分布式计算 MaxCompute，分布式调度 Fuxi），当时的设计初衷是为了解决大规模分布式资源的调度问题（本质上是多目标的最优匹配问题）。 随阿里经济体和阿里云丰富的业务需求（尤其是双十一）和磨练，伏羲的内涵不断扩大， 从单一的资源调度器（对标开源系统的YARN）扩展成大数据的核心调度服务，覆盖数据调度（Data Placement）、资源调度（Resouce Management）、计算调度（Application Manager）、和本地微（自治）调度（即正文中的单机调度）等多个领域， 并在每一个细分领域致力于打造超越业界主流的差异化能力。 过去十年来，伏羲在技术能力上每年都有一定的进展和突破（如2013年的5K，15年的Sortbenchmark世界冠军，17年的超大规模离在/在离混布能力，2019年的 Yugong 发布并论文被VLDB接受等等）。本文试从面向大数据/云计算的调度挑战出发，介绍各个子领域的关键进展，并回答什么是“伏羲 2.0”。 1. 引言 过去10年，是云计算的10年，伴随云计算的爆炸式增长，大数据行业的工作方式也发生了很大的变化：从传统的自建自运维hadoop集群，变成更多的依赖云上的弹性低成本计算资源

前面已经和大家提到过Shuffle的具体流程和运用场景，也提到过通常shuffle分为两部分： Map阶段的数据准备和Reduce阶段的数据拷贝处理。 Shuffle Write理解： 提供数据的一端，被称作 Map 端，Map 端每个生成数据的任务称为Mapper；将在map端的Shuffle称之为 Shuffle Write 。 Shuffle Read理解： 接收数据的一端，被称作 Reduce 端，Reduce 端每个拉取数据的任务称为 Reducer；将在Reduce端的Shuffle称之为 Shuffle Read 。 spark中rdd由多个partition组成，任务运行作用于partition。spark有两种类型的task： ShuffleMapTask ： 负责rdd之间的transform，map输出也就是 Shuffle Write。 ResultTask ,：job最后阶段运行的任务，也就是action（一个action会触发生成一个job并提交）操作触发生成的task，用来收集job运行的结果并返回结果到driver端。也就是 Shuffle Read 。 write和read原理 job依赖关系RDD结构图如下： 最终得到了整个执行过程，如下图所示： 这个执行过程中间就涉及到shuffle 过程； 前一个stage 的 ShuffleMapTask

前言 现在的架构很多，各种各样的，如高并发架构、异地多活架构、容器化架构、微服务架构、高可用架构、弹性化架构等，还有和这些架构相关的管理型的技术方法，如 DevOps、应用监控、自动化运维、SOA 服务治理、去 IOE 等等，还有很多。 那什么是分布式系统？分布式系统是支持分布式处理的软件系统，是由通信网络互联的多处理机体系结构上执行任务的系统。包括分布式操作系统、分布式程序设计语言及其编译系统、分布式文件系统分布式数据库系统等，当然这些也是分布式的关键技术。 分布式需要了解的重点 1、ActivMQ 分布式消息总线 在大型分布式系统中，在遵循JMS规范的前提下 ，进行系统之间的大规模异步消息通信和集中常用的通信机制。 能对JMS规范有深入的了解，以及分布式系统架构中的异步通信机制。 2、高并发编程必备之NIO基础 NIO的基本原理以及实现过程 能对传统IO和NIO的区别进行系统的了解并能学会NIO的实现原理 3、Redis内存数据库 在大型分布式系统中，怎样在高并发的情况下解决某些非结构化数据快速存取的解决方案。 能对非关系数据库和非关系数据库有个系统的了解 以及Redis内存数据库的基本数据类型和各自的应用场景。 4、高并发编程之NIO流行框架之Netty NIO框架Netty的简介以及netty的应用场景。 能运用netty实现客户端和服务器端的基本通信。 5、Lucene

桔妹导读：滴滴HBase团队日前完成了0.98版本 -> 1.4.8版本滚动升级，用户无感知。新版本为我们带来了丰富的新特性，在性能、稳定性与易用性方便也均有很大提升。我们将整个升级过程中面临的挑战、进行的思考以及解决的问题总结成文，希望对大家有所帮助。 1. 背景 目前HBase服务在我司共有国内、海外共计11个集群，总吞吐超过1kw+/s，服务着地图、普惠、车服、引擎、金融等几乎全部部门与业务线。 然而有一个问题持续困扰着我们：版本较社区落后较多——HBase线上集群使用0.98版本，而社区目前最新的release版本为2.3。这为我们的工作带来了很多额外的掣肘与负担，主要包括以下几点： 新特性引入成本极高： 0.98版本可以算是HBase第一个稳定版本，但过于老旧，社区已经不再维护。想要backport新特性难度越来越大。 自研patch维护成本较高： 我们基于0.98版本有数十个大大小小的自研patch，涵盖了从label分组、ACL鉴权等大的feature到监控体系建设、审计日志优化等Improvement以及各种bug fix。这些patch或是新版本中已支持但和我们实现有差异，或是由于版本差异过大无法合入社区，而且随着时间线的拉长，这种问题只会进一步恶化。 上层组件对于HBase存在一定需求： 得益于活跃的HBase生态圈，目前我们的用户使用形态也比较丰富，OLAP

生产环境的 Spark Job 都是跑在集群上的，毕竟 Spark 为大数据而生，海量的数据处理必须依靠集群。但是在开发Spark的的时候，不可避免我们要在本地进行一些开发和测试工作，所以如何在本地用好Spark也十分重要，下面给大家分享一些经验。 首先你需要在本机上安装好了Java，Scala和Spark，并配置好了环境变量。详情请参考官方文档或其他教程。 spark-shell 本地运行Spark最直接的方式就是在命令行里面运行spark-shell，成功后你将看到如下信息： 首先可以仔细阅读一下命令行的提示信息， Picked up _JAVA_OPTIONS: -Xmx512M -Xms512M // _JAVA_OPTIONS是我在系统环境变量里面设置的值 Using Spark's default log4j profile: org/apache/spark/log4j-defaults.properties // 告诉你log4j使用配置 Setting default log level to "WARN". // log级别 To adjust logging level use sc.setLogLevel(newLevel). For SparkR, use setLogLevel(newLevel). // 如何调整log级别 Spark context

Spark中文峰会第二日，就在本周日上午杭州会场，错过悔十年的压轴好戏来了～ SPARK + AI SUMMIT 2020 中文精华版线上峰会 ，十四位来自北京、上海、杭州、硅谷的PMC和意见领袖，一一还原英文现场的经典分享。 除 Databricks、Facebook、阿里巴巴、Intel 、领英等一线厂商的经典应用场景外，还有Ray、SQL、Structured Streaming、 MLflow、Koalas、K8s、Delta lake、Photon等新奇议题及社区生态的最新落地。 点击 详细议程 7月5日上午议题： 利用闪存优化在Cosco基础上的Spark Shuffle 吴一 Databicks开源项目组软件工程师，主要参与开源社区Spark和公司产品Databricks Runtime的研发。最近两年专注于Spark及大数据技术领域 来源： oschina 链接： https://my.oschina.net/u/4343506/blog/4332580

首先自己造了一份简单的社交关系的图 第一份是人物数据，id和姓名，person.txt 1 孙俪 2 邓超 3 佟大为 4 冯绍峰 5 黄晓明 6 angelababy 7 李冰冰 8 范冰冰 第二份是社交关系数据，两个人的id和社交关系，social.txt 1 丈夫 2 2 妻子 1 1 搭档 3 3 同学 4 3 好友 5 5 好友 3 5 妻子 6 5 好友 7 7 好友 8 使用SparkX和GraphStream来处理数据 package graphx import org.apache.spark.{SparkConf, SparkContext} import org.apache.spark.graphx._ import org.apache.spark.rdd.RDD import org.graphstream.graph.implementations.{AbstractEdge, SingleGraph, SingleNode} /** * Created by common on 18-1-22. */ object GraphxLearning { def main(args: Array[String]): Unit = { val conf = new SparkConf().setAppName("GraphX").setMaster(

1.近实时摄取 将数据从外部源如事件日志、数据库提取到 Hadoop数据湖 中是一个很常见的问题。在大多数Hadoop部署中，一般使用混合提取工具并以零散的方式解决该问题，尽管这些数据对组织是非常有价值的。 对于RDBMS摄取，Hudi通过Upserts提供了更快的负载，而非昂贵且低效的批量负载。例如你可以读取MySQL binlog日志或 Sqoop增量导入 ，并将它们应用在DFS上的Hudi表，这比 批量合并作业 或 复杂的手工合并工作流 更快/更高效。 对于像 Cassandra / Voldemort / HBase 这样的NoSQL数据库，即使规模集群不大也可以存储数十亿行数据，此时进行批量加载则完全不可行，需要采用更有效的方法使得摄取速度与较频繁的更新数据量相匹配。 即使对于像 Kafka 这样的不可变数据源，Hudi也会强制在DFS上保持最小文件大小，从而解决Hadoop领域中的 古老问题 以便改善NameNode的运行状况。这对于事件流尤为重要，因为事件流（例如单击流）通常较大，如果管理不善，可能会严重损害Hadoop集群性能。 对于所有数据源，Hudi都提供了通过提交将新数据原子化地发布给消费者，从而避免部分提取失败。 2. 近实时分析 通常实时 数据集市 由专门的分析存储，如 Druid 、 Memsql 甚至 OpenTSDB 提供支持

Checkpoint 到底是什么和需要用 Checkpoint 解决什么问题： Spark 在生产环境下经常会面临 Transformation 的 RDD 非常多(例如一个Job 中包含1万个RDD) 或者是具体的 Transformation 产生的 RDD 本身计算特别复杂和耗时 (例如计算时常超过1个小时) , 可能业务比较复杂，此时我们必需考虑对计算结果的持久化。 Spark 是擅长 多步骤迭代 ，同时擅长基于 Job 的复用。这个时候如果可以对计算的过程进行复用，就可以极大的提升效率。因为有时候有共同的步骤，就可以免却重复计算的时间。 如果采用 persists 把数据在内存中的话，虽然最快速但是也是最不可靠的；如果放在磁盘上也不是完全可靠的，例如磁盘会损坏，系统管理员可能会清空磁盘。 Checkpoint 的产生就是为了相对而言更加可靠的持久化数据，在 Checkpoint 可以指定把数据放在本地并且是多副本的方式，但是在正常生产环境下放在 HDFS 上，这就天然的借助HDFS 高可靠的特征来完成最大化的 可靠的持久化数据的方式 。 Checkpoint 是为了 最大程度保证绝对可靠的复用 RDD 计算数据的 Spark 的高级功能，通过 Checkpoint 我们通过把数据持久化到 HDFS 上来保证数据的最大程度的安任性 Checkpoint 就是针对整个RDD

码农不容易！ 我这十几年一直在学习，停都停不下来！因为互联网技术发展真的造化弄人：上学那会儿，老师说C++有前途，因为大多数的企业都用它来写服务器程序；过了两年突然原来这个世界是Java的，遂挑灯恶补Spring。然而，技术永远在诞生新的“概念”（就要玩死码农），hadoop又出来糟蹋我们的青春了（所以真正爱学习的程序员哪有时间去蹦迪），“大数据”吞噬了我们的“小时间”。 就在最近，很多人又开始慌了！各种技术前言的新闻都在露出一个似乎新的技术领域词汇“联邦学习”。没有办法，为了“保值”或者“升值”，程序员必须去了解和学习最新、最火的技术。 人才很稀缺 一个较新的行业领域，我习惯先看一下这个行业的人才市场。了解方式也不难，可以打开猎聘、拉钩、boss等招牌网站，搜索一下“联邦学习”、“多方安全计算”、“隐私计算”、“加密技术”等你想了解的关键词，基本上可以反映这个行业的薪水情况、哪些公司在做或者筹备、人才的要求及层次等。下图是我汇总了一部分企业招聘信息： 总体看下来，目前普遍处于招聘研究员为主，出价在50-100w年薪之间，学历要求普遍较高，资深一点的都需要研究生以上的学历。从岗位描述上基本上都在机器学习算法、联邦学习、多方安全计算等相关的技术上需要有比较深的认知。这些招牌单位有BAT这样的大厂，也有富数科技、华控清交这样的创业独角兽，还有银行、数据公司、汽车平台，甚至家喻户晓的抖音