Google和Linkedin的老司机是如何管理海量数据的

0x00 前言

本篇分享是元数据管理的内容,主要参考Google在2016年发布的论文《Goods: Organizing Google’s Datasets》以及 Linkedin在2016年新开源的项目:WhereHows,当然也有笔者的一点理解。

Google的论文整体描述十分详细,可以作为理论来学习,LinkedIn已经开源了一个版本的系统,可以看成最佳实践。两者结合起来,还是很能拓展思路的。

标题有点吸引人眼球的嫌疑,不过内容的确是从这两个大公司对外公布的技术中学到的(掺入不少自己的理解,不是原味的了)。

不太清楚Google和Linkedin真实的系统做成什么样,是不是像Gfs那样自己已经要淘汰了才发表文章出来。 不过这个不重要。只要能学到一些新东西就行了。

本文没有具体的实现,只有各种的设计思想。另外,其它数据仓库相关的文章请参考:文章集合

本文讲什么?

本文会围绕Goods来展开,辅助与LinkedIn的WhereHows和笔者的理解。

先整体说明一下Goods是什么?可以这样理解:

Google的数据表太多了,工程师们会生产出很多的数据表,为了更好地管理和复用这些表,Google做了一个数据管理系统

这个系统是一个开放的系统,它会通过类似爬虫的方式定时从各个系统(Hive、Hbase、Mysql)中抓取元数据信息然后存入系统中。并生产表之间的依赖关系。

他和EDM的不同在于,它是来爬各个系统的元数据,然后来汇总。这点很重要,属于一种事后处理。给了工程师更大的开放性。

文章结构

从我的感觉上来讲,元数据系统最经常被质疑的地方有两个:价值和作用。为了突出这两者的重要性,我会单独着重地写。

  1. 为什么。元数据系统的价值;
  2. 是什么。元数据系统相关的概念;
  3. 怎么做。分享一下Google的论文《Goods: Organizing Google’s Datasets》中的内容,只有部分内容;
  4. 怎么做。分享一下Linkedin的新开源的项目WhereHows的一些设计。
  5. 补充。笔者的一些想法。

0x01 价值何在?

挑战

元数据的存在有它的必要性,我大致做了一个简单的梳理,列出一些和数据相关的挑战。这些其实也是元数据系统的价值所在。

数据问题

如果业务复杂度比较低或者数据量比较小的话,可能就感触不深,不过在Google这种公司来讲,表的数量之大,光是管理表的元数据系统就要做成分布式的。

看一下Google的数据量,是挺大的了。

你可能感兴趣的:(大数据,漫谈大数据,数据管理,linkedin,海量数据,谷歌)