从架构特点到功能缺陷，重新认识分析型分布式数据库

HDFS作为Hadoop的存储基础，其本身不提供Update操作，这样所有在数据操作层面的Update最终会被转换为文件层面的Delete和Insert操作，效率上显著降低。据Ivan所知，在很多企业实践中会将这种增量存储转换为全量存储，带来大量数据冗余的同时，也造成实施方法上的变更。

联机查询并发能力不足

对于联机查询场景，最常见的是SQL on Hadoop方案，将Impala、HAWQ等MPP引擎架设在HDFS基础上，批量数据与联机查询共用一份数据。MPP引擎借鉴了MPP数据库的设计经验，相对Hive等组件提供了更低的延迟。但存在一个与MPP相同的问题，即并发能力不足。

通过一些项目测试中，Ivan发现在大体相同的数据量和查询逻辑情况下， Impala并发会低于GPDB。其原因可能是多方面的，不排除存在一些调优空间，但在系统架构层面也有值得探讨的内容。例如在元数据读取上，Impala复用了Hive MetaStore，但后者提供的访问服务延时相对较长，这也限制了Impala的并发能力[7]。

3. Like-Mesa

Mesa是Google开发的近实时分析型数据仓库，2014年发布了论文披露其设计思想[5]，其通过预聚合合并Delta文件等方式减少查询的计算量，提升了并发能力。

Mesa充分利用了现有的Google技术组件，使用BigTable来存储所有持久化的元数据，使用了Colossus (Google的分布式文件系统)来存储数据文件，使用MapReduce来处理连续的数据。

Mesa相关的开源产品为Clickhouse[6](2016年Yandex开源)和Palo[7](2017年百度开源)。

架构特点：

目前ClickHouse的资料仍以俄语社区为主，为便于大家理解和进一步研究，下面主要以Palo为例进行说明。

Palo没有完全照搬Mesa的架构设计的思路，其借助了Hadoop的批量处理能力，但将加工结果导入到了Palo自身存储，专注于联机查询场景，在联机查询部分主要借鉴了Impala技术。同时Palo没有复用已有的分布式文件系统和类BigTable系统，而是设计了独立的分布式存储引擎。虽然数据存储上付出了一定的冗余，但在联机查询的低延迟、高并发两方面都得到了很大的改善。

Palo在事务管理上与Hadoop体系类似，数据更新的原子粒度最小为一个数据加载批次，可以保证多表数据更新的一致性。

整体架构由Frontend和Backend两部分组成，查询编译、查询执行协调器和存储引擎目录管理被集成到Frontend;查询执行器和数据存储被集成到Backend。Frontend负载较轻，通常配置下，几个节点即可满足要求;而Backend作为工作负载节点会大幅扩展到几十至上百节点。数据处理部分与Mesa相同采用了物化Rollup(上卷表)的方式实现预计算。

Palo和ClickHouse都宣称实现了MPP Data Warehouse，但从架构上看已经与传统的MPP发生很大的变化，几乎完全舍弃了批量处理，专注于联机部分。

ClickHouse和Palo作为较晚出现的开源项目，还在进一步发展过程中，设定的使用场景以广告业务时序数据分析为主，存在一定局限性，但值得持续关注。

【编辑推荐】

1. 从运维角度来分析MySQL数据库优化的一些关键点
2. 4个MySQL优化工具AWR，帮你准确定位数据库瓶颈！
3. 阿里云PolarDB发布重大更新 支持Oracle等数据库一键迁移上云
4. 传统数据库一键上云 阿里云PolarDB发布重大更新
5. 系统慢得一批？看数据库运维老司机如何做优化

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!