yf2008在写这篇文章前，我先简单做个说明，对于性能问题诊断这个系列，我可能会暂缓一段时间，因为这段时间可能需要先学习下网络协议以及操作系统内核，这也是更加有助于后面写出更加优质的性能诊断的文章。这其中可能会穿插一些对网络协议以及操作系统内核学习过程中的学习记录，敬请期待。
这周四，参加了DTCC(中国数据库大会) 2019，这也是沾了老大的光，才能够有这样宝贵的机会来了解业界对于数据库这项领域的一些前沿进展。虽然只有短短一天的时间，但仍然有不少收获，与所有的参会感想类的感想一样，文章会分为两部分进行说明，首先是流水账式的回顾会议的内容，然后对整个参会的过程进行一些总结和自己的感想。闲言少叙，直接进入主题。
主会场–数据架构，十年变迁
上午的会场将大伙聚集在主会场，会议的主题是《数据架构，十年变迁》，因为今年正好是DTCC举办的第十个年头。也真的很荣幸能在这个特殊的时间节点来领略数据库的前沿发展。这是这个主题的第二天，来自平安，阿里云，浪潮，京东以及云和恩墨的老师分别带来各自在其所在领域针对数据库方面的实践。首先，来自平安科技的汪洋老师讲述了在平安这个金融领域的传统企业对于开源数据库的应用和实践。他的topic主要围绕如何根据自己的业务进行开源数据库的选型，以及如何针对这些数据库进行满足自己业务场景的个性化定制。平安所使用的数据库产品如下所示
在传统的关系型数据库中，平安的选择中极有商业化的数据库Oracle，SQL Server，也有一些开源的数据库引擎，Mysql以及PG。在NoSQL中，针对不同的场景，平安也选取了不同类型的数据库，几乎都是各种数据库中的领头羊，例如在内存kv数据库中的Redis，文档数据库中的Mongo DB，图数据库中的Neo4j，最后是时序数据库中的Influx DB还有一些现在较新型的数据库，例如New SQL中的TiDB等。在进行数据库选型的过程中，针对不同的对数据质量的要求以及业务特点，给出了选型的策略。在Topic的最后，有一点给我留下了比较深的印象，汪洋老师认为对于一个公司的数据库产品应当是“一主多垂”即一个公司需要有自己主打的数据库产品，但对于其他的一些，也需要进行较为广泛的涉猎，但又不能够把面铺的过大，最后每一个点都不太深入。
之后，来自阿里巴巴的林亮研究员带来了超大规模实时数仓Analytic DB的建设，个人认为，这是一个比较有亮点的Topic，因为无论是从演讲以及其中所涉及的对数据库发展的讲述，以及针对阿里巴巴中的各类业务需求对他们实时数仓的建设，其中涉及的feature都十分清晰。林老师首先介绍了数据库系统的发展趋势。实际与分布式系统发展类似，经历的是从单机系统，到share everything再到share nothing，发展流程如下所示
能够看出，最初的数据库，只存在单机上，单一的进程实例提供服务，有独立的磁盘，内存等资源，随着数据量的增长，会变为多个实例同时来提供服务，不同实例间共享存储。这种情况下，往往一台高性能的大型机才能够支撑这种服务场景。通常是数据库厂商提供的数据库一体机等，如果需要提高服务性能，则需要提升这些大型机的配置，这种情形我们称之为Scale up，一般称之为纵向扩展。到现在的情况，我们将每一个实例部署在不同的独立的node中，每个node通过网络互连。如果需要提升性能，则可以通过增加node数达到目标。这种我们称之为Scale out，称为横向扩展。而针对这一系列的变化，阿里在智能数仓方面也进行了一系列的实践与优化。首先林老师给出了整体阿里数据库的核心模块如下所示
其次，林老师给出了目前阿里集团中数据库面临的挑战，主要分为以下的几个方面
- 存储格式混合化(HTAP行寸与列存的结合)
- 自动化的引擎(自动调优，CBO(基于),RBO(基于规则优化))
- 多模数据库(针对于不同的数据格式，不同的场景)
- 分布式方式(Scale Out/Scale up)
- 混合负载(CPU，mem，net，disk)
- 分布式SQL引擎
- 硬件加速
- 云原生
接下来，面向这些挑战，阿里进行了一系列的优化，包括数据读写，内存优化，智能调度，自研优化器，自动化运维等。针对于这些优化，具体都体现在阿里发布在VLDB2019的论文《AnalyticDB:Real-time OLAP Database System at Alibaba Cloud》中，这里由于篇幅所限，无法全部展开，感兴趣可以研读这篇论文。
下面是有浪潮解决方案部门的钱进老师带来的inData超融合数据库一体机的应用实践，这个topic主要还是在商业化的大型机上为企业带来一站式的数据库解决方案，整个inData一体机分为了三层，计算层，网络层以及存储层。针对每一层inData都有自己的一些优化。
后面则是来自京东商城的刘海峰老师带来的大规模电商数据库的演进，这个topic主要围绕如何将自己的数据库由一个单机数据库到现在上云的演进，第一代则是完全基于物理机独占式的db服务，第二代则是基于K8s的Pod容器化数据库服务，不同实例间使用本地的磁盘空间(Share nothing)，到现在使用了基于共享存储于K8s的StatefulSet(Share everything)。伴随着这些演进，也存在一些自研的系统，包括JIMDB-NG，将Google的Spanner基于内存实现，而这个引擎基于了Chubao FS这个文件系统。
最后来自云和恩墨的盖国强老师介绍了Oracle 19c的特性，Oracle给人们的印象依旧是那种传统的商业数据库，但随着云计算等技术的高速发展，Oracle也提供了相对应的feature，在Oracle 19c中主要提供了一些很有意思的feature，包括主从路由的重定向，将读写请求透明的进行分离，以及通过机器学习自动创建索引等。这些小的feature都能够给用户在使用上带来更多的便利。(写到这里真的是觉得没有可以下载的ppt材料，很多都是凭借当时的零碎的记忆，感觉好难写，回头有了ppt之后还得再小调整一下)
专场–数据架构设计
时间来到了下午，下午场我选择了数据架构设计这个专场，选择这个专场的原因不仅仅是因为这个场中有自己老大的topic，主要原因还是因为这个专场基本是围绕大数据架构的设计展开。来自各个互联网各个大佬讲述了他们在数据架构设计中遇到的痛点以及相对应的解决方案。
首先，来自58的沈剑老师为我们带来了在海量并发中，如何进行数据库的无损扩容，虽然topic内容并不算非常多，但聚焦点十分集中，主要就是围绕“如何进行数据库扩容”这一个小点展开，这四种方案包括
- 停服方案
- 停服，迁移，重启
- 追日志方案
- 升级服务(记录变更日志)，数据迁移，数据补齐，数据校验
- 双写方案
- 升级服务(记录变更日志)，数据迁移，数据校验
- 成倍方案
- 修改配置，重写配置，清扫
接下来，来自腾讯云的孙旭老师带来了腾讯自研的针对PostgreSQL优化的数据库CynosDB，该数据库针对的是云原生这一特性来设计，由于是数据库内核相关，再加上没有ppt原稿，实在无法详细说明具体的feature，这里简单列举一下其中的核心架构设计分别为：
- 日志下沉
- 日志异步回放
- 多版本读(同步)
后面的三个topic，来自字节跳动，滴滴和美团的三位大咖介绍了各自在数据架构方面的实践。字节跳动罗齐老师，介绍了基于Flink的异构海量数据传输系统。字节跳动中的数据数据源异构，如果采用端对端的传输工具，首先这是一种M*N的管理方式，管理起来过于繁琐。而且每种数据源都有自己独特的数据结构，对数据传输过程的SLA无法保证。因此基于这些挑战，字节跳动设计了基于Flink的异构数据传输服务DTS。总体的架构如下
如图所示，整个系统的核心，是围绕Flink展开，总体的模型很明确，数据源作为Input，经过特定的Flink作业产生目标数据源的Output，整个Flink作业运行在用户的YARN队列中，DTS通过插件的方式管理所有数据源的导入以及导出。用户通过配置文件源数据源和目标数据源进行配置。同时DTS还提供了一系列的机制对Flink运行的本身进行监控与管理，包括指标监控，流量控制，自动调整并发度等。
说完了异步的数据传输，接下来，滴滴的费辉老师为我们带来了离线数据平台的实践，主要从引擎建设中遇到的一些问题，例如NameNode的单点问题，数据存储的治理等，滴滴通过积极的与社区保持同步，使用Fd等机制缓解了NameNode的压力，使用了YARN与HDFS的权限机制对滴滴的离线数据进行治理。
最后就是压轴了，美团的杨永辉老师为我们带来了万亿级数据采集系统的实践，由于链路比较长，涉及的点也比较多，所以这个topic确实是整个下午场听到的干活最多的一个。整个topic主要围绕以下几个角度展开。分别为
- 日志格式标准化
- 日志组件自研
- Kafka的高可用与高吞吐
- 审计流建设
从这四个角度，分别概括了美团从2015年到现在，数据采集系统的变迁和进化，在日志格式方面，由于整个数据采集系统支持了全公司的业务，业务的多样性带来的是数据本身的复杂性和异构性。这里美团采用了对日志格式进行标准化的方式，同时开发了与上面头条采集系统相类似的异构数据源的传输系统解决了数据的统一。其次使用自研的采集组件，大大降低了组件的资源使用率，同时使用了配置中心比较好的解决了日志的隔离等问题，防止不同的日志之间相互干扰。Kafka作为美团数据平台的重要枢纽，其中的高可用和低延迟显得十分关键。美团使用了磁盘Rebalance，离线任务实时拉取，SSD Cache，Safe mode等机制来解决延迟和高可用的问题。最后通过丢失率检测等方式来更好的进行数据的治理和审计。
个人感悟
虽然这个大会的主题还是与数据库相关，对于数据库的内核自己并没有特别的了解。但是通过这次参会，有些高频词和概念还是给了自己一些启发，下面会分别列举这些词汇和自己的一些浅薄的想法。这几个词分别为
- 云原生
- 新硬件
- 智能化运维
云原生
现在，不管是数据库，还是其他的系统，是否为云原生似乎已经成为了一个系统设计中最重要的feature，云计算相较于原先传统的数据中心，所有我们看到的资源都是通过一层计算之后所得到，可以方便的“按需获取”与“按需分配”。同时，容器化的封装性，能够使各个子系统之间解耦。对于传统的web系统，所谓的云原生架构则是通过微服务将整个的服务拆解为各个功能较为独立的模块，各个模块之间通过rpc，restful API等方式进行通信，这样使得每一个模块都可以方便的进行扩展，流控等治理，以打到服务自治。而对于大数据系统而言，在原先的部署方式上，一般的节点既会承担计算的任务，又会存储数据，每一层无法进行独立的扩展。而现在提出的新型的系统，如Pulsar，CynosDB等，都是将数据的处理层以及真正的数据存储层分开，使得每一层都可以进行独立的扩容等操作，这里面一般都会涉及“存储计算分离”。表面上看，存储与计算分离能够很好的进行工作，每一层都能自治显得比较灵活，但是这对整个系统如何管理自治系统提出了较高的要求，与Kafka为例，原先请求找到了对应的broker可能也就找到了对应的存储节点，但在Pulsar中，极有可能就要经历两跳才能够找到相应的存储节点。这其中带来的网络开销是否能够忽略，或者什么情况下自治系统的灵活性带来的收益会比整体管理带来的性能开销更大，都有待实际的场景进行进一步的验证。因此，个人认为，在设计“云原生”的系统时，还是需要根据具体的场景来衡量是否需要将不同的层分开自治，还是适当的将不同的层级之间耦合起来提升性能。
新型硬件
在软件生态每天都蓬勃发展的今天，硬件的发展同样没有停滞不前，虽然CPU的摩尔定律正在渐渐“失灵”，但一批其他的硬件，为我们计算机软件系统的设计带来了更多的可能性，这些硬件甚至会颠覆目前的计算机系统的设计理念。例如，现在的NVRAM兴起，使得内存突然有了“持久化数据”的可能性，这可能会完全改变之前对于系统的设计，可能今后
无磁盘化的存储系统会越来越受到关注和重用。再例如SSD是否真正的能够取代HDD也是一直都在引起着关注，越来越多的计算引擎都加上了GPU的支持，是的GPU这个硬件不仅仅单纯与图片和显示挂钩了，其独特的多核设计为一些计算的加速提供了天生的优势。如何能够很好地利用这些硬件特性，平衡好使用它们给系统带来的收益与开销相信是今后系统设计的一个关键点。而不仅仅是一个系统里只有CPU，传统的DRAM，和HDD。
智能化运维
对于大型系统的运维，其本身就相对较为复杂，需要工程师拥有较为深厚的功底，才能够较为迅速的发现庞大系统栈中可能蕴含的问题。每个工程师的培养成本较大，周期较长，并且需要大量的实战经验。然而这些实战经验，是不是可以考虑传授给计算机，让他们来帮助我们呢？我们现在处在人工智能时代，交给机器去处理一些大量的数据似乎是理所应当的，利用机器学习等理论工具，让计算机自己来“吸收”工程师们平日的运维经验，形成自己的智能化运维模型，从而转化为生产力。智能化运维的前提是自动化运维，如何将大型系统的运维进行标准化，遇到特定问题的自动化流程制定，对于今后想要解放生产力的我们而言十分关键。个人认为目前我们首要做的就是规范化系统的运维流程，做好自动化运维的工具。完成后运用适当的机器学习工具，训练智能化的运维模型。其实不仅仅是运维，对于系统的参数调优则更加如此，有时往往针对不同的场景，系统的最佳配置参数都是不同的，那么何不把这些场景分分类，让机器来记住每种场景的参数配置呢。因此，这个概念给我的启示是，我们需要充分利用大数据以及人工智能的优势，将复杂的系统运维以及参数调优的工作交给机器，我们需要做的不再是人肉的去每天参与运维，而是训练一支“训练有素”的机器人战队帮我们稳定的搞定这一切。
以上就是我对于dtcc参会的一些想法，时间也来到了新的一周，这些想法说出来都容易，但是真正落到实处还有很长的路要走，我继续去努力学习去了。如本文开头讲到的，后面会有一些网络协议以及操作系统内核方向的学习笔记，欢迎大家持续关注
https://bryantchang.github.io/2019/05/12/dtcc/