Apache Spark

（分割线前的都是废话） java8内存模型： http://www.cnblogs.com/paddix/p/5309550.html http://www.cnblogs.com/dingyingsi/p/3760447.html 帖子里提到 5、方法区： 方法区也是所有线程共享。主要用于存储类的信息、常量池、方法数据、方法代码等。 方法区逻辑上属于堆的一部分，但是为了与堆进行区分，通常又叫“ 非堆 ”。 1.7和1.8后这个方法区 没有了，被原空间取代了 不过元空间与永久代之间最大的区别在于： 元空间并不在虚拟机中，而是使用本地内存 。因此，默认情况下，元空间的大小仅受本地内存限制，但可以通过以下参数来指定元空间的大小： --------------分割线--------------------------------------------------------------------------------- 那么这些jvm在yarn 和spark的内存模型上是怎么工作的？ 其实我是想知道： spark on yarn下 一个yarn的Container 可以包含几个spark Executor？ 还是一个Executor 下可以有多个Container ？ 是一个Container 起了一个jvm，在这个jvm下执行多个task？ 一篇帖子 spark架构 中提到

使用方法： 可通过Java client、C++ client、Pythonclient操作kudu表，但要构建client并编写应用程序； 可通过kudu-spark包集成kudu与spark，并编写spark应用程序来操作kudu表； 可通过impala的shell对kudu表进行交互式的操作，因为impala2.8及以上的版本已经集成了对kudu的操作。下面主要讲述基于impala的使用方法。 基本要求： 安装2.8及以上版本的impala，并安装hive，使用其metastore服务来存储impala的元数据。此处Hadoop、hive、impala的安装过程省略。 注：需通过CDH 管理界面配置impala操作kudu； 基于kudu的基本操作（impala） 创建表：示例一 CREATE TABLE my_first_table ( id BIGINT, name STRING, PRIMARY KEY(id) ) PARTITION BY HASH PARTITIONS 16 STORED AS KUDU; CREATE TABLE new_table PRIMARY KEY (ts, name) PARTITION BY HASH(name) PARTITIONS 8 STORED AS KUDU AS SELECT ts, name, value FROM old

资源调优 ① 搭建Spark集群的时候要给Spark集群足够的资源（core，memory） 在spark安装包的conf下spark-env.sh SPARK_WORKER_CORES --worker节点的可用核数 SPARK_WORKER_MEMORY SPARK_WORKER_INSTANCE 在提交Application的时候给Application分配更多的资源。 提交命令选项：（在提交Application的时候使用选项） --executor-cores --executor-memory --total-executor-cores 配置信息：（在Application的代码中设置,在 Spark-default.conf 中设置） spark.executor.cores spark.executor.memory spark.max.cores 并行度调优 原则：一个core一般分配2~3个task,每一个task一般处理1G数据（task的复杂度类似wc） ① 提高并行度的方式： 1) .如果读取的数据在HDFS上，降低block块的大小 2) .sc.textFile(path,numPartitions) 3) sc.parallelize(list,numPartitions) 一般用于测试 4) coalesce

【业务场景】 　　在Spark的统计开发过程中，肯定会遇到类似小维表join大业务表的场景，或者需要在算子函数中使用外部变量的场景（尤其是大变量，比如100M以上的大集合），那么此时应该使用Spark的广播（Broadcast）功能来提升性能。 【原理说明】 　　在算子函数中使用到外部变量或两表join时，默认情况下，Spark会将该变量或小维表复制多个副本，通过网络传输到task中，此时每个task都有一个变量副本。如果变量本身比较大的话（比如100M，甚至1G），那么大量的变量副本在网络中传输的性能开销，以及在各个节点的Executor中占用过多内存导致的频繁GC，都会极大地影响性能。 【优化方案】 因此对于上述情况，如果使用的外部变量比较大，建议使用Spark的广播功能，对该变量进行广播。 广播后的变量，会保证每个Executor的内存中，只驻留一份变量副本 ，而Executor中的相关所有task执行时，可以共享该Executor中的这一份变量副本。可以大大减少变量副本的数量，从而减少网络传输的性能开销，并减少对Executor内存的占用开销，降低GC的频率。 　　我的代码实践： https://github.com/wwcom614/Spark 　　下一篇： 【Spark调优】数据倾斜及排查 　　上一篇： 【Spark调优】提交job资源参数调优 来源： oschina

