bigbigtree_个人页

通过pyspark库操作spark，参见：https://spark.apache.org/docs/latest/api/python/index.html

首先定义表结构，然后通过tunnel工具上传csv文件，导入数据

有损的方法： 找到异常数据，过滤掉 无损的方法： 对分布不均匀的数据，单独计算 先对key做一层hash，先将数据打散让它的并行度变大，再汇集

spark sql速度更快，性能更高，但内存资源消耗多，稳定性不如hive sql

建议直接在mysql数据表中增加unique key约束，由数据库端做数据去重

确定具体慢的task对应的kafka的分区id，确定分区id所在的物理环境，排查机器是否有问题

PROCESS_LOCAL 进程本地化，表示 task 要计算的数据在同一个 Executor 中。 NODE_LOCAL 节点本地化，速度稍慢，因为数据需要在不同的进程之间传递或从文件中读取。分为两种情况，第一种：task 要计算的数据是在同一个 worker 的不同 Executor 进程中。第二种：task 要计算的数据是在同一个 worker 的磁盘上，或在 HDFS 上恰好有 block 在同一个节点上。如果 Spark 要计算的数据来源于 HDFSD 上，那么最好的本地化级别就是 NODE_LOCAL。 NO_PREF 没有最佳位置，数据从哪访问都一样快，不需要位置优先。比如 Spark SQL 从 Mysql 中读取数据。 RACK_LOCAL 机架本地化，数据在同一机架的不同节点上。需要通过网络传输数据以及文件 IO，比 NODE_LOCAL 慢。情况一：task 计算的数据在 worker2 的 EXecutor 中。情况二：task 计算的数据在 work2 的磁盘上。 ANY 跨机架，数据在非同一机架的网络上，速度最慢。

作业执行流程描述： 客户端提交作业给Master Master让一个Worker启动Driver，即SchedulerBackend。Worker创建一个DriverRunner线程，DriverRunner启动SchedulerBackend进程。 另外Master还会让其余Worker启动Exeuctor，即ExecutorBackend。Worker创建一个ExecutorRunner线程，ExecutorRunner会启动ExecutorBackend进程。 ExecutorBackend启动后会向Driver的SchedulerBackend注册。SchedulerBackend进程中包含DAGScheduler，它会根据用户程序，生成执行计划，并调度执行。对于每个stage的task，都会被存放到TaskScheduler中，ExecutorBackend向SchedulerBackend汇报的时候把TaskScheduler中的task调度到ExecutorBackend执行。 所有stage都完成后作业结束。

HashPartitioner确定分区的方式：partition = key.hashCode () % numPartitions 弊端：弊端是数据不均匀，容易导致数据倾斜，极端情况下某几个分区会拥有rdd的所有数据。

累加器是Spark的一种变量，顾名思义该变量只能增加。有以下特点： 1，累加器只能在Driver端构建及并只能是Driver读取结果，Task只能累加。 2，累加器不会改变Spark Lazy计算的特点。只会在Job触发的时候进行相关累加操作。 3，现有累加器的类型。

在hadoop的mapreduce中默认patitioner是HashPartitioner,我们可以自定义Partitioner可以有效防止数据倾斜, 在Spark里面也是一样,在Spark里也是默认的HashPartitioner, 如果自己想自己定义Partitioner继承org.apache.spark里面的Partitioner并且重写它里面的两个方法就行了

从整体功能上看，两者并没有大的差别。 都是将 mapper（Spark 里是 ShuffleMapTask）的输出进行 partition，不同的 partition 送到不同的 reducer（Spark 里 reducer 可能是下一个 stage 里的 ShuffleMapTask，也可能是 ResultTask）。Reducer 以内存作缓冲区，边 shuffle 边 aggregate 数据，等到数据 aggregate 好以后进行 reduce（Spark 里可能是后续的一系列操作）。 从流程的上看，两者差别不小。 Hadoop MapReduce 是 sort-based，进入 combine和 reduce的 records 必须先 sort。这样的好处在于 combine/reduce可以处理大规模的数据，因为其输入数据可以通过外排得到（mapper 对每段数据先做排序，reducer 的 shuffle 对排好序的每段数据做归并）。以前 Spark 默认选择的是 hash-based，通常使用 HashMap 来对 shuffle 来的数据进行合并，不会对数据进行提前排序。如果用户需要经过排序的数据，那么需要自己调用类似 sortByKey的操作。在Spark 1.2之后，sort-based变为默认的Shuffle实现。 从流程实现角度来看，两者也有不少差别。 Hadoop MapReduce 将处理流程划分出明显的几个阶段：map, spill, merge, shuffle, sort, reduce等。每个阶段各司其职，可以按照过程式的编程思想来逐一实现每个阶段的功能。在 Spark 中，没有这样功能明确的阶段，只有不同的 stage 和一系列的 transformation，所以 spill, merge, aggregate 等操作需要蕴含在 transformation中。

