Apache Spark

下一代大数据计算引擎 自从数据处理需求超过了传统数据库能有效处理的数据量之后，Hadoop 等各种基于 MapReduce 的海量数据处理系统应运而生。从 2004 年 Google 发表 MapReduce 论文开始，经过近 10 年的发展，基于 Hadoop 开源生态或者其它相应系统的海量数据处理已经成为业界的基本需求。 但是，很多机构在开发自己的数据处理系统时都会发现需要面临一系列的问题。从数据中获取价值需要的投入远远超过预期。常见的问题包括： 非常陡峭的学习曲线。刚接触这个领域的人经常会被需要学习的技术的数量砸晕。不像经过几十年发展的数据库一个系统可以解决大部分数据处理需求， Hadoop 等大数据生态里的一个系统往往在一些数据处理场景上比较擅长，另一些场景凑合能用，还有一些场景完全无法满足需求。结果就是需要好几个系统来处理不同的场景。 （来源： https://mapr.com/developercentral/lambda-architecture/ ） 上图是一个典型的 lambda 架构，只是包含了批处理和流处理两种场景，就已经牵涉到至少四五种技术了，还不算每种技术的可替代选择。再加上实时查询，交互式分析，机器学习等场景，每个场景都有几种技术可以选择，每个技术涵盖的领域还有不同方式的重叠。结果就是一个业务经常需要使用四五种以上的技术才能支持好一个完整的数据处理流程

接上篇文章 java 超大文件分片上传 在其基础上继续实现 断点续传和文件秒传功能 在上篇中，我们可以使用 file. slice 方法对文件进行分片，可以从后台读到当前文件已经上传的大小，就可以知道从哪里开始切片，断点续传的原理就是基于这个的。 前端计算文件的 md5 ，后台数据库查询一遍（前提是把 md5 存储了，计算文件 md5 也是需要消耗时间的）即可知道是否有相同文件，这是实现文件秒传的方法。 可能存在的问题： 有两个人同时在上传同一个文件，但前一个人还没有上传完成，此时第二个文件认为是新文件不能秒传 此时获取文件原数据时需要将文件信息保存起来，重点是要保存 md5 ，保证一个文件的 md5 保计算一次 获取断点文件时，真实的文件上传位置应该是从文件系统中读出来的 根据需求说明，后台应该存在四个接口，获取文件信息（包含是否可以秒传），获取断点文件列表，分片上传接口，文件完整性验证 全部源码位置 ： https://gitee.com/sanri/example/tree/master/test-mvc /** * 加载断点文件列表 * @return */ @GetMapping("/breakPointFiles") public List<FileInfoPo> breakPointFiles(){ List<FileInfoPo> fileInfoPos =

接上篇文章 java 超大文件分片上传 在其基础上继续实现 断点续传和文件秒传功能 在上篇中，我们可以使用 file. slice 方法对文件进行分片，可以从后台读到当前文件已经上传的大小，就可以知道从哪里开始切片，断点续传的原理就是基于这个的。 前端计算文件的 md5 ，后台数据库查询一遍（前提是把 md5 存储了，计算文件 md5 也是需要消耗时间的）即可知道是否有相同文件，这是实现文件秒传的方法。 可能存在的问题： 有两个人同时在上传同一个文件，但前一个人还没有上传完成，此时第二个文件认为是新文件不能秒传 此时获取文件原数据时需要将文件信息保存起来，重点是要保存 md5 ，保证一个文件的 md5 保计算一次 获取断点文件时，真实的文件上传位置应该是从文件系统中读出来的 根据需求说明，后台应该存在四个接口，获取文件信息（包含是否可以秒传），获取断点文件列表，分片上传接口，文件完整性验证 全部源码位置 ： https://gitee.com/sanri/example/tree/master/test-mvc /** * 加载断点文件列表 * @return */ @GetMapping("/breakPointFiles") public List<FileInfoPo> breakPointFiles(){ List<FileInfoPo> fileInfoPos =

