yarn

1.摘要 大型数据分析框架正在朝着缩短任务执行时间和提高并行度的方向发展来提供低延迟，任务调度器面临的主要挑战是在几百毫秒内完成高度并行的作业调度，这需要在合适的机器上每秒调度数百万个任务，同时提供毫秒级的延迟和高可用性。本文证明了去中心化、随机抽样方法可提供最佳性能，同时避免了中心化设计存在吞吐量和高可用的问题。本文在110台计算机集群上部署Sparrow，并证明Sparrow的性能与理想的调度程序的误差在12%以内。 2.介绍 当今的数据分析集群运行的时间越来越短，作业的任务越来越多。在对低延迟交互式数据处理的需求的刺激下，研究机构和同行业共同努力产生了一些框架（例如Dremel，Spark，Impala）可以在数千台机器上工作，或将数据存储在内存以秒级分析大量数据，如图1所示。预计这种趋势会继续推动开发针对次秒级响应时间的新一代框架响应时间进入100ms左右，这让新的强大的应用程序成为可能；例如，面向用户的服务在每个查询的基础上将能够运行复杂的并行计算，比如语言翻译和高度个性化的搜索。 图1：数据分析框架分析大量数据的延迟非常低 调度由简短的次秒级任务组成的作业极具挑战，这些作业不仅是因为低延迟框架出现的，也有将长时间运行的批处理作业分解为大量短时间任务的原因。当任务以几百毫秒的速度运行时，调度决策必须有很高的吞吐量：一个由10000个16核机器组成的集群并运行100毫秒任务

一、软件准备 1、基础docker镜像：ubuntu，目前最新的版本是18 2、需准备的环境软件包： (1) spark-2.3.0-bin-hadoop2.7.tgz (2) hadoop-2.7.3.tar.gz (3) apache-hive-2.3.2-bin.tar.gz (4) jdk-8u101-linux-x64.tar.gz (5) mysql-5.5.45-linux2.6-x86_64.tar.gz、mysql-connector-java-5.1.37-bin.jar (6) scala-2.11.8.tgz (7) zeppelin-0.8.0-bin-all.tgz 二、ubuntu镜像准备 1、获取官方的镜像： docker pull ubuntu 2、因官方镜像中的apt源是国外资源，后续扩展安装软件包时较麻烦。先修改为国内源： （1）启动ubuntu容器，并进入容器中的apt配置目录 docker run -it -d ubuntu docker exec -it ubuntu /bin/bash cd /etc/apt （2）先将原有的源文件备份： mv sources.list sources.list.bak （3）换为国内源，这里提供阿里的资源。因官方的ubuntu没有艰装vi等软件，使用echo指令写入。需注意一点，资源必须与系统版本匹配

# Logs logs *.log npm-debug.log* yarn-debug.log* yarn-error.log* # Runtime data pids *.pid *.seed *.pid.lock # Directory for instrumented libs generated by jscoverage/JSCover lib-cov # Coverage directory used by tools like istanbul coverage # nyc test coverage .nyc_output # Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files) .grunt # Bower dependency directory (https://bower.io/) bower_components # node-waf configuration .lock-wscript # Compiled binary addons (https://nodejs.org/api/addons.html) build/Release # Dependency directories node_modules/ jspm_packages/

原文：https://my.oschina.net/wangmengjun/blog/864838 本文继续介绍Java自带的性能监测工具，本文使用jhat (Java Heap Analyse Tool)工具来玩~ jhat (Java Heap Analyse Tool) 是用来分析java堆的命令，可可以将对中的对象以html的形式展示，包括对象的数量、大小等信息，并支持对象查询语言 （OQL）。 先使用jps -l查看有哪些进程~ [root@dev03 ~]# jps -l 10838 sun.tools.jps.Jps 13823 org.apache.hadoop.hdfs.server.namenode.NameNode 13588 org.apache.hadoop.yarn.server.nodemanager.NodeManager 21983 org.apache.catalina.startup.Bootstrap 13941 org.apache.hadoop.hdfs.server.datanode.DataNode 13318 org.apache.hadoop.yarn.server.resourcemanager.ResourceManager 14097 org.apache.hadoop.hdfs.server.namenode

背景 在数据中台建设过程中，一个典型的数据集成场景是将 MQ (Message Queue，例如 Kafka、RocketMQ 等)的数据导入到 Hive 中，以供下游数仓建设以及指标统计。由于 MQ-Hive 是数仓建设第一层，因此对数据的准确性以及实时性要求比较高。 本文主要围绕 MQ-Hive 场景，针对目前字节跳动内已有解决方案的痛点，提出基于 Flink 的实时解决方案，并介绍新方案在字节跳动内部的使用现状。 已有方案及痛点 字节跳动内已有解决方案如下图所示，主要分了两个步骤： 通过 Dump 服务将 MQ 的数据写入到 HDFS 文件 再通过 Batch ETL 将 HDFS 数据导入到 Hive 中，并添加 Hive 分区 痛点 任务链较长，原始数据需要经过多次转换最终才能进入 Hive 实时性比较差，Dump Service、Batch ETL 延迟都会导致最终数据产出延迟 存储、计算开销大，MQ 数据重复存储和计算 基于原生 Java 打造，数据流量持续增长后，存在单点故障和机器负载不均衡等问题 运维成本较高，架构上无法复用公司内 Hadoop/Flink/Yarn 等现有基础设施 不支持异地容灾 基于 Flink 实时解决方案 优势 针对目前公司传统解决方案的痛点，我们提出基于 Flink 的实时解决方案，将 MQ 的数据实时写入到 Hive，并支持事件时间以及

