浅谈数据链路以及Apache Kudu的作用
2019-03-17
大数据存储技术的更新换代，使得海量大规模数据的存储日渐成熟，分布式数据分析计算引擎的发展，使得离线/实时的PB级数据分析成为可能。而如何能精确地匹配存储技术和计算框架，简化数据链路，健壮数据架构，以适应各种数据场景，一直是这两项大数据核心技术不断更迭的动力。
目前，广泛使用的大数据存储技术有：HDFS，HBase，Cassandra等。HDFS一般用于静态数据分析，在HDFS上可以采用Parquet和ORC的列式存储技术对数据进行存储。列式存储技术除了能够降低磁盘存储空间，还可以跳过不符合条件的数据，只读取需要的数据和相关列，降低IO数据量，以获取更好的扫描性能。而Hbase是以KV形式存储的半结构化列式分布数据库，适合随机读写场景。
当前这些大数据存储技术虽然各有优势，但是都存在着一定局限性：1、列式存储技术对于INSERT/UPDATE操作，即对数据的更新非常麻烦，而且基本不支持随机读写；2、Hbase虽然可以支持随机读写，但却不适用于基于SQL的数据分析场景。所以，目前企业中，一般会结合两套分布式存储技术，分别支持离线分析计算场景和快速的数据分析场景，所以形成以下两种常见的数据ETL链流：
但是这样的数据ETL链流，会带来两个难以避免的问题：1、时效性差，因为数据的ETL流程通常要几个小时，如果在有一些应用层的依赖任务，时间会更久；2、数据更新需求应对会非常困难，因为列式存储的静态数据的更新操作需要对相关任务和数据的重新刷入；3、存储资源的浪费，两套存储系统意味着占用磁盘空间会大大增加。
而Kudu恰恰填补了Hadoop家族中存储技术的尴尬之处。Kudu是一种分布式的列式存储技术，支持行级别的随机读写，并支持批量顺序检索功能。Kudu定位于应对快速变化数据的快速分析型数据仓库，希望靠系统自身能力，支撑起同时需要高吞吐率的顺序和随机读写的应用场景，提供一个介于HDFS和HBase的性能特点之间的一个系统，在随机读写和批量扫描之间找到一个平衡点，并保障稳定可预测的响应延迟。三种存储技术的架构很相似：
和HBase不同的是，Kudu没有借助于HDFS存储实际数据，而是自己直接在本地磁盘上管理分片数据，包括数据的Replication机制，kudu的Tablet server直接管理Master分片和Slave分片，自己通过raft协议解决一致性问题等，多个Slave可以同时提供数据读取服务，相对于HBase依托HDFS进行Region数据的管理方式，自主性会强一些，不过比如Tablet节点崩溃，数据的迁移拷贝工作等，也需要Kudu自己完成。
Kudu的优点总结如下：
- OLAP 工作的快速处理；
- 与MapReduce，Spark和其他Hadoop生态系统组件集成；
- 与Impala紧密集成，成为一个很好的可变的数据链流替代方案；
- 强大而灵活的一致性模型，允许根据每个 per-request（请求选择）一致性要求，包括 strict-serializable（严格可序列化）一致性的选项；
- High availability（高可用性）。Tablet server 和 Master 使用 Raft Consensus Algorithm 来保证节点的高可用，确保只要有一半以上的副本可用，该 tablet 便可用于读写。
Kudu 常见的应用场景总结如下：
- 实时更新的应用；
- 根据海量历史数据查询；
- 必须非常快地返回关于单个实体的细粒度查询；
- 实时预测模型的应用，支持根据所有历史数据周期地更新模型。
目前，国内Kudu成功使用的案例有小米，下面我们来看一下Kudu对小米数据链流架构的简化效果，使用Kudu之前：
使用Kudu之后：
使用Kudu之后，数据链路被简化了。当然，具体的数据链路设计和技术架构搭建，还要根据具体的应用场景来具体分析，以上只是自己的一些浅略的思考。