Apache Spark

前言 不知不觉，2020年已经过去一半了，最近突然反应过来自己也看了不少文献资料了，就想着把看过的文献和觉得比较好的书籍做一个总结，基本都是大数据分布式领域的，回顾自己学识的同时，也给想从事或这个领域的小伙伴一些参考 😃。最后顺便把接下来要看的东西列个列表，也会将自己学习的心得和经验分享出来，有需要的童鞋可以参考参考。 另外有些文献看完我会进行整理和输出，这部分链接我一并附在文献的介绍后面，后面看的书或是文献也会保持这种习惯，如果觉得有兴趣欢迎各位大佬交流，顺便也可以点波关注~~ 论文总结 MapReduce 《MapReduce Simplified Data Processing on Large Clusters》 从现在的眼光来看，Mapreduce可以说可圈可点。但在那个年代，这个思想可以说是相当先进的。不得不说Google一直引领技术潮流，包括近几年流行的k8s也是Google主导。 这篇文章主要介绍了Mapreduce的流程还有一些细节方面的介绍，如果已经有使用过Mapreduce编程的小伙伴应该看一遍就能懂。另外，看完如果想加以巩固的话，推荐做MIT6.824的Lab1，用go实现一个Mapreduce。至于什么是Mit6.824，百度一下就知道喔。我以前也有写过一篇介绍MR，有兴趣的童鞋不妨看看： 从分治算法到 Hadoop MapReduce 。 地址：

一 、 介绍 KNIME Analytics Platform是用于创建数据科学应用程序和服务的开源软件。KNIME直观，开放，不断整合新的开发，使人们可以理解数据，设计数据科学工作流程和可重用组件。 借助KNIME Analytics Platform，您可以使用直观的拖放式图形界面创建可视化工作流程，而无需编码。 在本快速入门指南中，我们将引导您完成KNIME Workbench，并向您展示如何构建您的第一个工作流程。 二 、启动KNIME Analytics Platform 如果您尚未安装KNIME Analytics Platform，则可以在此 https://www.knime.com/downloads 下载。 启动KNIME Analytics Platform，当KNIME Analytics Platform Launcher窗口出现时，在此处定义KNIME工作区，如图1所示。 图1. KNIME Analytics Platform Launcher KNIME工作区是本地计算机上的一个文件夹，用于存储KNIME工作流，节点设置和工作流生成的数据。存储在工作区中的工作流程和数据可通过KNIME Workbench左上角的KNIME Explorer获得。 选择文件夹作为项目的KNIME工作区后，单击“ 启动”。在使用时，KNIME Analytics

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 导读： 一次机缘巧合，在研究BI产品技术选型的时候，我接触到了ClickHouse，瞬间就被其惊人的性能所折服。这款非Hadoop生态、简单、自成一体的技术组件引起了我极大的好奇。那么ClickHouse好在哪呢？本文带你做一个初步了解。 01 传统BI系统之殇 得益于IT技术的迅猛发展，ERP、CRM这类IT系统在电力、金融等多个行业均得以实施。这些系统提供了协助企业完成日常流程办公的功能，其应用可以看作线下工作线上化的过程，这也是IT时代的主要特征之一，通常我们把这类系统称为联机事务处理（OLTP）系统。 企业在生产经营的过程中，并不是只关注诸如流程审批、数据录入和填报这类工作。站在监管和决策层面，还需要另一种分析类视角，例如分析报表、分析决策等。而IT系统在早期的建设过程中多呈烟囱式发展，数据散落在各个独立的系统之内，相互割裂、互不相通。 为了解决数据孤岛的问题，人们提出了数据仓库的概念。即通过引入一个专门用于分析类场景的数据库，将分散的数据统一汇聚到一处。借助数据仓库的概念，用户第一次拥有了站在企业全局鸟瞰一切数据的视角。 随着这个概念被进一步完善，一类统一面向数据仓库，专注于提供数据分析、决策类功能的系统与解决方案应运而生。最终于20世纪90年代，有人第一次提出了BI

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

笔记作者：来自于阿里P8级架构师： Mark 笔记特点：条理清晰，含图像化表示更加易懂。 内容概要：包括 Java 集合、JVM、多线程、并发编程、设计模式、Spring全家桶、Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、MongoDB、Redis、MySQL、RabbitMQ、Kafka、Linux、Netty、Tomcat等大厂面试题等、等技术栈！ 由于整个文档比较全面，内容比较多，篇幅不允许，下面以截图方式展示 。 JAVA集合 接口继承关系和实现 List ArrayList（数组） Vector（数组实现、线程同步） LinkList（链表） Set HashSet（Hash表） TreeSet（二叉树） JVM JVM就是java虚拟机,它是一个虚构出来的计算机,可在实际的计算机上模拟各种计算机的功能。JVM有自己完善的硬件结构,例如处理器、堆栈和寄存器等,还具有相应的指令系统。 线程 JVM内存区域 JVM运行时内存 垃圾回收与算法 JAVA 四种引用类型 GC分代收集算法 VS 分区收集算法 GC垃圾收集器 JAVA IO/NIO JVM 类加载机制 JAVA多线程并发 JAVA并发知识库 JAVA线程实现/创建方式 4种线程池 线程生命周期(状态) 终止线程4种方式 sleep与wait 区别

