聊聊大数据的前生今生

前段时间一直忙于跳槽，最近终于是把新工作的事情定下来了，也即将离开做了四年的大数据方向，在此写篇文章来作为这几年工作的总结和一些对技术的感悟，希望可以帮地里做同样方向的朋友们。更重要的是楼主玩了五六年一亩三分地，现在大米都不够看面经，希望各位如果觉得有帮助的话求给点米。



先来介绍下个人背景，我是先做微服务，后来干了两年之后发现写业务很无聊就萌生了去做数据方向，于是跳到了一个传统公司去做数据平台，在这边干了几年也算是小有成就。我个人认为，很多技术的出现和发扬光大其实都和时代的context有关，但是当技术成为主流之后很有可能context已经不存在了，而很多没有context的后进者可能并不了解这项技术为什么出现，为什么被发扬光大，所以了解一项技术的历史是非常重要的。所以接下来我把这篇文章分成三个部分，过去，现在和未来，希望可以说清楚我们现在使用技术栈的前因后果，以及个人对于行业未来的一点预测。总的来说，我觉得可以用两句话来形容：”合久必分，分久必合”， “历史都是螺旋上升的”。
一些背景：
鉴于很多读者朋友不是专门做我这个方向的，我在这里先列出一些技术名词和他们的大意。
大数据：这篇文章中的大数据是狭义的大规模数据分析和数据仓库，商业目标是给通过聚合的方式为公司决策做支持，技术上一般是跑类似于 select count(*) as dau from user where login_dt > xxx 这样的query。
OLTP：狭义指对事务处理优化过的数据库，比如mysql，postgre，广义可以是你的业务系统
OLAP：指对分析处理优化过的数据库，比如bigquery，redshift，广义可以是你的分析系统
ETL：即Extract， Transform，Load，意思是把数据从OLTP拿出来，对数据做一些操作，把数据放到OLAP中去
过去：
“大数据” 这个名词大概出现在199x，不过这个名词真正广为人知还是因为2004-2008年谷歌发的三篇论文(GFS, Mapreduce, Bigtable)。那么在这之前，难道其他公司就都不做大规模数据分析了么？那显然不是这样的，我们先来回顾一下2004之前的历史，看看没有谷三篇之前的世界。
1960-1980：信息化刚刚开始的世界
在这个时代，计算机刚刚从研究所里拿出来被各大公司用来做数据处理，在这个时代我们熟悉的FLAG还没有创立，当时还是通用福特天下无敌的世界，最像FLAG的是现在已经被排除出科技公司的AT&T。那个时候只有这些大型工业公司才有大规模数据处理的需求，这个时候计算机还是很fancy的技术，大多数公司并没有认识到信息化的价值，纯粹的IT公司并没有那么多。这个时代绝大多数的数据管理系统都是工业公司做的，比如通用的IDS（网状数据模型），IBM的IMS（层级数据模型）以及70年代的Ingres，oracle（关系型模型）。
这个年代
从数据模型的角度来看
网状数据模型把所有的数据看作一个多对多的图，所以表示many-to-many relationship非常方便
层次数据模型把数据看作一个树状的结构，所以表示文档非常方便
关系型就不说了，大家都懂
硬件的角度来看
在那个时候，因为摩尔定律非常有效，再加上软件硬件并没有分家，而且网络这个东西刚刚出现，原则上是不存在我们现在熟悉的依赖网络的”分布式系统”的，所以那个时候各家的优化都focus在scale up上面，于是也就出现了大型机和各种database computer，即为某种程序特殊优化的硬件系统，在这个时候并没有我们上面说的OLTP OLAP，只有数据库。因为数据量都还很小，增长速度还没有超过摩尔定律，所以一个数据库可以包打天下。换句话来说，这个时代所有的数据库都是HTAP
从算力的角度来看
在这个时间段，个人PC基本等于零，绝大多数算力都集中在政府和大公司手里，而绝大数的软件设计都是性能为主，易用性为辅，
1980-2000: 数据增长开始超过摩尔定律的世界
随着信息高速公路的疯狂建设，各大企业都对信息化的需求越来越大，我想那个时候的信息化大概和现在的上云一样，是属于非常火热的项目。同时科学家们也发现了一个问题，即数据的增量远大于摩尔定律带来的硬件性能（硬件性能每18个月X2，数据量每年增加数倍）。这意味着总有一天这种传统的scale up方式终归无法处理天量的数据，为了解决这个问题，数据库行业有了那个著名的问题，can one size fit all？
One size fit all 的意思是，是否存在一个数据库/数据处理软件可以满足用户所有的需求？在1980年的时候，绝大多数的数据库vendor的答案是YES。那个时候绝大多数公司也并不太注重跨业务线的分析，或者说信息化只是把所有的流程搬上电脑，但公司的整体架构和决策模式还没有真正的信息化。随着时间到了1990年初，越来越多的公司开始重视起了商业智能（business intelligent），这也就意味着他们需要做很多跨业务的分析，而这在按业务分库的系统里面却并不容易。（是的，分库分表从那个时候就已经存在了）所以，越来越多的企业有了数据仓库（data warehouse）的需求。
数据仓库：数仓和我们之前所说的数据库在逻辑上是有着本质区别的，通常情况下数据仓库里应该存放了该公司所有系统的全量历史数据，而数据库里面则只放着当前有效的数据。但从物理实现角度来讲，两者都可以用关系型数据库来实现。
在这种情况下，我们会发现数据仓库的容量可能百倍，千倍于数据库，而数据的access pattern也有很大的区别，在常规数据库中，通常的access pattern是以单行操作为主，比如update xx set x=y 或者select * from x where id = y这种类型，而BI或者说数据仓库的access pattern则是以列为主，跑的query 类似于 select sum(x) from y 这类的query。所以这个时候，database vendor们发现one size may not fit all。于是我们有了第一次合久必分，传统数据库被分成了OLAP和OLTP。同时，也出现了ETL工程师这种职位。
这个年代
从数据模型的角度来看
基本上关系型模型一统天下，网状数据模型和层级数据模型成为了时代的眼泪。我们也第一次看到了分久必合。但是我们也看到了在OLAP出现之后，数据的建模方式也有了更新，虽然业界依旧使用关系型模型，但是却并不遵循那些所谓的normal form，而是使用了snowflake schema这种反范式建模
从硬件的角度来看
这个时代数据处理遇到了理论上的性能压力，单一CPU并不能真正解决性能问题，所以无论是业界还是学界都把眼光投向了”分布式系统”，同时也出现了SMP，MPP这种架构。
SMP：是一种多CPU架构，所有的CPU分享所有的内存和IO，简单的来说就是硬件版的share disk
MPP：也是一种多CPU架构，每个CPU有自己独享的内存和IO，简单的来说就是硬件版的share nothing
从算力的角度来看
大部分算力还是被大公司所垄断，但是这个时候商业级硬件已经铺开，个人电脑也是如火如荼，再加上电子表格比如excel的普及，很多计算被从大型机拿到了本地计算，我们可以看到算力已经有了分散的趋势
从商业的角度来看
这是第一批数据分析公司创业的时候，现在被认为老土的公司比如oracle，micro strategy还是小鲜肉，但我们今天主要是讲OLAP，所以我们的主角是Teradata
Teradata 创立于1979年的加州，是由当时加利福尼亚理工的教授和citibank的数据分析组联合创立的。换句话来说，他是这个年代的的databricks，直到今天还有着很多传统公司在用着他们的系统。Teradata在1992年就为walmart提供了1TB级别的分析型数据库。在1999年，Terdata最大的分析型数据库已经超过了130TB，这个数据量级即使是在今天也不算小了，但是Teradata在20多年前就已经做到了分钟级的分析。
Teradata的收入主要是来源于以下几个方面：卖软硬协作的系统，卖数据模型（比如各种financial service data model），卖各种咨询服务，在这个年代，无疑是科技公司中的当红炸子鸡。
2000-2010: 大数据的兴起
前面我们大多都在聊历史，这一节因为和我们现在用的技术比较接近了，技术类的东西会多一些。
毫无疑问这段时间是整个Hadoop体系兴起的世界，自从谷三篇发了之后，业界很明显对于这些技术非常激动，于是来自雅虎的工程师把谷三篇重新实现为了我们耳熟能详的Hadoop。但是在这个时间段，学术界对于这些系统的看法却和业界有一些分歧，其中比较有名的一篇文章叫做Mapreduce，a big step backward。抨击Mapreduce的人有很多，但之所以拿出这篇文章来说，是因为他的作者是数据库巨擘，图灵奖得主，ingress，postgres，vertica，voltdb，streambase之父，Michael stonebreaker。他的各种称号大概和龙妈一样，在这里一页都写不完。但我们今天主要来看看他这篇文章到底写了啥，这篇文章大概提到了以下五个观点。
MR并没有像数据库一样，使用结构性描述（即数据要有schema这种东西），把结构性描述和处理逻辑分离（即用数据库中的表一类的抽象代替本身的数据结构），使用高级的描述性语言（要写SQL不要写Code）
MR的实现非常poor，并没有索引帮助加速，没有sharding会出现数据倾斜，多个reducer从mapper中pull数据会有一些IO问题
MR的idea我们学术界20年前已经玩过啦
MR和db比差了很多feature啦，比如批量导入，索引，事务，约束。。。
MR和现在所有的db相关的工具都不兼容啦（不支持sql肯定的嘛）
说到底，这篇文章与其说是说MR有多烂，不如说是MR和数据库的解决方法有哪些区别，那么MR和数据库的解决方案到底有啥区别呢，我们还是先来看看一个基本的数据库是如何工作的吧
数据库有一个server，他负责从client手中拿到请求和SQL
数据库有一个parser，他负责把拿到的SQL解析，并变成一个执行计划
数据库有一个optimizer，他负责把执行计划进行优化
数据库有一个executor，他负责把执行计划变成真正的code logic(比如for loop)去运行
数据库有一个bufferpoll，他负责数据的缓存，executor会从这里拿数据去跑
数据库有一个transaction manager，他负责处理数据库的事务逻辑，executor会从这里去做MVCC一类的东西
数据库有一个lock manger，他负责处理事务中的锁相关的东西，并发的executor会在这里竞争锁
数据库有一个WAL，他负责把executor处理的日志写到硬盘，方便来做recovery
数据库有特殊的文件layout，bufferpool会从这些文件中拿到executor需要的数据
那么做一个简单的对比，我们就可以知道MR事实上只是数据库的executor而已，只是这里的执行计划需要我们手动去写，而且需要满足MR的接口。而MR的优势就是他是分布式的，可以简单地scale out，所以拿MR和database来做比较，可能未必公平。
所以，以2008年的眼光来看，Michael大佬的一些看法显然过于守旧，充斥着一副“旧时代的残党”+谷歌捞过界的感觉。
但工业界很显然接受了Hadoop这一套东西并且把它发扬光大了，那为什么一套非常完善的解决方案（MPP数据库）反而在这段时间被刚刚兴起的MR暴打呢？原因很简单，就是便宜。以上文的Teradata为例，他家的数据库收费，首先是按CPU核心收license（一个核心一年小几十万），再加上需要额外的硬件成本（EMC点了一百个赞），而且还需要特制的机房来放这些Database computer，需要数个额外的组来维护这些硬件，需要用Teradata家特制的数据模型（也要钱的哦），出了什么问题还需要TD的咨询部门来处理（一小时大几百刀哦）。所以在那个年代，维护这样一套系统是非常昂贵的，随便维护费用就可以一年破kw。对于传统企业来说，因为能替代他家的产品真的不多，再加上自身的数据属于高价值低数量的类型，咬咬牙，也是可以买上这一套系统的。 但是谁叫这段时间出现了很多互联网企业，传统企业做的东西再怎么小，一般来说一条数据所对应的business也有个几十块，而互联网企业则是完全不同，像谷歌这种企业，平均下来一条数据估计能有个1分钱就谢天谢地了，那在这种情况下，维护这套系统交的钱估计比他的利润都多，自然互联网企业不愿意去用这些解决方案。
但就像我们上面所说的，MR最初只是一个MPP的廉价替代品，也只是一个executor而已，如果长期让昂贵的工程师来写MR代码，很显然只是把cost从咨询挪到了人力上面，生产力并没有得到大幅度的提升，所以那个年代的工程师遇事不决就开始造轮子。
所以我们就有了这些东西
分布式lock manger – zookeeper（2008）
分布式的parser + optimizer + schema management– pig（2006） Hive(2010)
特制的文件layout avro(2009)
这个年代
从数据模型上来看：
关系型模型显然依旧占据着王者的地位，但是我们也看到了层次性模型和网状模型的复活（Nosql，Mongodb），Nosql搞的如火如荼，想要用json击败关系型模型，07年诞生的Neo4j则宣布额网状模型的回归。我们可以看到数据模型又开始合久必分了。究其原因还是因为事务侧没有一个分布式的关系型数据库，再加上互联网企业未必需要严格的数据模型。
从硬件的角度来看
这是一个网速大跃进的年代，网络的发展使得我们现在所使用的基于网络的分布式系统得以大规模部署，并且取得了非常好的效果。但是这个阶段，整体思想还是使用商业级X86服务器去替代曾经的大型机，很明显对于软硬结合设计不是一个好年头
从算力的角度来看
这个年代，个人PC已经大规模普及，再加上互联网企业越来越多，大家都在自建DC，很明显算力更分散了
从商业角度来看
分布式系统的普及带来了新的商机，传统企业因为数据量的原因也越来越多的遇到了性价比问题，也开始对大数据计算有着自己的需求。所以Cloudra出现了，试图商业化Hadoop全家桶并挑战传统的Teradata。也是在这个时间，amazon中一个叫aws的部门也默默的成立了，试图用虚拟化技术来让传统企业外包数据中心。而db方向也没有闲着，东岸的Michael大佬在05年发布了C-store（即Vertica）使得MPP数据库也可以在商业化硬件上跑，而通过列式的储存引擎，可以随意做到秒级的数据分析，性能大概是MR的百倍。而西岸的伯克利，一个叫Matei的博士生则做了一个有趣的project， spark。不得不说，我们今天还在使用的系统，多半都可以追溯到这段时间，这段时间基本上是大数据infra的黄金时代。
2010-2022： 大数据的成熟期
从技术上来看，我们可以看到业界提出了对大数据的最终需求其实就是做高效的addhoc query。那么在此之下，又出现了新的技术，即以storm为例的流式引擎和presto为例的高速查询引擎。那么，为什么我们在有spark，MR这种计算引擎的时候还需要这两种新的东西呢？ 一个原因是，因为很多时候数据的实时性要求会很高，尤其是比如要做实时topk这种计算的时候，spark，MR这种基于批处理的效果并不是非常好。还有一个原因是，MPP架构先天对于查询就有一定的优势。原因很简单，MPP数据库整体是一个储存计算高度耦合的架构。这意味着在MPP数据库里面执行query并不需要一开始就shuffle到计算节点，而是尽可能的先在本地计算之后在进行聚合shuffle等操作，因为计算层对储存层的感知非常好，所以MPP的性能通常情况下都会比MR要好。而Presto则借用了MPP架构，再加上他并不奢求计算完所有的数据，而是只要算个大概就行，那么P99一定也是比MR这种batch process要好得多
于是，我们把传统的数据操作拆成了三种不同的情况，也就有了lambda，kappa之分
大批量数据的ETL操作 - Spark Hive MR
快速进行数据分析 - Presto Impala
流式计算数据 - Storm Flink
但，仅仅是几年后，谷歌的一本dataflow证明了流计算和批计算本质上是一个东西，流就是微批，批就是有界流，dataflow带来了apache beam，统一了计算模型的同时也使spark和flink开始进攻对方的市场。
同时，我们又看到了更多有趣的项目
分布式的buffer pool – Alluxio
分布式的WAL - Kafka Flume
分布式的transaction manager – Hudi Iceberg
这个年代
从数据模型上来看：
关系型模型已经吃掉了文档模型，基本所有的关系型数据库都支持Json了，那么定义一个json column本质上和一个column family已经没啥区别，所以这两个模型已经合二为一了，而图模型最近却是慢慢地火了起来，目前还没有看到这两个模型融合的迹象，但是我相信关系型模型也可以通过图储存引擎来解决这个问题
从硬件的角度来看
们可以看到很多新硬件因为无法平衡企业级和商业级市场而最终被砍（optane），感觉在这段时间对于 hardware software codesign是一个不太友好的时期。而随着NVME的普及，这个时代的IOPS已经不再是困扰数据处理的问题了，反而压力来到了CPU上，但可惜的是VM上的语言都会有一定的CPU overhead，随着摩尔定律的终结，这会意味着C++这种zero cost abstraction语言的复苏么？
从算力的角度来看
随着云计算的发展，越来越多地公司放弃了自己的DC而选择租用云服务供应商的DC，我们可以很明显的看到算力再一次聚集到了大公司手中，我觉得这也意味着软硬协作的日子回来了
从商业的角度来看
这是一个竞争的年代，也是技术成熟的年代，随着越来越多的企业遇到了性价比问题，越来越多的非IT企业开始讨论大数据，咨询公司们也在制作着各种“大数据解决方案”，由此带来的则是各个公司之间的明争暗斗。随着Yahoo的衰落，Yahoo把自己的Hadoop团队拆了出来变成了Hortonworks，再加上MapR，成为了Hadoop市场三巨头。这三家的商业模式都是以开源为基准，然后为Hadoop增加更多的易用性，然后卖产品给其他公司。这几家公司在Hadoop火的时候也是打的不可开交，然而却忽视了身后的Databricks和AWS。很显然，AWS这种saas的方式对于用户来说更为友好，用户不需要自己建DC就可以直接搞一个集群来，相当于AWS垄断了用户的流量。而这个时候Hadoop三巨头还在互相掐技术，殊不知不拥抱云计算，自己的脖子都被掐住了。而随着三巨头在主推Hive的时候，西岸的Matei带着他的spark做起了databrickes。不得不说，Spark RDD的计算模型相比于MR来说有着很大的提升，再加上同时支持了非结构化的dataframe api和结构化的sql接口，而更重要的是spark还可以在某种程度上兼容Hive，再加上databricks拥抱云的更早，于是成为了最后的赢家。而与此同时，MPP界的新秀snowflakes也靠着云原生站稳了脚跟，回过头来，不得不说云计算是一场革命，凡是拥抱云计算的，都活的美滋滋，继续和传统dc一起玩的，基本都活的不太舒服。
2022-*
.google  и一点点比较crazy的看法，如果没中就当无事发生233333
我觉得，big data这20年做了一件事情，把一个数据库拆成不同的模块，然后每个模块做了一个分布式的版本。而且现在看来没有什么别的部件可以拿来在做了，那么我预测someone会把上面的这些东西拼起来拼成一个 有ACID 支持SQL 对用户友好 支持所有数据处理类型，各个组件可以scale out的数据处理系统。根据鸭式辨别法，这是一个每个组件都可以自由伸缩的数据库
我觉得，随着云计算的发展，算力会越来越多地集中在云厂商手里，同时会带来更多的hardware software codesign的机会，我们有生之年可能可以看到一些大型机的技术在DC里面复活
我觉得，现在的HTAP不会取代现在OLAP的生态位，而是有可能OLAP会把一部分analytics job offload 到HTAP的列式计算引擎上，以提升ETL的性能

