最近在学习Hbase的使用，并仔细阅读了一篇官方推荐的博客，在这里就以一边翻译一边总结的方式和大家一起梳理一下HBase的数据模型和基本的表设计思路。
官方推荐的博客原文地址：http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/9353-login1210_khurana.pdf点击打开链接


HBase是一个开源可伸缩的针对海量数据存储的分布式nosql数据库，它根据Google Bigtable数据模型来建模并构建在hadoop的hdfs存储系统之上。它和关系型数据库Mysql, Oracle等有明显的区别，HBase的数据模型牺牲了关系型数据库的一些特性但是却换来了极大的可伸缩性和对表结构的灵活操作。

在一定程度上，Hbase又可以看成是以行键(Row Key),列标识(column qualifier),时间戳(timestamp)标识的有序Map数据结构的数据库，具有稀疏，分布式，持久化，多维度等特点。

Base的数据模型介绍
HBase的数据模型也是由一张张的表组成，每一张表里也有数据行和列，但是在HBase数据库中的行和列又和关系型数据库的稍有不同。下面统一介绍HBase数据模型中一些名词的概念:
      
         表(Table): HBase会将数据组织进一张张的表里面，但是需要注意的是表名必须是能用在文件路径里的合法名字，因为HBase的表是映射成hdfs上面的文件。

         行(Row): 在表里面，每一行代表着一个数据对象，每一行都是以一个行键（Row Key）来进行唯一标识的，行键并没有什么特定的数据类型，以二进制的字节来存储。

         列族(Column Family): 在定义HBase表的时候需要提前设置好列族, 表中所有的列都需要组织在列族里面，列族一旦确定后，就不能轻易修改，因为它会影响到HBase真实的物理存储结构，但是列族中的列标识(Column Qualifier)以及其对应的值可以动态增删。表中的每一行都有相同的列族，但是不需要每一行的列族里都有一致的列标识(Column
 Qualifier)和值，所以说是一种稀疏的表结构，这样可以一定程度上避免数据的冗余。例如：{row1, userInfo: telephone —> 137XXXXX869 }{row2, userInfo: fax phone —> 0898-66XXXX } 行1和行2都有同一个列族userinfo，但是行1中的列族只有列标识(Column Qualifier):移动电话号码，而行2中的列族中只有列标识(Column Qualifier):传真号码。

         列标识(Column Qualifier): 列族中的数据通过列标识来进行映射，其实这里大家可以不用拘泥于“列”这个概念，也可以理解为一个键值对,Column Qualifier就是Key。列标识也没有特定的数据类型，以二进制字节来存储。

         单元(Cell): 每一个 行键，列族和列标识共同组成一个单元，存储在单元里的数据称为单元数据，单元和单元数据也没有特定的数据类型，以二进制字节来存储。

         时间戳(Timestamp): 默认下每一个单元中的数据插入时都会用时间戳来进行版本标识。读取单元数据时，如果时间戳没有被指定，则默认返回最新的数据，写入新的单元数据时，如果没有设置时间戳，默认使用当前时间。每一个列族的单元数据的版本数量都被HBase单独维护，默认情况下HBase保留3个版本数据。


图片来自：http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/9353-login1210_khurana.pdf


        有时候，你也可以把HBase看成一个多维度的Map模型去理解它的数据模型。正如下图，一个行键映射一个列族数组，列族数组中的每个列族又映射一个列标识数组，列标识数组中的每一个列标识(Column Qualifier)又映射到一个时间戳数组，里面是不同时间戳映射下不同版本的值，但是默认取最近时间的值，所以可以看成是列标识(Column Qualifier)和它所对应的值的映射。用户也可以通过HBase的API去同时获取到多个版本的单元数据的值。Row
 Key在HBase中也就相当于关系型数据库的主键，并且Row Key在创建表的时候就已经设置好，用户无法指定某个列作为Row Key。




