Apache HBase

配置namenode HA高可用 使用cloudera manager方式安装，namenode是单节点方式，需要额外配置成HA。配置NameNode HA的两点前提条件： （1）至少是3个或3个以上奇数个JournalNode，否则将无法继续配置NameNode HA. （2）配置NameNode需要有Zookeeper. 在hdfs - 操作 -选择启用HA 填写nameservice名称，自定义即可： 选择另外一台服务器安装namenode ，三个或5个节点安装journalnode。 配置namenode,journalnode数据目录,如/data1/dfs/nn，/data1/dfs/jn 继续等待命令执行完成，按照向导操作即可 启用HA成功 配置yarn HA高可用 使用管理员用户登录Cloudera Manager的Web管理界面，进入YARN服务 点击“启用High Avaiability”，选择ResourceManager主机 点击“继续”，启用ResourceManager HA 点击“完成”，查看YARN服务实例 可以看到YARN的ResourceManager实例为两个，一个是活动状态，一个是备用状态，至此已完成YARN HA的启用，那么接下来就测试下YARN HA功能的可用性。 Yarn HA功能可用性测试 ResourceManager服务状态

数据分为结构化和非结构化两种。尽管大数据为各种规模的组织提供了许多洞察和分析的机会，但处理起来非常困难，并且需要一系列的特定技能。 大数据由大数据架构师处理，这是一个非常专业的职位。很多组织需要大数据架构师采用数据技术Hadoop分析数据来解决重大的问题。 大数据架构师需要大规模处理数据库并分析数据，以便帮助组织做出正确的业务决策。具有这种才能的架构师需要成为一支强大团队的领导者。他应该具有指导团队成员工作并与不同的团队合作的能力。对于他们而言，与各种组织和供应商建立良好的合作关系也至关重要。 从事大数据架构师工作所需的6种技能 成为大数据架构师需要多年的学习培训，需要具有广泛的能力，而这些能力会随着领域的发展而增长。大数据架构师需要具备以下6种技能： (1) 数据分析的决策权，应具备采用大数据技术分析海量数据的能力。 (2) 应该了解机器学习技术，因为这是至关重要的知识。还要具有模式识别、处理数据的聚类以及文本挖掘等能力。 (3) 大数据架构师应该对编程语言和所有最新技术有浓厚的兴趣和经验。了解所有类型的JavaScript框架，如HTML5、RESTful服务、Spark、Python、Hive、Kafka和CSS都是必不可少的框架。 (4) 大数据架构师应具备必要的知识和经验，以处理最新的数据技术，例如Hadoop、MapReduce、HBase、oozie、Flume

参考文章： CDH常用端口汇总 Hadoop： 50070：HDFS WEB UI端口 8020 ： 高可用的HDFS RPC端口 9000 ： 非高可用的HDFS RPC端口 8088 ： Yarn 的WEB UI 接口 8485 ： JournalNode 的RPC端口 8019 ： ZKFC端口 10020：historyserver端口 Zookeeper: 2181 ： 客户端连接zookeeper的端口 2888 ： zookeeper集群内通讯使用，Leader监听此端口 3888 ： zookeeper端口 用于选举leader Hbase: 60010：Hbase的master的WEB UI端口 60030：Hbase的regionServer的WEB UI 管理端口 Hive: 9083 : metastore服务默认监听端口 10000：Hive 的JDBC端口 Spark： 7077 ： spark 的master与worker进行通讯的端口 standalone集群提交Application的端口 8080 ： master的WEB UI端口 资源调度 8081 ： worker的WEB UI 端口 资源调度 4040 ： Driver的WEB UI 端口 任务调度 18080：Spark History Server的WEB UI 端口 Kafka：

面对可能出现的网络延迟，不可预估的请求流量等情况，设计一个分布式系统，我们通常围绕系统高可用，数据一致性的目标去规划和实现，想要完全实现这个目标，却并非易事。由此，分布式系统领域诞生了一个基本定理，即 CAP 定理，用于指导分布式系统的设计，从系统高可用，数据一致性，网络容错三个角度将分布式系统的特性抽成一个分区容错一致性模型。这样一来，让系统设计者只需根据业务场景特点，进行权衡设计适合业务场景的分区容错一致性模型即可，很大程度简化了分布式系统设计的难度。 也因此，CAP 定理是架构师所必须要掌握的内容，它影响着架构师对分布式系统的技术选型，技术决策。既然如此重要，接下来，我们就一起学习下 CAP 定理吧。 什么是 CAP CAP 定理最初是由加州大学伯克利分校的计算机科学家埃里克·布鲁尔（Eric Brewer）在 2000 年的 ACM PODC 上提出的一个猜想，也因此被叫做布鲁尔定理。后来在 2002 年，麻省理工学院的赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）发表了 CAP 定理的证明，让它成为分布式系统领域公认的一个定理。 CAP 定理指出了，在一个跨区域网络连接，共享数据的分布式系统中，一致性（Consistency），可用性（Availability）和分区容错性（Partition Tolerance）

HBase借鉴 列存储 的思想，但是最底层依然是依靠键值对来存储数据，HBase为非关系型数据库 而MySQL则是 行存储 ，MySQL为关系型数据库 写过程 行存储因为数据是连续的，所以只需要进行追加即可； 列存储因为数据不连续，所以需要不断的寻址来添加或者修改数据。 读过程 整表读的时候，因为行存储的数据是连续的，所以读取速度比较快； 字段都得时候，此时列存储比较快；并且在实际生产中，字段都比较多 来源： oschina 链接： https://my.oschina.net/u/4115134/blog/4365836