安装 yarn add parcel-bundler parcel-plugin-externals package.json 忽视vscode, 添加watch "externals": [ "vscode" ], "scripts": { "lint": "eslint .", "pretest": "yarn run lint", "test": "node ./test/runTest.js", "watch": "parcel ./src/extension.js -d dist --target node", "build": "parcel build ./src/extension.js -d dist --target node" }, Launch.json // A launch configuration that launches the extension inside a new window // Use IntelliSense to learn about possible attributes. // Hover to view descriptions of existing attributes. // For more information, visit: https://go.microsoft.com/fwlink/?linkid

Spark 任务提交运行基本概念 基本概念 application :整个spark应用程序 driver :相当于驱动节点,负责资源申请,任务分配和监控,也即是运行main函数所在进程的节点,main函数中会创建 Sparkcontext(Spark上下文),它会包含spark env(spark 运行环境等),并且和 ClusterManager 通讯,申请资源 分配任务 监控任务,sparkContext中创建的类主要包括spark env, TaskScheduler(任务调度器), DAGScheduler (DAG调度器) executor :应用运行在worker节点(这里只的是物理节点,一个机器上的一个jvm)上的进程,该进程负责运行一些task,并且负责将这些task的运行过程中的数据存储在内存或者磁盘上,executor会将task包装成 taskRunner,然后从线程池中分配一个空闲的线程运行它,executor能并行运行多少个task,取决于给他分配的core的个数,一个core同一时间只能运行一个task. Worker : 集群中可以运行Application代码的节点。在Spark on Yarn模式中指的就是NodeManager节点 task : 在Executor进程中执行任务的工作单元，多个Task组成一个Stage

相信不少读者在开发 Flink 应用时或多或少会遇到在内存调优方面的问题，比如在我们生产环境中遇到最多的 TaskManager 在容器化环境下占用超出容器限制的内存而被 YARN/Mesos kill 掉[1]，再比如使用 heap-based StateBackend 情况下 State 过大导致 GC 频繁影响吞吐。这些问题对于不熟悉 Flink 内存管理的用户来说十分难以排查，而且 Flink 晦涩难懂的内存配置参数更是让用户望而却步，结果是往往将内存调大至一个比较浪费的阈值以尽量避免内存问题。 对于作业规模不大的普通用户而言，这些通常在可以接受的范围之内，但对于上千并行度的大作业来说，浪费资源的总量会非常可观，而且进程的不稳定性导致的作业恢复时间也会比普通作业长得多，因此阿里巴巴的 Blink 团队针对内存管理机制做了大量的优化，并于近期开始合并到 Flink。本文的内容主要基于阿里团队工程师宋辛童在 Flink Forward Beijing 的分享[2]，以及后续相关的几个 FLIP 提案。 Flink 目前（1.9）的内存管理 TaskManager 作为 Master/Slave 架构中的 Slave 提供了作业执行需要的环境和资源，最为重要而且复杂，因此 Flink 的内存管理也主要指 TaskManager 的内存管理。 TaskManager 的资源

[源码解析]Oozie来龙去脉之内部执行 目录 [源码解析]Oozie来龙去脉之内部执行 0x00 摘要 0x01 Oozie阶段 1.1 ActionStartXCommand 1.2 HiveActionExecutor 0x2 旧版本LauncherMapper 0x3 新版本Yarn Application Master 3. 1 YARN简介 3.2 ApplicationMaster 3.3 LauncherAM 0x4 Hive on Yarn 0x5 Tez计算框架 5.1 DAGAppMaster 5.2 与Resource Manager交互 0x6 Java on Yarn 0x7 Yarn job 执行结束 7.1 检查任务机制 7.2 回调机制 7.3 异步执行 7.3.1 CallableQueueService 7.3.3 PriorityDelayQueue 7.3.3 PollablePriorityDelayQueue 7.4 跳转下一个操作 0xFF 参考 0x00 摘要 Oozie由Cloudera公司贡献给Apache的基于工作流引擎的开源框架，是用于Hadoop平台的开源的工作流调度引擎，用来管理Hadoop作业，进行。本文是系列的第二篇，介绍Oozie的内部执行阶段。 前文 [源码解析]Oozie的来龙去脉 --- (1)提交任务阶段

0.Hive中的优化分类 真正想要掌握Hive的优化，要熟悉相关的MapReduce，Yarn，hdfs底层源码，明晰Hive的底层执行流程。真正让你明白Hive调优系列，会征对下面分类逐一分析演示。 大类1：参数优化 文件输入前看是否需要map前合并小文件 控制map个数，根据实际需求确认每个map的数据处理量，split的参数等 Map输出是否需要启动压缩，减少网络传输，OOM处理等 控制redcue个数，控制每个reduce的吞吐量，OOM处理等 是否将common-join转换成map-join处理策略 文件输出是否需要启动小文件合并策略 其他相关参数的配置：如严格模式，JVM重用，列剪切等 大类2：开发中优化 数据倾斜，这个是Hive优化的重头戏。出现的原因是因为出现了数据的重新分发和分布，启动了redcue。Hive中数据倾斜分类：group by ，count(distinct)以及join产生的数据倾斜（当然一些窗口函数中用了partition by一会造成数据倾斜） j oin相关的优化 ：分类大表join大表，小表join大表的优化 代码细节优化分类 ： 比如去重用group by替代distinct ； 多表关联，先进行子查询后再进行关联 ；表关联时一定要在子查询里过滤掉NULL值，避免数据倾斜； 不要对一个表进行重复处理，多使用临时表