HDFS

HDFS分布式存储公链：一套完整的个人数据存储解决方案 HDFS分布式存储公链是一套完整的个人数据存储解决方案，它由无数的节点以p2p的形式组成一个数据存储阵列，采用POC+POST的双重共识机制来识别及分配奖励，采用加密机制对数据传输及存储过程进行保护形成一套安全、高效、经济的个人数据存储全套解决方案。 数据层：是整套HDFS的底层机制，包含了整套个人数据存储方案的解决体系，基于数据层的约定的机制，各方可以在这套分布式存储网络中找到自己的应该履行的义务及可以获取的权利，数据层是开源的任何联网的单机下载并运行数据包既是HDFS的节点，同步存储HDFS的数据获得HDFS 的奖励。 网络层：HDFS采用的是p2p的网络机制，用户的数据上传及下载直接从对应的节点磁盘内调取资源，P2P 的形式更加安全而且充分利用了节点独立带宽的优势在数据上传及下载的过程之中能够实现多线程同步协作的形式，极大提升了数据读写的效率。 共识层：HDFS 采用的是抵押挖矿的模式，即检查用户的POC也检查用户的POST，识别节点的贡献的时候，一方面是考察节点的可用存储空间的大小POC，另外POST机制还要求节点定时回传硬盘存储的文件的哈希值以验证节点是否一直履行自己的义务。如果节点掉线或者硬盘扇区被破坏则主网会对节点采取惩罚措施，视情节的轻重采取罚款、罚没用户抵押金甚至是取消节点身份的惩罚措施。 激励层

################ 修改目录权限 #################### [root@vwmaster hadoop]# chown -R root:root hadoop260/ ################ JDK #################### [root@vwmaster hadoop260]# vi etc/hadoop/hadoop-env.sh export JAVA_HOME=/opt/bigdata/java/jdk180 ################ hadoop fs 文件系统 #################### 集群配置时将 IP 改为 主机名 [root@vwmaster hadoop260]# vi etc/hadoop/core-site.xml <configuration> <property> <name>fs.defaultFS</name> <value>hdfs://vwmaster:9000</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/opt/bigdata/hadoop/hadoop260</value> </property> <property> <name>hadoop.proxyuser.root

Hadoop环境快速搭建 官方文档： YARN Setup 在上一篇 Flink部署及作业提交（On Flink Cluster） 文章中，我们介绍了如何编译部署Flink自身的资源分配和管理系统，并将作业提交到该系统上去运行。但通常来讲这种方式用得不多，因为在企业中，可能会使用不同的分布式计算框架，如Spark、Storm或MapReduce等。 如果每一种框架都需要搭建各自的资源分配和管理系统，就无法共享资源，导致资源利用率低。并且大多企业一般会使用Hadoop生态的相关组件做作为大数据处理平台的底座，如HDFS、Hive、YARN等。 其中 YARN 是资源调度框架、通用的资源管理系统，可以为上层应用提供统一的资源管理和调度，Spark、Flink、Storm等计算框架都可以集成到 YARN 上。如此一来这些计算框架可以享受整体的资源调度，进而提高集群资源的利用率，这也就是所谓的 xxx on YARN。因此，绝大部分企业都是将计算作业放到 YARN 上进行调度，而不是每种计算框架都单独搭一个资源分配和管理系统。这也是为什么要单独介绍Flink On YARN的原因。 想要让Flink作业跑在 YARN 上，我们首先得搭建一个Hadoop环境，为了简单这里只搭建单节点环境。我这里使用的是CDH的Hadoop发行版。下载地址如下： http://archive.cloudera

