HDFS

K8s服务器配置 服务器节点 cat >> /etc/hosts << EOF 192.168.207.133 k8s-master 192.168.207.134 k8s-node1 192.168.207.135 k8s-node2 EOF kubeadm 初始化 kubeadm init \ --apiserver-advertise-address=192.168.207.133 \ --image-repository registry.aliyuncs.com/google_containers \ --kubernetes-version v1.19.0 \ --service-cidr=10.96.0.0/12 \ --pod-network-cidr=10.244.0.0/16 \ --ignore-preflight-errors=all 搭建Hadoop集群 编写hadoop.yaml apiVersion: v1 kind: ConfigMap metadata: name: kube-hadoop-conf data: HDFS_MASTER_SERVICE: hadoop-hdfs-master HDOOP_YARN_MASTER: hadoop-yarn-master --- apiVersion: v1 kind: Service metadata:

HDFS分布式存储有什么优势?如何进行数据存储 互联网时代，数据是当今社会较为看重的事情，随着5G火热的到来，全球布局已经开始，预计在2025年，中国区将会有100亿5G用户。数量庞大的物联网设备节点、越来越多的超高清视频传输应用需求、蓬勃发展的数字经济对现有区块链技术的挑战，都需要互联网经济依靠数据运行，所有这些数据都推动了一场数字革命，这是时代发展趋势。 在面对数据海量增长时，虽然用户生成的数据是网络最有价值的资产，但互联网用户自己几乎无法控制这些数据；数据存储、数据所有权都高度集中，今天的互联网生态系统使得少数公司攫取极高的利润，平台之间相互兼并，对于用户数据则是肆无忌惮的“分享”，导致终端用户“无处可逃”，并且超过98%的网络链接在20年内不可用，我们正在进入数据时代，但以这个速度，我们的数据存储有效时间还不如一个塑胶材质。 今年疫情来势汹汹，国内外受疫情影响所造成的巨大破坏都是无可估量的，自然灾害面前，人类显得如此渺小。但如果在数百年后，面对只能有限的网络存储时间，我们对这些曾经发生的历史都记忆模糊了，那如何对的起在这些灾难中牺牲的同胞，又如何起到一个警示世人的作用？ 幸好目前的技术足够发达，我们可以改变这一现状。HDFS分布式存储一直致力于改变数据存储的方式来达到存储的去中心化。我们改善今天的中心化网络，引用未来的去中心化网络。

微信公众号： 北风中独行的蜗牛 HDFS 全称 Hadoop Distributed File System - Hadoop分布式文件系统，是Hadoop项目的核心子项目，对海量数据进行进行存储与管理 HDFS存储块为128M 现在HDFS的block的默认大小为128M。寻址时间指的是在HDFS中，找到目标block的时间。如果block越大，寻址时间就越短，因为NameNode中存储的元数据就越少，但是明显传输时间会就变大，反之，寻址时间就越长。通常MapReduce中每一个任务只会处理一个块，如果block太大也会影响任务的执行时间。经过前人的研究，寻址时间平均为10ms比较合适，就是查找block的时间为10ms，寻址时间为传输时间的1%，也就是10/0.01=1S,现在磁盘的读取速率大概为100M/s,所以每秒大概为100M，取2的指数级，即为128M。如果磁盘的读取速率 为200M/s, 则block的大小为256M。Block的大小 在hdfs-site.xml 中设置，name为dfs.blocksize 机架感知 数据块的存储涉及到一个概念，叫做机架感知。意思是同一个数据的备份，会放到不同机架的不同节点上，防止数据的丢失。通常冗余的数据为3，放数据的策略是第一个block放到与client同一个机器的DataNode节点上，如果Client不在集群范围

