您的位置:首页 > 大数据

大数据十年回顾(1):大数据史前的数据库发展

2019-05-09 13:26 1041 查看

是当前最热的技术之一,这十年它经历了哪些阶段?每个阶段分别创造和发展了什么?未来大数据又将朝着哪些方向继续前行?在这篇文章里,我们沿大数据发展时间线,从产品、行业、技术多角度讨论其发展脉络,究其发展承其脉络大家可以学习、借鉴、并最终推测未来大致走向。

 

引子

我一直认为大数据中文社区里面不乏各类技术大牛所著深度架构干货,同时亦不乏各类技术的总监 /VP/CXO 高屋建瓴指点行业江山的激情文字,所缺的往往是站在技术、产品、社区、市场交汇点的思考点滴。有如我经常在我部门中所说,中国当前不乏各类云计算的技术大牛,亦不缺各类 C 端领域的产品大拿,但中国云计算领域要盘点出来一个既通晓技术、又懂得产品全局观、更有甚者能够把握行业脉络的技能全通行业闻名者,确实屈指可数乏善可陈。

我一直笃定一名优秀的云计算产品经理一定是全技能通才,上可讨论行业趋势产业脉络,下可写得了代码修得了 Bug,中还可设计产品交互参与 API 制定,有时可能自恋一把还去 投投稿、赚赚人气、刷刷存在感。同理,我希望这篇命题式作文亦兼具如此多条思路:

沿大数据发展时间线,从产品、行业、技术多角度讨论其发展脉络,究其发展承其脉络我们可以学习、借鉴、并最终推测未来大致走向。

我不敢用“预测”而只能用“推测”,是因为我非常认可吴军老师在《硅谷来信》中所言”轻预测重反应“,他对于如此复杂如此变幻的市场、世界,缺乏直言预测的勇气。我深以为然。因此,我不敢轻言预测,只能说我们尝试用之前的发展轨迹去推测一下未来的走势。至于最终市场方向是否符合我们预计,实在是天命难测命运难为。当然,最终如果市场不按我们预测的套路出牌,错的不是市场,而是我们的理论。所谓”市场永远是正确的,错误的只能是我们的理论“,是吴军老师教会我的第二点产品市场观。

站在云高度提供独一无二的视角去观察大数据 / 云计算的发展。

我曾有幸作为一个不处在核心岗位仍在电商边缘工作的观察者在电商崛起的时代被有幸卷入电商浪潮。我是亲眼看到以淘宝、天猫为代表中国电商行业崛起的时代,那是一个创造金钱、财富、神话的时代,你可以比之为美国淘金时代。接下来的时代,即我们当前的时代,可能是一个更加激动人心、更加”技术爆炸“的时代,它们可能是 IOT 时代、是大数据时代、是云计算时代、是人工智能时代。上述都是从产业某种维度观察 IT 技术设施发展的浅显断论,可能是一叶障目管中窥豹,亦可能是独辟蹊径曲线救国。但不管怎样,站在云计算高度来看,这些都是当前云计算所希望领域突破,也是希望能够利用云计算服务上述更多行业、造福更多中国中小企业的领域。比如当前阿里云服务的具有百万级客户群体以及技术积累,从市场份额来看它是后续数个追随者份额之和。兵贵神速,任何的先发优势在行业井喷年代造就的发展加速度是任何后续资本、人力、技术投入都不可比拟的。才发现,差之毫厘谬以千里,形容发展加速度亦十分贴切。

接下来,我会从上篇(大数据史前)、下篇(大数据当代),讨论整体大数据发展特点和脉络。负责任地说,以下论点都是作者一家之言(不代表任何公司的立场),同时篇幅受限论点基本均是管中窥豹,不成体系。大家权当作为茶余饭后消遣阅读的 IT 杂文。

 

大数据史前

历史

