一文饱览DTCC 2020

作为数据库领域重量级的大会，DTCC每年都会引发人们的关注。通过大会，可以了解行业动态，洞悉趋势发展，学习最新技术。今年因个人原因，没有现场参会。所幸近期大会PPT材料已放出，抽空学习了一下。

1. 数据趋势篇

人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。

❖ 单模型 => 多模型 => 多模

从最早的层次模型、网状模型，发展到关系模型。后者长期占据数据的模型的主导地位，直到今天仍然如此。关系模型所带来的数据表述方式结合SQL语言帮助人们可以很好地使用数据。但从90年代开始，随着人们对数据的使用方式的变化，出现了键值、列簇、文档、图等多种数据表述方式，随之各种分化产品也不断涌现。针对不同的场景化需求，有着不同应对解决产品。这种趋势，有利有弊；满足了个性化需求的同时，也带来的管理、使用、开发的复杂度。近些年来，多模产品成为新的一种思路，通过单一产品支持多种数据模型，简化人们的使用。辅助以分布式、云化技术，解决传统方式在规模、性能等方面的短板。这一趋势值得关注。

❖ 生产者变化，带来规模方式变化

数据，在社会发展中正扮演着愈发重要的作用。从早期仅限于学术研究、军事领域，到后面应用到企业经营活动、再到个人互联网应用、直到云与物联网时代。使用数据的端走过了“高校->企业->个人->万物”的过程。不同的使用使用端，对数据使用有着不同的诉求。因此，数据存储使用底层平台（数据库）也经历了不同的发展阶段。从层次、网状模型到关系模型，从单机到集群，从单体架构到集群架构，从线下到云端。以此来满足对数据的承载能力、使用特点差异。

随着数据使用者的扩大，越来越多的数据被挖掘出来。这些数据不仅规模巨大，而且非结构化明显，这些都会底层平台提出了更高的要求。

针对不同的数据，不仅其量级、特征、生产者不同，而且其数据价值也差异明显。其所带来的数据使用方式，也做过了从离线到在线、从单一业务到混合业务的过程。

其使用方式的举例，如从早期企业业务生产数据，通过离线处理形成仪表盘数据供管理经营决策，这种面向“决策”的处理方式。到后面的，针对个人的大量个性化数据处理，提供的更为实时、更为细粒度的数据分析，满足面向“服务”的处理方式。不同的处理方式，自然对数据承载能力、处理性能等产生了不同的要求。

❖ 业务混合负载成为常态

随着接入数据源的不断增加，越来越多的数据被集中管理起来。这些数据规模巨大、结构不同、使用行为存在差异。这也导致混合负载成为一种普遍性的需求。现在只承载一类数据，按一种方式使用的场景，已经很难找到。人们希望通过统一的访问接口（如SQL），按不同的方式（如离线、在线）使用数据。

针对上面的需求，无论是传统的IOE架构还是后面的大数据架构，都存在种种不足。因此，NEWSQL的形态正愈发受到人们的关注。无论是传统大厂、云厂商到新兴创业公司纷纷在支持分布式架构、具备混合负载支撑能力的产品上发力。

2. 数据治理篇

❖ 数据治理成为刚需

作为数据使用的上层建筑，数据治理正受到企业的高度关注。这主要是因为一方面数据的多源、异构、价值差异等特点导致复杂度的提高；另一方面数据价值正在被更多的企业所关注。如何在企业内部用统一视角看待数据，让数据在企业中存好用好发挥出更大价值，是企业数字化转型必然面临的问题。数据治理，正是解决这一问题的利器。过去，数据治理往往在高价值数据集中且规范程度较高的企业（如金融业）受到重视，但现在更多的企业（包括互联网）也重视数据治理的建设。从理论模型来讲，上图的DAMA是国外在数据治理领域沉淀多年的治理框架。其将整个数据治理过程，划分为11个作用域加以建设。国内也有类似的治理框架。

很多人会觉得数据治理很虚。确实，如果无法真正理解数据治理，最终很可能只会转化为一堆文档、标准束之高阁。上面示例中，通过菜店案例，很好地诠释了数据治理各个作用域的作用，并可将各个作用域有机结合起来。在真实建设过程中，可参考此案例结合企业自身特点，以一两个作用域为切入点，小步迭代，通过收益逐步驱动治理行为的贯彻落地。

在建设选择上，可仿照上面找到合适的切入点。这些切入点，往往是通过某个具体业务需求来触发，这样更容易落地并产生效益。

❖ 数据治理源头：元数据

