Apache Spark

阿里云分析型数据库重磅推出基础版，极大降低了用户构建数据仓库门槛。高度兼容MySQL，极低的使用成本和极高的性能，使中小企业也可以轻松的搭建一套实时数据仓库，实现企业数据价值在线化。 AnalyticDB for MySQL的产品系列包括基础版（单机版）和集群版，基础版为单个节点提供服务，极简的架构大大的降低了基础版的成本。存储计算分离架构、行列混存技术、轻量的索引构建方式和分布式混合计算引擎又保证了基础版强大的分析性能。年成本不到一万就可以构建一套实时数据仓库，无需成立专门的大数据团队，为企业节省百万成本。 1.基础版技术架构 如下为基础版架构图，整体由Coordinator和Worker组成，各自的职责如下介绍。 1.1 Coordinator: 前端控制节点，职责包括 （1）MySQL协议层接入，SQL解析 （2）认证和鉴权，提供了更完善和细化的权限体系模型，白名单和集群级别RAM控制，并审计与合规记录所有SQL操作。 （3）集群管理：成员管理、元数据、数据一致性、路由同步、备份与恢复（数据与log管理) （4）后台异步任务管理 （5）事务管理 （6）优化器，执行计划生成 （7）计算调度，负责执行任务调度 1.2 Worker: 存储和计算节点，包含 （1）计算模块 分布式MPP+DAG混合计算引擎和优化器达到了更高的复杂计算能力和混合负载管理能力

主题： 存储计算分离场景的计算适应优化 时间： 2020.4.9（周四）19:00 参与方式： 扫描下方二维码加入钉钉群，群内直接观看 或点击直播间链接： https://developer.aliyun.com/live/2592 讲师：王道远 花名健身，阿里云EMR技术专家，Apache Spark活跃贡献者，主要关注大数据计算优化相关工作。 直播简介： 本次分享会介绍云上大数据处理的存储计算分离特征，分析传统大数据处理中数据本地化与存储计算分离场景的区别，以及在存储计算分离场景中阿里云EMR的相关优化。 来源： oschina 链接： https://my.oschina.net/u/4399154/blog/3225327

shuffle调优 调优概述 大多数Spark作业的性能主要就是消耗在了shuffle环节，因为该环节包含了大量的磁盘IO、序列化、网络数据传输等操作。因此，如果要让作业的性能更上一层楼，就有必要对shuffle过程进行调优。但是也必须提醒大家的是，影响一个Spark作业性能的因素，主要还是代码开发、资源参数以及数据倾斜，shuffle调优只能在整个Spark的性能调优中占到一小部分而已。因此大家务必把握住调优的基本原则，千万不要舍本逐末。下面我们就给大家详细讲解shuffle的原理，以及相关参数的说明，同时给出各个参数的调优建议。 ShuffleManager发展概述 在Spark的源码中，负责shuffle过程的执行、计算和处理的组件主要就是ShuffleManager，也即shuffle管理器。而随着Spark的版本的发展，ShuffleManager也在不断迭代，变得越来越先进。 在Spark 1.2以前，默认的shuffle计算引擎是HashShuffleManager。该ShuffleManager而HashShuffleManager有着一个非常严重的弊端，就是会产生大量的中间磁盘文件，进而由大量的磁盘IO操作影响了性能。 因此在Spark 1.2以后的版本中，默认的ShuffleManager改成了SortShuffleManager

今日有朋友加好友与我探讨一些问题，我觉得这些问题倒挺有价值的；于是就想在本公众号开设一个问答专栏，方便技术交流与分享，专栏名就定为：《读者来信》。如遇到本人能力有限难以解决的问题，该贴将会被转发至我的资源圈寻求大佬们出手帮助，并附上提问者微信二维码。也欢迎大家在留言区积极探讨解决方案~ 来信人：黄*伟 小猿提问 如果我用Spark处理文件写进HBase，文件按日期每天增量下发，如果只想在HBase中保留最近90天的文件数据，有什么好的方法吗？TTL会有禁用表操作，后端查询就会报错。除了TTL，还有别的解决方案吗？ 小猿分析 该问题主要的症结点在于：建表之初，没有及时给列族设置TTL，入数据之后想到可以设置表的TTL属性来保证数据时效性但又不想禁用表。怎么办呢？ 小猿解答 这里，小猿给出两条解决方案： 方案一： 其实在稍微高一点的HBase版本，设置表TTL属性已经可以在线进行，不需要disable表了。如果不确定，可以先建一个测试表在线设置一下TTL试一试。如果支持，那可以选择在低峰期通过HBase Shell手动修改列族的时效性，一劳永逸。 hbase(main):030:0> create 'test','f1' 0 row(s) in 1.2990 seconds => Hbase::Table - test hbase(main):031:0> desc 'test'

