一文读尽：数据趋势、数据治理、数据架构、数据中台、云数据库、数据安全

2021-01-19 08:51

一数据趋势篇

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

? 单模型 => 多模型 => 多模

从最早的层次模型、网状模型,发展到关系模型。后者长期占据数据的模型的主导地位,直到今天仍然如此。关系模型所带来的数据表述方式结合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上开源

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

五数据运维篇

? 运维平台发展阶段

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

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

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

? 算法落地,产生效能

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

? 运维平台发展变化

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

一是由管理到服务,更好满足前端对库的需求。

二是从被动到主动,避免背锅侠身份,走到前台。

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

? 自动驾驶,未来可期

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

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

六数据中台篇

? 数据中台,建还是不建

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

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

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

七云数据库篇

? 存储计算分离,仍是难点

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

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

? 上云之路千万条

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

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

? 上云之路,考虑多种因素

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

迁移方式对比

网络方案对比

计算对比

存储对比

形态对比

八数据安全篇

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

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

? 数据脱敏,把住数据使用安全关

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