Spark憋了一年半的大招后，发布了3.0版本，新特性主要与Spark SQL和Python相关。这也恰恰说明了大数据方向的两大核心：BI与AI。下面是本次发布的主要特性，包括性能、API、生态升级、数据源、SQL兼容、监控和调试等方面的升级。 本次主要整理了性能方面的优化，包括了自适应查询与动态分区裁剪。 1 自适应查询 AQE，Adaptive Query Execution，说的简单点就是让Spark在运行中根据搜集到的信息灵活采取优化手段，提升性能。 说起这个可以先回想下Spark的发展历史，在1.x时代Spark通过RDD的编程形成DAG图，这个阶段可以说没啥优化完全是按照规则来执行；在2.x时代，引入了代价计算，Spark会通过提前进行代价计算，选择代价最小的查询计划（跟大部分的数据库类似，代价计算依赖于数据本身的统计，如数据量、文件大小、分区数等，由于Spark是存储与计算分离的模式，因此这些统计信息有时候会缺失或者不准确，那么得到的查询代价自然也就不准确了）；在3.x时代，引入自适应查询，即在运行的过程中可以根据得到的缓存数据信息动态调整分区策略、join策略等。这样就保证了刚开始表的统计信息不准，可能查询计划不是最高效的，但是随着查询的执行，可以动态优化整个查询计划。 那么到底自适应都可以做什么呢？ 1.1 动态分区合并 在Spark的经典优化策略里

一个近期由Hudi PMC & Uber Senior Engineering Manager Nishith Agarwal分享的Talk 关于Nishith Agarwal更详细的介绍，主要从事数据方面的工作，包括摄取标准化，数据湖原语等。 什么是数据湖？数据湖是一个集中式的存储，允许以任意规模存储结构化和非结构化数据。你可以存储原始数据，而不需要先转化为结构化的数据，基于数据湖之上可以运行多种类型的分析，如dashboard、大数据处理的可视化、实时分析、机器学习等。 接着看看对于构建PB级数据湖有哪些关键的要求 第一个要求：增量摄取（CDC） 企业中高价值的数据往往存储在OLTP中，例如下图中，users表包含用户ID，国家/地区，修改时间和其他详细信息，但OLTP系统并未针对大批量分析进行优化，因此可能需要引入数据湖。同时一些企业采用备份在线数据库的方式，并将其存储到数据湖中的方法来摄取数据，但这种方式无法扩展，同时它给上游数据库增加了沉重的负担，也导致数据重写的浪费，因此需要一种增量摄取数据的方法。 第二个要求：Log Event去重 考虑分析大规模时间序列数据的场景，这些事件被写入数据管道，并且数量非常大，可达数十亿，每秒可达百万的量。但流中可能有重复项，可能是由于至少一次（atleast-once）保证，数据管道或客户端失败重试处理等发送了重复的事件

首先建议先看一下基于前面的字节码知识： Java字节码的一段旅行经历——提升硬实力1 在日常的项目开发中，经常遇到a++、++a、a--之类，下面我们开始从字节码的视角来分析a++。 java代码如下： /* 从字节码角度分析 a++ 相关题目 */ public class T03_ByteAnalyseAPlusPlus { public static void main(String[] args) { int a = 10; int b = a++ + ++a + a--; System.out.println(a); System.out.println(b); } } 使用javap -v xxx.class 来查看类文件全部指令信息：javap -v T03_ByteAnalyseAPlusPlus，如下： public static void main(java.lang.String[]); descriptor: ([Ljava/lang/String;)V flags: ACC_PUBLIC, ACC_STATIC Code: stack=2, locals=3, args_size=1 0: bipush 10 2: istore_1 3: iload_1 4: iinc 1, 1 7: iinc 1, 1 10: iload_1 11: iadd 12:

Detected both log4j-over-slf4j.jar AND slf4j-log4j12.jar 解决方法 问题： 导入spark依赖包后，local模式下运行spark本地程序报错： Caused by: java.lang.IllegalStateException: Detected both log4j-over-slf4j.jar AND slf4j-log4j12.jar on the class path， preempting StackOverflowError. See also http://www.slf4j.org/codes.html#log4jDelegationLoop for more details. 这个错运行spark程序比较常见，由于很多maven项目中都依赖了log4j的包，这里需要针对冲突的包执行exclude即可 第一层（exclusion 报错jar 包的log4j即可）： 网上最常见的解决方法，也是报错日志官方给出的解决方案 假设我加入了spark core的依赖包： <dependency> <groupId>org.apache.spark</groupId> <artifactId>spark-core_2.11</artifactId> <version>2.2.1</version> <

写在前面： 最近，数据湖的概念非常热，许多前线的同学都在讨论数据湖应该怎么建？阿里云有没有成熟的数据湖解决方案？阿里云的数据湖解决方案到底有没有实际落地的案例？怎么理解数据湖？数据湖和大数据平台有什么不同？头部的云计算玩家都各自推出了什么样的数据湖解决方案？带着这些问题，我们尝试写了这样一篇文章，希望能抛砖引玉，引起大家一些思考和共鸣。感谢南靖同学为本文编写了5.1节的案例，感谢西壁的review。 本文包括七个小节：1、什么是数据湖；2、数据湖的基本特征；3、数据湖基本架构；4、各厂商的数据湖解决方案；5、典型的数据湖应用场景；6、数据湖建设的基本过程；7、总结。受限于个人水平，谬误在所难免，欢迎同学们一起探讨，批评指正，不吝赐教。 一、什么是数据湖 数据湖是目前比较热的一个概念，许多企业都在构建或者计划构建自己的数据湖。但是在计划构建数据湖之前，搞清楚什么是数据湖，明确一个数据湖项目的基本组成，进而设计数据湖的基本架构，对于数据湖的构建至关重要。关于什么是数据湖，有如下定义。 Wikipedia是这样定义的： A data lake is a system or repository of data stored in its natural/raw format,[1] usually object blobs or files. A data lake is usually