实验包括： 1. 使用EMR创建Hadoop集群 2. 定义schema，创建示例表。 3. 通过HiveQL分析数据，并将分析结果保存到S3上 4. 下载已经分析结果数据。 Task1：创建一个S3 桶 创建一个存储桶比如hadoop202006… Task2：创建EMR集群 这里我解释一下Hadoop集群中的一些组件，了解大数据的同学直接忽略就好。 Apache Hadoop：在分布式服务器集群上存储海量数据并运行分布式分析应用的开源框架，其核心部件是HDFS与MapReduce。 Ganglia：分布式监控系统 Apache Tez：支持 DAG 作业的开源计算框架，它可以将多个有依赖的作业转换为一个作业从而大幅提升DAG作业的性能。比如Hive或Pig可以将Tez作为执行引擎。 Hive：可以通过类似SQL语句实现快速MapReduce统计 Hue：通过使用Hue我们可以通过浏览器方式操纵Hadoop集群。例如put、get、执行MapReduce Job等等。 Pig：它提供的SQL-LIKE语言叫Pig Latin，该语言的编译器会把类SQL的数据分析请求转换为一系列经过优化处理的MapReduce运算。Pig为复杂的海量数据并行计算提供了一个简单的操作和编程接口。 解释一下，Master、Core、Task。 Master Node：主节点集群管理

背景 在数据仓库建模中，未经任何加工处理的原始业务层数据，我们称之为ODS(Operational Data Store)数据。在互联网企业中，常见的ODS数据有业务日志数据（Log）和业务DB数据（DB）两类。对于业务DB数据来说，从MySQL等关系型数据库的业务数据进行采集，然后导入到Hive中，是进行数据仓库生产的重要环节。如何准确、高效地把MySQL数据同步到Hive中？一般常用的解决方案是批量取数并Load：直连MySQL去Select表中的数据，然后存到本地文件作为中间存储，最后把文件Load到Hive表中。这种方案的优点是实现简单，但是随着业务的发展，缺点也逐渐暴露出来： 性能瓶颈：随着业务规模的增长，Select From MySQL -> Save to Localfile -> Load to Hive这种数据流花费的时间越来越长，无法满足下游数仓生产的时间要求。 直接从MySQL中Select大量数据，对MySQL的影响非常大，容易造成慢查询，影响业务线上的正常服务。 由于Hive本身的语法不支持更新、删除等SQL原语(高版本Hive支持，但是需要分桶+ORC存储格式)，对于MySQL中发生Update/Delete的数据无法很好地进行支持。 为了彻底解决这些问题，我们逐步转向CDC (Change Data Capture) + Merge的技术方案

