HBase的BulkLoad有两种方式：
thinrow的机制是flatmap把cell的信息进行flatmap；适合少于1万列的数据集；thinrow的涵义就是少行多列；
bulkload的机制则是flatmap的是行，把行在拆分为cell是在map里面做的。适合多余1万列的数据集。
Basic和ThinRows的机制其实类似，但是接收的数据格式不一样，前者接受的是一个二元组ListSeq((keyFamilyQualifier, value))；其中KeyFamilyQualifier(包括rowKey, family, qualifier)以及value，后者是一个二元组List(new ByteArrayWrapper(Bytes.toBytes(rowKey)), familyQualifiersValues) familyQualifiersValues中包含family, qualifier, value。
Basic是一个平行结构，ThinRow其实是一个层级结构；
Basic和thin之间的差别在于入口的数据结构；basic入口的是(rowkey-famil-quantity，cellvalue)，说白了就是一个cellvalue；thinrow的入口参数则是一行数据（rowkey，columnValues），注意，columnValues是一个数组；这种差别直接导致了两者处理的差异性，下面将会讲到；
bulkload在map一下row信息之后，将会进行一次repartitionAndSortWithinPartitions，这个repartion将会导致shuffle，最后是hbaseForeachPartition，这个是一个action；在这个action中将会遍历shuffle的数据，进行处理，好的，basic和thinrow的性能差别就在这里，因为basic的入口是cellvalue，那么在shuffle过程中（RPC），传输的粒度就是一个cellvalue；处理完毕一个相应了，再来一个；对于thinrow而言，一次是一行数据，RPC一次传输的粒度就是一行数据，明显吞吐量要高于basic；
basic的hbaseForeachPartition（it代表一个分区）
it.foreach{ case (keyFamilyQualifier, cellValue:Array[Byte]) => ...
thinrow的hbaseForeachPartition
it.foreach{ case (rowKey:ByteArrayWrapper, familiesQualifiersValues:FamiliesQualifiersValues) => ...
那么为什么对于多于1万列的场景要使用basic呢？就是因为可能会超过RPC的上限，即使没有超过，一次传输一个超大数据对于网络来讲压力也很大。
注意这里有一个Roll的动作，就是bulk/thinrow入口参数有一个max_size，代表多大小对HFile文件进行拆分，Basic默认是HConstants.DEFAULT_MAX_FILE_SIZE，ThinRow其实也是一样的，但是官网坑爹的写了个20，所以导致的每个记录都会单独成为一个HFile，结果爆了一个异常：HFileLoad的大小超过了32。
这个异常本质还是因为Roll Size设置的太小了，采用默认值即可。
BulkLoad插入数据的速度将会比采用put方式要快很多：这是因为PUT方式需要些metadata，采用bulkload方式避免了写入metadata，直接通过HFile的添加来实现。但是bulkLoad需要对数据进行组合，这里又要耗费一些时间，所以优势更多的体现在大量数据，分布比较多的设备的场景下。
shuffle指的是各个节点在为reduce准备数据，比如检索，排序同时对数据进行打包；repartion这是对数据进行分区，正常情况下每个分区将会对应一个CPU核，repartition这是通过指定分区规则（指定分区数量或者指定按照某种规则分区）来对数据进行重新分区，重新分区应该只是针对可重用数据才有价值，否则数据重新分区本身就是一件比较耗费性能的事情。
备注：bulkload是在hbase-spark-2.0.0-alpha3.jar下面的orgapachehadoophbasesparkHBaseContext.scala中定义的。
参考：
https://hbase.apache.org/book.html（Chapter 102. Bulk Load）