元数据的建设，往往是整个数据治理过程中的起始部分。通过元数据，了解企业内有哪些数据？数据是如何使用的？数据被谁使用等问题。即解决数据的5W H问题（who、where、what、why、when、how）。可以说是数据治理的基础和源头。笔者之前也做过元数据过程（包括相关平台的建设），这可以说是“脏活累活”。通过平台化建设可以提高元数据收集的质量、效率等。但这个过程收益较慢，如何快速变现？从个人实践来看，可以从血缘/影响分析、元数据自服务等作为初期切入点，快速产生收益。

3. 数据架构篇

❖ “去O”是个系统化工程

“去O”，是近些年很热的话题。这也是很多传统企业在面临数据库架构选型、升级上不得不走的路。但这里需要强调的是，去O不仅只是底层数据库平台的替换，而是需要从系统工程角度去考虑。从基本的结构、数据迁移工具，到业务开发的转换；从现状数据逻辑的梳理拆分，到业务逻辑的适配改造；从流量切换，小步尝试；到全面替换后备用方案的支持。整个去O过程，需要研发、运维、架构甚至是业务团队的紧密配合。

在具体的建设过程中，应本着严谨的态度，制定完善的过程步骤，做到步步可回溯、风险降最低。工具、平台的自动化辅助以业务适配改造、完整的流程方法，才可能最终完成。

❖ 迁移过程痛苦而漫长

传统数据库迁移过程，往往是个痛苦而漫长的过程。往往遵循从评估、改造、迁移、优化的过程。在很多大型项目中，迁移过程可能持续1~2年的时间。这其中涉及到诸多方面的问题，包括基础架构、应用研发、业务过程等多方面。具体可参见我之前写过的一篇关于迁移的文章。

为了提高迁移效率，可以通过工具辅助这一过程。这里强调下是辅助过程，目前的工具尚无法完全替代。顺便说下，即使可以替代，也建议有个人工检核的过程，毕竟数据问题是很严肃的。这类工具，不仅可帮助辅助完成迁移过程，此外还可以在之前提供评估，方便我们预估可能的迁移成本（人力、时间成本等）及规避可能的风险。

在具体的技术实现上，如上图就是某厂数据迁移辅助平台的实现过程，可供参考。

❖ MySQL高可用谨慎选择

作为最为流行的开源数据库产品，MySQL正成为很多企业的选择。但在承载核心业务场景上，如何做到高可用呢？MySQL技术发展也经历了几个阶段。上图很好地总结了高可用技术的演进过程，并归纳总结当前选择高可用方案建议从三、四代架构中选择。

在具体选择上，企业可根据自身情况来选择，并关注新一代的高可用方案。

4. 分布式篇

❖ 选择分布式不是简单过程

当企业考虑选择分布式时，是个比较艰难的过程。因分布式与传统的单体架构差异较大，是需要考虑多方面因素的。上图列出了需要考虑的很多因素。从底层的基础架构适配、到构建运维体系，从结构、语句设计优化，到开发规范的制定，从构建源码级支持能力，到选择场景并做好适配改造等等。个人建议是，不要为了上分布式而上分布式，还是要看实际需求并遵循客观规律。

❖ 分布式路线，各有优劣

在具体分布式技术路线选择上，有多种可能性。目前尚没有所谓完美的方案，不同技术路线及产品各有优劣点。甚至有些规模较大的公司，选择了多种技术路线，在享受分布式所带来的技术红利的同时，也尽量规避可能的问题。相对而言，从接受的难易程度来看，是自下而上难度逐步增大的。可以根据公司自身情况来选择。

上例中工行就选择了两步走的战略，通过中间层的方案作为早期过渡，长期关注分布式数据库。

❖ 分布式事务：核心难点，值得关注

分布式事务，是分布式数据库的核心难点之一。腾讯-李海翔老师带来的关于分布式事务的分享，值得关注。此部分因内容过于干核，还需要抽时间具体研究下。感兴趣的同学，可具体关注下腾讯事务处理技术验证系统-3TS，目前已在github上开源

https://github.com/databaseService/3TS。

目前在工程实现上，存在多种做法，网易带来其在这方面的体会。

5. 数据运维篇

❖ 运维平台发展阶段

运维平台的发展，走过了三个阶段，经历了人力、自动化、智能化的发展过程。从早期的以个人为主，通过个体的经验运维。此阶段面临的问题在于运维无法体系化，受限于个人的能力，不仅运维能力无法沉淀也受限于个人无法大规模扩展。到了下一阶段，将个人经验，通过工具平台沉淀下来，可满足支持大规模运维需求。但随着运维规模、复杂度的提高，工具平台还是无法适应日益复杂的运维需求。因而智能运维应运而生，其通过AIOPS的引入，通过人工领域知识的积累和智能场景化学习相结合，满足了更为复杂的运维场景。