ucfgut 发表于 2022-08-15 08:59:18
大佬水平很高。
Mpp 比spark 厉害那么多 为啥databricks 还没死呢

因为贵啊，而且未必厉害多少。个人觉得databricks的完全体就是我说的  一个看起来和MPP很像，但是每个组件都可以自己scale的系统，他们多半会叫什么数据平台，但是根据鸭子辨别法，我觉得就是重新发明了db

具体到系统设计其实两边都有在拿对方的一些东西来用。比如td的atlas号称spark+mr+mpp 啥都有。而且做这些系统的人也是一波人。再加上MPP在各种试图支持semi structure，DB也是很早就有了自己的SQL引擎。本质上他们要解决的问题时是类似的，只是出发点不同

具体到实现层面上感觉还是那些老几样 SIMD，code generation，云原生，etc 用的技术都是一样的的，就看谁的算法写得好，或者说储存层对计算层的感知更强呗。



补充内容 (2022-08-16 00:31 +08:00):
突然想到MPPvsDatalake有点类似于买苹果整机vs自己攒电脑。买整机除了贵和硬件选择不自主都是优点，自己攒电脑则是可以根据自己的需要选配硬件，以及更加低廉的成本。

daydreamerlee 发表于 2022-08-15 10:54:42
感谢大佬的分享！打通了这些名词上关联
可以请楼主在分享一些对下面问题的看法么。
1. Data-lake vs data-warehouse: data-lake 的起源和 context， 应用