再写 HDFS Federation机制的时候，发现基础不扎实，需要将之前的hadoop再详细记录一下原理（重点只说Hadoop2.0版本）： Hadoop2.0版本，引入了Yarn。核心：HDFS+Yarn+Mapreduce Yarn是资源调度框架。能够细粒度的管理和调度任务。此外，还能够支持其他的计算框架，比如spark等。 存储的基础知识以及原理： 元数据信息和具体数据，分别对应namenode和datenode: namenode 工作职责： 1.要知道管理有哪些机器节点，即有哪些datanode。比如ip信息等。 2.要管理文件信息，文件名、文件多大、文件被切成几块、以及每一块的存贮位置信息（存在哪个datanode节点上了），即管理元数据信息。 3.要有一个机制要知道集群里datanode节点的状态变化。可以rpc心跳机制来做到。 4.namenode存在单点故障问题，可以再引入一台管理者节点。 5.datanode挂掉后，可能数据就丢失，文件就不完整了，要有一个备份机制，一般来说，一个文件块，有3个备份，本机一份，同一机架的其他datanode有一份，另外一机器的机器上有一份。 管理元数据信息，文件名，文件大小，文件块信息等。 namdenode把元数据信息存到内存里，为了快速查询，此外为了应对服务宕机而引起的元数据丢失，也要持久化到本地文件里。

简介： 本文由美团研究员、实时计算负责人鞠大升分享，主要介绍 Flink 助力美团数仓增量生产的应用实践。内容包括：1、数仓增量生产；2、流式数据集成；3、流式数据处理；4、流式 OLAP 应用；5、未来规划。 一、数仓增量生产 1.美团数仓架构 先介绍一下美团数仓的架构以及增量生产。如下图所示，这是美团数仓的简单架构，我把它叫做三横四纵。所谓三横，第一是贯穿全链路的元数据以及血缘，贯穿数据集成、数据处理、数据消费、以及数据应用的全过程链路。另外一块贯穿全链路的是数据安全，包括受限域的认证系统、权限系统、整体的审计系统。根据数据的流向，我们把数据处理的过程分为数据集成、数据处理、数据消费、以及数据应用这 4 个阶段。 在数据集成阶段，我们对于公司内部的，比如说用户行为数据、日志数据、DB 数据、还有文件数据，都有相应的集成的系统把数据统一到我们的数据处理的存储中，比如说 Kafka 中。 在数据处理阶段，分为流式处理链路、批处理链路以及基于这套链路的数仓工作平台（万象平台）。生产出来的数据，经过 Datalink 导入到消费的存储中，最终通过应用以不同的形式呈现出来。 我们目前在 Flink 上面应用比较广泛的地方，包括从 Kafka 把数据导到 Hive，包括实时的处理，数据导出的过程。今天的分享就集中在这些方面。 2.美团 Flink 应用概况 美团的 Flink 目前大概有

Checkpoint介绍 checkpoint机制是Flink可靠性的基石，可以保证Flink集群在某个算子因为某些原因(如 异常退出)出现故障时，能够将整个应用流图的状态恢复到故障之前的某一状态，保 证应用流图状态的一致性。Flink的checkpoint机制原理来自“Chandy-Lamport algorithm”算法。 每个需要checkpoint的应用在启动时，Flink的JobManager为其创建一个 CheckpointCoordinator(检查点协调器) ，CheckpointCoordinator全权负责本应用的快照制作。 1) CheckpointCoordinator(检查点协调器) 周期性的向该流应用的所有source算子发送 barrier(屏障)。 2) 当某个source算子收到一个barrier时，便暂停数据处理过程，然后将自己的当前状态制作成快照，并保存到指定的持久化存储中，最后向CheckpointCoordinator报告自己快照制作情况，同时向自身所有下游算子广播该barrier，恢复数据处理 3) 下游算子收到barrier之后，会暂停自己的数据处理过程，然后将自身的相关状态制作成快照，并保存到指定的持久化存储中，最后向CheckpointCoordinator报告自身快照情况，同时向自身所有下游算子广播该barrier，恢复数据处理。

