HBase和Phoenix的整合

安装Phoenix
约定安装到/opt目录下面
解压:
soft]# tar -zxvf phoenix-4.7.0-HBase-1.1-bin.tar.gz -C ../
重命名 opt]# mv phoenix-4.7.0-HBase-1.1 phoenix
拷贝lib目录下面jar包到regionserver机器的lib($HBASE_HOME/lib)目录
phoenix]# scp *.jar root@hadoop02:/opt/hbase/lib/
phoenix]# scp *.jar root@hadoop03:/opt/hbase/lib/
一下两个顺序
2.重启regionserver
hbase-daemon.sh stop regionserver
hbase-daemon.sh start regionserver
1.将phoenix中的client拷贝到hbase的client中,重启master
phoenix]# cp phoenix-4.7.0-HBase-1.1-client.jar /opt/hbase/lib/
另外,为了防止出错,将phoenix-4.7.0-HBase-1.1-client.jar添加到HBASE_CLASSPATH
vim /opt/hbase/conf/hbase-env.sh
export HABASE_CLASSPATH=$HABASE_CLASSPATH:/opt/hbase/lib/phoenix-4.7.0-HBase-1.1-client.jar 
官网测试案例:
./psql.py hadoop01:2181 us_population.sql us_population.csv us_population_queries.sql

./psqlline.py zookeeper


部分hbase英文注释

/**
 * File format for hbase.
 * A file of sorted key/value pairs. Both keys and values are byte arrays.
 * <p>
 * The memory footprint of a HFile includes the following (below is taken from the
 * <a
 * href=https://issues.apache.org/jira/browse/HADOOP-3315>TFile</a> documentation
 * but applies also to HFile):
 * <ul>
 * <li>Some constant overhead of reading or writing a compressed block.
 * <ul>
 * <li>Each compressed block requires one compression/decompression codec for
 * I/O.
 * <li>Temporary space to buffer the key.
 * <li>Temporary space to buffer the value.
 * </ul>
 * <li>HFile index, which is proportional to the total number of Data Blocks.
 * The total amount of memory needed to hold the index can be estimated as
 * (56+AvgKeySize)*NumBlocks.
 * </ul>
 * Suggestions on performance optimization.
 * <ul>
 * <li>Minimum block size. We recommend a setting of minimum block size between
 * 8KB to 1MB for general usage. Larger block size is preferred if files are
 * primarily for sequential access. However, it would lead to inefficient random
 * access (because there are more data to decompress). Smaller blocks are good
 * for random access, but require more memory to hold the block index, and may
 * be slower to create (because we must flush the compressor stream at the
 * conclusion of each data block, which leads to an FS I/O flush). Further, due
 * to the internal caching in Compression codec, the smallest possible block
 * size would be around 20KB-30KB.
 * <li>The current implementation does not offer true multi-threading for
 * reading. The implementation uses FSDataInputStream seek()+read(), which is
 * shown to be much faster than positioned-read call in single thread mode.
 * However, it also means that if multiple threads attempt to access the same
 * HFile (using multiple scanners) simultaneously, the actual I/O is carried out
 * sequentially even if they access different DFS blocks (Reexamine! pread seems
 * to be 10% faster than seek+read in my testing -- stack).
 * <li>Compression codec. Use "none" if the data is not very compressable (by
 * compressable, I mean a compression ratio at least 2:1). Generally, use "lzo"
 * as the starting point for experimenting. "gz" overs slightly better
 * compression ratio over "lzo" but requires 4x CPU to compress and 2x CPU to
 * decompress, comparing to "lzo".
 * </ul>
 *
 * For more on the background behind HFile, see <a
 * href=https://issues.apache.org/jira/browse/HBASE-61>HBASE-61</a>.
 * <p>
 * File is made of data blocks followed by meta data blocks (if any), a fileinfo
 * block, data block index, meta data block index, and a fixed size trailer
 * which records the offsets at which file changes content type.
 * <pre>&lt;data blocks>&lt;meta blocks>&lt;fileinfo>&lt;data index>&lt;meta index>&lt;trailer></pre>
 * Each block has a bit of magic at its start.  Block are comprised of
 * key/values.  In data blocks, they are both byte arrays.  Metadata blocks are
 * a String key and a byte array value.  An empty file looks like this:
 * <pre>&lt;fileinfo>&lt;trailer></pre>.  That is, there are not data nor meta
 * blocks present.
 * <p>
 * TODO: Do scanners need to be able to take a start and end row?
 * TODO: Should BlockIndex know the name of its file?  Should it have a Path
 * that points at its file say for the case where an index lives apart from
 * an HFile instance?
 */

猜你喜欢

转载自blog.csdn.net/kaaosidao/article/details/78242254