一文读尽：数据趋势、数据治理、数据架构、数据中台、云数据库、数据安全（附下载链接）
❖ 单模型 => 多模型 => 多模
从最早的层次模型、网状模型，发展到关系模型。后者长期占据数据的模型的主导地位，直到今天仍然如此。关系模型所带来的数据表述方式结合SQL语言帮助人们可以很好地使用数据。但从90年代开始，随着人们对数据的使用方式的变化，出现了键值、列簇、文档、图等多种数据表述方式，随之各种分化产品也不断涌现。针对不同的场景化需求，有着不同应对解决产品。这种趋势，有利有弊；满足了个性化需求的同时，也带来的管理、使用、开发的复杂度。近些年来，多模产品成为新的一种思路，通过单一产品支持多种数据模型，简化人们的使用。辅助以分布式、云化技术，解决传统方式在规模、性能等方面的短板。这一趋势值得关注。
❖ 生产者变化，带来规模方式变化
数据，在社会发展中正扮演着愈发重要的作用。从早期仅限于学术研究、军事领域，到后面应用到企业经营活动、再到个人互联网应用、直到云与物联网时代。使用数据的端走过了“高校->企业->个人->万物”的过程。不同的使用使用端，对数据使用有着不同的诉求。因此，数据存储使用底层平台（数据库）也经历了不同的发展阶段。从层次、网状模型到关系模型，从单机到集群，从单体架构到集群架构，从线下到云端。以此来满足对数据的承载能力、使用特点差异。
随着数据使用者的扩大，越来越多的数据被挖掘出来。这些数据不仅规模巨大，而且非结构化明显，这些都会底层平台提出了更高的要求。
针对不同的数据，不仅其量级、特征、生产者不同，而且其数据价值也差异明显。其所带来的数据使用方式，也做过了从离线到在线、从单一业务到混合业务的过程。
其使用方式的举例，如从早期企业业务生产数据，通过离线处理形成仪表盘数据供管理经营决策，这种面向“决策”的处理方式。到后面的，针对个人的大量个性化数据处理，提供的更为实时、更为细粒度的数据分析，满足面向“服务”的处理方式。不同的处理方式，自然对数据承载能力、处理性能等产生了不同的要求。
❖ 业务混合负载成为常态
随着接入数据源的不断增加，越来越多的数据被集中管理起来。这些数据规模巨大、结构不同、使用行为存在差异。这也导致混合负载成为一种普遍性的需求。现在只承载一类数据，按一种方式使用的场景，已经很难找到。人们希望通过统一的访问接口（如SQL），按不同的方式（如离线、在线）使用数据。
针对上面的需求，无论是传统的IOE架构还是后面的大数据架构，都存在种种不足。因此，NEWSQL的形态正愈发受到人们的关注。无论是传统大厂、云厂商到新兴创业公司纷纷在支持分布式架构、具备混合负载支撑能力的产品上发力。
❖ 数据治理成为刚需
作为数据使用的上层建筑，数据治理正受到企业的高度关注。这主要是因为一方面数据的多源、异构、价值差异等特点导致复杂度的提高；另一方面数据价值正在被更多的企业所关注。如何在企业内部用统一视角看待数据，让数据在企业中存好用好发挥出更大价值，是企业数字化转型必然面临的问题。数据治理，正是解决这一问题的利器。过去，数据治理往往在高价值数据集中且规范程度较高的企业（如金融业）受到重视，但现在更多的企业（包括互联网）也重视数据治理的建设。从理论模型来讲，上图的DAMA是国外在数据治理领域沉淀多年的治理框架。其将整个数据治理过程，划分为11个作用域加以建设。国内也有类似的治理框架。
很多人会觉得数据治理很虚。确实，如果无法真正理解数据治理，最终很可能只会转化为一堆文档、标准束之高阁。上面示例中，通过菜店案例，很好地诠释了数据治理各个作用域的作用，并可将各个作用域有机结合起来。在真实建设过程中，可参考此案例结合企业自身特点，以一两个作用域为切入点，小步迭代，通过收益逐步驱动治理行为的贯彻落地。
在建设选择上，可仿照上面找到合适的切入点。这些切入点，往往是通过某个具体业务需求来触发，这样更容易落地并产生效益。
❖ 数据治理源头：元数据
元数据的建设，往往是整个数据治理过程中的起始部分。通过元数据，了解企业内有哪些数据？数据是如何使用的？数据被谁使用等问题。即解决数据的5W+H问题（who、where、what、why、when、how）。可以说是数据治理的基础和源头。笔者之前也做过元数据过程（包括相关平台的建设），这可以说是“脏活累活”。通过平台化建设可以提高元数据收集的质量、效率等。但这个过程收益较慢，如何快速变现？从个人实践来看，可以从血缘/影响分析、元数据自服务等作为初期切入点，快速产生收益。
❖ “去O”是个系统化工程
“去O”，是近些年很热的话题。这也是很多传统企业在面临数据库架构选型、升级上不得不走的路。但这里需要强调的是，去O不仅只是底层数据库平台的替换，而是需要从系统工程角度去考虑。从基本的结构、数据迁移工具，到业务开发的转换；从现状数据逻辑的梳理拆分，到业务逻辑的适配改造；从流量切换，小步尝试；到全面替换后备用方案的支持。整个去O过程，需要研发、运维、架构甚至是业务团队的紧密配合。
在具体的建设过程中，应本着严谨的态度，制定完善的过程步骤，做到步步可回溯、风险降最低。工具、平台的自动化辅助以业务适配改造、完整的流程方法，才可能最终完成。
❖ 迁移过程痛苦而漫长
传统数据库迁移过程，往往是个痛苦而漫长的过程。往往遵循从评估、改造、迁移、优化的过程。在很多大型项目中，迁移过程可能持续1~2年的时间。这其中涉及到诸多方面的问题，包括基础架构、应用研发、业务过程等多方面。具体可参见我之前写过的一篇关于迁移的文章。
为了提高迁移效率，可以通过工具辅助这一过程。这里强调下是辅助过程，目前的工具尚无法完全替代。顺便说下，即使可以替代，也建议有个人工检核的过程，毕竟数据问题是很严肃的。这类工具，不仅可帮助辅助完成迁移过程，此外还可以在之前提供评估，方便我们预估可能的迁移成本（人力、时间成本等）及规避可能的风险。
在具体的技术实现上，如上图就是某厂数据迁移辅助平台的实现过程，可供参考。
❖ MySQL高可用谨慎选择
作为最为流行的开源数据库产品，MySQL正成为很多企业的选择。但在承载核心业务场景上，如何做到高可用呢？MySQL技术发展也经历了几个阶段。上图很好地总结了高可用技术的演进过程，并归纳总结当前选择高可用方案建议从三、四代架构中选择。
在具体选择上，企业可根据自身情况来选择，并关注新一代的高可用方案。
❖ 选择分布式不是简单过程
当企业考虑选择分布式时，是个比较艰难的过程。因分布式与传统的单体架构差异较大，是需要考虑多方面因素的。上图列出了需要考虑的很多因素。从底层的基础架构适配、到构建运维体系，从结构、语句设计优化，到开发规范的制定，从构建源码级支持能力，到选择场景并做好适配改造等等。个人建议是，不要为了上分布式而上分布式，还是要看实际需求并遵循客观规律。
❖ 分布式路线，各有优劣
在具体分布式技术路线选择上，有多种可能性。目前尚没有所谓完美的方案，不同技术路线及产品各有优劣点。甚至有些规模较大的公司，选择了多种技术路线，在享受分布式所带来的技术红利的同时，也尽量规避可能的问题。相对而言，从接受的难易程度来看，是自下而上难度逐步增大的。可以根据公司自身情况来选择。
上例中工行就选择了两步走的战略，通过中间层的方案作为早期过渡，长期关注分布式数据库。
❖ 分布式事务：核心难点，值得关注
分布式事务，是分布式数据库的核心难点之一。腾讯-李海翔老师带来的关于分布式事务的分享，值得关注。此部分因内容过于干核，还需要抽时间具体研究下。感兴趣的同学，可具体关注下腾讯事务处理技术验证系统-3TS，目前已在github上开源
https://github.com/databaseService/3TS。
目前在工程实现上，存在多种做法，网易带来其在这方面的体会。
❖ 运维平台发展阶段
运维平台的发展，走过了三个阶段，经历了人力、自动化、智能化的发展过程。从早期的以个人为主，通过个体的经验运维。此阶段面临的问题在于运维无法体系化，受限于个人的能力，不仅运维能力无法沉淀也受限于个人无法大规模扩展。到了下一阶段，将个人经验，通过工具平台沉淀下来，可满足支持大规模运维需求。但随着运维规模、复杂度的提高，工具平台还是无法适应日益复杂的运维需求。因而智能运维应运而生，其通过AIOPS的引入，通过人工领域知识的积累和智能场景化学习相结合，满足了更为复杂的运维场景。
针对后者来说，通常采用上面过程来提高运维效能。通过数据清理、数据清洗、模型训练、数据验证到改善反馈的过程往复迭代，逐步提高。
在具体实践上，可采取类似上图的架构，将上面的逐步细化。
❖ 算法落地，产生效能
智能运维落地，选择合适的算法很重要，经常面临雷声大、雨点小的窘境。花费很大代价做的模型分析，其结果却无法帮助到实际运维工作。上例中使用了KNN算法，原理很简单，但通过距离分离可辅助做好根因分析，具备很好的可落地性。
❖ 运维平台发展变化
在新的形式下，传统运维模式面临很多问题，如何满足新形势下的运维诉求？这里主要有两个转变：
一是由管理到服务，更好满足前端对库的需求。
二是从被动到主动，避免背锅侠身份，走到前台。
通过统一平台，完成从交付、管理、告警、预防、分析、定位、处理、保障全域的支持。
❖ 自动驾驶，未来可期
自动驾驶，是人们对数据库的理想，希望通过完全自治的方式实现自我管理。目前几个大厂通过自身多年的实践，大量的数据积累，也推出这样的产品。借此提升用户使用体验。可以说，这是护城河式的产品，对企业（特别是云厂商）意义重大。
在具体的实践上，可参考上面的实现方式。
❖ 数据中台，建还是不建
数据中台，在前几年有些沉寂后，近段时间有热度渐起。关于拆中台等论调，层出不穷。其核心还是在于前一阶段中台理念大热，导致人们对中台的定位有些偏差，期望越高，失望越大。在讨论中台之前，我们先来辨析下中台与平台的关系，借此可以更好地给中台做个定位。
中台不是一个新概念，在之前不同阶段也存在所谓中台，只是但是的叫法不同而已。中台本省不是解决具体数据供给侧的问题，而是面向解决数据使用侧的问题。前者往往是通过平台方来提供，而中台更多是面向业务方解决问题。其定位是更好地解决稳定的基础底座与快速前台业务发展的矛盾。它更多是提供业务能力数据化的输出能力，方便业务快速解决自身问题。
但同时也要看到，数据中台本身更多是提供零件，还需要将其组合形成数据产品，才能最终被业务方使用到。未来的IT架构演化，正沿着业务中台化、系统平台化（云化）的方向演进。
❖ 存储计算分离，仍是难点
作为云的核心能力这一，存储与计算分离对云的刚需。正是通过两者的解耦，提供充分的弹性能力，才是最终实现云的根本诉求。
但目前这一方面仍存在较大短板。可以说AWS的Aurora开启了云原生分布式数据库的先河，但其核心理念在20多年的Oracle RAC其实已经实现，甚至现在还有所不及。如何实现真正的多写多读，是未来的核心要点。当某个大厂能拿出这一能力，那必将是一款颠覆性的产品。
❖ 上云之路千万条
企业上云，是未来的趋势；但国内受限于国情，专有云或混合云成为云生态重要的补充。因而企业上云，是可以有多种路径的。如何选择适合企业的最佳路径，值得探讨。既能满足企业合规、监管、安全需求，又能享受到云带来便利。上述三种路径，都是一种选择。
同时，类似数据网管类产品也推了出来，方便用户将云上云下联动起来。
❖ 上云之路，考虑多种因素
企业上云，与传统基础设施有着很大的区别。快速了解掌握两者差异，做出科学的选择，有助于铺平企业上云之路。下面列举的正是上云时需考虑的多种因素。
迁移方式对比
网络方案对比
计算对比
存储对比
形态对比
❖ 从数据生命全周期考虑安全
数据从产生、流动、归集、归档、转储、备份、清理、销毁，整个生命周期无不需考虑安全问题。可以说安全贯彻了整个数据生命周期。上图针对生命周期的各个阶段，需要做哪些安全措施进行了说明。我们在换个角度，从数据完整、可信、过程可查、可控角度来看待数据安全。
❖ 数据脱敏，把住数据使用安全关
数据脱敏，可以说是离前线最近的数据安全关口。它跟每个研发、运维人员息息相关。如何把住数据安全这第一道关，成为数据安全建设的首要问题。数据脱敏，从原理上讲很简单，只要识别出敏感信息，脱敏输出即可。但在实践上，需要考虑的问题很多。首先前提是做好数据的分类分级，掌握一手准确的元数据；其次在保障效率和准确性下，做好敏感数据识别；再次针对敏感数据，做到保证质量不失真的脱敏处理。大的原则就是，在保证安全的前提下，兼顾效率平衡。
在实操上，敏感数据梳理是劳心劳力的活。准确识别很关键，除了借助数据资产信息外，还可以辅助规则、甚至AI的能力识别敏感数据。
有了上述敏感信息后，如下图所示构建脱敏服务即可。
❖ 数据审计，留下所有数据行为
数据审计的范围很广，狭义上是指数据访问类操作，广义上也保护了数据访问特征、执行计划等信息。其目的是保证数据访问的可追溯，此外也可作为性能优化等的需求输入。基本的思路如下图：
拿最为常见的SQL审计为例，用户访问数据库的SQL被实时记录下来，通过流式处理与机器学习的配合，生成各种审计结果通过服务对外暴露。
在具体使用上，可采用类似网络嗅探的方式获得。
并最终得到基于事件、行为、对象及规则匹配后的结果。
❖ 数据可靠，安全的底线
保证数据可靠，可追溯是安全的底线。无论什么时候，都要保证可以拿到全部数据。如何满足这一需要，是需要从多方面无死角地堵住可能的漏洞。下面是某厂的实践，针对数据安全需要有这样一份全局的视图，提高最后一块数据安全短板。