图片来自：http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/9353-login1210_khurana.pdf    
        

       又有的时候，你也可以把HBase看成是一个类似Redis那样的Key-Value数据库。如下图，当你要查询某一行的所有数据时，Row
 Key就相当于Key，而Value就是单元中的数据(列族，列族里的列和列中时间戳所对应的不同版本的值)；当深入到HBase底层的存储机制时，用户要查询指定行里某一条单元数据时，HBase会去读取一个数据块，里面除了有要查询的单元数据，可能同时也会获取到其它单元数据，因为这个数据块还包含着这个Row Key所对应的其它列族或其它的列信息，这些信息实际也代表着另一个单元数据，这也是HBase的API内部实际的工作原理。


图片来自：http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/9353-login1210_khurana.pdf


        HBase提供了丰富的API接口让用户去操作这些数据。主要的API接口有3个，Put，Get，Scan。Put和Get是操作指定行的数据的，所以需要提供行键来进行操作。Scan是操作一定范围内的数据，通过指定开始行键和结束行键来获取范围，如果没有指定开始行键和结束行键，则默认获取所有行数据。


HBase的表设计中需要注意的问题
   当开始设计HBase中的表的时候需要考虑以下的几个问题：
        1. Row Key的结构该如何设置，而Row Key中又该包含什么样的信息（这个很重要，下面的例子会有说明）
        2. 表中应该有多少的列族
        3. 列族中应该存储什么样的数据
        4. 每个列族中存储多少列数据
        5. 列的名字分别是什么，因为操作API的时候需要这些信息
        6. 单元中(cell)应该存储什么样的信息
        7. 每个单元中存储多少个版本信息
     在HBase表设计中最重要的就是定义Row-Key的结构，要定义Row-Key的结构时就不得不考虑表的接入样本，也就是在真真实应用中会对这张表出现什么样的读写场景。除此之外，在设计表的时候我们也应该要考虑HBase数据库的一些特性。
       1. HBase中表的索引是通过Key来实现的
       2. 在表中是通过Row Key的字典序来对一行行的数据来进行排序的，表中每一块区域的划分都是通过开始Row Key和结束Row Key来决定的。
       3. 所有存储在HBase表中的数据都是二进制的字节，并没有数据类型。
       4. 原子性只在行内保证，HBase表中并没有多行事务。
       5. 列族(Column Family)在表创建之前就要定义好
       6. 列族中的列标识(Column Qualifier)可以在表创建完以后动态插入数据时添加。

接下来我们考虑一个这样的场景，我们要设计一张表，用来保存微博上用户互粉的信息。所以设计表之前，我们要考虑业务中的读写场景。

读场景中我们要考虑：
1. 每个用户都关注了谁
2. 用户A有没有关注用户B
3. 谁关注了用户A

写场景中我们要考虑：
1. 用户关注了另一个用户
2. 用户取消关注某个用户

下面我们来看几种表结构的设计:
第一种表结构设计中，在这种表结构设计中，每一行代表着某个用户和所有他所关注的其它用户。这个用户ID就是Row Key，而每一个列标识(Column Qualifier)就是这个用户所关注的其他用户在列族里的序号，单元数据就是这个用户所关注的其他用户的用户ID。在这种表结构的设计下，“每个用户都关注了谁”这个问题很好解决，但对于“用户A有没有关注用户B”这个问题在列很多的时候，需要遍历所有单元数据去找到用户B，这样的开销会十分大。并且当添加新的被关注用户时，因为不知道给这个新用户分配什么样的列族序号，需要遍历整个列族中的所有列找出最后一个列，并将最后一个列的序号+1给新的被关注用户作为列族内的序号，这样的开销也十分大。


图片来自：http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/9353-login1210_khurana.pdf


所以衍生出了第二种表结构设计，如下图，添加一个counter记录列族中所有列的总数量，当添加新的被关注用户时，这个新用户的序号就是counter+1。但是当要取消关注某个用户时，一样得遍历所有的列数据，而且最大的问题是在于HBase不支持事务处理，这种通过counter来添加被关注用户的操作逻辑得写在客户端中。


