元数据服务故意只实现SQL的一个子集：为未来拆分成独立服务预留扩展空间

HAWQ的元数据服务目前位于Master节点上，对外提供的接口是一种叫CaQL（Catalog Query Language）的查询语言——这个接口本身只支持SQL的一个子集功能，包括单表选择、计数、多行删除、单行插入更新这几类基础操作，而不是完整意义上的SQL能力。这个”故意做窄”的设计不是能力不足，而是一个提前为未来演进铺路的主动决策：团队未来希望能把元数据服务从当前所在的主节点上分离出去，让它成为一个独立的服务；如果现在就把这个对外接口设计成支持完整、复杂的SQL能力，未来要把它从单机内嵌功能拆分成一个独立的分布式服务时，接口本身的复杂度会成为拆分和扩展的沉重包袱——而只支持一个足够简单、边界清晰的SQL子集，恰恰是”作为元数据服务来说已经够用”，同时又”容易扩展”，为将来的架构拆分预留了空间。这个案例给出了一条系统接口设计的重要思路：设计一个组件对外暴露的接口能力时，不应该简单地以”能力越全越好”作为默认目标，而应该结合这个组件未来可能的演进方向（比如”未来要不要被拆分成独立服务”）来反向约束当前接口的范围——如果预见到未来有拆分、独立部署这类需求，现在就主动把接口能力控制在一个刚好够用、边界清晰的子集内，会比日后再想办法从一个功能复杂的大接口里”瘦身”要容易得多；接口能力的克制，本身可以是一种为未来架构灵活性主动买的保险，而不只是当前功能不够完善的权宜之计。