HBaseCon West 2017 Session解读
HBaseCon West 2017的PPT解读如下： 1. HBase at Xiaomi 由小米的杨哲和张洸濠合作分享，两位是2016年新晋升的HBase Committer (ps: 小米目前总共产生了8位HBase Committer，其中2位HBase PMC，解决了数百个issue). 分享的一些亮点主要有： 1. 0.94升级到0.98集群的一些经验。 2. 小米内部HBase使用g1gc的一些经验。 3. 2016年小米对社区做的一些开发和改进，包括但不限于顺序推送复制日志/优化Scan操作/开发异步客户端功能以及相关测试结果，等等。 2. Apache HBase at DiDi (by Kang Yuan) 主要分享了HBase在滴滴的一些实践经验，目前滴滴的HBase是基于0.98.21版本，然后将rsgroup这个功能迁移到了自己的分支，用来做业务隔离。另外，PPT中也提到通过将地理位置坐标进行GeoHash转换成一维byte存放到HBase中，可以解决查询一个点周边坐标的问题。 3. Accordion: HBase Breathes with In-Memory Compaction (From Yahoo) 有了InMemory-Compaction功能之后，HBase支持将Memstore直接Flush成一个ImmutableSegment，这个ImmutableSegment其实是一块内存空间，多次Memstore的Flush操作会导致产生多个ImmutableSegment，特定条件下，多个ImmtableSegment会进行In-Memory的Compaction，也就是多个ImmutableSegment完全在内存中合并成为一个大的ImmutableSegment（其中BASIC类型的InMemoryCompaction会保留所有数据，EAGER类型的InMemoryCompaction会清理冗余版本数据）。最终，这个大的ImmutableSegment还是要Flush到磁盘的，然后接着触发做磁盘上的Compaction操作。 按照设计文档以及PPT的说明，InMemory-Compaction有以下好处： 由于InMemoryCompaction会在内存中进行compaction， 不用频繁的Flush Memstore到Disk(Flush次数太多会造成storefile个数增长, storefile的增长会导致读性能严重下降)， 从而可以降低读操作延迟。 ImmtableSegment今后可能会和HFile的layout保持一致，这样Flush的速度将大幅提升。 对于行数据频繁更新的场景，InMemory-Compaction可以采用EAGER方式在内存中就清理掉冗余版本数据，节省了这部分数据落盘的代价。 最后，PPT测试数据也确实说明使用InMemoryCompaction后，写吞吐有较大幅度提升，读延迟有较大幅度下降。 ps. In-memory Compaction由stack等6位成员共同完成(将在HBase2.0的release版本发布），这其中有两位美女工程师（PPT中的照片证明颜值确实很高），现在都已经是HBase的Committer了。 另外，In-memory compaction详细设计文档请参考：https://issues.apache.org/jira/browse/HBASE-13408 4. Efficient and portable data processing with Apache Beam and HBase (By Google) 这个演讲更多是来HBaseCon宣传下Apache Beam这个项目。 Apache Beam这个项目始于2016年2月份，近1年多的时间内就收到了来自全球178个贡献者的8600+提交，主要是希望提供一个统一的API用来同时处理Batch任务和Streaming任务，他的API后端可以接Apex/Flink/Spark/GoogleCloudDataFlow等服务，同时提供Java和Python的客户端SDK。这个东西就好比JDBC一样，提供了一个统一的借口，后端可以连接MySQL/Oracle/Postgresql/SQLServer等关系型数据库。我没理解错的话，这个东西应该是可以用来在HBase/MongoDB/HDFS/Cassandra/Kafka/BigTable/Spanner/Elasticsearch/GridFS/Hive/AMQP等(超过20种通用的存储服务)各种服务间实现数据transform。...