Google的一些工具/技术栈整理

=Start=

缘由:

前段时间在朋友圈看到了「一图了解Google工具栈」一文,学到了很多,再想起之前在学习大数据时了解到的Google三驾马车(GFS、MapReduce、BigTable),所以想着整理一下(我知道或了解的)Google公开的一些paper以及基于此的开源/商业替代方案。

正文:

参考解答:

HDFS(Hadoop分布式文件系统)
源自Google的 GFS 论文,发表于2003年10月,HDFS是 GFS 克隆版。

MapReduce(分布式计算框架)
源自Google的 MapReduce 论文,发表于2004年12月,Hadoop MapReduce是 Google MapReduce 克隆版。

HBase(分布式列式kv数据库)
源自Google的 Bigtable 论文,发表于2006年11月,HBase是 Google Bigtable 克隆版。

Zookeeper(分布式协作服务)
源自Google的 Chubby 论文,发表于2006年11月,Zookeeper是 Chubby 克隆版。

Dapper(大规模分布式系统的跟踪系统)
源自Google的 Dapper 论文,当前流行的有 Pinpoint/SkyWalking/Zipkin/CAT 等。

TiDB(一种可横向扩容且具备强一致性的关系型数据库服务)
源自Google的 Spanner 论文,当前流行的有 TiDB/Vitess/CockroachDB 等。

Drill(“交互式”大数据分析系统)
源自Google的 Dremel 论文,当前流行的有 Apache Drill/Presto 等。

Kubernetes(容器编排、集群管理系统)
源自Google的 Borg ,当前流行的有 Kubernetes/Mesos 等。

==

The Google File System
https://ai.google/research/pubs/pub51

MapReduce: Simplified Data Processing on Large Clusters
https://ai.google/research/pubs/pub62
MapReduce: The programming model and practice
https://ai.google/research/pubs/pub36249

Bigtable: A Distributed Storage System for Structured Data
https://ai.google/research/pubs/pub27898

The Chubby lock service for loosely-coupled distributed systems
https://ai.google/research/pubs/pub27897

Dapper, a Large-Scale Distributed Systems Tracing Infrastructure
https://ai.google/research/pubs/pub36356

Spanner: Google’s Globally-Distributed Database
https://ai.google/research/pubs/pub39966

Dremel
http://research.google.com/pubs/pub36632.html

Borg, Omega, and Kubernetes
https://ai.google/research/pubs/pub44843

==

# Dapper
回到网易后开源 APM 技术选型与实战
https://www.infoq.cn/article/apm-Pinpoint-practice

Dapper,大规模分布式系统的跟踪系统
https://bigbully.github.io/Dapper-translation/

几种分布式调用链监控组件的实践与比较(一)实践
https://juejin.im/post/5a0579e6f265da4326524f0f

有什么知名的开源apm(Application Performance Management)工具吗?
https://www.zhihu.com/question/27994350

==

# Spanner(一种可横向扩容且具备强一致性的关系型数据库服务)
https://research.google.com/archive/spanner-osdi2012.pdf
https://cloud.google.com/spanner/

如何看待Google的Cloud Spanner?
https://www.zhihu.com/question/55828060

==

Google的 Borg 和 Kubernetes 的不同

 

参考链接:

=END=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/4379.html

《Google的一些工具/技术栈整理》上有1条评论

  1. 从TDengine的开源说起技术选型
    https://mp.weixin.qq.com/s/Mn5hWmiNhBIFW_Im29jUWA
    https://github.com/taosdata/TDengine

    如果一艘快艇足够承载下你的所有货物到达彼岸,那么你不需要使用一艘轮船出行。产品设计和技术选型也是一样,我们经常会说:“我需要一个能够处理百万规模并发读写操作的,低延时,高可用的系统。” 如果按照这样的需求去设计系统,你可能得到的是一个设计复杂,代价昂贵的通用方案。但是如果仔细分析一下需求,你可能省略了需求背后的一些前提条件,比如真实的需求可能是这样的:“我需要一个能够处理百万规模的并发(只是理论峰值,平均情况小于10万并发)读写操作(读写比例1:9,只有追加写,没有修改操作)的低延时,高可用的(可以接受一定程度数据不一致性的)系统。” 那么你可能可以为这个特定的需求设计一个简单的,高效又低成本的系统。

    做技术选型时,我们不会单纯的说A方案比B方案好,只是在解决特定的问题上,A方案比B方案更合适,选择了A方案的同时也意味着接受A方案里那些不如B方案的地方。在特定领域问题上的优化和定制方案往往能够取胜于解决更多领域问题的通用方案。

    在TDengine的官网文档上我们可以了解到这是一个针对IOT领域数据特性优化的强大的大数据计算平台。最近花了一些时间去熟悉这个开源项目的文档和代码,聊聊在做IOT时序数据库这方面的技术选型时使用TDengine或者其他产品一些可能需要考虑的点。

    版本的选择
    开源协议的考虑
    数据的删改支持
    Insert 与 Import
    数据的一致性
    Everything is about tradeoff

    TDengine在物联网的场景下以牺牲部分功能支持的代价换来了超过10倍的性能提升。区别于其他时序数据库底层使用基于树的存储引擎数据结构(InfluxDB使用Time-Structured Merge Tree),TDengine基于顺序表结构的存储,追加写的插入,二分查找的查询,结构化的定长数据,预计算的聚合结果等优化大大提升了时序数据存储的读写性能。当前完整的TDengine开源代码近13w行,本文仅选取了项目的若干点进行探讨,TDengine在工程方面也有不少值得借鉴的地方。

    在商业模式上,TDengine 选择了与InfluxDB同样的开源单机版,销售集群版的路线,作为国内少有的热门开源项目(github开源一周近5千Star)后续发展值得关注。

发表评论

电子邮件地址不会被公开。 必填项已用*标注