MapReduce源码分析 - JobSplit 根据MapRudece的原理，我们从4个过程去分析MR的源码： Split阶段； MapTask阶段； Shuffle阶段； ReduceTask阶段； 本小节首先介绍Split阶段的源码。 Split源码分析 MR是通过JobSubmitter.submitJobInternal提交给RM的 在submitJobInternal中通过 writeSplits(JobContext job, Path jobSubmitDir) 将job的输入文件进行split writeSplit只是对新旧api进行了下封装，根据你的代码选择新旧api，这里调用 writeNewSplits 使用新API对file进行split 整个切片的逻辑过程主要就是在 writeNewSplit里 ① writeNewSplits源码分析 进入writeNewSplits()方法，可以看出该方法首先获取splits数组信息后，排序，将会优先处理大文件，最终返回mapper数量。 这其中又分为两部分：确定切片数量 和 写入切片信息。 确定切片数量的任务交由FileInputFormat的getSplits(job)完成，写入切片信息的任务交由JobSplitWriter.createSplitFiles(jobSubmitDir, conf,

为什么要构建数据湖 大数据时代早期，Apache HDFS 是构建具有海量存储能力数据仓库的首选方案。随着云计算、大数据、AI 等技术的发展，所有云厂商都在不断完善自家的对象存储，来更好地适配 Apache Hadoop/Spark 大数据以及各种 AI 生态。由于对象存储有海量、安全、低成本、高可靠、易集成等优势，各种 IoT 设备、网站数据都把各种形式的原始文件存储在对象存储上，利用对象存储增强和拓展大数据 AI 也成为了业界共识，Apache Hadoop 社区也推出了原生的对象存储“Ozone”。从 HDFS 到对象存储，从数据仓库到数据湖，把所有的数据都放在一个统一的存储中，也可以更加高效地进行分析和处理。 对于云上的客户来说，如何构建自己的数据湖，早期的技术选型非常重要，随着数据量的不断增加，后续进行架构升级和数据迁移的成本也会增加。在云上使用 HDFS 构建大规模存储系统，已经暴露出来不少问题。HDFS 是 Hadoop 原生的存储系统，经过 10 年来的发展，HDFS 已经成为大数据生态的存储标准，但我们也看到 HDFS 虽然不断优化，但是 NameNode 单点瓶颈，JVM 瓶颈仍然影响着集群的扩展，从 1 PB到 100+ PB，需要不断的进行调优、集群拆分来，HDFS 可以支持到 EB 级别，但是投入很高的运维成本，来解决慢启动，心跳风暴，节点扩容、节点迁移

Elasticsearch定义 elastic(弹性、灵活）+search（搜索） Elasticsearch 是一个支持分布式、高扩展、高实时的高效搜索与数据分析引擎。 支持分布式实时文件存储。 支持将字段值都编入索引，使其可以被搜索。 实时分析的分布式搜索引擎。 可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。 Elasticsearch 的实现原理主要分为以下几个步骤 用户将数据提交到Elasticsearch 数据库中。 es通过分词控制器去将对应的语句分词。（这里如需更高级的策略优化，后期可以替换分词器）。 将其权重和分词结果一并存入数据库。 当用户搜索数据时候，根据权重将结果排名，打分（相关度）。 将返回结果呈现给用户。 有关概念 cluster：代表一个集群，集群中有多个节点，其中有一个为主节点，这个主节点是可以通过选举产生的，主从节点是对于集群内部来说的。es的一个概念就是去中心化，字面上理解就是无中心节点，这是对于集群外部来说的，因为从外部来看es集群，在逻辑上是个整体，你与任何一个节点的通信和与整个es集群通信是等价的。 shards：代表索引分片，es可以把一个完整的索引分成多个分片，这样的好处是可以把一个大的索引拆分成多个，分布到不同的节点上。构成分布式搜索。分片的数量只能在索引创建前指定，并且索引创建后不能更改。 replicas：代表索引副本

简介： 近几年，数据湖架构的概念逐渐兴起，很多企业都在尝试构建数据湖。相比较大数据平台，数据湖在数据治理方面提出了更高的要求。对于数据湖场景所提出的新需求，“传统”的大数据工具在很多方面都面临着新的挑战。JindoTable 正是专为解决数据湖管理结构化数据甚至是半结构化数据的痛点而设计的，包括数据治理功能和查询加速功能。 概述 近几年，数据湖架构的概念逐渐兴起，很多企业都在尝试构建数据湖。相比较大数据平台，数据湖在数据治理方面提出了更高的要求。对于数据湖场景所提出的新需求，“传统”的大数据工具在很多方面都面临着新的挑战。JindoTable 正是专为解决数据湖管理结构化数据甚至是半结构化数据的痛点而设计的，包括数据治理功能和查询加速功能。 数据优化 数据湖需要存储来自各种数据源的数据。对于 HDFS 集群，小文件问题让很多用户倍感烦恼。在存储计算分离的数据湖中，小文件同样会产生很多问题：过多的文件数会导致目录list时间显著变长，小文件也会影响很多计算引擎的并发度。此外，由于对象存储一般以对象为单位，小文件也会导致请求数量的上升，会明显影响元数据操作的性能，更会增加企业需要支付的费用。而如果数据文件过大，如果数据又使用了不可分割的压缩格式，后续计算的并发度会过低，导致无法充分发挥集群的计算能力。因此，即使是数据湖架构中，对数据文件进行治理和优化也是非常必要的。

hbase shell 1 DDL 在hbase中没有database的概念使用namespace替代database的作用 1.1 建表 create (指定列族) create "tb_user" , "cf" -- 创建表 指定一个列族 create 'tb_user2' ,'cf1' ,'cf2' ,'cf3' --指定多个列族 create "tb_user3" , {NAME=>'info1' ,VERSIONS=>3,TTL=>240} 设置3个数据版本 过期时间 1.2 查看系统中的表 list list ["tb_user", "tb_user2"] 1.3 查看表的结构 describe desc describe 'tb_name' desc 'tb_name' --查看表结构 COLUMN FAMILIES DESCRIPTION {NAME => 'cf1', VERSIONS => '1', EVICT_BLOCKS_ON_CLOSE => 'false', NEW_VERSION_BEHAVIOR => 'false', KEEP_DELETED_CELLS => 'FALSE', CACHE_DATA_ON_WRITE => 'false', DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', MIN