数据库内核杂谈(十八) ：自动驾驶的数据库系统

{"type":"doc","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"本文是数据库内核系列文章之一。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"这一期，内核杂谈我们跟风来聊一个最近很火的话题：自动驾驶。最近各大互联网公司，纷纷宣布，all in自动驾驶，开始造车。等等，这不是数据库内核杂谈吗？是的，从这一期开始，内核杂谈介绍一个能自动驾驶的数据库管理系统：这是CMU数据库领域的教授Andy Pavlo的研究领域之一，self-driving database management。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"项目的名称叫NoisePage（网址"},{"type":"link","attrs":{"href":"https:\/\/noise.page\/about\/?fileGuid=GjGyPpKQKkJdDHvt","title":"","type":null},"content":[{"type":"text","text":"https:\/\/noise.page\/about\/"}]},{"type":"text","text":"）。NoisePage是一个从头开发的致力于自动管理的数据库系统。通过machine learning技术来调整，优化系统参数和对系统进行调优。目前支持的参数包括，但不限于，物理数据库设计如如何建立索引，materialized views，如何对数据进行sharding；系统参数的调优，数据库SQL语句的调优，以及硬件扩容策略。学术研究主要负责构建系统来支持这些自动化驾驶型调优，并且，通过预测未来的查询语句workloads，来提前做好规划，最终目的是构建一个尽量减少人为干预的数据库系统（额...这是想取代DBA的节奏啊）。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"看了一下相关的学术论文，已经发表了好几篇了。而且，最近在Professor Pavlo搞的Vaccination Database Talks系列中他的Phd学生Lin Ma正好给了一个最新的presentation(https:\/\/www.youtube.com\/watch?v=YqW9Pq5488s&t=2047s)，欢迎大家去学习一下。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"这一期，一起来学习第一篇论文，Self-Driving Database Management Systems，发表于Conference on Innovative Data Systems Research(CIDR) 2017。对整个自动驾驶数据库系统做了一个综述，并分享了当时获得的进展。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"简介"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"数据库的诞生，SQL语句的盛行，最初想解决的问题就是把数据存储，管理等复杂的逻辑隐藏起来，让程序员可以通过SQL这个declarative language来描述想要获得什么样的数据。但随着几十年数据库系统的发展，系统本身变得越来越复杂， 需要配置，优化的地方越来越多。因此也催生了一类专门的职业，DBA (Database Administrator)。DBA的主要职责就是确保数据库系统可以很好地支持现有的业务逻辑需求workloads，大到存储，节点配置，小到某个GUC的设定来优化SQL语句，都属于DBA的范畴（在我还在上大学那时，DBA可是个热门职业，传说Oracle的DBA工资可高了）。而随着分布式数据库，云原生数据库的诞生，新的趋势却是返璞归真，尽量把数据库系统做得越来越傻瓜化，不需要复杂配置，就可以很好地运行业务逻辑。一是，系统越来越复杂，迭代越来越快，成为一个好的DBA越发困难；二是随着人工智能的进步，我们觉得机器可以通过算法来优化操作，做的比人类更好。人类是懒惰的，追求自动化，效率最大化是我们的本性。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"当下，已经有很多相关研究在这一领域开展。但是，本文指出，之前的研究大部分都集中在某一个单点领域，比如如何更好地设计物理数据库，如何设计index，如何设计存储格式，或者partition scheme；其他的一些研究旨在给出最优化的GUC调整来提高SQL语句的运行效率。文中也指出了现有研究的一些缺陷。比如，大部分的优化管理都并不是原生于数据库系统中（外部构建）；并且更多的是反应式地来提供优化，并不能主动去适应查询语句的变化；大部分的优化都是关注局部，而不能从全局角度来考虑最优。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"而本文介绍的研究，是如何从宏观角度，支持自动管理整个数据库系统。并且提出了一种新的架构，即自动驾驶模块需要被构建在数据库系统内部。文中所用的系统是Peloton，就是CMU database group自己构建的数据库系统，用于尝试和支持各种研究。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"要使数据库自动驾驶，需要解决哪些问题"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"第一个挑战就是，如何预测未来的workloads，即哪些SQL语句会被执行。如果能够准确预测这些语句，能解决什么问题？ 试想一下，即便只是了解到这些workloads属于online transaction processing (OLTP) 或是online analytical processing (OLAP)，数据库已经可以进行优化：如果workloads属于OLTP，系统可以选择row-store（行存）来优化写操作，反之，如果workloads属于OLAP，系统可以选择column-store（列存）来优化读取操作。如果各种workloads都有，一个可行的优化是部署两套系统，行存用来优化写操作，然后将数据同步到列存数据库中来支持读取操作。另一种优化方式就是部署HTAP（hybrid transaction-analytical processing）数据库来同时处理读操作和写操作。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"除了预测未来workloads，还有什么信息可以帮助优化数据库配置？第二个能想到的就是这些语句的资源使用情况。如，需要多少CPU，多少内存来执行SQL语句。如果能够准确地预测这些信息，数据库就可以提前做好准备，来确保性能不受影响。这就好比，DBA通常会把数据库清理，或更新操作安排在业务需求量最小的时候，比如深夜。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在能够预测未来workloads和resource utilization的情况下，数据库系统可以支持哪些优化呢？本文给出了三个大类："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"1）physical design（物理设计）：比如添加或者删除index，materialized view来加速查询或者插入操作，选择row store或者column store来优化写操作或者读操作。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"2）data design（数据存储）：根据查询语句的需求，对数据进行冷热区分或者进行sharding操作。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"3）runtime（运行时优化）：比如针对SQL语句的optimization，或者knob的tuning，再或者，根据查询语句的容量大小来决定是否需要增加新的计算节点。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.geekbang.org\/infoq\/49\/491360dc76c6038527c55d11c664c5ff.png","alt":null,"title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"文中同时提到，非常重要的一点就是，自动优化的数据库系统必须支持动态地对配置进行更改，致使优化配置能够即时生效。试想，如果一个数据库系统，需要重启才能更新配置，那自动驾驶带来的优化就需要大打折扣了。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"总结一下，本文认为，一款自动驾驶的数据库， 应该具备预测workloads和资源使用情况，提供多种优化操作，并且支持动态更新配置。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"自动驾驶架构"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"要如何构建一个系统来实现上述提到的种种操作呢？文章介绍的架构基于Peloton，CMU数据库小组自主构建的系统。下图给出了具体架构图。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.geekbang.org\/infoq\/63\/630c4bf492fa8d9e25b148a3c54660f4.png","alt":null,"title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"目前市场上的所有自动驾驶，都是人工智能驱动的。自动驾驶的数据库也不例外。而人工智能最重要的就是，数据。因此，整个架构都是围绕数据来打造的。结合架构图，一个部件一个部件来看。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"第一个介绍的部件就是用来做数据收集的workload monitor。Workload monitor负责收集所有workload运行的相关信息，除了SQL语句之外，数据操作量，资源使用等，都会被记录。此外，还会定期收集数据库系统随时间流的硬件指标，比如CPU，内存，IO使用率等等。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"收集了原始数据，第二个部件负责workload classification（workload分类）。文中使用的是unsupervised learning（非监督型学习）来把具有类似属性(characteristic)的语句分到一起。机器学习的术语是clustering，聚类。聚类的作用就是去重，只为相似的语句保留一个model即可，让预测更容易。文中使用的方法是DBSCAN，是一个已经被验证过的聚类方法。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"聚类的挑战在于，什么feature属性应该被考虑进去？这样的属性分成两类，语句的运行时feature和语句的semantic logic。前者的好处在于，能够将类似的语句分类在一起，甚至不需要去理解这些SQL语句，但这样的modeling也会对数据库的任何更改变得敏感，任何物理上的改动都可能使得预测变得不准确。另一个问题就是，当类似的语句在不同的并发程度下运行，那运行时属性就可能完全不一样，这同样使得数据变得不准确。另一个方法就是从SQL语句的语义出发，比如物理执行计划，读取了哪些表，用到了哪些index，等等。这些信息往往独立于数据库本身。文中并没有给出结论哪个更好，应该还处于探索中。我认为，应该一股脑全交给ML model来自己决定。以我粗浅的对与深度学习的理解，它要解决的就是能够减少feature engineering，让model自己决定哪些feature更重要（欢迎指正）。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在得到了workload cluster聚类后，要做的就是预测这些workload cluster未来什么时候会再次出现。预测的作用在于能够帮助数据库系统更好地应对未来的workloads，提前做好配置优化或者扩容等。文中使用的技术，是对于每个执行的语句，tag预测后的clusterID，然后通过收集这些cluster出现的时间，来预测未来再次出现的时间(对于部署在生产环境中的数据库，大部分的workloads应该是具备周期性的，比如定点的auto script等。因此，预测并不会特别困难)。文中提到了RNN以及long short-term memory (LSTM) 长，短记忆模型能够更好地预测周期性和重复性的pattern，也提及了用多个RNN来预测模型。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"预测了未来workloads的模型，下一步就是实施优化来提前让数据库做好准备。文中介绍了管理模块，用来根据预测的模型做出优化决策并实施。第一个部件就是action generator，负责搜索action可以用来优化性能，这里需要提到，优化函数就是减少语句运行的时间，提高性能。但文中同时提到，优化函数是可以扩展到throughtput，资源消耗等等。那系统是如何做的呢？首先，系统存储了一系列可能的优化action，并记录了它们对数据库的影响，相当于step function。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"万事俱备，只欠东风。有了action库，有了预测workload的模型，目前的数据库配置，就可以根据目标函数来产生action plan来逐渐逼近目标。文中使用的方法是control theory, 控制理论来操作。文中提到了receding-horizon control model (RHCM)模型，是被广泛应用在真.自动驾驶汽车中的模型。 RHCM的工作原理，简单而言就是，在每个时间周期内，用模型预测可能出现的workloads，然后在action catalog中搜索一系列的action来使得目标函数得到最小值（逼进优化目标）。但是，数据库只把这一系列的action中的第一个apply到数据库当中，等待数据库响应这个action，然后到下一个周期，再重复上述操作。整个优化过程就可以被类比为一个对树状图的搜索过程，从根节点作为第一个time epoch。作者也强调，为什么需要一个高性能，并且可以动态更新配置的数据库来支持自动驾驶。因为需要对更新过得数据库系统重新收集数据来判断加载的action是否产生了效果。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"总结"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"读完整篇文章，给我最大的感受就是，一开始提到如何自动驾驶数据库系统，完全无头绪。但是作者通过把问题分解成各个步骤，大家是否也觉得，整个逻辑通顺。并且，会觉得，真的，好像这样一步一步去做，就可以实现。 我觉得这就是一流学者所做的，能把一个复杂的问题想清楚，抽丝剥茧，然后找出解决方案。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"感谢阅读！下一期，我们接着学习第一个模块，workload forecasting。"}]}]}