【场景】 　　Spark提交作业job的时候要指定该job可以使用的CPU、内存等资源参数，生产环境中，任务资源分配不足会导致该job执行中断、失败等问题，所以对Spark的job资源参数分配调优非常重要。 　　spark提交作业，yarn-cluster模式示例： 　　./bin/spark-submit\ 　　--class com.ww.rdd.wordcount \ 　　--master yarn \ 　　--deploy-mode cluster \ 　　--executor-memory 4G \ 　　--num-executors 50 \ 　　 --driver-memory 1G \ 　　--conf spark.default.parallelism=1000 \ 　　 --conf spark.memory.fraction =0.75 \ 　　 --conf spark.memory.storageFraction =0.5 \ 　　/home/spark/wordcount.jar \ 　　1000 #入参 【参数】 num-executors 　　 参数说明 ：该参数用于设置每个Spark作业总共要用多少个Executor进程来执行。例如Driver向YARN集群管理器申请资源时

num-executors 参数说明：该参数用于设置Spark作业总共要用多少个Executor进程来执行。Driver在向YARN集群管理器申请资源时，YARN集群管理器会尽可能按照你的设置来在集群的各个工作节点上，启动相应数量的Executor进程。这个参数非常之重要，如果不设置的话，默认只会给你启动少量的Executor进程，此时你的Spark作业的运行速度是非常慢的。 参数调优建议：每个Spark作业的运行一般设置50~100个左右的Executor进程比较合适，设置太少或太多的Executor进程都不好。设置的太少，无法充分利用集群资源；设置的太多的话，大部分队列可能无法给予充分的资源。 executor-memory 参数说明：该参数用于设置每个Executor进程的内存。Executor内存的大小，很多时候直接决定了Spark作业的性能，而且跟常见的JVM OOM异常，也有直接的关联。 参数调优建议：每个Executor进程的内存设置4G~8G较为合适。但是这只是一个参考值，具体的设置还是得根据不同部门的资源队列来定。可以看看自己团队的资源队列的最大内存限制是多少，num-executors乘以executor-memory，就代表了你的Spark作业申请到的总内存量（也就是所有Executor进程的内存总和），这个量是不能超过队列的最大内存量的。此外

一、概述 　　 1.什么是scala 　　Scala是一种多范式的编程语言，其设计的初衷是要集成面向对象编程和函数式编程的各种特性。Scala运行于Java平台（Java虚拟机），并兼容现有的Java程序。 　　 官网 ： http://www.scala-lang.org/ 　　scala 特性： 　　　 　　　　 面向对象特性、 　　　　函数式编程 　　　　 静态类型 　　　　扩展性 　　　　并发性 　　详细的阐述，参考 菜鸟教程 ： http://www.runoob.com/scala/scala-intro.html 　　　　　　　　　　 易百教程 ： https://www.yiibai.com/scala/scala_overview.html 　　通过官网的一句话总结： 当面向对象遇上函数式编程。 　　到今天（2018年），scala 已经15岁了！ 　　 2.scala 如何工作 编译成Java字节码 可在任何标准JVM上运行 甚至是一些不规范的JVM上，如Dalvik Scala编译器是Java编译器的作者写的 　　 3.为什么选择scala 作者：吴雪峰 链接：https: // www.zhihu.com/question/27630156/answer/37598031 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