1.简介 本篇文章主要讲如何使用java生成Avro格式数据以及如何通过spark将Avro数据文件转换成DataSet和DataFrame进行操作。 1.1Apache Arvo是什么？ Apache Avro 是一个数据序列化系统，Avro提供Java、Python、C、C++、C#等语言API接口，下面我们通过java的一个实例来说明Avro序列化和反序列化数据。 支持丰富的数据结构 快速可压缩的二进制数据格式 存储持久数据的文件容器 远程过程调用（RPC） 动态语言的简单集成 2.Avro数据生成 2.1定义Schema文件 1.下载avro-tools-1.8.1.jar Avro官网： http://avro.apache.org/ Avro版本：1.8.1 下载Avro相关jar包：avro-tools-1.8.1.jar 该jar包主要用户将定义好的schema文件生成对应的java文件 2.定义一个schema文件，命名为CustomerAdress.avsc { "namespace":"com.peach.arvo", "type": "record", "name": "CustomerAddress", "fields": [ {"name":"ca_address_sk","type":"long"}, {"name":"ca_address_id",

二进制all包多为spark2 scala2.11的所以源码编译本地相关版本兼容的包的及其它hadoop hive yarn 版本，源码git下载编译排错见前边文章，下为编译合适版本后的安装过程： 1.zeppelin081/conf/zeppelin-env.sh: export MASTER=local[2] #yarn-client #export SCALA_HOME=/usr/share/scala export SCALA_HOME=/opt/soft/scala-2.10.5 export HIVE_HOME=/opt/cloudera/parcels/CDH/lib/hive #export SPARK_HOME=/opt/cloudera/parcels/SPARK2/lib/spark2 export SPARK_HOME=/opt/cloudera/parcels/CDH/lib/spark export HADOOP_HOME=/opt/cloudera/parcels/CDH/lib/hadoop if [ -n "$HADOOP_HOME" ]; then export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${HADOOP_HOME}/lib/native fi #export SPARK_CONF_DIR=/etc

