HDFS

参考文章： 使用springboot构建rest api远程提交spark任务 spark-submit动态提交的办法（SparkLauncher实战） 用java提交一个Spark应用程序 Spark-利用SparkLauncher 类以JAVA API 编程的方式提交spark job --impt 官网API参考: http://spark.apache.org/docs/latest/api/java/index.html?org/apache/spark/launcher/package-summary.html github代码链接：github地址 1. spark集群及版本信息 服务器版本：centos7 hadoop版本：2.8.3 spark版本：2.3.3 使用springboot构建rest api远程提交spark任务，将数据库中的表数据存储到hdfs上，任务单独起一个项目，解除与springboot项目的耦合 2. 构建springboot项目 1. pom配置 <properties> <java.version>1.8</java.version> <spark.version>2.3.3</spark.version> <scala.version>2.11</scala.version> </properties> <dependencies>

文章目录 前言 NameNode请求处理慢的场景 RPC返回response的Handler处理慢问题 HDFS RPC call异步response改造 前言 众所周知，在HDFS NameNode中，一直都有一个老生常谈的难题就是其扩展性的问题，而很多时候我们说HDFS的扩展性问题时我们很多时候都在谈的点在于里面全局锁的问题。一个很通常的场景是NameNode在高并发请求处理下存在着激烈的锁竞争，进而使得用户感觉到他们的请求被处理的有点慢。不过本文笔者不聊关于全局锁优化的问题，最近笔者遇到了另外一种NameNode性能慢的场景，这个事情是发生在锁外的，发生的场景也比较有意思，于是借此机会简单聊聊。 NameNode请求处理慢的场景 我们先来探讨几个能够引发NameNode请求处理慢的场景？ NameNode处于严重Full GC阶段 NameNode锁竞争激烈 NameNode内部用于处理用户请求的Handler持续处于繁忙状态 上述3点是笔者能够快速联想到的场景，除去第一点是JVM层面的优化后，后面两点其实不太好优化，后面两点很多时候是和集群所面临的请求吞吐量有关联。有人可能会说了，上面第三点关于Handler繁忙的状态，我们不可用简单调大NameNode Handler count数量不就可用解决了嘛。调大Handler表面上能够增大throughput

Hadoop分布式文件系统(HDFS)是一种被设计成适合运行在通用硬件上的分布式文件系统。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。它能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。要理解HDFS的内部工作原理，首先要理解什么是分布式文件系统。 1、分布式文件系统 多台计算机联网协同工作(有时也称为一个集群)就像单台系统一样解决某种问题，这样的系统我们称之为分布式系统。 分布式文件系统是分布式系统的一个子集，它们解决的问题就是数据存储。换句话说，它们是横跨在多台计算机上的存储系统。存储在分布式文件系统上的数据自动分布在不同的节点上。 分布式文件系统在大数据时代有着广泛的应用前景，它们为存储和处理来自网络和其它地方的超大规模数据提供所需的扩展能力。 2、分离元数据和数据：NameNode和DataNode 存储到文件系统中的每个文件都有相关联的元数据。元数据包括了文件名、i节点(inode)数、数据块位置等，而数据则是文件的实际内容。 在传统的文件系统里，因为文件系统不会跨越多台机器，元数据和数据存储在同一台机器上。 为了构建一个分布式文件系统，让客户端在这种系统中使用简单，并且不需要知道其他客户端的活动，那么元数据需要在客户端以外维护。HDFS的设计理念是拿出一台或多台机器来保存元数据，并让剩下的机器来保存文件的内容。

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 前言 在我还不了解分布式和大数据的时候已经听说过HBase了，但对它一直都半知不解，这篇文章来讲讲吧。 在真实生活中，最开始听到这个词是我的一场面试，当年我还是个『小垃圾』，现在已经是个『大垃圾』了。 面试官当时给了一个场景题问我，具体的题目我忘得差不多了，大概就是考试与试题的一个场景，问我数据库要如何设计。 我答了关系型数据库的设计方案，他大概说：这个场景比较复杂多变，为什么不考虑一下HBase这种NoSQL的数据库来存储呢? 我就说：“对对对，可以的” (虽然我当时不知道HBase是什么，但是气势一定要有，你们说是不是) 最后面试官还是给我发了offer，但我没去，原因就是离家太远了。 一、介绍HBase Apache HBase™ is the Hadoop database, a distributed, scalable, big data store. HBase is a type of "NoSQL" database. Apache HBase 是 Hadoop 数据库，一个分布式、可伸缩的大数据存储。 HBase是依赖Hadoop的。为什么HBase能存储海量的数据?因为HBase是在HDFS的基础之上构建的，HDFS是分布式文件系统。 二

