目前主流的OLAP数据库计算层架构有Master-Slave和Master-Master两种形态，但大多数选择的是Master-Slave架构，Master-Slave有助于控制流和计算流的分离，更简单的部署方式（Master集成元数据）等优势，下面是关于各个数据库或数据仓库产品的调研结果。
Master-Slave
1. Snowflake
snowflake的架构设计
- snowflake共分为三层，Cloud Services，Virtual Warehouse，Data Storage。
- Cloud Services层负责对外接入认证，优化解析，事务管理，元数据存储等工作。
- Virtual Warehouse是纯计算层。Virtual Warehouse共享分布式Cache
- Datastorage就是云原生存储。
可以看出来，snowflake实际上是Master-Slave架构，有Cloud Services中Optimize,Authentication and Access Control等组件提供对外连接，等服务，计算层中由Virtual Warehouse负责计算，计算节点不会影响到连接节点，并且更容易做到计算的弹性。数据存储在S3上，元数据由Cloud Services管理。
2. Apache doris
apache doris FE-BE架构
apache doris架构中分为FE和BE两大组件。
- Frontend（FE），主要负责用户请求的接入、查询解析规划、元数据的管理、节点管理相关工作。
- Backend（BE），主要负责数据存储、查询计划的执行。
3. presto
presto的计算组件分为Presto Coordinator和presto Worker，Presto Coordinator负责连接，并通过Hive Connector来访问Hive MetaStore。Coordinators connect with workers and clients via REST.
Presto Coordinator：用于提交查询并管理跨 Presto Worker 的解析、计划和调度查询执行
Presto Worker：处理查询，添加更多的worker可以让您更快地处理查询
从以上的分析中可以看出，Master-Slave架构的优势在于
- Master节点不参与计算，负载压力较小，可以承担更大的query连接压力。单个计算节点故障对外部连接服务影响较小。
- 只有Master节点与metaserver交互，逻辑更简单。
4. GreenPlum
GreenPlum是share-nothing架构的分布式数据库，计算层架构分为Master Servers和Segment Servers，
Segment Servers是实际的计算节点，每个节点仅查询自己的数据，所得到的结果再经过主节点处理得到最终结果。通过增加节点数目达到系统线性扩展。
Master Servers负责负责相应客户端请求并将请求的SQL语句进行优化器解析生成分布式计划，将分布式计划调度分发到Segment Servers进行查询，并将查询结果返回客户端。
Master-Master
1.Impala
impala是标准的mpp架构，massively-parallel query execution engine，支持在上百台机器的Hadoop集群上执行快速查询。他对底层的存储系统解耦，不像数据库要求那么严格，不同的底层存储都可以联合查询。
上图是impala整体的架构图，可以简单的把impala集群看成三种角色服务。
impalad用于接收查询请求并分解成查询任务、组织并完成集群中的数据查询、汇总完成数据的整合关联。如果Impala用于调度查询请求的时候，一般会把它称为调度者(Coordinator)。在Impala中Impalad是对等的，也就是说每个进程内部的角色都一样，都可以作为调度者接收请求，这样即有助于容错，又可以做到负载均衡。一般每个数据节点都要安装一个imapald进程，这样impala可以查询本机的数据，实现数据本地性，减少网络IO。
statestored进程用于维护特定消息的发布订阅服务，用于在集群中广播一些消息。这个服务是单点的。
最后是catalogd，它主要负责维护元数据的读取查询。当执行DDL操作时，会同步到catalog，然后通过statestore广播给其他的节点。
参考文档
- https://www.alluxio.io/learn/presto/architecture/
- https://zhuanlan.zhihu.com/p/87022094
- https://cloud.tencent.com/developer/article/1032986