今天我将介绍如何在 Java 工程使用 Scala 代码。对于那些想在真实场景中尝试使用 Scala 的开发人员来说，会非常有意思。这和你项目中有什么类型的东西毫无关系：不管是Spring还是Spark还是别的。我们废话少说，开始吧。 抽象 Java Maven项工程 　　这里我们使用Maven来管理我们的 Java 项目，项目的结果如下所示： 如果想及时了解Spark、Hadoop或者Hbase相关的文章，欢迎关注微信公共帐号： iteblog_hadoop 正如你所看到的，工程的结构非常简单。它有标准的布局和仅仅三个Java类，如下所示： package com.iteblog.demo.model; /** * User: 过往记忆 * Date: 2016-12-30 * Time: 下午23:16 * bolg: https://www.iteblog.com * 本文地址：https://www.iteblog.com/archives/1947.html * 过往记忆博客，专注于hadoop、hive、spark、shark、flume的技术博客，大量的干货 * 过往记忆博客微信公共帐号：iteblog_hadoop */ public class Book { private String name = null; private String author =

本系列共两篇文章，会探讨如何将Ignite和Spark进行集成。 Ignite是一个分布式的内存数据库、缓存和处理平台，为事务型、分析型和流式负载而设计，在保证扩展性的前提下提供了内存级的性能。 Spark是一个流式数据和计算引擎，通常从HDFS或者其他存储中获取数据，一直以来，他都倾向于OLAP型业务，并且聚焦于MapReduce类型负载。 因此，这两种技术是可以互补的。 将Ignite与Spark整合 整合这两种技术会为Spark用户带来若干明显的好处： 通过避免大量的数据移动，获得真正可扩展的内存级性能； 提高RDD、DataFrame和SQL的性能； 在Spark作业之间更方便地共享状态和数据。 下图中显示了如何整合这两种技术，并且标注了显著的优势： 在本系列的第一篇文章中会聚焦于Ignite RDD，在第二篇文章中会聚焦于Ignite DataFrame。 Ignite RDD Ignite提供了一个SparkRDD的实现，叫做IgniteRDD，这个实现可以在内存中跨Spark作业共享任何数据和状态，IgniteRDD为Ignite中相同的内存数据提供了一个共享的、可变的视图，它可以跨多个不同的Spark作业、工作节点或者应用，相反，原生的SparkRDD无法在Spark作业或者应用之间进行共享。 IgniteRDD作为Ignite分布式缓存的视图

在 前面的文章 中，我们分别介绍了 Ignite 和 Spark 这两种技术，从功能上对两者进行了全面深入的对比。经过分析，可以得出这样一个结论：两者都很强大，但是差别很大，定位不同，因此会有不同的适用领域。 但是，这两种技术也是可以互补的，那么它们互补适用于场景是什么呢？主要是这么几个方面：如果觉得 Spark 中的 SQL 等运行速度较慢，那么 Ignite 通过自己的方式提供了对 Spark 应用进行进一步加速的解决方案，这方面可选的解决方案并不多，推荐开发者考虑，另外就是数据和状态的共享，当然这方面的解决方案也有很多，并不是一定要用 Ignite 实现。 Ignite 原生提供了对 Spark 的支持，本文主要探讨 为何 与 如何 将 Ignite 和 Spark 进行集成。 1.将 Ignite 与 Spark 整合 整合这两种技术会为 Spark 应用带来若干明显的好处： 通过避免大量的数据移动，获得真正可扩展的内存级性能； 提高 RDD、DataFrame 和 SQL 的性能； 在 Spark 作业之间更方便地共享状态和数据。 下图显示了如何整合这两种技术，并且标注了显著的优势： 通过该图，可以从整体架构的角度看到 Ignite 在整个 Spark 应用中的位置和作用。 Ignite 对 Spark 的支持主要体现为两个方面，一个是 Ignite RDD，一个是

1.问题描述 Spark的HistoryServer能正常查看之前的历史作业日志，但新提交的作业在执行完成后未能在HistoryServer页面查看。 2.问题复现 1.分别使用root和ec2-user用户执行作业 2.通过sparkHistory Server可以正常查看到所有历史作业 3.将/user/spark/applicationHistory目录的所属组修改为supergroup，再次执行作业 sudo –u hdfs hadoop dfs –chown spark:supergroup /user/spark/applicationHistroy 作业执行完成 HDFS上正常记录了spark作业日志，但作业所属group为supergroup sparkHistoryServer报异常，没有权限访问历史job目录 4.在History Server未查看到刚执行完成的007作业 3.问题原因 由于/user/spark/applicationHistory目录的所属组为supergroup，导致所有用户作业的目录均为supergroup组，之前能正常查看的历史作业由于目录的所属组任为spark。 4.解决方法 将/user/spark/applicationHistory目录及该目录下的子目录所属组修改为spark sudo –u hdfs hadoop dfs

1. 介绍 这三个计算框架常常被拿来比较。从我的角度来看，三者的比较可以分为两类(mini-batches vs. streaming)。spark streaming属于微批量的伪流式准实时计算框架(spark本身属于批处理框架)。而flink和storm则作为典型的实时流处理框架。 2. spark vs flink 两者虽然有很多设计实现思路上比较接近以及互相学习，但是主要区别还是mini-batch和streaming的选择上。根据实际场景在吞吐量和实时性上做权衡。 3. flink vs storm 名称 批处理 数据处理保证 api level 容错机制 storm 不支持 at least once(实现采用record-level acknowledgments)，Trident可以支持storm 提供exactly once语义 low record-level acknowledgments flink 支持 exactly once（实现采用Chandy-Lamport 算法，即marker-checkpoint ） high marker-checkpoint 4. 其他资料 5. 总结 我写的比较简略。强烈建议看看下面我罗列的参考资料，都写的很不错。 参考资料： What is/are the main difference(s) between