注：此文章内容均节选自充电了么创始人，CEO兼CTO陈敬雷先生的新书 《分布式机器学习实战》（人工智能科学与技术丛书）【陈敬雷编著】【清华大学出版社】 文章目录 前言 Hbase原理和功能介绍 1. Hbase特性 2. Hbase的架构核心组件 Hbase数据结构和表详解 总结 前言 Hbase 经常用来存储实时数据，比如Storm/Flink/Spark-Streaming消费用户行为日志数据进行处理后存储到Hbase，通过Hbase的API也能够毫秒级别的实时查询。如果是对Hbase做非实时的离线数据统计，我们可以通过Hive建一个到Hbase的映射表，然后写Hive SQL来对Hbase的数据进行统计分析。并且这种方式可以方便的和其它的Hive表做关联查询，做更复杂的统计。所以从交互形势上Hbase满足了实时和离线的应用场景，在互联网公司应用的也非常普遍。 Hbase原理和功能介绍 HBase是一个分布式的、面向列的开源数据库，该技术来源于 Fay Chang 所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统（File System）所提供的分布式数据存储一样，HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目

简介： 本文由美团研究员、实时计算负责人鞠大升分享，主要介绍 Flink 助力美团数仓增量生产的应用实践。内容包括：1、数仓增量生产；2、流式数据集成；3、流式数据处理；4、流式 OLAP 应用；5、未来规划。 一、数仓增量生产 1.美团数仓架构 先介绍一下美团数仓的架构以及增量生产。如下图所示，这是美团数仓的简单架构，我把它叫做三横四纵。所谓三横，第一是贯穿全链路的元数据以及血缘，贯穿数据集成、数据处理、数据消费、以及数据应用的全过程链路。另外一块贯穿全链路的是数据安全，包括受限域的认证系统、权限系统、整体的审计系统。根据数据的流向，我们把数据处理的过程分为数据集成、数据处理、数据消费、以及数据应用这 4 个阶段。 在数据集成阶段，我们对于公司内部的，比如说用户行为数据、日志数据、DB 数据、还有文件数据，都有相应的集成的系统把数据统一到我们的数据处理的存储中，比如说 Kafka 中。 在数据处理阶段，分为流式处理链路、批处理链路以及基于这套链路的数仓工作平台（万象平台）。生产出来的数据，经过 Datalink 导入到消费的存储中，最终通过应用以不同的形式呈现出来。 我们目前在 Flink 上面应用比较广泛的地方，包括从 Kafka 把数据导到 Hive，包括实时的处理，数据导出的过程。今天的分享就集中在这些方面。 2.美团 Flink 应用概况 美团的 Flink 目前大概有

对比三种引擎的实现：　　 hash存储引擎：哈希表持久化的实现，可以快速支持增删改查等随机操作，且时间复杂度为o(1)，但是不支持顺序读取扫描，对应的存储系统为k-v存储系统的实现。 b树存储引擎是b树的持久化实现，不仅支持单条记录的增删改查操作，还支持顺序扫描，对应的存储系统就是mysql。 lsm树存储引擎和b树存储引擎，一样支持，增删改查，也支持顺序扫描操作。LSM牺牲了读性能，提高写性能。 LSM的原理：将对数据的修改增量保存在内存中，达到指定大小限制之后批量把数据flush到磁盘中，磁盘中树定期可以做merge操作，合并成一棵大树，以优化读性能。不过读取的时候稍微麻烦一些，读取时看这些数据在内存中，如果未能命中内存，则需要访问较多的磁盘文件。极端的说，基于LSM树实现的hbase写性能比mysql高了一个数量级，读性能却低了一个数量级。 LSM树原理把一颗大叔拆分成N颗小树，它首先在内存中，它首先写入内存中，随着小树越来越大，内存中的小树会flush到磁盘中，磁盘中的树定期可以做merge操作，合并成为一个大叔，用来优化读性能。 以上就是hbase存储设计的重要思想，这里说明一下： 因为数据是先写到内存中，所以为了防止内存数据丢失，会先把数据写入hlog中，也符合了数据库中标准，先写日志，再写数据 memstore上的树达到一定大小之后，需要flush到磁盘中