导读： 随着互联网的高速发展和信息技术的普及，企业经营过程中产生的数据量呈指数级增长，AI 模型愈发复杂，在摩尔定律已经失效的今天，AI 的落地面临着各种各样的困难。本次分享的主题是分布式机器学习框架如何助力高维实时推荐系统。 机器学习本质上是一个高维函数的拟合，可以通过概率转换做分类和回归。而推荐的本质是二分类问题，推荐或者不推荐，即筛选出有意愿的用户进行推荐。 本文将从工程的角度，讲述推荐系统在模型训练与预估上面临的挑战，并介绍第四范式分布式机器学习框架 GDBT 是如何应对这些工程问题的。 主要内容包括： 推荐系统对于机器学习基础架构的挑战 大规模分布式机器学习场景下，不同算法的性能瓶颈和解决思路 第四范式分布式机器学习框架 GDBT 面临的网络压力及优化方向 01 推荐系统对于机器学习基础架构的挑战 1. 海量数据+高维特征带来极致效果 传统的推荐系统中，我们只用简单的模型或者规则来拟合数据，就可以得到一个很好的效果 ( 因为使用复杂的模型，很容易过拟合，效果反而越来越差 )。但是当数据量增加到一定的数量级时，还用简单的模型或者规则来拟合数据，并不能充分的利用数据的价值，因为数据量增大，推荐的效果上限也随之提升。这时，为了追求精准的效果，我们会把模型构建的越来越复杂，对于推荐系统而言，由于存在大量的离散特征，如用户 ID、物品 ID 以及各种组合

大型网站的特点 大型网站一般有如下特点： 用户多，分布广泛 大流量，高并发 海量数据，服务高可用 安全环境恶劣，易受网络*** 功能多，变更快，频繁发布 从小到大，渐进发展 以用户为中心 免费服务，付费体验 大型网站架构目标 大型网站的架构目标有如下几个： 高性能：提供快速的访问体验。 高可用：网站服务一直可以正常访问。 可伸缩：通过硬件增加/减少，提高/降低处理能力。 扩展性：方便地通过新增/移除方式，增加/减少新的功能/模块。 安全性：提供网站安全访问和数据加密、安全存储等策略。 敏捷性：随需应变，快速响应。 大型网站架构模式 如上图是大型网站的架构模式： 分层：一般可分为应用层、服务层、数据层、管理层与分析层。 分割：一般按照业务/模块/功能特点进行划分，比如应用层分为首页、用户中心。 分布式：将应用分开部署（比如多台物理机），通过远程调用协同工作。 集群：一个应用/模块/功能部署多份（如：多台物理机），通过负载均衡共同提供对外访问。 缓存：将数据放在距离应用或用户最近的位置，加快访问速度。 异步：将同步的操作异步化。客户端发出请求，不等待服务端响应，等服务端处理完毕后，使用通知或轮询的方式告知请求方。一般指：请求——响应——通知模式。 冗余：增加副本，提高可用性、安全性与性能。 安全：对已知问题有有效的解决方案，对未知/潜在问题建立发现和防御机制。 自动化：将重复的

