HDFS

简介 数据存储模型及关系型数据库的区别 一般都是牺牲一致性， 最终达到最终一致性 HBase 概念 区别 基础架构 HBASE 原理和操作 写流程 预写入会写入HLog 里面， 通过HLog 来保证数据不丢失 读流程 模块协作 shell 命令 学会用 help , 可以获取使用说明 比如： help 'status' # HBase shell中的帮助命令非常强大，使用help获得全部命令的列表，使用help ‘command_name’获得某一个命令的详细信息 help 'status' # 查询服务器状态 status # 查看所有表 list # 创建一个表 create 'FileTable','fileInfo','saveInfo' # 获得表的描述 describe 'FileTable' # 添加一个列族 alter 'FileTable', 'cf' # 删除一个列族 alter 'FileTable', {NAME => 'cf', METHOD => 'delete'} # 插入数据 put 'FileTable', 'rowkey1','fileInfo:name','file1.txt' put 'FileTable', 'rowkey1','fileInfo:type','txt' put 'FileTable', 'rowkey1',

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 学习 HBase 最难的地方在于要让你的脑子真正理解它是什么。 HBase：Google BigTable 的开源实现 我们经常会把关系型数据库（RDBMS，比如 MySQL）和 HBase 搞混，因为在这两个系统中都包含 table 和 base（HBase，Database）。 这篇文章的目标是从概念上来说清楚 HBase 这个分布式的数据存储系统。读完后，你应该可以很清楚的知道什么情况下 HBase 更好，什么情况下传统的关系型数据库更好。 关于一些术语 幸运的是，Google 的 BigTable论文清楚的解释了 BigTable 到底是什么。下面是论文中数据模型章节的第一句话： BigTable 是一个稀疏的、分布式的、可持久化的多维有序 map。 在这个节骨眼上，我想给读者一个机会，让他们在读到最后一行字时，能够收集到他们脑壳里的活动信息（这可能是个笑话，但我没懂^v^）。 论文中，继续解释如下： map 通过 rowKey，columnKey 和时间戳进行索引，map 中的每个值都是一个连续的字节数组。 注：rowKey 是记录的主键，唯一标识一行记录 在 Hadoop 的官方文档中，也对 HBase 的架构做了说明： HBase 使用了与 BigTable

作者 | 唐云（茶干），阿里巴巴高级开发工程师 整理 | 张壮壮（Flink 社区志愿者） 摘要：本文根据 Apache Flink 系列直播整理而成，由阿里巴巴高级开发工程师唐云（茶干）分享。主要内容如下： 容器管理系统的演变 Flink on K8S intro Flink on K8S实战分享 Demo Tips：点击下方可查看更多 1.10 系列直播视频～ 1.10系列直播： https://ververica.cn/developers/flink-training-course-1-10/ 本文第一部分将简明扼要地介绍容器管理系统的演变；第二部分是 Flink on K8S 简介，包括集群的部署模式调度原理等等；第三部分是我们这一年以来关于 Flink on K8S 的实战经验分享，介绍我们遇到的问题、踩过的坑；最后一部分是 Demo，将手把手演示集群部署、任务提交等等。 容器管理系统的演变 首先是以一个 Kubernetes 非内核开发人员的角度去探讨其和 YARN 之间的关系。众所周知，Apache Hadoop YARN 可能是在国内用途最广的一个调度系统，主要原因在于 Hadoop HDFS 在国内或者是在整个大数据业界，是一个使用最广泛的存储系统。因此，基于其上的 YARN 也自然而然成为了一个广为使用的一个调度系统，包括早期的 Hadoop

　　1. 配置JAVA_HOME环境和Hadoop环境： 　　 　　2. 配置bin 　　3. 进入Hadoop中/etc/hadoop下 　　　　配置hdfs-site.xml增加： 　　 <property> <!-- 单节点，所以配置成1 --> <name>dfs.replication</name> <value> 1 </value> </property> <!-- 指定Hadoop辅助名称节点主机配置,即：2NN配置 --> <property> <name>dfs.namenode.secondary.http-address</name> <value>localhost: 50090 </value> </property> <!-- 配置前台访问页面 --> <property> <name>dfs.namenode.http.address</name> <value>slave1: 50070 </value> </property> 　　配置core-site.xml文件： 　　 <property> <name>fs.defaultFS</name> <value>hdfs: // node1:9820</value> </property> <property> <name>hadoop.tmp. dir </name> <value>/I:

万级TPS亿级流水-中台账户系统架构设计 标签：高并发 万级TPS 亿级流水 账户系统 背景 业务模型 应用层设计 数据层设计 日切对账 背景 我们需要给所有前台业务提供统一的账户系统，用来支撑所有前台产品线的用户资产管理，统一提供支持大并发万级TPS、亿级流水、数据强一致、风控安全、日切对账、财务核算、审计等能力，在万级TPS下保证绝对的数据准确性和数据溯源能力。 注：资金类系统只有合格和不合格，哪怕数据出现只有0.01分的差错也是不合格的，局部数据不准也就意味着全局数据都不可信。 本文只分享系统的核心模型部分的设计，其他常规类的（如压测验收、系统保护策略-限流、降级、熔断等）设计就不做多介绍，如果对其他方面有兴趣欢迎进一步交流。 业务模型 基本账户管理： 根据交易的不同主体，可以分为 个人账户 、 机构账户 。 账户余额 在使用上没有任何限制，很纯粹的账户存储、转账管理，可以满足90%业务场景。 子账户功能： 一个用户可以开通多个子账户，根据余额属性不同可以分为基本账户、过期账户，根据币种不同可以分为人民币账户、虚拟币账户，根据业务形态不同可以自定义。 （不同账户的特定功能是通过账户上的 账户属性 来区分实现。） 过期账户管理： 该账户中的余额是会随着 进账流水 到期自动过期。 如：在某平台充值1000元送300元，其中300元是有过期时间的，但是1000元是没有时间限制的