图片来自：http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/9353-login1210_khurana.pdf


回想一下，列标识(Column Qualifier)存储的时候是二进制的字节，所以列标识可以存储任何数据，而且列标识还是动态增添的，基于这个特性我们再改进表的设计，如下图。这次以被关注的用户ID做为列标识(Column Qualifier)，然后单元数据可以是任意数字，比如全部统一成1。在这种表结构的设计下，添加新的被关注者，以及取消关注都会变得很简单。但是对于读场景中，谁关注了用户A这个问题，因为HBase数据库的索引只建立在Row
 Key上，这里不得不扫描全表去统计所有关注了用户A的用户数量，所以下面的这个表结构设计也存在一定的性能问题。这里也引出一个思路，被关注者需要以某种方式添加索引。


图片来自：http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/9353-login1210_khurana.pdf


针对上面的表结构有三种优化方案，第一种是新建另一张表，里面保存某个用户和所有关注他的用户。第二种解决方案就是在同一张表中也存储某个用户和所有关注他的用户的信息，并从Row Key中区分开来，比如：Row key为Jame_001_following的这行保存着所有Jame关注的人的信息，而Row_Key为Jame_001_followed的这行保存着所有关注Jame的人的信息。最后一种优化方案就是，如下图，将Row
 Key设计成“followerID+followedID”的形式，比如：“Jame+Emma”，这里的Row Key值就代表着Jame关注了Emma(其实这里应该是“Jame的ID+Emma的ID”，只是为了解释方便而直接用名字)，同时包含了关注者和被关注者两个信息；还需要注意的一点就是列族的名字被设计成只有一个字母f，这样设计的好处就是减少了HBase对数据的I/O操作压力，同时减少了返回到客户端的数据字节，提高响应速度，因为每一个返回给客户端的KeyValue对象都会包含列族名字。同时将被关注人的用户名称也保存在了表中作为Column
 Qualifier，这样做的好处就是节省了去用户表查找用户名的资源。在这种表结构设计下，“用户A取消关注某个用户B”，“用户A有没有关注用户B？”的业务处理就会变得简单高效。




图片来自：http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/9353-login1210_khurana.pdf


还有一个需要注意的问题，就是在实际的生产环境中，还需要将Row Key使用MD5加密，一方面是使Row Key的长度都一致，能提高数据的存取性能。这方面的优化不在本文的讨论范围内。


图片来自：http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/9353-login1210_khurana.pdf


总结：
整篇文章概述了HBase的数据模型和基本的表设计思路。下面是HBase一些关键特性的总结:
   1. Row Key是HBase表结构设计中很重要的一环，它设计的好坏直接影响程序和HBase交互的效率和数据存储的性能。
   2. Base的表结构比传统关系型数据库更灵活，你能存储任何二进制数据在表中，而且无关数据类型。
   3. 在相同的列族中所有数据都具有相同的接入模式
   4. 主要是通过Row Key来建立索引
   5. 以纵向扩张为主设计的表结构能快速简单的获取数据，但牺牲了一定的原子性，就比如上文中最后一种表结构；而以横向扩张为主设计的表结构，也就是列族中有很多列，比如上文中第一种表结构，能在行里面保持一定的原子性。
   6. HBase并不支持事务，所有尽量在一次API请求操作中获取到结果
   7. 对Row Key的Hash优化能获得固定长度的Row Key并使数据分布更加均匀一些，而不是集中在一台服务器上，但是也牺牲了一定的数据排序和读取性能。
   8. 可以利用列标识(Column Qualifier)来存储数据。
   9. 列标识(Column Qualifier)名字的长度和列族名字的长度都会影响I/O的读写性能和发送给客户端的数据量，所以它们的命名应该简洁！

References
[1] Amandeep Khurana   Introduction To HBase Schema Design: http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/9353-login1210_khurana.pdf

cifar-10 数据集是机器学习入门第二个使用到的数据集合（第一个当然是MNIST），下面介绍一下如何解析。