不是大佬，只是个人看法

1. datalake不就是分布式储存引擎+分布式计算引擎+别的吗，我下面说的那种每个组件都可以scale的未来数据库不就是datalake嘛，广义上的data warehouse就是跨产品线的历史数据分析系统，从这个角度来说 datalake可以算是data warehouse的一个实现吧。狭义上来说data warehouse一般是snowflake这种数据库

2. 个人对于non determinisyic的算法不是很感兴趣【被调参各种折磨】，对这些不太懂

3. 我觉得tidb spanner广义上可以算MPP架构 aurora可以说是SMP 但是因为这俩词一般用在OlAP side，所以做OLTP的不会去提。HTAP是指又能做分析 又能做事务。那么 tidb 和f1/spanner应该都算htap

4. 不要把OLTP和OLAP做对比，他们用于不同的场景。没有人用snowflake当application的后端。也没有人用aurora做数据仓库。 snowflake和db上面已经说了。我觉得spanner和aurora的区别其实还是在于成本，毕竟spanner要做的是跨大州级别的强一致性，虽然听起来很美，但是有几家公司有这个需求？而aurora这种share disk+兼容主流数据库的方式反而更加容易migrate+足够便宜。所以说技术上spanner是很强的，但商业上aurora绝对更有优势。

daydreamerlee 发表于 2022-08-15 11:43:58
感谢！
第二个问题其实是想问
-  支撑 ML training 的海量数据，现在都在用什么类型的数据库 （或 warehouse ）进行管理。

对ML不是很了解。但就我了解的来看因为OLAP要做额外的denormalization schema design 所以很多数据不处理并不适合于ML。很多产品focus的DS应该会更喜欢用ODS中的数据。所以有的企业现在的做法是数据从数据源拿到 s3这种地方做ods 再放到MPP里面的denormalize schema里面。而DS会更倾向于从ODS层拿数据用spark这种计算框架来算

礼貌询问楼主 感觉根据楼主的描述 大数据前景还是挺好的 楼主是跳槽了那个方向呀？

抢个沙发 硬核知识 谢谢楼主

写的太好了

仔细看完了 写的很棒！

给大佬加分

先加米再看 lz请继续

写的很通透，膜拜大佬

very nice!!!

大佬水平很高。
Mpp 比spark 厉害那么多 为啥databricks 还没死呢