如果我把大数据开创的时代当做公元元年纪年,那么我把大数据开创时代之前的时间称之为”史前时代“,当然此史前并未真正较真为“文明之前”,仅仅笔者的象征性说法。另外需要注意的是,我专门使用的名词是”史前时代“而非”田园时代“,史前指代的是蛮荒、指代的是愚昧、指代的是茹毛饮血,而田园往往给人以心理暗示是男耕女织、自给自足、路不拾遗的上古伊甸园。我从不认可人类社会文明之前乃是一个夜不闭户、道不拾遗的谦谦君子社会,古人常云”人心不古世风日下“就好比男人经常性怀念前女友整日日有所思夜有所梦,倘要他们真的返回原始社会过着食不果腹衣不蔽体,常常需要血肉厮杀、易子而食的时候,这波文人可能就两眼一瞪:傻缺才愿意回去过苦日子呢,我又不傻!

同理,我从不认为大数据之前的数据处理特别包括数据库理论才是数据处理的田园时代,以至于大批数据库理论学派发檄文声讨 MapReduce 理论的种种缺憾;同时我亦不认为当前整体软件系统设计过于复杂,整个大数据生态过于冗余。IT 圈时常有人感慨,当前系统设计之臃肿、运作之复杂,实在有违“Simplicity is beauty”的原则,时常追忆当年玩 Unix Shell、翻翻 X86 中断手册,无比简约无比快感。但可惜,市场永远是对的,如果当前企业级软件市场确实需要如此复杂的软件体系、如此多样的系统生态,说明这部分理论基础以及工程实践确实需要如此复杂化、多样化。试看当今任何学科之前沿领域,无不复杂绝顶,即便同一学科不同子领域之下的职业从业者亦可能相互之间无法洞悉各自精髓。社会发展已经到如此精细化地步,不能责怪与之服务的人类知识体系。

大数据史前时代的数据处理,笔者粗略地将其划为两个时代边界:程序时代以及后续的数据库时代。

程序时代

从时间上,从计算机诞生到专业数据库发迹(不精确来说,以 IBM 关于数据库论文发表左右时间代表专业数据库诞生,同样上述时代划分并不一定科学也并非严格意义的严谨),那个时候的程序员(或者更应该称之为计算机科学家)过着普遍“轮子帮”的编码生活,即一切都需要靠手解决。这个是程序员的蛮荒时代,人人都面临着所有最基础、最原始、最重复的劳动工作,人人需要面对硬件、面对驱动,人人需要处理算法、处理数据结构;同时,这也是程序员的黄金时代,由于重复构建轮子所练就的技术内功,人人皆可为大神:随随便便读下 RFC 就可以完整实现 TCP/IP 协议栈(Bill Joy)、做个学校大作业就可以完成一个 Lex(Eric Schmidt),或者在大二在校时间写一个现代操作系统(Linus Torvalds)。不过,从商业公司角度而言我一直较为排斥重复造轮子的做法,因为大部分自研或者不客气说就是造轮子(注意,我指大部分并非全部人员,没有一棍子打死所有人),其实是对于最大化实现商业公司价值无异于缘木求鱼;而从程序员自我实现角度而言,我推荐程序员多去造造轮子,以便最大化窥览计算机最核心的知识精华。我承认,尽管在现代中国劳资双方关系还算友好,但毕竟各取所需各有利益,双方在一些底层商业逻辑上面一直有矛盾存在。

私以为,”一切程序都是对于信息(数据)的处理“应该是我们计算机处理问题的底层构建逻辑,是计算机领域放之四海而皆准的公理性断论。因此,不管是上古时代 C/S 架构的代码,抑或当前风头正紧的微服务、还是大数据中有关数据处理 Pipeline 的抽象,均是对于数据的处理抽象。不同的是视当前问题的复杂程度、抽象对象的复杂程度,我们提供了不同层次的抽象设计原则而已。程序对于数据处理的抽象最为直接最为裸奔,整个程序处理逻辑都在于对计算机硬件执行抽象,是为数据处理 Action 的抽象,是 Input->Action->Output 的抽象。该抽象对于数据的存储、数据的结构、数据的传输、数据的压缩等等均无定义,交由应用开发程序员自行安排、自行处理。这里的抽象最为原始、最为暴力,其灵活度甚高,同样其普适性亦涵盖整个计算机应用领域,无人敢说我的程序不是处理数据 / 信息的,因为整个计算机的发明即为信息 / 数据处理所服务的。因此我可以说,程序,是为(大)数据处理最为初级的抽象方式,这是大数据史前时代最为野蛮也最为普适的一个抽象。随着计算机科学以及工程的发展,我们一定会发展出更加高阶的抽象层次。