面对可能出现的网络延迟，不可预估的请求流量等情况，设计一个分布式系统，我们通常围绕系统高可用，数据一致性的目标去规划和实现，想要完全实现这个目标，却并非易事。由此，分布式系统领域诞生了一个基本定理，即 CAP 定理，用于指导分布式系统的设计，从系统高可用，数据一致性，网络容错三个角度将分布式系统的特性抽成一个分区容错一致性模型。这样一来，让系统设计者只需根据业务场景特点，进行权衡设计适合业务场景的分区容错一致性模型即可，很大程度简化了分布式系统设计的难度。 也因此，CAP 定理是架构师所必须要掌握的内容，它影响着架构师对分布式系统的技术选型，技术决策。既然如此重要，接下来，我们就一起学习下 CAP 定理吧。 什么是 CAP CAP 定理最初是由加州大学伯克利分校的计算机科学家埃里克·布鲁尔（Eric Brewer）在 2000 年的 ACM PODC 上提出的一个猜想，也因此被叫做布鲁尔定理。后来在 2002 年，麻省理工学院的赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）发表了 CAP 定理的证明，让它成为分布式系统领域公认的一个定理。 CAP 定理指出了，在一个跨区域网络连接，共享数据的分布式系统中，一致性（Consistency），可用性（Availability）和分区容错性（Partition Tolerance）

参考文章： 几种常见的数据分区方法 数据分区方法 数据的分区方法（Partitioning methods）大概有以下几种： 垂直分区（Vertical partitioning） 水平分区（Horizontal partitioning） 混合分区（Hybrid partitioning） 垂直分区（Vertical partitioning） 垂直分区需要创建一些较少列的表，每张表存储源表的部分列，以此达到数据的分区。比如我们有一张名为 iteblog 表，如下： CREATE TABLE iteblog ( attr1 INT, attr2 INT, attr3 INT, attr4 TEXT ); 使用垂直分区，可以将这张表拆分成以下形式： 这个在 大数据 数据仓库 很常见，比如我们将一些数据量小，但是经常查询的数据放到 ES 中，数据量比较大的部分，但是不经常被查到放到 HBase 中。这种方法还可以根据说的访问频率，把不同的列数据存放到不同的存储介质中，以此节省存储成本。 水平分区（Horizontal partitioning） 水平分区分区也称为分片（sharding），其根据不同的分区算法将不同行的数据存储到不同的表中（比如关系型数据库中的分库分表）。例如，邮政编码小于50000 的客户存储在 CustomersEast 表中，而邮政编码大于或等于 50000

简介： 用户只需在前端简单配置下指标，系统即可自动生成大宽表，让用户查询到他所需要的实时数据，数据源支持跨库并支持多种目标介质。这样的数据全局实时可视化如何实现？本文从需求分析开始，分享自动生成SQL功能开发中运用到的设计模式和数据结构算法设计。 一 概述 ADC（Alibaba DChain Data Converger）项目的主要目的是做一套工具，用户在前端简单配置下指标后，就能在系统自动生成的大宽表里面查询到他所需要的实时数据，数据源支持跨库并支持多种目标介质。说的更高层次一点， 数据的全局实时可视化这个事情本身就是解决供应链数据“神龙效应”的有效措施（参考施云老师的《供应链架构师》[1]一书）。做ADC也是为了这个目标，整个ADC系统架构如下图所示： 架构解析： 初始数据来自于元数据中心。 经过元数据适配层后转换为内部格式数据。 调度中心把内部格式的数据传到计划中心，计划中心分析数据需求并建模，通过SQL生成器生成资源和SQL，分别通过告警中心、对账中心设定监控标准和对账标准。 对账中心定时对账，查看数据的对齐情况。 告警中心可以针对任务错误、延迟高等情况发送报警。 资源的生命周期管控在资源管理中心下，view删除时资源管理中心负责回收资源。 基础资源适配层主要借助集团基础资源管理能力串联阿里各类数据服务， 比如阿里云MaxComputer、Flink

文章收录在我的 GitHub 仓库，欢迎Star/fork： Java-Interview-Tutorial https://github.com/Wasabi1234/Java-Interview-Tutorial 一般初创软件，为快速上线，几乎不考虑分层。但随业务越发复杂，就会导致逻辑复杂、模块相互依赖、代码扩展性差等各种问题。 架构分层迫在眉睫。 1 什么是架构分层? 软件工程中常见的设计方式，将整体系统拆分成N个层次，每个层次有独立的职责，多个层次协同提供完整的功能。 初学 JavaWeb 时一般要求设计成 MVC 架构。另外一种常见的分层方式是将整体架构分为 表现层（Web） 展示数据结果和接受用户指令的，是最靠近用户的一层； 逻辑层（Service） 复杂业务的具体实现； 数据访问层（Dao） 主要处理和存储之间的交互。 这就可以隔离关注点，让不同的层专注做不同的事情。其它分层案例，比如OSI网络七层模型，TCP/IP协议网络四层模型。 2 分层有什么好处？ 简化设计 各司专职，而不必将自己活成全才。 高复用 比如在设计某系统时，发现某层具有通用性，就可把它抽取独立出来，在设计其它系统时使用。 横向扩展 可以让我们更容易做横向扩展。如果系统没有分层，当流量增加时我们需要针对整体系统来做扩展。但是，如果我们按照上面提到的三层架构将系统分层后

1 创建Maven项目 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>org.example</groupId> <artifactId>doit15-hbase</artifactId> <version>1.0-SNAPSHOT</version> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> </properties>