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的数据量，是挺大的了。