我们可以将计算机 / 程序的发展脉络简单提炼出两点,同时这两点也会指导我们讨论后续所有系统发展的一般客观规律,即:

人类社会的发展脉络之一就是社会分工,程序的抽象就是计算机科学 / 工程领域对于社会分工的计算机实践。人类社会从最早与兽无异的捕猎者,逐步进化到农业社会有君主、有祭司、有农民,然后过渡到工业社会出现厂主、工人、商人,最终演化到时至今日三百六十行隔行如隔山的分门别类职业爆发。究其原因,均源于社会发展导致的社会分工,当人类社会面向的知识领域、技能领域浩如烟海,大量职业参与者穷其一生无法精通其中寥寥数种工种和领域之时,必定将爆发出各种人类社会分工;同时由于分工导致社会合作协作加剧,不容于社会分工体系之下的个人、公司、国家必定淘汰于这个全球分工协作网络。

计算机科学 / 工程无不遵守上述社会发展大规律,当有大量底层系统构建者构建出操作系统、编译器、数据库之后,上层应用开发者仅仅需要了解底层 API 功能原理即可拼凑完整其上层业务构建。操作系统构建者抽象了硬件资源使用方式,我们必须 Follow 操作系统构建者的抽象去通过各类 System Call 完成计算资源的调用;编译器构建者抽象了业务逻辑的表达方式,我们必须 Follow 编译器构建者的抽象去使用各类程序语言和 Library 去完成业务逻辑的编排;数据库构建者抽象了数据处理的语言表达,我们必须 Follow 数据库构建者的抽象去使用 SQL/API 操作我们的数据。同理,大数据系统 / 框架在分布式计算资源之上抽象了对于数据处理的 Pattern,大数据应用开发者只能 Follow 这个抽象去做相应的大数据计算和处理。

构建底层的操作系统、数据库、中间件、大数据、AI,是社会分工的制定者,是游戏规则的设计者,是产业上游的利益分配者,他们能够定义整个 IT 商业市场的规模、玩法以及利益分配。他们可能是传统的软件服务商,例如 Microsoft、Oracl 20000 e,也可能是新型的云计算公司,例如阿里云、AWS。对于这类公司而言,未来它们(当然,得在云时代存活下来的计算服务商)会成为整个信息社会的底层构建者,未来它们会是一层不可逾越的商业基础设施。

人类文明的两大发展主线:能量和信息。人类社会一直都沿着上述两条发展主线演进,即扩大能量使用以及加速信息传播。能量的使用,从人类使用火(减少能量散失)、到发明农业

(扩大能量摄入)、到最终原子弹发明(开发更大效率的核能),所有能量发展均沿着能量的“开源节流”线发展。同时对于信息,包括文字(跨地域跨时空传播信息)、印刷术(大规模传播信息)、电报(及时传播信息)、IT 技术(大规模数字化传播信息)均在尝试最大化将信息流动起来、传播起来。

从这个角度拉看,在互联网 /IT 领域,凡是有利于信息产生、传播、处理、反馈的技术、系统、产品都将创造巨大的社会价值,进而创造巨大的财富价值。例如从个体信息传播发展来看,从互联网 1.0 时代集中式官媒发声到所谓 Web2.0 时代大量博客、微博发声,都是有利于互联网用户传播自己的信息渠道;从 Web2.0 的博客(长篇大论的文字)到微博(只言片语想到说到及时上传文字 + 图片信息)到现在抖音(传播信息量更大的视频内容)。下一代技术 / 系统,凡是有利于数据从物理世界进入信息世界(当前大量行业尚未被信息化),凡是有利于信息世界传播的均是发展热点,例如:5G(加速信息传播)、VR(更多物理世界信息化)、IOT(更多物理世界信息化)。