1.在uri中配置 hive://localhost:10000/default 2.查询 3.如果你的hive集群是带有kerberos认证的,hive数据源需要这样配置 hive://xxx:xxx/default?auth=KERBEROS&kerberos_service_name=hive 如果在连接的时候报了如下的错 Could not start SASL: b'Error in sasl_client_start (-1) SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure 那就就是你没有用keytab进行认证 kinit -kt xxx.keytab xxx@XXXX superset也支持模拟用户,配置方法如下 然后就能支持使用hive,impala或者hdfs用户来对普通用户进行模拟,如果模拟出来的用户没有权限的话,就会抛出异常 来源： oschina 链接： https://my.oschina.net/u/4343420/blog/4295357

大型网站的特点 大型网站一般有如下特点： 用户多，分布广泛 大流量，高并发 海量数据，服务高可用 安全环境恶劣，易受网络*** 功能多，变更快，频繁发布 从小到大，渐进发展 以用户为中心 免费服务，付费体验 大型网站架构目标 大型网站的架构目标有如下几个： 高性能：提供快速的访问体验。 高可用：网站服务一直可以正常访问。 可伸缩：通过硬件增加/减少，提高/降低处理能力。 扩展性：方便地通过新增/移除方式，增加/减少新的功能/模块。 安全性：提供网站安全访问和数据加密、安全存储等策略。 敏捷性：随需应变，快速响应。 大型网站架构模式 如上图是大型网站的架构模式： 分层：一般可分为应用层、服务层、数据层、管理层与分析层。 分割：一般按照业务/模块/功能特点进行划分，比如应用层分为首页、用户中心。 分布式：将应用分开部署（比如多台物理机），通过远程调用协同工作。 集群：一个应用/模块/功能部署多份（如：多台物理机），通过负载均衡共同提供对外访问。 缓存：将数据放在距离应用或用户最近的位置，加快访问速度。 异步：将同步的操作异步化。客户端发出请求，不等待服务端响应，等服务端处理完毕后，使用通知或轮询的方式告知请求方。一般指：请求——响应——通知模式。 冗余：增加副本，提高可用性、安全性与性能。 安全：对已知问题有有效的解决方案，对未知/潜在问题建立发现和防御机制。 自动化：将重复的

Kafka提供两种启动方式，一种是单机版standalone，一种是分布式版distributed，与之想对应的配置文件也是分开的 单机版的配置文件：connect-standalone.properties 分布式的配置文件：connect-distributed.properties 单机启动方式：bin/connect-standalone.sh -daemon config/connect-standalone.properties config/connect-console-sink.properties 分布式启动方式：bin/connect-distributed.sh -daemon config/connect-distributed.properties 启动完之后就能通过curl的方式请求确认服务是否正常 curl localhost:8083/connectors 单机模式配置信息在提交的配置文件里面，例如：config/connect-console-sink.properties 集群模式需要通过REST API去提交 基于Debezium 的CDC为例，介绍下如何提交一个Kafka Connect source 任务： curl -X POST -H "Content-Type: application/json" http://localhost

打开虚拟机进入linux系统 进入Hadoop目录下 多用tab键 它可以自动补齐命令 1. 启动Hadoop集群 start-all. sh 等价于 start-dfs.sh 和 start-yarn.sh 2. 关闭Hadoop集群 stop- all.sh 3. 查看启动的服务进程 jps 4. 查看HDFS上的文件和目录 hadoop fs -ls / hadoop fs - ls - R //-R是递归 5. 查看文件内容 hadoop fs -cat HDFS文件路径 //可在192.168.5.100：50070中Utillities中Browse the file system查看 6. 查看集群的工作状态 hdfs dfsadmin -report 7. 清屏 clear 以下个人觉得慎用 1. 在HDFS上创建文件夹 hadoop fs -mkdir -p /test/ name 2. 上传文件 hadoop fs -put source(本地文件路径) dest(HDFS路径) 3. 下载文件 hadoop fs -get source(HDFS路径) dest(本地文件路径) 4. 删除文件 hadoop fs - rm HDFS文件路径 hadoop fs - rm -r HDFS目录路径 相关上一篇：linux的常用命令 相关下一篇