1.  cifar-10 简介

该数据集共有60000张彩色图像，图像大小是3通道的32*32，分为10个类，每类6000张图。这里面有50000张用于训练，构成了5个训练批，每一批10000张图；另外10000用于测试，单独构成一批。测试批的数据里，取自10类中的每一类，每一类随机取1000张。抽剩下的就随机排列组成了训练批。注意一个训练批中的各类图像并不一定数量相同，总的来看训练批，每一类都有5000张图。 

数据的下载：共有三个版本，python,matlab,binary version 适用于C语言 

python： http://www.cs.toronto.edu/~kriz/cifar-10-python.tar.gz

MATLAB： http://www.cs.toronto.edu/~kriz/cifar-10-matlab.tar.gz

bin： http://www.cs.toronto.edu/~kriz/cifar-10-binary.tar.gz

2. 数据解析，Python为例

cifar-10 数据以字典的形式存储，key为：dict_keys([b’batch_label’, b’labels’, b’data’, b’filenames’])，也就是说包含四个内容： batch_label，标签，图像数据，图片对应的文件名。通过一下函数加载：



def unPickle(file):
    import pickle as pk
    with open(file, 'rb') as f:
    d = pk.load(f, encoding='bytes')
    return d

得到数据：



data = unPickle('data_batch_1')
img = data[b'data']
img.shape  # 显示为（10000，3072）

由于是3通道32*32的彩色图像，故每个图像大小为32*32*3=3072

3. 重建图像

将数组重建为彩色图像：



img_0 = img[0] #得到第一张图像
img_reshape = img_0.reshape(3,32,32)
import PIL.Image as image
import matplotlib.pyplot as plt
r = image.fromarray(img_reshape[0]).convert('L')
g = image.fromarray(img_reshape[1]).convert('L')
b = image.fromarray(img_reshape[2]).convert('L')
img_m = image.merge('RGB',(r,g,b))
plt.imshow(img_m)
plt.show()

重要说明

原数据是以数组存储，在应用中需要数据为什么形式（数据还是rgb图像）根据需求决定。

目录
概述
DICOM多帧数据存储
pydicom应用