继续从这个角度入手,我们同样可以发掘数据系统发展趋势:凡是有利于数据(信息)产生、传播、处理、反馈的技术都可能带动整体数据系统的向前演进。例如更简单地抽象了数据处理范式(SQL)、更简单地应对互联网时代下大规模数据处理能力(MapReduce 以及其衍生系统)、AI(大数据处理后直接提交 AI 系统做市场决策)。因此,在下文我们做未来数据系统发展推演,我将不遗余力地使用该原则进行发展推演。

数据库时代

我应该把文件系统的抽象放置在数据库时代之前,毕竟文件系统的抽象同样解放了数据程序员去关注底层硬件指令和驱动的繁琐。在此,我之所以略过文件系统不在于文件系统本身重要性欠佳,文件系统抽象和操作系统抽象一样,奠定了我们今时今日整个计算机世界的工程基石。但篇幅所限,我们今天本文重点讨论数据系统,而非存储系统发展历史,我们不得不暂时省略掉不在我们讨论主线的主题。

令人称赞的数据库时代!让程序员终将摆脱直接面对硬件磁盘结构以及底层文件系统进行数据操作。可以想象,在数据库诞生之前的时代,程序员是如何面对底层存储系统结构去构建自己的应用代码,在存储要靠磁带的蛮荒时代,程序员在一个类似线性表存储中自己尝试去构建数据索引以及设计数据内容存储,并且还需要面对底层磁盘硬件操作写入方式;在接下来当提供文件系统抽象封装的操作系统之上构建各自应用时,程序员稍加解脱可基于一个成熟的文件系统而不用去直接面向磁盘操作,但终究仍需要面对设计诸如索引结构、存储结构、并发读写、失败恢复等诸多底层系统设计细节。可以想象,诸如此类基础底层的系统类软件设计和实现,绝逼难度异于常规,非大神级别参与实现不可,这将变相提升整个软件项目的复杂度以及投入成本,并最终带来项目落地以及市场商业的巨大风险。

困难往往意味着机会,越普遍越难解的困难往往蕴藏着巨大的市场机会。如前文所言,诸如操作系统、数据库、编译器之类的软件产业基础服务,投入巨大、风险巨高,非一般公司可以为之。但同理而言,一旦此类公司发布出可商用的软件版本、构建出可繁衍的软件生态,即可成就一番软件霸业。操作系统如此,看看曾经“不可一世”的微软、当前如日中天的苹果;数据库如此,瞧瞧遍大街的 Oracle“霸占”多少银行电信行业,养活多大上下市场生态。

在此,我想仅仅想讨论数据库领域两个我认为涉及到本文主旨的论点。

数据处理一次社会化的大分工

文件系统的抽象将存储进行了分工,大量开发人员不用在面对硬件和驱动读写存储,而是面向文件句柄、目录层次、读写权限,这是一个巨大的飞跃,恰到好处地将操纵硬件资源包装为一个面对有结构有层次利于操作的系列文件 API;再次,数据库将存储抽象从一个完全平面的、Bit 线性表、操作对象粒度为文件的层次再次提升到关系二维表(特指关系型数据库)、面向业务记录(数据行)、操作对象粒度细化到数据的层次。

