•个数原则：如果列的个数比较多，建议2 ~ 3个，如果列的个数比较少，建议1个 –列族个数多了，导致比较次数变多，降低性能 –列族个数少了，导致列的比较次数变多，降低性能 •长度原则 ：能满足业务需求的情况下，越短越好
HBase中的一级索引指数据在写入region时，会根据rowkey进行排序后写入，之后regionserver在加载region时，会自动为当前region的rowkey创建一个LSM树的索引,方便对当前region,rowkey的查询。
本文介绍了详细了HBaseSQL，Phoinix和Spark的架构，适用性以及优缺点，并在最后规划出未来将要设计的一款更符合用户需求的产品。
在前面的学习中, 我们知道 HBase 只能通过 rowkey 进行搜索, 一般把 rowkey 称作一级索引. 在很长的一段时间里 HBase 就只支持一级索引. HBase 里面只有 rowkey 作为一级索引， 如果要对库里的非 rowkey 字段进行数据检索和查询， 往往要通过 MapReduce/Spark 等分布式计算框架进行，硬件资源消耗和时间延迟都会比较高。 为了 HBase 的数据查询更高效、适应更多的场景， 诸如使用非 rowkey 字段检索也能做到秒级响应，或者支持各个字段进行模糊查询和多字段组合查询等， 因此需要在 HBase 上面构建二级索引， 以满足现实中更复杂多样的业务需求。 从 0.94 版本开始, HBase 开始支持二级索引. HBase 索引有多种放方案, 我们今天要做的是使用 Phoenix 给 HBase 添加二级索引.
在HBase中，表格的Rowkey按照字典排序，Region按照RowKey设置split point进行shard，通过这种方式实现的全局、分布式索引，成为了其成功的最大的砝码。图1显示了HBase
机票业务看起来简单，实际上整个流程的处理链条很长，调用关系也非常复杂，上下游涉及的各类日志种类约60个，每种日志都有独立格式和请求/响应报文，日生产的日志数据量约50-100亿，如果时间范围再扩大到15天，数据量轻松的达到千亿级以上。
hbase的内部使用KeyValue的形式存储，其key时rowKey：family:column:logTime,value是其存储的内容。
HBase是大数据NoSQL领域里非常重要的分布式KV数据库，是一个高可靠、高性能、高伸缩的分布式存储系统，目前国内知名公司都有在大规模使用，社区也非常活跃。本文就是学习HBase的敲门砖，主要从以下几个方面解读HBase。
Phoenix 在 HBase 生态系统中占据了非常重要的地位，本文主要包括以下几方面内容：
1.客户端与服务端通信会遇到哪些问题？ 2.怎样基于Storm和HBase打造实时监控平台？ 3.怎样对Web系统进行分布式改造？ 快的打车从2013年年底到2014年下半年，系统访问量迅速膨胀，很多
快的打车从2013年年底到2014年下半年，系统访问量迅速膨胀，很多复杂的问题要在短时间内解决，且不能影响线上业务，这是比较大的挑战，看下打车架构演变过程遇到的一些有代表性的问题和解决方案。
HBase的一级索引就是rowkey，我们只能通过rowkey进行检索。如果我们相对hbase里面列族的列列进行一些组合查询，就需要采用HBase的二级索引方案来进行多条件的查询。 常见的二级索引方案有以下几种： 1.MapReduce方案 2.ITHBASE方案 3.IHBASE方案 4.Coprocessor方案 5.Solr+hbase方案 MapReduce方案IndexBuilder：利用MR的方式构建Index 优点：并发批量构建Index 缺点：不能实时构建Index ITHBAS
作者：王小雪。滴滴出行架构师，原快的打车架构师。 来源：程序员杂志 某知名打车平台从随着业务的发展，系统访问量迅速膨胀，很多复杂的问题要在短时间内解决，且不能影响线上业务，这是比较大的挑战，本文将会阐
很久很久以前，有一天，我在HBase中新建了一张表 “XXX: XXX _EXCEPTION_LIST_INFO”，同时HBase在处理大量更新操作。然后在DROP掉表XXX: XXX_EXCEPTION_LIST_INFO时，HBase Master就宕机。
Cloudera Labs在2016-06-27宣布打包了Apache Phoenix项目，版本为4.7.0，并基于CDH5.7.0。安装依旧是大家熟悉的Parcel方式，下载地址为：http://archive.cloudera.com/cloudera-labs/phoenix/parcels/1.3/
由于hbase基于行健有序存储，在查询时使用行健十分高效，然后想要实现关系型数据库那样可以随意组合的多条件查询、查询总记录数、分页等就比较麻烦了。想要实现这样的功能,我们可以采用两种方法:
目前的分区方案都依赖KV数据模型。KV模型简单，都是通过K访问记录，自然可根据K确定分区，并将读写请求路由到负责该K的分区。
Phoenix是HBase的开源SQL皮肤。可以使用标准JDBC API代替HBase客户端API来创建表，插入数据和查询HBase数据。
二级索引与索引Join是多数业务系统要求存储引擎提供的基本特性，RDBMS早已支持，NOSQL阵营也在摸索着符合自身特点的最佳解决方案。这篇文章会以Hbase做为对象来讨论如何基于Hbase构建二级索引与实现索引join。文末同时会列出目前已知的包括0.19.3版secondary index, ITHbase, Facebook方案和官方Coprocessor的介绍。 理论目标在HBase中实现二级索引与索引Join需要考虑三个目标：1，高性能的范围检索。2，数据的低冗余（存储所占的数据量）。3，数据的
Hbase理论知识点概要 问题01：Hbase的功能与应用场景？ 功能：Hbase是一个分布式的、基于分布式内存和HDFS的按列存储的、NoSQL数据库 应用：Hbase适合于需要实时的对大量数据进行快速、随机读写访问的场景 问题02：Hbase有什么特点？ 分布式的，可以实现高并发的数据读写 上层构建分布式内存，可以实现高性能、随机、实时的读写 底层基于HDFS，可以实现大数据 按列存储，基于列实现数据存储，灵活性更高 问题03：Hbase设计思想是什么？ 设计思想
二级索引 二级索引是从主键访问数据的正交方式。Hbase中有一个按照字典排序的主键Rowkey作为单一的索引。不按照Rowkey去读取记录都要遍历整张表，然后按照你指定的过滤条件过滤。通过二级索引，索引的列或表达式形成一个备用行键，以允许沿着这个新轴进行点查找和范围扫描。 1 覆盖索引（Covered Indexes） Phoenix特别强大，因为它提供了覆盖索引。一旦找到索引的条目，不需要返回主表。相反，把我么关心的数据绑定到索引行，节省了读取的时间开销。 例如，以下内容将在v1和v2列上创建一个
本期有 HBase入门教程、Spark On HBASE、HBase二级索引、SQL 与 NoSQL、高并发&高可用、MySQL索引、Redis。 希望大家会喜欢！
2）无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一张表中不同的行可以有截然不同的列；
接着上一篇介绍协处理器的文章http://qindongliang.iteye.com/blog/2277145，本篇我们来实战一个例子，看下如何使用协处理来给Hbase建立二级索引。 github地址：https://github.com/qindongliang/hbase-increment-index 业务需求： 现有一张Hbase的表，数据量千万级+，而且不断有新的数据插入，或者无效数据删除，每日新增大概几百万数据，现在已经有离线的hive映射hbase 提供离线查询，但是由于性能
文章简介：Phoenix是一个开源的HBASE SQL层。它不仅可以使用标准的JDBC API替代HBASE client API创建表，插入和查询HBASE，也支持二级索引、事物以及多种SQL层优化。
温馨提示：要看高清无码套图，请使用手机打开并单击图片放大查看。 Fayson的github： https://github.com/fayson/cdhproject 提示：代码块部分可以左右滑动查看噢 1.文档编写目的 ---- Fayson在前面的文章《Cloudera Labs中的Phoenix》，《如何在CDH中使用Phoenix》和《如何使用Phoenix在CDH的HBase中创建二级索引》中介绍了Cloudera Labs中的Phoenix，如何在CDH5.11.2中安装和使用Phoenix4.
现如今大量的中小型公司并没有大规模的数据，如果一家公司的数据量超过100T，且能通过数据产生新的价值，基本可以说是大数据公司了 。起初，一个创业公司的基本思路就是首先架构一个或者几个ECS，后面加入MySQL,如果有图片需求还可加入磁盘，该架构的基本能力包括事务、存储、索引和计算力。随着公司的慢慢发展，数据量在不断地增大，其通过MySQL及磁盘基本无法满足需求，只有分布式化。 这个时候MySQL变成了HBase,检索变成了Solr/ES，再ECS提供的计算力变成了Spark。但这也会面临存储量大且存储成本高等问题。
Elasticsearch（简称ES）是当前使用最多、规模最大的检索系统。ES是一个分布式，高实时的搜索引擎，覆盖许多实时检索场景和更低的响应时效，为所有类型的数据提供近乎实时的搜索和分析。ES的检索能力广泛应用于各种搜索场景中。下图是检索平台数据流程：
全局索引是Phoenix的重要特性，合理的使用二级索引能降低查询延时，让集群资源得以充分利用。本文将讲述如何高效的设计和使用索引。
作者：Matt Kalan 原文：The Future of Big Data Architecture 译者：孙薇 本文讲述了大数据的相关问题，以及“大数据架构”得名的由来。 大数据的问题 或许所有读者都明白这一点：数据正在飞速增长。若是能够有效利用的话，我们能从这些数据中找到非常有价值的见解；传统技术有很多都是在40年前设计的，比如RDBMSs，不足以创造“大数据”炒作所宣称的商业价值。在大数据技术的使用上，常见的案例是“客户单一视图”；将关于客户所知道的一切内容放在一起，以便最大化服务提供与自身收入，
用户从 Lambda 架构入手，将数据管道拆分为批处理链路和流处理链路。对于实时数据流，他们应用 Flink CDC ；对于批量导入，他们结合了 Sqoop、Python 和 DataX 来构建自己的数据集成工具，名为 Hisen。
MySQL：关系型数据库，主要面向OLTP，支持事务，支持二级索引，支持sql，支持主从、Group Replication架构模型（本文全部以Innodb为例，不涉及别的存储引擎）。
(1)创建Connection是重量级的，并且，创建过多Connection会导致HBase拒绝连接。
Phoenix是什么 简单来说，Phoenix 是一个可以让我们通过SQL的方式操作HBase数据库的框架。 HBase是一个NoSQL数据库，shell客户端只支持一些简单的操作，而且看起来容易晕。
Feed流：可以理解为信息流，解决的是信息生产者与信息消费者之间的信息传递问题。 我们常见的Feed流场景有：
Hbase默认只支持对行键的索引，那么如果需要针对其它的列来进行查询，就只能全表扫描了。表如果较大的话，代价是不可接受的，所以要提出二级索引的方案。网上的实现方法很多，华为，360等公司都有自己的方案，其中华为的已经开源，但是貌似对源码改动较大，新手不容易接受，所以没有选择它们。而其它的像利用Phoenix，solr等外部框架构建索引对Hbase的学习并没有太大的帮助。综上所述，我使用了Hbase自带的Cprocessor（协处理器）来实现。
首先通过搜索词匹配倒排表得到一个只有id的结果集，然后通过id匹配正排索引拿到对应的文档字段，最后返回结果，这样的好处是：
hbase-site.xml： <property> <name>hbase.master.maxclockskew</name> <value>45000000</value> </property> <property> <name>hbase.rpc.timeout</name> <value>36000000</value> </property> <property> <name>hbase.client.scanner.timeout.period</name> <value>36000000</value> </property> <property> <name>mapreduce.task.timeout</name> <value>1200000</value> </property> <property> <name>zookeeper.session.timeout</name> <value>1200000</value> </property> <property> <name>hbase.client.write.buffer</name> <value>20971520</value> </property> <property> <name>hbase.balancer.period</name> <value>300000</value> </property> <property> <name>hbase.regionserver.wal.codec</name> <value>org.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec</value> </property> 组合主键: create table "test_keys2" ( "V_1" decimal(24,8), "V_2" varchar, "YEAR" INTEGER not null , "PERIOD" INTEGER not null ,"ACCOUNT" INTEGER not null , "ENTITY" INTEGER not null , "SCENARIO" INTEGER not null , "CURRENCY" INTEGER not null , "VERSION" INTEGER not null , "CST_DIM_02217" INTEGER not null, "CST_DIM_30453" INTEGER not null, "CST_DIM_47894" INTEGER not null , "CST_DIM_61310" INTEGER not null , "CST_DIM_81981" INTEGER not null , "CST_DIM_01216" INTEGER not null, "CST_DIM_25287" INTEGER not null, "CST_DIM_41183" INTEGER not null constraint pk primary key("YEAR" , "PERIOD" , "ACCOUNT" ,"ENTITY" , "SCENARIO" , "CURRENCY" , "VERSION","CST_DIM_02217" ,"CST_DIM_30453" ,"CST_DIM_47894" , "CST_DIM_61310","CST_DIM_81981" ,"CST_DIM_01216" , "CST_DIM_25287" ,"CST_DIM_41183")); upsert插入数据有问题 二级索引： 同步创建索引 CREATE INDEX ifact1 ON C1_FACT("diminfo".YEAR) INCLUDE("diminfo"."V_1","diminfo".V_2 , "diminfo".PERIOD , "diminfo".ACCOUNT , "diminfo".ENTITY , "diminfo".SCENARIO , "diminfo".CURRENCY , "diminfo".VERSION ,"diminfo"."CST_DIM_02217" , "diminfo"."CST_DIM_30453" , "diminfo"."CST_DIM_47894" , "diminfo"."CST_DIM_61310", "diminfo"."CST_DIM_81981" ,
分布式实时消息队列Kafka（一） 知识点01：课程回顾 Hbase是什么？ 分布式基于内存按列存储NoSQL数据库，用于实时、随机读写大量的数据 Hbase的设计思想是什么？ 冷热数据分离 热数据：大概可能被使用的数据，新产生的数据 写入内存 冷数据：小概率被读取的数据，产生一段时间的数据 写入磁盘 什么是列族，为什么要设计列族？ 列族就是对列进行分组存储 Hbase是一个按列存储的数据库，每张表可以存储上百万列 如果对列做了分组，加快数据读取的速度 Hbase
从这一章开始要讲Region Server这块的了，但是在讲Region Server这块之前得讲一下StoreFile，否则后面的不好讲下去，这块是基础，Region Sever上面的操作，大部分都
谷歌在2006年的一份研究报告中首次对Bigtable进行了阐述，如果你熟悉Bigtable这个名词，那么：行先是以一种非常独特的方式被索引，随后Bigtable利用行键对数据进行分割，将它们分布到集群中。这句话你应该不陌生。
04-08把元数据以及在它基础上的五大应用场景：数据发现（数据地图）、指标管理、模型设计、数据质量、成本优化，全部讲完。这部分内容对应的就是数据中台OneData 方法论。学完这部分内容，你已了解OneData方法论在企业内部落地的方法。
分析用例几乎只使用查询表中列的子集，并且通常在广泛的行上聚合值。面向列的数据极大地加速了这种访问模式。操作用例更有可能访问一行中的大部分或所有列，并且可能更适合由面向行的存储提供服务。Kudu 选择了面向列的存储格式，因为它主要针对分析用例。
在阐述HBase高级特性和热点问题处理前，首先回顾一下HBase的特点：分布式、列存储、支持实时读写、存储的数据类型都是字节数组byte[]，主要用来处理结构化和半结构化数据，底层数据存储基于hdfs。
今天，Cloudera正式宣布在CDH中支持Apache Phoenix，同时也会集成到未来的Cloudera Data Platform中。
大家应该都清楚，数据正在以巨幅的速度增长。如果能够有效地利用这些数据，可以发现非常有价值的内容，然而传统技术（许多早在40年前设计的，比如RDBMS这样的技术）对于“大数据”的大肆宣传的商业价值的创造是远远不够的。一个使用大数据技术的典型例子就是“客户的单一视图” - 旨在汇总有关客户的所有信息，以优化客户的参与度和收益，例如精准地确定通过哪种渠道和什么时间向他们发推送。
总结: HADOOP仅适合存储大批量的数据, 进行顺序化读取数据, 并不支持随机读取数据操作
最近看一本书，铃木敏文的《零售的哲学》，里面提到一个很有意思的观点，711核心使命是提供便利，围绕便利场景，提供一系列食品、ATM服务等，而不是和超市去PK货物品种。 联想到常见的NOSQL数据库和传统关系型数据的区别也有点类似；传统关系型数据库发展了几十年，就像超市一样，功能非常多，非常完善，也是进入到各个行业中去。NOSQL从一出生就是带着解决关系数据中的某些场景的不突出/不擅长的使命。 另外一些新数据库又思考着突破NoSQL的场景的限制，想着同时解决OTLP/OLAP，也有诞生了NewSQL或者HTA
Phoenix是基于HBase的，而Phoenix的索引其实是HBase的二级索引，当Phoenix的索引处于disable状态时，整个Phoenix表是无法正常使用的，要将索引修复为enable状态，往往需要重建索引，这对应一些大表来说，往往需要花费几个小时是时间，那么这几个小时，系统基本上就处于不可用状态，这对应现网系统来说，往往是不可接受的。
Phoenix是构建在HBase上的一个SQL层，能让我们用标准的JDBC APIs而不是HBase客户端APIs来创建表，插入数据和对HBase数据进行查询。 Phoenix完全使用Java编写，作为HBase内嵌的JDBC驱动。Phoenix查询引擎会将SQL查询转换为一个或多个HBase扫描，并编排执行以生成标准的JDBC结果集。直接使用HBase API、协同处理器与自定义过滤器，对于简单查询来说，其性能量级是毫秒，对于百万级别的行数来说，其性能量级是秒。 Phoenix通过以下方式使我们可以少写代码，并且性能比我们自己写代码更好：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
