我还清楚记得，五年前的这个时候，当时还在豌豆荚，午后与刘奇和崔秋的闲聊关于未来数据库的想象，就像一粒种子一样，到了今天看起来也竟枝繁叶茂郁郁葱葱，有点感慨。按照惯例，五年是一个重要的节点，没有十年那么冗长，也没有一两年的短暂，是一个很好的回顾节点，就在此认真的回顾一下过去，展望一下未来。
五年前创业的出发点其实很朴素：做一个更好的分布式数据库。从学术的角度上看起来，并不是提出了什么惊天地泣鬼神的神奇算法，我们选择的Shared-nothing的架构其实在当时的业界也不是什么新鲜的事情了，但真正令我激动的是：我们要造的是一个真正能作为整个系统的SingleSourceofTruth的基础软件。这句话怎么理解呢？我在后边会好好聊聊。
数据是架构的中心
作为一个互联网行业的架构师，几乎是天天都在和各种类型的数据打交道，这么多年的经验，不同行业不同系统，从技术层面来说，抽象到最高，总结成一句话就是：数据是架构的中心。仔细想想，我们其实做的一切工作，都是围绕着数据。数据的产生，数据的存储，数据的消费，数据的流动……只不过是根据不同的需求，变化数据的形态和服务方式。计算机系的同学可能还记得老师说过的一句话：程序=算法+数据结构，我这里斗胆模仿一下这个句式：系统=业务逻辑x数据。可以说很多架构问题都是出在数据层，例如常见的「烟囱式系统」带来的种种问题，特别是数据孤岛问题，其实本质上的原因就出在没有将数据层打通，如果不从数据架构去思考，就可能「头疼医头、脚疼医脚」，费了半天劲还是很别扭，反过来如果将数据层治理好，就像打通「任督二脉」一样，起到四两拨千斤的效果。但是理想通常很丰满，现实却很骨感。至少在我们五年前出来创业那会儿，我们觉得并没有一个系统能够很好的解决数据的问题。可能好奇的读者就要问了：不是有Hadoop？还有NoSQL？再不济关系型数据库也能分库分表啊？其实列出的这几个几乎就是当年处理存储问题的全部候选，这几个方案的共同特点就是：不完美。具体一点来说，这几个解决方案对于数据应用的场景覆盖其实都不大，对于复杂一点的业务，可能需要同时使用n多个方案才能覆盖完整。这就是为什么随着近几年互联网业务越来越复杂，类似Kafka这样的数据Pipeline越来越流行，从数据治理的角度其实很好理解：各种数据平台各负责各的，为了做到场景的全覆盖，必然需要在各个「岛」之间修路呀。我们当年就在想，能不能有一个系统以一个统一的接口尽可能大的覆盖到更多场景。我们需要一个SingleSourceofTruth。数据应该是贯穿在应用逻辑各个角落，我理想中的系统中对于任意数据的存取都应该是可以不加限制的（先不考虑权限和安全，这是另一个问题），这里的“不加限制”是更广义的，例如：没有容量上限，只要有足够的物理资源，系统可以无限的扩展；没有访问模型限制，我们可以自由的关联、聚合数据；没有一致性上的限制；运维几乎不需要人工干预……以分布式数据库为统一中心的架构
我当年特别着迷于一个美剧：PersonofInterest（疑犯追踪），这个电视剧里面有一个神一样的人工智能TheMachine，收集一切数据加以分析，从而预测或是干预未来人们的行动。虽然这部美剧还是比较正统的行侠仗义之类的主题，但是更让我着迷的是，是否我们能设计一个TheMachine？虽然直到目前我还不是一个AI专家，但是给TheMachine设计一个数据库似乎是可行的。这几年创业过程中，我们发现更令人兴奋的点在于：以分布式数据库为统一中心的架构是可能的。这个怎么理解呢？举个例子，就像在上面提到的分裂带来的问题，数据层的割裂必然意味着业务层需要更高的复杂度去弥补，其实很多工程师其实偏向于用线性的思维去思考维护系统的成本。但是实际的经验告诉我们，事情并不是这样的。一个系统只有一个数据库和有十个数据库的复杂程度其实并不是的简单的10x，考虑到数据的流动，维护成本只可能是更多，这里还没有考虑到异构带来的其他问题。以分布式数据库为中心的架构是什么样子的呢？很好理解，整个架构的中心是一个场景覆盖度足够广，且具有无限的水平伸缩能力的存储系统。大部分数据的流动被限制在这个数据库内部，这样应用层就可以几乎做到无状态，因为这个中心的数据库负责了绝大部分状态，每个应用可以通过自己的缓存来进行加速。这里我想提醒的是，为什么我在上面强调水平扩展能力，是因为受限的扩展能力也是导致分裂的一个重要的原因。我们从来都没有办法准确的预测未来，我们很难想象甚至是一年后业务的变化（想想这次疫情），有句老话说的很好：唯一不变的就是变化。另外一个经常被问到的问题，为什么要强调缓存层需要离业务层更近，或者说，为什么位于中心的这个巨型数据库不应该承担缓存的责任？我的理解是，只有业务更懂业务，知道应该以什么样的策略缓存什么样的数据，而且出于性能（低延迟）考虑，缓存离业务更近也是有道理的。对应上面那句话「唯一不变的就是变化」，这个架构带来最大的好处正是「以不变应万变」，或者更简单的一个词：简洁。Google其实在很早就想清楚了这个问题，因为他们很早就明白什么是真正的复杂。另一个例子是HTAP，如果