抽象有利于业务表达,因为抽象会提供更高级别的 API(从文件 API 提升到数据 API),更有利于业务开发人员聚焦自身的业务表达;但任何事情都有 trade-off,聚焦意味着放弃,抽象反面就是泛化,文件系统作为一个存储系统设计而言具有最为广泛的市场应用价值,但同时如果要让每个业务开发人员在文件系统层面操纵结构化数据存储,必定其痛苦万分几欲自宫。因此,数据库设计人员跨出这一步,提炼出高阶数据 API 同时丢失了文件系统普适性的广阔市场。于是乎,我们在云计算行业里面可以看到,阿里云的 OSS、AWS 的 S3 仍然可能承载了云上最广泛、最庞大的数据资源(但却不一定是最有业务价值的数据,例如云计算上一个存储对象的二级制文件系统服务出现宕机,可能给用户造成的后果是短时间内该文件句柄指代的对象不可读写:可能是音乐不能播放、文档不能打开,用户可能尚且能够等待网站恢复,但一个业务关键数据库系统一旦宕机,可能造成的后果就是灾难性的:全站不可登录、不可交易,是巨大的业务故障)。因为其文件系统(当然这里是一个分布式文件系统)业务适配范围远远超出关系数据库的适配范围;同时,在阿里云 RDS 周边,我们看到了更多类似数据库的其他垂直领域数据处理系统,例如消息队列(提供流式数据读写的 API 抽象)、搜索引擎(提供全文检索服务的 API 抽象)等等等等,因为传统关系型数据库在聚焦关系代数二维模型情况下,让出其他数据存储和处理市场份额给到了其他数据系统。

 

因此,就数据处理系统而言,我一直在不停强调分工、分工、分工。原因是所有的数据存储服务、工具、引擎都在基于文件系统这个普适性的存储抽象上做垂直领域化的逻辑抽象,包括数据库、消息队列、搜索引擎,以至于到本文重点大数据处理系统。这些都是抽象,是底层逻辑构建者在定义自己的理想世界,然后让上层应用开发人员心甘情愿融入或者被屈服拉入这一层被抽想改造的”乌托邦“。抽象意味着分工,意味着独立的市场领域以及商业份额,越是底层领域普适性越高、受众面越大、收入空间越足,而越是上层领域普适性越差、受众面越小、收入空间越小、但可能利润空间不错。故而,可以想象,云计算厂商在争取到巨大的 IT 市场流量入口之后,势必逐步下沉到普适性更强领域,因此其市场领域更大、想象空间更大,因此处于垄断地位的云计算公司未来一定会大力发展诸如 CPU、GPU、IOT 甚至于各类小型机、大型机等各类计算端 + 中心设备,而上层的软件生态,包括从最为基础的 OS 直到上层 SaaS 服务,都是在为这个庞大的 IT 基础设施为带动更多的算力资源消耗之目标而服务。对于庞大如阿里云、AWS 类的云计算服务商,本质上做的是计算力生意,本质上是构建下一代计算力的全社会基础设施。

SQL 与关系代数

我有充分的理由可以说,当前 IT 领域最火热的技术已经不是数据库,或者至少不是传统关系型的数据库。当前,包括大数据、人工智能、微服务、NoSQL 各类新型技术层出不穷、屡见不鲜,以至于我时常误以为 IT 技术到了刘慈欣《三体》所言的”技术爆炸“时代。身边人所言 IT 技术更新换代之快速,非常容易造成从业人员跟不上节奏,不无道理。从另外角度而言,不叫卖的技术要么早已技术基石、人人皆知,要么濒临淘汰、昨日黄花。诚然,关系型数据库绝非当红炸子鸡,但其技术影响力绝非后者,而恰恰相反早已经是整个计算机科学和工程的基石。犹如计算机科学领域的操作系统,当前已经没有任何太多新颖故事可讲。犹记得我在大学时间正值中国互联网大爆发的时代,LAMP 架构风头正劲无出其右,因此有关 Linux/Unix 的网站、教材、博客如投机创业一般地争风口要上市。而时至今日,有关 Linux/Unix 的材料早已烂大街再无人作为市场亮点宣传,而风头正紧的乃是大数据、人工智能、Kubernetes、Docker 等各类技术噱头。每每看到这些满大街的网红技术,想想当年 LAMP 培训宣传的如日中天,感叹其实技术圈和网红圈本质上没有太多差别,追一个流量网红和追一个“噱头技术”其实相差无几。