窗口函数在工作中经常用到，在面试中也会经常被问到，你知道它背后的实现原理吗？ 这篇文章从一次业务中遇到的问题出发，深入聊了聊hsql中窗口函数的数据流转原理，在文章最后针对这个问题给出解决方案。 ​ 一、业务背景 先模拟一个业务背景，比如大家在看淘宝app时，如下图： 搜索一个关键词后，会给展示一系列商品，这些商品有不同的类型，比如第一个是广告商品，后面这几个算是正常的商品。把这些数据用下面的测试表来描述： create table window_test_table ( id int , --用户id sq string , --可以标识每个商品 cell_type int , --标识每个商品的类型，比如广告，非广告 rank int --这次搜索下商品的位置，比如第一个广告商品就是1，后面的依次2，3，4... ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' ; 在该表中插入以下数据： 以上数据中，cell_type列，假设26代表是广告，现在有个需求，想获取每个用户每次搜索下非广告类型的商品位置自然排序，如果下效果： 业务方的实现方法： --业务方的写法 select id , sq, cell_type, rank , if (cell_type!= 26 ,row_number() over ( partition by

一、自适应框架能解决什么问题 1、目前SparkSQL中reduce阶段的task个数取决于固定参数spark.sql.shuffle.partition(默认值200)，一个作业一旦设置了该参数，它运行过程中的所有阶段的reduce个数都是同一个值。 而对于不同的作业，以及同一个作业内的不同reduce阶段，实际的数据量大小可能相差很大，比如reduce阶段要处理的数据可能是10MB，也有可能是100GB, 如果使用同一个值对实际运行效率会产生很大影响，比如10MB的数据一个task就可以解决，如果spark.sql.shuffle.partition使用默认值200的话，那么10MB的数据就要被分成200个task处理，增加了调度开销，影响运行效率。 SparkSQL自适应框架可以通过设置shuffle partition的上下限区间，在这个区间内对不同作业不同阶段的reduce个数进行动态调整。 通过区间的设置，一方面可以大大减少调优的成本(不需要找到一个固定值)，另一方面同一个作业内部不同reduce阶段的reduce个数也能动态调整 参数如下： spark . sql . adaptive . enabled 默认false 自适应执行框架的开关 spark . sql . adaptive . minNumPostShufflePartitions 默认为1

Apache Spark是专为大规模数据处理而设计的快速通用的计算引擎；现在形成一个高速发展应用广泛的生态系统。 Spark三种分布式部署方式比较 目前Apache Spark支持三种分布式部署方式，分别是standalone、spark on mesos和 spark on YARN，详情参考。 Spark standalone模式分布式部署 环境介绍 主机名 应用 tvm11 zookeeper tvm12 zookeeper tvm13 zookeeper、spark（master）、spark（slave）、Scala tvm14 spark（backup）、spark（slave）、Scala tvm15 spark（slave）、Scala 说明 依赖scala： Note that support for Java 7, Python 2.6 and old Hadoop versions before 2.6.5 were removed as of Spark 2.2.0. Support for Scala 2.10 was removed as of 2.3.0. Support for Scala 2.11 is deprecated as of Spark 2.4.1 and will be removed in Spark 3.0. zookeeper：

es的详细介绍 SearchTemplate tmdb 表示的是模板名称 dmdb1 表示的是当前的索引 脚本方式编辑 ##编辑模板 POST _scripts/tmdb { "script": { "lang": "mustache", "source": { "_source": ["title", "overview"], "size": 20, "query": { "multi_match": { "query": "{{q}}", "fields": ["title", "overview"] } } } } } ## 编辑查询 POST tmdb1/_search/template { "id": "tmdb", "params": { "q": "basketball with cartoon aliens" } } aliases 的用户 它相当于 es 某个文档的一个别名，可以把多个索引放入到同一个视图中，也可以添加过滤器，把符合条件的索引数据 查询出来，最后集中成一个别名，查询该别名可以把多个索引里的数据都查询出来 #### 新增别名 POST _aliases { "actions": [ { "add": { "index": "news", "alias": "new1" } }, { "add": { "index": "blogs", "alias"

本文基于 Spark 2.4.4 版本的源码，试图分析其 Core 模块的部分实现原理，其中如有错误，请指正。为了简化论述，将部分细节放到了源码中作为注释，因此正文中是主要内容。 Spark Core RDD RDD(Resilient Distributed Dataset)，即弹性数据集是 Spark 中的基础结构。RDD 是 distributive 的、immutable 的，可以被 persist 到磁盘或者内存中。 对 RDD 具有转换操作和行动操作两种截然不同的操作。转换(Transform)操作从一个 RDD 生成另一个 RDD，但行动(Action)操作会去掉 RDD 的 Context。例如take是行动操作，返回的是一个数组而不是 RDD 了，如下所示 scala> var rdd1 = sc.makeRDD(Seq(10, 4, 2, 12, 3)) rdd1: org.apache.spark.rdd.RDD[Int] = ParallelCollectionRDD[40] at makeRDD at :21 scala> rdd1.take(1) res0: Array[Int] = Array(10) scala> rdd1.take(2) res1: Array[Int] = Array(10, 4) 转换操作是 Lazy 的，直到遇到一个

转载自： https://www.cnblogs.com/qingyunzong/p/8946679.html 一：数据倾斜 （一）数据倾斜调优了解 有的时候，我们可能会遇到大数据计算中一个最棘手的问题——数据倾斜，此时Spark作业的性能会比期望差很多。数据倾斜调优，就是使用各种技术方案解决不同类型的数据倾斜问题，以保证Spark作业的性能。 （二）数据倾斜发生时的现象 绝大多数task执行得都非常快，但个别task执行极慢 。比如，总共有1000个task，997个task都在1分钟之内执行完了，但是剩余两三个task却要一两个小时。这种情况很常见。 原本能够正常执行的Spark作业，某天突然报出OOM（内存溢出）异常，观察异常栈，是我们写的业务代码造成的。 这种情况比较少见。 （三）数据倾斜原理 数据倾斜的原理很简单： 在进行shuffle的时候，必须将各个节点上相同的key拉取到某个节点上的一个task来进行处理，比如按照key进行聚合或join等操作。 此时 如果某个key对应的数据量特别大的话，就会发生数据倾斜。 比如大部分key对应10条数据，但是个别key却对应了100万条数据，那么大部分task可能就只会分配到10条数据，然后1秒钟就运行完了； 但是个别task可能分配到了100万数据，要运行一两个小时。因此