通过分区聚合，避免任务过多，导致资源浪费

BlockManager 是整个 Spark 底层负责数据存储与管理的一个组件，Driver 和 Executor 的所有数据都由对应的 BlockManager 进行管理。 Driver 上有 BlockManagerMaster，负责对各个节点上的 BlockManager 内部管理 的数据的元数据进行维护，比如 block 的增删改等操作，都会在这里维护好元数据 的变更。每个节点都有一个 BlockManager，每个 BlockManager 创建之后，第一件事即去向 BlockManagerMaster 进行注册

原则一：避免创建重复的RDD，尽可能复用同一个RDD 对于同一份数据不要创建多个RDD，对不同的数据执行算子操作时要尽可能地复用一个RDD。 原则二：对多次使用的RDD进行持久化 前面已经提到Spark中rdd内部的转换关系是一个DAG，因此对于一个RDD执行多次算子时，都会重新从源头处计算一遍，这种方式的性能是很差的。如下图所示，其中D和E代表action算子，在计算D和E时要分别从A开始计算。 有向无环图（DAG） 最好的方法就是对C进行持久化，此时Spark就会将数据保存到内存或者磁盘中，以后每次对C这个RDD进行算子操作时，都会直接从内存或磁盘中提取持久化的RDD数据，不会从源头处重新计算一遍。 原则三：尽量避免使用shuffle类算子 Spark作业运行过程中，最消耗性能的地方就是shuffle过程。shuffle过程就是将分布在集群中多个节点上的同一个key，拉取到同一个节点上，进行groupby或join等操作，reduceByKey、join、distinct、repartition等都属于shuffle算子。 原则四：使用预聚合的shuffle操作 如果有些时候实在无法避免使用shuffle操作，那么尽量使用可以预聚合的算子。预聚合就是在每个节点本地对相同的key进行一次聚合操作，多条相同的key被聚合起来后，那么其他节点再拉取所有节点上的相同key时，就会大大减少磁盘IO以及网络传输开销。下图所示，每个节点本地首先对于相同key进行了聚合。 原则五：使用高性能的算子 除了shuffle相关的算子有优化原则之外，其他的算子也都有着相应的优化原则，不一一陈述。

B

从字面意思上，说是kafka topic的offset越界异常；在job中使用的是Kafka DirectStream，每成功处理一批数据，就把对应的offset更新到zookeeper中；和数组越界异常一样，offset越界应该分为头越界和尾越界，如下图所示。 头部越界： zookeeper中保存的offset在topic中仍然存在的最老message的offset之前时(zk_offset last_offset)

实时一般是ms级别延迟；准实时可以允许秒级延迟。

生态圈对比： 大数据领域一个项目的火热离不开相关的技术栈，Spark和Flink基于对底层数据和计算调度的高度抽象的内核（Core）开发出了批处理，流处理，结构化数据，图数据，机器学习等不同套件，完成对绝大多数数据分析领域的场景的支持，意欲一统大数据分析领域。统计作为计算引擎，也很好的支持了与周边大数据分析项目的兼容， Spark和Flink均有Scala/Java混合编程实现，Spark的核心逻辑由Scala完成，Flink的主要核心逻辑由Java完成 支持应用语言 Flink主要支持Scala，和Java编程，部分API支持python应用 Spark主要支持Scala，Java，Python,R语言编程，部分API暂不支持Python和R

需要注意任务的计算量与费用是相关的。。。￣□￣｜｜