数据库技术已成计算机基石,早已度过当年求曝光要宣传的流量小生时代。但不可否认,整个数据库技术为后续数据处理带来了大量基础科学理论以及工程实践。大量数据库理论论文、工程代码在后续的大数据、中间件领域中被大量借鉴、拷贝、甚至于”抄袭“。特别是关系型数据库有关数据处理模型的抽象:理论是关系代数、工程是 SQL 查询语言。

虽然说,数据库模型的历史虽然不是起源于关系型模型,但必须得说关系型数据库曾统一了所有的数据库模型,并一直统治至今。 关系型模型进入人们视野的具体时间是 E.F.Codd 在 1970 年发表的论文: “A Relational Model of Data for Large Data Bank”。很多人对关系型数据模型的印象是表和字段,并还能想到的是表与表之间通过某些字段可以关联起来。似乎正因为这样,关系型数据库才被冠于这个名字。 然而关系型数据模型中的“关系”在英文中对应的单词“Relation”是一个抽象的数学概念,它既不是独指 2 个表之间的关系,也不等价于一个二维表(虽然习惯于以二维表来表示)。 数学中关于 Relation 的定义是这样的:给定 n 个集合 S1、S2、 S3、 …、 Sn, R 是一个 n 元数组 (n-tuples),它的第一个元素取自集合 S1,第二个元素取自集合 S2,以此类推。我们将 R 称之为基于该 n 个集合的一个 Relation,Sj 为 R 的第 j 个域 (Domain)。

另外一个值得大书特书的就是 SQL,即结构化查询语言 (Structured Query Language)。笔者是个产品经理,相较之如谈论如同白开水一般的计算机科学理论例如上文的关系代数,非我等产品经理兴趣所在;我们更加关注我们的产品接口(Interface),这层接口可为 UI、同样亦可为 API,而上述 SQL 即为关系代数理论之上用来方便构建用户和系统交互的恰当方式。相比较于用户之前使用硬件接口 / 驱动直接操纵数据读写存储空间,以及后续稍显友好文件系统读写接口,SQL 给应用开发者提供的 API 是令人震撼的,SQL 本质是声明性语言,它告诉计算机我们想要什么(What),而非执行步骤(How)。从抽象程度而言,What 的命令通常要比 How 的命令在描述问题抽象程度更有利于业务沟通,试想“我想成功约到一个漂亮小姐姐”类似愿望的表达,始终会比”我打算去健身,同时在园区物色一个漂亮小姐姐,天天请吃西餐 + 看电影,持续一个月,看看对方反馈效果“的计划显得更加贴近男人的内心表达。如此,不恰当地说,前者就是声明式语言,后者就是命令式语言。同理,对于声明式语言,其业务抽象程度较之命令式更高,笔者作为产品经理非常能够理解 SQL 设计者意欲将关系代数理论以及数据存储处理的工程都使用 SQL 语言进行封装,同时我亦承认,SQL 在统一数据抽象层方面意义巨大。但,理论总归完美,现实总有残缺,相比于工程而言,大量工程业务细节不一定能够完全用理论 Hold,例如在某些极端情况下,一段 SQL 语句往往在成本和产出之间无法达到最优,往往需要专业 DBA 设定特殊的 Hint 往往才能够提升数据库查询性能。毕竟,现实数据情况多种多样,预制的专家规则无法一一穷举,只能靠具体的 DBA 专家进行特殊性能调优。未来,对于程序处理的优化,我们认为每个系统都会有类似 AlphaGo 一样的 AI Daemo,时时刻刻在学习当前的数据特征以及程序处理情况,进而进行深入的、定制化的个性化优化。

在本小节的结束时间,我们附上有关数据库发展 Timeline,希望数据库的发展路线给大家看到整个数据库发展时间脉络 [注 2]。

大数据开发技术群:957205962

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: