Apache Spark

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 在Spark 1.5版本及以前，Spark采用静态内存管理模型。Spark 1.6版本推出以后，Spark采用了统一内存管理模型。 静态内存管理模型中 Spark在一个Executor中的内存分为三块，一块是execution内存，一块是storage内存，一块是other内存。 JVM On_heap 内存 1.storage内存是存储broadcast，cache，persist数据的地方。其中10%（60% 10%）用于防止OOM。另外90%中的20%用于unroll，数据展开的（比如说，rdd.perist让数据序列化持久化，当要读出来的时候就需要反序列化，可以理解为解压，这就需要unroll这部分的内存空间了），其余的内存（90% 80%）用于RDD缓存数据和广播变量。 2.execution内存是执行内存，文档中说join，aggregate都在这部分内存中执行，shuffle的数据也会先缓存在这.个内存中，满了再写入磁盘，能够减少IO。其实map过程也是在这个内存中执行的。 3.other内存是程序执行时预留给自己的内存，像task的执行和task执行时产生的对象。 从Spark 1.6版本推出以后，Spark采用了统一内存管理模型。Spark 2.1.0 新型 JVM Heap 分成三个部份

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> ## mmlspark https://mvnrepository.com/artifact/Azure/mmlspark/0.15 ## lightgbmlib https://mvnrepository.com/artifact/com.microsoft.ml.lightgbm/lightgbmlib/2.2.200 [root@hadoop-1-1 ~]# more lgbm.sh /app/spark2.3/bin/spark-submit \ --master yarn \ --jars /root/external_pkgs/mmlspark-0.15.jar,/root/external_pkgs/lightgbmlib-2.2.200.jar \ --class com.sf.demo.lgmClassifier /root/lgbm_demo.jar nohup sh lgbm.sh > lgbm_20191226_001.log 2>&1 & package com.xx.demo import org.apache.spark.SparkConf import org.apache.spark.sql.SparkSession import org.apache.spark.ml

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 几十个问题，万字长文，阿里云新任总裁行癫履新后首次出面与钛媒体独家深入讨论了一下阿里云对云计算未来的判断，深度解读未来阿里云生态战略，揭秘阿里技术委员会和阿里中台思想的原生思考。转载自钛媒体，作者：刘湘明 。标题为 《钛媒体独家对话行癫：最详解密阿里云顶层设计和底层逻辑》 。分享给大家。 阿里云智能总裁张建锋 钛媒体注 ：张建锋（花名行癫）的阿里生涯，一直在踩着技术与业务的交界线前进，某种意义上可以看作阿里战略重点转移的缩影——在担任集团CTO和阿里云总裁之前，他先后管过淘宝网技术架构部、B2C开发部及淘宝网产品技术开发部，还分管过聚划算事业部、本地生活事业部、1688事业部及天猫事业部。2015年还担任过阿里中国零售事业群总裁。 2018年11月，还在担任阿里巴巴集团首席技术官，同时也在负责达摩院的张建锋，被任命为阿里云智能事业群总裁。 云计算的市场发展很快，根据调研机构Canalys给出的数据，2018年全球云计算市场规模突破800亿美元，达到804亿美元，同比增长46.5%。市场的高速发展，也带来云生态环境的快速变化，技术、客户需求、伙伴关系都伴随着规模的扩张和应用的深入在不停地演变。 张建锋过往的这些经历，对于他在这个快速变化的云生态环境里，理解技术与业务的关系，切换合作伙伴视角去思考问题

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 背景 消息报表主要用于统计消息任务的下发情况。比如，单条推送消息下发APP用户总量有多少，成功推送到手机的数量有多少，又有多少APP用户点击了弹窗通知并打开APP等。通过消息报表，我们可以很直观地看到消息推送的流转情况、消息下发到达成功率、用户对消息的点击情况等。 个推在提供消息推送服务时，为了更好地了解每天的推送情况，会从不同的维度进行数据统计，生成消息报表。个推每天下发的消息推送数巨大，可以达到数百亿级别，原本我们采用的离线统计系统已不能满足业务需求。随着业务能力的不断提升，我们选择了Flink作为数据处理引擎，以满足对海量消息推送数据的实时统计。 本文将主要阐述选择Flink的原因、Flink的重要特性以及优化后的实时计算方法。 离线计算平台架构 在消息报表系统的初期，我们采用的是离线计算的方式，主要采用spark作为计算引擎，原始数据存放在HDFS中，聚合数据存放在Solr、Hbase和Mysql中： 查询的时候，先根据筛选条件，查询的维度主要有三个： appId 下发时间 taskGroupName 根据不同维度可以查询到taskId的列表，然后根据task查询hbase获取相应的结果，获取下发、展示和点击相应的指标数据。在我们考虑将其改造为实时统计时，会存在着一系列的难点： 原始数据体量巨大

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 前段时间收到某个 Kafka 集群的生产客户端反馈发送消息耗时很高，于是花了一段时间去排查这个问题，最后该集群进行扩容，由于某些主题的当前数据量实在太大，在对这些主题迁移过程中话费了很长一段时间，不过这个过程还算顺利，因为在迁移过程中也做足了各方面的调研，包括分区重平衡过程中对客户端的影响，以及对整个集群的性能影响等，特此将这个过程总结一下，也为双十一打了一剂强心剂。 排查问题与分析 接到用户的反馈后，我用脚本测试了一遍，并对比了另外一个正常的 Kafka 集群，发现耗时确实很高，接下来 经过排查，发现有客户端在频繁断开与集群节点的连接，发现日志频繁打印如下内容： Attempting to send response via channel for which there is no open connection, connection id xxx(kafka.network.Processor) 定位到源码位置： kafka.network.Processor#sendResponse： 看源码注释，是远程连接关闭了或者空闲时间太长了的意思，找到具体客户端负责人，经询问后，这是大数据 Spark 集群的节点。 从以上日志看出，Spark 集群的某个消费组 OrderDeliveryTypeCnt

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一 检索模型 1.1 bool模式 bool模式下，是最简单的检索模式，依据操作符AND 或者 OR 过滤document,结果只是包含指定的term的文档。他不会对document打分，只是为了减少后续要计算的document的数量，提升性能 1.2 TF/IDF TF 是 term frequency的缩写，表示这个词条term在该文档出现的频率，往往能够表现文档的主体信息，即TF值越大，应该给于这个单词更大权值，具体计算词频因子的时候，基于不同的出发点，可以采纳不同的计算公式，最直接的方式就是直接利用词频数。假设某一个term出现过5次，那么这个term的TF值就是5，还有些变体计算公式: 第一个变体，为身取log是因为基于如下考虑：假设一个term出现了10次，也不该在计算权值时比出现1次的情况大10倍。加上1的目的是为进行平滑，比如TF就是1，那么计算对数，就是0，本来出现了一次的term,现在是不出现了。所以需要+1进行平滑。 第二个变体：a 是调节因子，0.4效果更好，TF表示实际的词频数，Max(TF)表示文档中所有单词出现次数最多的单词对应的词频数。 之所以这样做是因为：出于对长文档的限制，因为如果文档比较长，与短文档相比，则长文档中所有单词的TF值普遍比短文档高

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一、总述 为了应对日志实时分析的需求，选择的实时处理框架为kafka + SparkStreaming + mongoDB. 具体流程是将数据(此次demo是从文件中读取某一行数据)实时写入到kafka中，SparkStreaming 按一定时间间隔(1s, 5s, 10s等) 从kafka中读取数据，经过加工处理，最后将数据实时写入到mongoDB中，同时会将数据沉淀到hdfs中，做为历史数据用于后期hive的批量加工分析。 二、集群部署 需要部署Kafka集群+Spark集群+Mongo ，具体部署过程可参考其它文档 三、SparkStreaming运行原理 此次案例中使用SparkStreaming，spark streaming是将持续不断输入的数据流转换成多个batch分片，使用一批spark应用实例进行处理。 四、流程实现 1. Kafka部分 1.1 说明 从文件中随机读取某一行数据写入到kafka中 1.2 实现 1) 创建maven 项目 在pom.xml中添加如下依赖 <dependency> <groupId>org.apache.kafka</groupId> <artifactId>kafka_2.11</artifactId> <version>1.0.1</version> <

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Join背景 当前SparkSQL支持三种join算法：Shuffle Hash Join、Broadcast Hash Join以及Sort Merge Join。 其中前两者归根到底都属于Hash Join，只不过载Hash Join之前需要先Shuffle还是先Broadcast。 其实，Hash Join算法来自于传统数据库，而Shuffle和Broadcast是大数据在分布式情况下的概念，两者结合的产物。 因此可以说，大数据的根就是传统数据库。Hash Join是内核。 Spark Join的分类和实现机制 上图是Spark Join的分类和使用。 Hash Join 先来看看这样一条SQL语句：select * from order,item where item.id = order.i_id，参与join的两张表是order和item，join key分别是item.id以及order.i_id。现在假设Join采用的是hash join算法，整个过程会经历三步： 确定Build Table以及Probe Table：这个概念比较重要，Build Table会被构建成以join key为key的hash table，而Probe Table使用join key在这张hash

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> checkpoint的意思就是建立检查点,类似于快照,例如在spark计算里面 计算流程DAG特别长,服务器需要将整个DAG计算完成得出结果,但是如果在这很长的计算流程中突然中间算出的数据丢失了,spark又会根据RDD的依赖关系从头到尾计算一遍,这样子就很费性能,当然我们可以将中间的计算结果通过cache或者persist放到内存或者磁盘中,但是这样也不能保证数据完全不会丢失,存储的这个内存出问题了或者磁盘坏了,也会导致spark从头再根据RDD计算一遍,所以就有了checkpoint,其中checkpoint的作用就是将DAG中比较重要的中间数据做一个检查点将结果存储到一个高可用的地方(通常这个地方就是HDFS里面) 一般我们先进行cache然后做checkpoint就会只走一次流程,checkpoint的时候就会从刚cache到内存中取数据写入hdfs中 其中作者也说明了,在checkpoint的时候强烈建议先进行cache,并且当你checkpoint执行成功了,那么前面所有的RDD依赖都会被销毁 来源： oschina 链接： https://my.oschina.net/u/660188/blog/1838692

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 网上一大把资源来介绍cache的好处优点，但有的时候偏偏就是会溢出，那么来说说‘同父异母’的方法persist的使用吧 ，完美的解决了cache内存溢出的尴尬。 两者都是持久化Rdd的方式，但是persist方法是包含cache方法的： 在persist的持久化方法有很多种组和 MEMORU_ONLY 指的就是cache 参数代表的含义分别是：是否使用磁盘缓存、是否使用内存、是否使用对外内存、是否使用反序列化 DISK_ONLY：全部用磁盘缓存（一般你的需要持久化的RDD或者DF等特别大的时候可以用这种） DISK_ONLY_2：和上边这个类似就是多了最后一个参数，表示每个分区在两个节点上创建副本 MEMORY_AND_DISK：使用磁盘加内存 （一般不是特别大的需求的时候比较推荐，最起码内存满了会自动写磁盘 ） 最后几个带_SER:的就是用java对象的方式进行存储，相比于前几种的同类型存储来说就是速度快了，但是更吃cpu 不管那个方法用完记得释放：unpersist（）！！！！ 举例调用代码： //持久化防治溢出 调用persist方法 里面要传入相应的缓存等级，这里使用的是内存加磁盘 Dataset<Row> goodsSpecPersist = goodsSpec.persist