在phoenix上做了TPC-C测试，记录一些SQL的转换经历。

今天因为不了解hadoop，误操作把hdfs上数据全删了，下面是整个经过。

Hadoop家族使用过程中一些异常的处理记录，主要包括Hadoop（MR，YARN），HBase，Hive，Phoenix，CDH等。大部分异常都可以通过google搜到，为了避免重复搜索和确保解决方法可用，故作此记录。不断更新。

某个项目需要使用kafka与hbase phoenix等结合使用，故在此记录一些关于kafka的操作

最近在学习hbase之上的索引，趁机阅读了一下hbase的源码。从网上收集了一些资料，记录如下。第一部分是关于数据写入和读取的。

背景

考虑一个多维度查询的例子，因为hbase只能根据rowkey查询，因此多维度查询只能利用filter来过滤，但是这是一个全表扫描，效率低下。也可以把各个维度拼到rowkey中，利用rowkey的filter，因为rowkey是字典序的，所以越靠前的维度效率越高，后面的就会退化成全表扫描。

这时候就需要用到二级索引来查询数据。

Tephra 在 Apache HBase 的基础上提供了全局一致性的事务支持。HBase 提供了强一致性的基于行(row)和区域(region)的 ACID 操作支持，但是牺牲了在跨区域操作的支持。这就要求应用开发者花很大力气来确保区域边界上操作的一致性。而 Tephra 提供了全局事务支持，可以夸区域、跨表以及多个 RPC 上简化了应用的开发。

• 看回了HBase rowkey设计。rowkey设计本身已经没有多少新东西了，关键是应用场景。根据rowkey构造，枚举相关的col可能出现的值做检索可能是一个优化点。
• 阅读了phoenix源码。两个收获，一个是分布式SQL层的整体设计。一个是具体的如何做scan，如何做transaction。
• 找研究方向啊研究方向，找点啊找点，找idea啊找idea。。。。。
• nginx负载均衡扩展
• phoenix与tephra集成，提供全局事务处理
• chef安装老是出错。。

github streak竟然断了。。

不可冷漠

某公司的某关系型数据库中有79张表，数据量从几千条到上亿条不等，其中最大的交易流水表每月大约增量1亿2千万条数据。每张表都有自己的主键，但是表与表之间没有明确的关系，表之间的关系由业务和应用来驱动。目前对这些表主要的操作是进行校验然后生成报文，比如查询出某张表某个字段不符合规范的记录，然后对其修改。整个过程分为四个部分，导入数据，校验，补录，导出生成报文；对应于数据库的四种操作，导入，查询，更新，导出。这套流程在传统关系型数据库中进行时，因为数据量较大，在校验和补录阶段比较缓慢，而对其做分库分表又比较麻烦，另外后续需要对这些数据进行挖掘和分析，考虑到大数据平台在对数据统一管理和数据分析方面的优越性，因此想将整个流程迁入大数据平台。