从MLSQL性能设计到对架构师的重新思考

从MLSQL性能设计到对架构师的重新思考

五年前，我会认为，架构仅仅是针对一个可大可小的问题，把流程设计好，然后往里面填充合适的组件，从而最终解决这个问题。在这个过程中，区分架构师是否资深主要是在设计过程中对可扩展性，可维护性，以及成本权衡的把控能力。

现在，我觉得架构不应该仅仅是这样的。

真正的架构，它会是一个自上而下的思考模式，首先需要对问题本质的进行解析，进而进行抽象。最高层的抽象可能类似，”解决复杂的问题的办法一定是简单的“东西，这是一句有价值，但基本没法实操的话，是水货，但却可以作为自己在接下来设计的一个指导原则，一个准绳，一个衡量现在的路对不对的指标。

我们知道，自上而下的思考本质是抽象的层层具象化，而每个抽象是不是合理，是不是比较优的，那就靠这个最高的抽象进行评判。

当我们试图针对现有的问题，去思考出一个更具象化一点的抽象的时候，这个抽象的来源在于，你需要对问题的历史进行回顾，找到这个问题的最初产生的动机，亦或是针对目前的场景我们做一个统一的概括，看这个概括是不是能覆盖到目前所有能想到的场景。

举个例子，假设我要想解决的问题是MLSQL的查询性能问题。那我认为，一定有一个简单的抽象，这个抽象可以把我们要解决的问题归结为一个简单的问题。这个抽象经过我的经验，我发现是索引。对索引我的解释是，

1. 在存储维度上，索引可以是数据自身的分布，也可以是对原始数据生成新的数据结构组织。
2. 在时间维度上，索引和原始数据是可以有时延性的，可以是实时秒，分级别的，也可以是小时，天，甚至月级别的。

那么这个索引的抽象是不是具有较高的抽象层次？我认为是有的，我们可以做些场景match测试，一个典型的情况是，我认为无论数据批处理同步到数仓中，亦或是通过CDC的方式同步数仓中，数仓本质上就是我们要同步的数据的一种索引，是对关系型业务数据的一个索引。我们通过这个索引加速了我们的查询。那么批处理和CDC表面是入库方式的不同，但实际上我们认为是索引的时延不同而已。CDC是实时索引，按时间周期全量同步的，是非实时索引。既然是索引，如果我不需要加速，那么数仓在我们的架构体系中，就是可选的。如果我们返回到数仓产生的原始动机那里去，你就能知道我们的抽象是合理的：数仓出现的最早的动机是，当时的分布式计算框架(MR)不给力，底层的关系型数据库不给力，最终导致两者无法结合，所以为了解决这个问题，需要有个数仓，把数据丢到汇总到数仓里，让不给力的MR可以在数仓上计算。知道这个动机后，你就会知道，数仓他在最早期，是因为技术上不给力才产生的，尽管随着发展他衍生出了很多新的东西新的概念。按这个思路，我们就能推演出，数仓未来一定是会萎缩的，随着技术突破，联邦查询会是主流，这也体现了技术的螺旋式上升。我们看到，通过我们使用索引对数仓进行解释，以及对这个技术产生的动因分析，他们竟然得到了惊人一致的结论，这也再次证明，我们的抽象是合理的。

从上面的例子，我们还能看到，抽象也可以视为一种思维模型，而且这种思维模型是可以推导出一些新的结论的。

有了索引的抽象之后，我们需要进一步具象化新的抽象，以便于我们能够真正的落地它，从而解决我们实际要解决的问题：如何提升MLSQL的性能。

使用索引，应该是有一种具体的形态的，针对大数据场景，我们可能会得到如下一个新的抽象：多表转宽表，宽表加索引。

对于多表，我们如何给其加索引呢？或者说索引的形态是什么？在这层抽象里他指明了方案，就是宽表（典型如物化视图技术）。宽表我们也需要进一步提速，所以宽表上也需要有索引，到这里这里可以具象化到更加细致的技术上了，比如z-ordering，bitmap之类。

再具象化一层，我们应该有一个合理的架构去承载上层的这些抽象，如何在MLSQL之上可以让用户实现各种索引，如何然让用户使用这种索引，于是，我们需要在MLSQL两个层面去做设计：

1. 如何让用户在使用MLSQL语言的时候，指定或者透明使用索引。
2. 如何让用户实现一套规范，即可将索引注册到MLSQL系统上。

其实到这里，就已经非常细化了，几乎到了初步可执行的层面。我们最终在MLSQL引擎上构建了一套开放的可插拔的索引体系，在此基础上，我们实现了诸如

1. z-ordering索引细节，Z-Ordering索引加速大数据查询,
2. json字段索引加速，可以对json里的字段进行查询加速。
3. 联邦查询技术聚合下推

以及一些基于索引技术理念的应用

1. 如何开箱即用的分析你的数据库数据（JDBC索引技术预览）