ASPIRE

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=

Docker

, ,
, , ,

《 “Google的一些工具/技术栈整理” 》 有 7 条评论

  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）后续发展值得关注。
    `

    回复

  5. Google安全性白皮书
    https://cloud.google.com/security/overview/whitepaper?hl=zh-cn
    `
    * 简介
    * Google 的安全文化
    ____* 员工背景调查
    ____* 针对所有员工的安全培训
    ____* 内部安全和隐私活动
    ____* 我们的专门安全团队
    ____* 我们专门的隐私权团队
    ____* 内部审核和合规性专家
    ____* 与安全研究社区的协作
    * 运营安全
    ____* 漏洞管理
    ____* 阻止恶意软件
    ____* 监控
    ____* 事件管理
    * 以安全为核心的技术
    ____* 先进的数据中心
    ____* 服务器定制硬件和软件
    ____* 硬件跟踪和处理
    ____* 具有独特安全优势的全球网络
    ____* 保护传输中的数据的安全
    ____* 低延迟和高可用性解决方案
    ____* 服务可用性
    * 独立的第三方认证
    * 数据使用情况
    ____* 我们的理念
    * 数据访问权限和限制
    ____* 管理员权限
    ____* 客户管理员权限
    ____* 执法数据要求
    ____* 第三方供应商
    * 法规遵从
    * 总结
    `

    回复

  6. Kubernetes这么香，为什么谷歌还坚持使用Borg？
    https://mp.weixin.qq.com/s/HE0i8-Cj7RZyYDt2fdH7FA
    `
    上周，在 Kubecon 欧洲在线虚拟大会上，Kubernetes 的两位早期开发者 Brendan Burns 和 Tim Hockin 针对大家的提问“谷歌会不会从 Borg 迁移到 Kubernetes”进行了回复。

    作为谷歌开源的容器集群管理系统，Kubernetes 建立在谷歌内部的 Borg 技术之上。发展到今天，Kubernetes 的规模已经变得非常庞大，它被认为是计算基础设施的未来，与虚拟机一脉相承，就像虚拟机取代裸机成为计算部署的最常见单元一样，尤其是在云环境中。

    作为业界最主流的容器技术，谷歌会不会考虑迁移到 Kubernetes 呢？

    Hockin 表示，“Kubernetes 和 Borg 在思想上非常相似，但在细节上有很大的不同。Borg 没有像 Kubernetes 那样的网络模型。Borg 应用程序是为了在 Borg 中运行而编写的，因此它可以更具规范性，Borg 应用程序是高度同质化的：同样的库、同样的 RPC 系统、同样的认证。”

    “最关键的是 Kubernetes 的设计是为了与现有的开源系统一起工作。虽然它们都专注于自动化、短暂性、动态管理，以及让用户在大多数情况下不必关心与他们无关紧要的细节。” “我们已经在 Kubernetes 上运行了一些云服务，但 Borg 有超过 14 年以上的定制功能，如搜索、广告、Gmail 等，而 Kubernetes 并不需要这些定制功能。”

    “我们将 Kubernetes 作为一个整体来介绍，因为它一下子解决了一类问题，但每一个部分真的是不同的，” Hockin 说，“Kubernetes 的 API 部分非常‘薄’——几乎所有的执行都是与 API 异步的，而且完全可以替换。”

    是 Kubernetes 太复杂了吗？“肯定的，Kubernetes 很复杂，因为它有 100 多个不同的 API 协同工作，有很多可动部件和子系统。但我并不认为它比任何其他类似操作系统的东西更复杂。我对简单性和复杂性的想法很纠结。我们能让它变得更简单吗？当然能，可代价是什么？你愿意删减那些功能吗？事实是，每个功能都有人在用。”

    至于未来的关注点，Hockin 说，“我会更多地专注于模块解耦。我会更努力地主张嵌套命名空间。我会让集群边缘的墙变得不那么坚不可摧。我会把更多的精力放在 API 机制上，作为一种 IDL（Interface Definition Language，接口描述语言）——API 核心的更强大的功能。”

    联合创始人 Brendan Burns 也在第二天上场接受了盘问。和 Hockin 一样，他也对 Kubernetes 的发展进行了反思。他被问及一开始有没有想过 Kubernetes 会变得这么大？他回答道：“我们看到了相关领域的空白，相信会有东西出现并填补它，但我无法保证那一定会是 Kubernetes。当时，有相当多的可选方案。”
    `

    回复

  7. 分布式文件系统架构对比
    https://www.infoq.cn/article/bp7uvbnb7dbgdk2gtxl9

    分布式文件系统对比与选型参考
    https://blog.csdn.net/yym373872996/article/details/105650908
    `
    一、分布式文件系统
    二、主流分布式文件系统介绍
    目前主流的分布式文件系统有：GFS、HDFS、Ceph、Lustre、MogileFS、MooseFS、GlusterFS、FastDFS、TFS、GridFS等。

    三、分布式文件系统的对比
    四、选型参考
    五、参考文献
    `

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注