项目介绍 项目整体介绍 1.项目模型搭建 此项目为数据仓库项目,主要是做离线计算的 项目模型:项目分为流量域和业务域两个主题域,为了方便管理这么多数据,又将每个主题域划分为五个层级,分别是ODS层,DWD层,DWS层,ADS层及DIM层,分层的原因为解耦,复用,便于管理,下面我分别介绍一下项目中他们的应用场景 1.1 ODS层 ODS层:源数据层,分为流量域ODS层及业务域ODS层 流量域ODS层:数据来源于日志服务器(用户行为日志数据(APP端和WEB端)),日志服务器将数据生产到Kafka,然后使用Flume日志采集工具消费Kafka中的数据并将数据采集到Hdfs集群,在Hive中将数据加载到ODS层的Hive表中,这样就完成了原始数据的采集 业务域ODS层:数据来源于业务系统中的关系型数据库mysql,采用sqoop抽取工具将数据从mysql导入到Hdfs中,再在Hive中将数据加载到ODS层相应的表中 1.2 DWD层 DWD层:数据明细层,同样分为流量域DWD层及业务域DWD层 流量域DWD层:将数据在ODS层进行ETL操作(先对ODS层数据进行清洗,过滤(过滤掉缺失重要字段信息,重要字段信息为空或者json格式不正确的数据),降维等操作),再抽取到DWD层 业务域DWD层:抽取ODS层每天的增量数据,与DWD层每天的全量数据进行合并

大数据技术栈——Hadoop概述 1 引例 2 MapReduce 3 HDFS 4 Hadoop 5 HBase 5.1 逻辑模型 5.2 物理模型 5.3 Region服务器 6 Hive 7 Pig 8 ZooKeeper 8.1 ZooKeeper的特性 8.2 ZooKeeper的设计目标 1 引例 Hadoop是专为离线和大规模数据分析而设计的，上图Hadoop整体技术框架描述。（为了方便学习，会先介绍Map Reduce与HDFS） 2 MapReduce MapReduce是Google提出的大规模并行计算解决方案，应用于大规模廉价集群上的大数据并行处理（Map Reduce1.0运行模型如下）。 MapReduce以key/value的分布式存储系统为基础，采用“分而治之”的思想，是一种并行编程模型，将计算阶段分为两个阶段：Map阶段（分）和Reduce阶段（治）。 原理：利用一个输入（key，value）对的集合产生一个输出的（key，value）对的集合。 map阶段 ：被分配了map任务的worker程序读入数据片段，解析出（key，value）对，传给用户定义的Map函数，Map函数生出中间对，缓存在内存中。 Reduce阶段 ：该阶段由Reduce函数把Map阶段具有相同key值的中间结果收集到相同Reduce结点进行合并处理，并将结果写入本地磁盘

目录 为什么写这篇文章 一些重要概念 部署架构 数据写入 数据查询 负载均衡 数据合并策略 宕机恢复 为什么写这篇文章   可能有些童鞋已经发现：1.阿里云上的Hbase服务，基于Hbase深度定制和扩展，能比较好的支持时序场景和全文检索场景，其增强版Lindorm，已经作为单独的云服务售卖，单独演进。2.腾讯云上，基于ES构建了CTSDB时序数据库单独售卖，同时也推出了增强版的ES云服务。可以看出，在这两个服务所在团队中，一边选择基于ES来支持时序和全文检索场景，一边则选择基于Hbase来支持时序和全文检索场景。基于ES来支持时序和全文检索场景是比较好理解的，因为它本身的功能就支持这些，但是Hbase如何比较好支持全文检索场景呢？实际上，阿里云的Hbase服务借助了Solr这个搜索引擎来构建这块的能力，因为Solr和ES一样，都是基于Lucene构建的搜索服务。那为什么阿里不和腾讯一样，直接基于ES来构建这块的能力呢？Hbase和ES又究竟有哪些共同点，有哪些差异点呢？   总的来说，在数据量不是非常大的时候，使用ES更加简单，单纯使用ES就能解决各种查询场景的需求，但是当数据量非常大的时候，现有的社区版本ES则存在不少问题，这个时候往往需要进行一些内核级别的改进（否则就需要更多的业务层干预，并且成本消耗会比较高），类似阿里云和腾讯云上提供的ES服务，实际上都对ES内核做过改进

配置 hadoop 高可用集群的原因：如果集群只有一个 NameNode，若NameNode 节点出现故障，那么整个集群都无法使用，也就是存在单点故障的隐患，hadoop 高可用集群能够实现 standby NameNode 自动切换为 active。 HA 的架构，节点个数一般为奇数个，有两个 NameNode，一台为 active 状态，一台为 standby 状态，active NameNode 对外提供服务，standby Namenode 实时同步了 active NameNode 的元数据，当 active NameNode 节点出现故障，standby NameNode 节点可立即切换为active状态并对外提供服务，ResourceManager 同理。所以，在实际生产中一般采用 HA 架构来提高集群的可靠性。 我这里用三台机器来搭建 Hadoop 高可用集群，hadoop 版本3.2.0 集群可以自己规划，节点最好为奇数，最少为3个节点 用Hadoop用户需要相关设置，也可以直接用root用户(我这里用的是root) 集群环境下配置SSH免密码登录 注意：配置SSH免密码登录，使用hadoop身份登录虚拟机服务器，进行相关的操作。 分别在每台机器上安装 设置好hosts 192.168.217.128 hadoop301 192.168.217.129