前言 《牧神记》有一句话说的好，破心中神。当不再对分布式，微服务，CLR畏惧迷茫的时候，你就破了心中神。 zipkin复习 第一篇: .Net架构篇:思考如何设计一款实用的分布式监控系统？ 第二篇： NetCore实践篇：分布式监控客户端ZipkinTracer从入门到放弃之路 ,我们提到了zipkin的原理和架构说明，以及用zipkintracer实践失败的记录。 今天我们来复习下。 zipkin作用 全链路追踪工具（根据依赖关系） 查看每个接口、每个service的执行速度（定位问题发生点或者寻找性能瓶颈） zipkin工作原理 创造一些追踪标识符（tracingId，spanId，parentId），最终将一个request的流程树构建出来 zipkin架构 Collector接收各service传输的数据； Cassandra作为Storage的一种，默认存储在内存中，也支持ElasticSearch和mysql用于生产落库； Query负责查询Storage中存储的数据,提供简单的JSON API获取数据，主要提供给web UI使用； Web 提供简单的web界面； zipkin分布式跟踪系统的目的 zipkin为分布式链路调用监控系统，聚合各业务系统调用延迟数据，达到链路调用监控跟踪；

1.1 例子，美国 1880 － 2014 年新生婴儿数据统计 目标：用美国 1880 － 2014 年新生婴儿的数据来做做简单的统计 数据源： https://catalog.data.gov 数据格式： 每年的新生婴儿数据在一个文件里面 每个文件的每一条数据格式：姓名,性别,新生人数 1.2 运行流程概览 上面的 22 行代码，就已经把构建一个 spark app 的三大步骤完成了，amazing, right? 今天我们主要讲 spark 的运行逻辑，所以我们就以核心的 11 － 16 ，这六行代码来作为今天的主线，了解了解 spark 的原理。 可以看到，整个逻辑实际上就用了 sparkContext 的一个函数，rdd 的 3 个 transformation 和 1 个 action。 现在让我们从 WEB UI 上来看看，当我们运行这段代码的时候，后台都发生了什么。 可以看到，执行这段代码的时候，spark 通过分析，优化代码，知道这段代码需要一个 job 来完成，所以 web ui 上只有一个 job。值得深究的是，这个 job 由两个 stage 完成，这两个 state 一共有 66 个 task。 所以，这里我们就再次理解下 spark 里，job，stage，task 的概念： job : A job is triggered by an action,

一、电力设备在线监测的目的及意义 1、项目背景 电力设备在线检测是指在不停电的情况下，对电力设备状况进行连续或周期自动检测监视。运用传感器技术、广域通信技术、信息处理技术 实时感知-->监视预警-->分析诊断-->评估预测 电力设备在线检测是实现电力设备运行检修管理、提升生产运行管理精益化的重要手段，对提升电网智能化水平，实现电力设备状态运行管理具有积极而深远的意义。 例如：海量数据处理平台 变压器油色谱监测，容性设备在线检测，数字化变电站，山火监测，雷电定位系统，覆冰预警系统，SCADA系统。 2.数据特点： 规模巨大：TB->PB 【一个省级电网公司，150+变电站，150TB、day】 数据处理速度：性能瓶颈，实时监控画面刷新周期小于5s 数据类型多样：结构化，半结构化，非结构化 价值密度低：在正常数据占据大多数，希望发现隐匿在里面的价值数据。 3.国家电网公司数据存储和系统架构【现状】 过于依赖集中式SAN存储 基于SOA的数据集成 主要采用“企业级关系型数据库” 只存储二次加工的“熟数据” 速度慢，静态，关联性强 OLTP没有用武之处 容量，性能，可靠性，扩展性 一次性设备绝缘放电电流波形信号 4.先进的技术解决 阿里云、亚马逊、ODPS、HADOOP,SPARK,HBASE,STORM,ZOOKEEPER 5.选择计算场景 流式计算：消息触发，单挑处理，实时计算