概述
pydicom是一个常用python DICOM parser。但是，没有提供解析多帧图的示例。本文结合相关函数和DICOM知识做一个简单说明。
DICOM多帧数据存储
DICOM标准中关于多帧数据存储的最重要一部分说明是PS3.5 Annex A.4 A.4 Transfer Syntaxes For Encapsulation of Encoded Pixel Data。
无论何时，Pixel Data都存放在Pixel Data (7FE0,0010)中。有可能是直接存放的(native)，也有可能是被打包存放的(encapsulated）。常见的多帧图一般采用打包存放的方式，特别是在数据存采用压缩格式的时候。
在打包存放时，数据被拆分成很多数据段(Data Stream Fragment)，每个段保存成一个Tag为(FFFE,E000)的DICOM 项目(item)。其中第一个项目保存基础偏移表(Basic Offset Table)，保存每个帧的起始偏移。然后，后面的数据段保存真正的数据。
**理论上，一帧（Frame）可以保存在多个数据段(Fragment)中。**但是，一个数据段不会保存两帧的数据。实际应用中，很少见到Frame跨数据段的情况，不过好的DICOM Parser应该支持这种情况。这就是导致有些DICOM库的接口看起来有点古怪的原因。
pydicom应用
以pydicom 1.2为例，pydicom.encaps封装了多帧有关的功能。解析最可能用到的几个函数
多帧使用 pydicom.encaps来处理
pydicom.encaps.decode_data_sequence 返回每个(FFFE,E000)组成的item，形式是byte string的list。这样一次拿到了所有fragment数据，可能比较耗内存。注意理论上拿到的不是帧(Frame)
pydicom.encaps.generate_pixel_data 生成一个generator。每次迭代，返回做成一个fragments tuple，每个fragment是一个bytes，每个tuple是一个Frame。如果一个Fame保存在一个Fragment中。tuple就只有一个元素。
pydicom.encaps.generate_pixel_data_frame 迭代每次返回一个bytes，这个bytes代表了帧的全部数据。这应该是最常用的函数。代码实现就是把generate_pixel_data生成的tuple给拼接起来了。
这几个方法的输入都是pixel_array。相应的Pydicom提供了用fp做参数的方法。

 

http://www.sunrayimage.com/yuvtools.html   yuvtools

 

RAM数据格式解析

Raw格式是sensor的输出格式，是未经处理过的数据，表示sensor接受 到的各种光的强度。

Raw数据在输出的时候是有一定的顺序的，一般为以下四种:

00： GR/BG

01:   RG/GB

10: BG/GR

11:   GB/RG



为什么每种情况里有两个G分量呢？这时因为人的眼睛对绿色比较敏感，所以增加了对绿色的采样。其中每个分量代表一个piexl。所以GR/BG就代表四个piexl，在物理sensor上就表示4个晶体管，用一个晶体管只采样一个颜色分量，然后通过插值计算得到每个piexl，这样做的主要目的是降低功耗。

sensor输出的数据一般要送到ISP中处理才会得到一个好的效果，这就需要ISP知道sensor输出的raw数据的顺序与大小，其中顺序一般通过配置ISP的pattern寄存器来实现，大小一般配置在ISP的输入格式控制寄存器中。



下面说以下raw数据几种常用的格式:

RAW8:

Raw8即是用8bits表示G/R/B/G中的一个分量,而不是使用8bits表示RG/GB四个分量。在sensor中，为了降低功耗，使用一个晶体来表示一种颜色，然后利用差值计算出相邻像素的值。

Raw10:

Raw10就是使用10bit表示上述的一个G/R/B/G，但是数据中是16bit的，高6位没用。

Raw12:

Raw12: 就是使用12bit表示上述的一个G/R/B/G，但是数据中是16bit的，高4位没用。

看raw数据的工具

看raw数据工具有很多，再此我只介绍我使用的三款：

1 > picasa

Google 的免费图片管理工具Picasa，数秒钟内就可找到并欣赏计算机上的图片。 Picasa 原为独立收费的图像管理、处理软件，其界面美观华丽， 功能实用丰富。后来被 Google 收购并改为免费软件， 成为了 Google 的一部分，它最突出的优点是搜索硬盘中的相片图片的速度很快，当你输入一个字后，准备输入第二个字时，它已经即时显示出搜索出的图片。不管照片有多少，空间有多大，几秒内就可以查找到所需要的图片.

使用比较简单，将文件后缀名修改为raw，然后拖到软件中即可。

2>irfanview

仅仅不到2M的小软件，功能却能与体积大到几十M的ACDSee相媲美！这个软件就是IrfanView。图片、音频、视频浏览，图片批量格式转换、批量重命名，JPE图片无损旋转等只是IrfanView最基本的功能。IrfanView是世界第一个支持多页Gif动画的Windows图像查看器，另外强大的插件外挂功能、自定义皮肤功能以及多种热键支持让你可以定制一个完全属于自己的IrfanView！

使用时，需要将文件后缀名改为raw，然后拖到软件中，填入raw的长宽，然后选择depth，主要是选择pattern，需要知道raw数据是RG/GB等的顺序。这个软件有个问题就是打开的raw数据是上下颠倒的。

3>photoshop

功能强大，不需多言。这里只说一下怎样使用其看raw数据：

首先打开raw数据，在弹出的对话框中填入宽度，然后选择通道为1，如果是raw10，depth选择16，然后选择IBM，打开，发现是一张全黑的图片，然后选择：滤镜->其他->自定义。。。"在弹出的对话框中将中间的白框填入64，其他填入0，即可得到raw图，不过图片是黑白的，但是正反是正常的。

 

 

 

图像bayer格式介绍以及bayer插值原理CFA

1 图像bayer格式介绍

　　bayer格式图片是伊士曼·柯达公司科学家Bryce Bayer发明的，Bryce Bayer所发明的拜耳阵列被广泛运用数字图像。

　　对于彩色图像，需要采集多种最基本的颜色，如rgb三种颜色，最简单的方法就是用滤镜的方法，红色的滤镜透过红色的波长，绿色的滤镜透过绿色的波长，蓝色的滤镜透过蓝色的波长。如果要采集rgb三个基本色，则需要三块滤镜，这样价格昂贵，且不好制造，因为三块滤镜都必须保证每一个像素点都对齐。当用bayer格式的时候，很好的解决了这个问题。bayer 格式图片在一块滤镜上设置的不同的颜色，通过分析人眼对颜色的感知发现，人眼对绿色比较敏感，所以一般bayer格式的图片绿色格式的像素是是r和g像素的和。

　　另外，Bayer格式是相机内部的原始图片, 一般后缀名为.raw。很多软件都可以查看, 比如PS。我们相机拍照下来存储在存储卡上的.jpeg或其它格式的图片, 都是从.raw格式转化过来的。如下图，为bayer色彩滤波阵列，由一半的G，1/4的R，1/4的B组成。

　　　　　　　　　　　　　　　　　　　　　　

2 bayer格式图像传感器硬件

　　图像传感器的结构如下所示，每一个感光像素之间都有金属隔离层，光纤通过显微镜头，在色彩滤波器过滤之后，投射到相应的漏洞式硅的感光元件上。  

　　　　　　　　　　 

　　当Image Sensor往外逐行输出数据时，像素的序列为GRGRGR.../BGBGBG...（顺序RGB）。这样阵列的Sensor设计，使得RGB传感器减少到了全色传感器的1/3，如下所示。

　　　　　　　　　　　　　　　　　　　　　　　　

3 bayer格式插值红蓝算法实现

　　每一个像素仅仅包括了光谱的一部分，必须通过插值来实现每个像素的RGB值。为了从Bayer格式得到每个像素的RGB格式，我们需要通过插值填补缺失的2个色彩。插值的方法有很多（包括领域、线性、3*3等），速度与质量权衡，最好的线性插值补偿算法。其中算法如下： 

　　R和B通过线性领域插值，但这有四种不同的分布，如下图所示： 

 　　　　　　　　　　　　　　　　　　

                       　　　　　　　　　　　　　　　　(a)                                   (b)

 　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　 (c)                                   (d)

　　在（a）与（b）中，R和B分别取邻域的平均值。

　　在（c）与（d）中，取领域的4个B或R的均值作为中间像素的B值。 

4 bayer格式插值绿算法实现

 　　　　　　　　　　　　

      　　　　　　　　　　　　　　　　　　  (c)                                                        (d)

　　由于人眼对绿光反应最敏感，对紫光和红光则反应较弱，因此为了达到更好的画质，需要对G特殊照顾。在上述（c）与（d）中，扩展开来就是上图的（e）与（f）中间像素G的取值，者也有一定的算法要求，不同的算法效果上会有差异。经过相关的研究，

　　（e）中间像素G值的算法如下： 

 　　　　　　　　　　　　　　　　　　

　　（f）中间像素G值的算法如下：

 　　　　　　　　　　　　　　　　　　　　　　　　

　　CMOS摄像头这部分转换是在内部用ADC或者ISP完成的，生产商为了降低成本必然会使得图像失真。当然用外部处理器来实现转换，如果处理器的速度足够NB，能够胜任像素的操作，用上面的算法来进行转换，皆大欢喜。不过上述算法将直接成倍提高了算法的复杂度，速度上将会有所限制。因此为了速度的提成，可以直接通过来4领域G取均值来中间像素的G值，将会降低一倍的速率，而在性能上差之甚微，算法如下： 

 　　　　　　　　　　　　　　　　　　

　　如果能够通过损失图像的额质量，来达到更快的速度，还可以取G1、G2的均值来实现，但是这样的做法会导致边沿以及跳变部分的失真。