针对后者来说，通常采用上面过程来提高运维效能。通过数据清理、数据清洗、模型训练、数据验证到改善反馈的过程往复迭代，逐步提高。

在具体实践上，可采取类似上图的架构，将上面的逐步细化。

❖ 算法落地，产生效能

智能运维落地，选择合适的算法很重要，经常面临雷声大、雨点小的窘境。花费很大代价做的模型分析，其结果却无法帮助到实际运维工作。上例中使用了KNN算法，原理很简单，但通过距离分离可辅助做好根因分析，具备很好的可落地性。

❖ 运维平台发展变化

在新的形式下，传统运维模式面临很多问题，如何满足新形势下的运维诉求？这里主要有两个转变：

一是由管理到服务，更好满足前端对库的需求。
二是从被动到主动，避免背锅侠身份，走到前台。

通过统一平台，完成从交付、管理、告警、预防、分析、定位、处理、保障全域的支持。

❖ 自动驾驶，未来可期

自动驾驶，是人们对数据库的理想，希望通过完全自治的方式实现自我管理。目前几个大厂通过自身多年的实践，大量的数据积累，也推出这样的产品。借此提升用户使用体验。可以说，这是护城河式的产品，对企业（特别是云厂商）意义重大。

在具体的实践上，可参考上面的实现方式。

6. 数据中台篇

❖ 数据中台，建还是不建

数据中台，在前几年有些沉寂后，近段时间有热度渐起。关于拆中台等论调，层出不穷。其核心还是在于前一阶段中台理念大热，导致人们对中台的定位有些偏差，期望越高，失望越大。在讨论中台之前，我们先来辨析下中台与平台的关系，借此可以更好地给中台做个定位。

中台不是一个新概念，在之前不同阶段也存在所谓中台，只是但是的叫法不同而已。中台本省不是解决具体数据供给侧的问题，而是面向解决数据使用侧的问题。前者往往是通过平台方来提供，而中台更多是面向业务方解决问题。其定位是更好地解决稳定的基础底座与快速前台业务发展的矛盾。它更多是提供业务能力数据化的输出能力，方便业务快速解决自身问题。

但同时也要看到，数据中台本身更多是提供零件，还需要将其组合形成数据产品，才能最终被业务方使用到。未来的IT架构演化，正沿着业务中台化、系统平台化（云化）的方向演进。

7. 云数据库篇

❖ 存储计算分离，仍是难点

作为云的核心能力这一，存储与计算分离对云的刚需。正是通过两者的解耦，提供充分的弹性能力，才是最终实现云的根本诉求。

但目前这一方面仍存在较大短板。可以说AWS的Aurora开启了云原生分布式数据库的先河，但其核心理念在20多年的Oracle RAC其实已经实现，甚至现在还有所不及。如何实现真正的多写多读，是未来的核心要点。当某个大厂能拿出这一能力，那必将是一款颠覆性的产品。

❖ 上云之路千万条

企业上云，是未来的趋势；但国内受限于国情，专有云或混合云成为云生态重要的补充。因而企业上云，是可以有多种路径的。如何选择适合企业的最佳路径，值得探讨。既能满足企业合规、监管、安全需求，又能享受到云带来便利。上述三种路径，都是一种选择。

同时，类似数据网管类产品也推了出来，方便用户将云上云下联动起来。

❖ 上云之路，考虑多种因素

企业上云，与传统基础设施有着很大的区别。快速了解掌握两者差异，做出科学的选择，有助于铺平企业上云之路。下面列举的正是上云时需考虑的多种因素。

迁移方式对比

网络方案对比

计算对比

存储对比

形态对比

8. 数据安全篇

❖ 从数据生命全周期考虑安全

数据从产生、流动、归集、归档、转储、备份、清理、销毁，整个生命周期无不需考虑安全问题。可以说安全贯彻了整个数据生命周期。上图针对生命周期的各个阶段，需要做哪些安全措施进行了说明。我们在换个角度，从数据完整、可信、过程可查、可控角度来看待数据安全。

❖ 数据脱敏，把住数据使用安全关

数据脱敏，可以说是离前线最近的数据安全关口。它跟每个研发、运维人员息息相关。如何把住数据安全这第一道关，成为数据安全建设的首要问题。数据脱敏，从原理上讲很简单，只要识别出敏感信息，脱敏输出即可。但在实践上，需要考虑的问题很多。首先前提是做好数据的分类分级，掌握一手准确的元数据；其次在保障效率和准确性下，做好敏感数据识别；再次针对敏感数据，做到保证质量不失真的脱敏处理。大的原则就是，在保证安全的前提下，兼顾效率平衡。