《福布斯》:Google 能从开源生态系统中获得什么?

《福布斯》日前刊文,记者深入谷歌,探明其开源以TensorFlow为代表的一系列核心技术原因:开源能够更好更快地改善技术,同时也能够让自己成为价值生态链数据获取的核心。今天,竞争优势不再属于最会减少成本、利用资本的企业,而是属于为整个生态创造新的信息价值的企业。本文同时收录谷歌主要开源项目。

《福布斯》:Google 能从开源生态系统中获得什么?

我们一直认为艺术最需要人类创造力,但近年来,能理解创造力的机器不断出现。一位音乐教授甚至开发了一个能谱曲的程序。与挖洞、造车的机器不同,能产生有创造力作品的算法需要理解即使是人类自己都难解释清楚的事情。谷歌的Magenta项目就是要为艺术、音乐开发机器学习工具。Magenta建立在TensorFlow平台上,TensorFlow是谷歌最近发布的开源技术平台,相当于一个机器学习工具库,任何人都可以下载源代码。可是,为什么谷歌要开源其最先进的技术呢?

氧分子网(www.yangfenzi.com)曾刊登Google和开源的渊源:

➤ 为什么很多优秀的软件公司和开发者愿意开源和共享? 

➤ 谷歌开源总监迪博纳专访:开源如何改变了谷歌

开源,让自己成为价值链的中心

TensorFlow是谷歌基于DistBelief进行研发的第二代人工智能学习系统,其命名来源于本身的运行原理。Tensor(张量)意味着N维数组,Flow(流)意味着基于数据流图的计算,TensorFlow为张量从图象的一端流动到另一端计算过程。TensorFlow是将复杂的数据结构传输至人工智能神经网中进行分析和处理过程的系统,可在小到一部智能手机、大到数千台数据中心服务器的各种设备上运行。TensorFlow 包括众多机器学习工具,可被用于语音识别或图像识别等多项机器深度学习领域。这些工具能帮助开发人员创造更加智能的产品。

人类的知识非常复杂,因此不可能使用一套逻辑对其预编程。这个规则系统的缺点是因为人类的智能太复杂、难以复制。

TensorFlow已经通过学习克服了这个缺点。AI系统不断学习,谷歌已经开源算法训练技术。这为开发人员与机器交互以及开发更强大的应用程序打开了大门,即使他们本身的AI知识非常有限。

TensorFlow毫无疑问是非常有价值的技术。机器学习本身就处于计算机科学的边缘,谷歌又是该领域为数不多的一家公司。那么,为什么谷歌要开源,让所有人,甚至是竞争对手都能使用TensorFlow呢?

开源的决定是Jeff Dean提出的,他认为常规科学发展缓慢,阻碍了公司的创新。谷歌的研究员要是写一篇论文,要到几个月后才会在某个大会上被讨论。然后再过几个月才有别的人在他们的基础上写另一篇论文。

Dean认为,开源TensorFlow能够大大加快这一进程。谷歌的研究人员不用等到下一篇论文或是下一场大会,就能积极地与科学界实时协作。谷歌公司之外的人才也能改善源代码,通过更广泛地分享机器学习技术,还能为该领域培养更加专业的人才。

开源TensorFlow后,我们能够和许多其他大学、企业的研究员进行合作,这会给我们如何提高技术带来新想法。我们决定开源后,代码运行更快了,可以做更多的事情,也更加便捷。”TensorFlow 团队负责人Rajat Monga说。

从传统观念来看,谷歌的开源TensorFlow的决定很奇怪。许多科技公司,比如苹果公司,对于自己的产品、技术一直是保密的。甚至于谷歌自己的许多东西,像是搜索算法,都秘而不宣。

然而,世界正在改变。过去,取得成功最确切的做法就是使价值链达到最优。通过精简内部流程和提高规模,你可以提高自己在与客户、供应商谈判时的地位,提升企业效率,从而打造可持续的竞争优势。

然而现在,最成功的产品来自价值生态系统。谷歌的确雇用了一些非常聪明的人,但是只有在他们融入更大的科技圈时才能提高谷歌的技术。谷歌也需要别人将谷歌的技术嵌入到他们的产品中去,以便更好地扩大谷歌的领域。

这就是为什么谷歌以及许多其他处于技术前沿的公司要公开自己的重要技术。在谷歌开源TensorFlow后不久,Facebook就宣布开源自家的AI工具库,特斯拉开源了电动汽车的专利。最近,IBM还将其量子计算平台共享到云上。

今天,竞争优势不再属于最会减少成本、利用资本的企业,而是属于为整个价值生态创造新的信息价值的企业。位于价值生态系统中心的企业才是最强大的。

谷歌主要开源项目列表

谷歌累计开源900多个项目,超过2000万行代码。以下选取了其中较为熟知的项目:

Android: 第一个免费、开源而且可完全自定义的移动平台,提供完整的堆栈:一个操作系统、中间件和重要的一用应用,它包含丰富的API可以让第三方开发者开发出强大的应用程序。

Angular:一个开源的JavaScript和web应用程序框架

Bazel:一款可再生的代码构建工具。它主要是用于构建 Google 的软件,处理出现在谷歌的开发环境的构建问题。

Brotli:一个通用目的的无损压缩算法,它通过用变种的 LZ77 算法,Huffman 编码和二阶文本建模进行数据压缩,是一种压缩比很高的压缩方法。

Chromium:chrome浏览器背后的引擎,其目的是为了创建一个安全、稳定和快速的通用浏览器。

Closure Tools:谷歌内部使用的一款JavaScript开发工具,帮助外部程序员开发出速度更快的Web应用程序。

Course Builder:一个在线课程免费创建工具

Dart:一种基于类的可选类型化编程语言,设计用于创建Web应用程序。

Ganeti:基于Xen虚拟机管理器和其他开源软件的虚拟服务器管理软件工具。

Gerrit:一种免费、开放源代码的代码审查软件,使用网页界面。

Go:Google开发的一种编译型,并发型,并具有垃圾回收功能的编程语言。支持多国语言界面显示,完全插件体系结构,支持编辑器配色方案。

gRPC:一个高性能、开源和通用的 RPC 框架,面向移动和 HTTP/2 设计。

Google Web Toolkit:一种开源 Java 软件开发框架,可以使不会使用第二种浏览器语言的开发人员编写 Google 地图和 Gmail 等 AJAX 应用程序时更加轻松。

Guava:该项目是 Google 的一个开源项目,包含许多Google核心的Java 常用库。

Kubernetes:Google 云平台的开源容器集群管理系统。

LiquidFun:一款2D物理游戏引擎,可以模拟柔体、流体、粒子等物理效果

Native Client:一种允许在浏览器中运行native compiled code 的技术,允许开发者运用自己熟悉的语言来开发web应用。

Tesseract OCR:当前精度最高的OCR引擎之一

V8 JavaScript Engine:谷歌的开源、高性JavaScript引擎。用C++写的,用于Chrome及谷歌的开源浏览器。

WebM:该项目旨在为对每个人都开放的网络开发高质量、开放的视频格式。

ZXing:是Java的开源多格式1D/2D条码图像处理库,用于Android系统。

【文/新智元(微信号:AI_era)编译 译者:张冬君 来源:Forbes】

氧分子网(www.yangfenzi.com)是关注互联网生态圈的科技新媒体

·氧分子网(http://www.yangfenzi.com)延伸阅读:

➤ Google Angular 中文网站上线发布,开源推动互联网技术的发展

➤ 曹政:傲慢与偏见之 – 谷歌中国逆袭史

➤ Facebook如何推动下一波开源浪潮?

➤ Google 重磅突破:相比LSTM,NLP 关键任务提升 20%

➤ Facebook开源深度学习框架Torchnet与谷歌TensorFlow有何不同

分享给您的好友:

您可能还喜欢…

1 Response

  1. InfoQ:百度正式开源其RPC框架brpc说道:

    百度开源的这款 RPC 框架 brpc,背后有什么门道?
    写在前面
    9 月 14 日,百度正式在 GitHub 上基于 Apache 2.0 协议开源了其 RPC 框架 brpc。brpc 是一个基于 protobuf 接口的 RPC 框架,在百度内部称为“baidu-rpc”,它囊括了百度内部所有 RPC 协议,并支持多种第三方协议,从目前的性能测试数据来看,brpc 的性能领跑于其他同类 RPC 产品。
    brpc 开发于 2014 年,主要使用的语言是 C++ 和 Java,是百度内部使用最为广泛的 RPC 框架,它经受了高并发高负载的生产环境验证,并支撑了百度内部大约 75 万个同时在线的实例。据 InfoQ 了解,百度内部曾有多款 RPC 框架,甚至在 2014 年时还开源过另外一款 RPC 框架 sofa-pbrpc。那 brpc 是在什么样的背景下诞生的?它有什么样的优势?又为何要开源?就这些问题,InfoQ 记者采访了 brpc 负责人戈君。
    GitHub 地址:https://github.com/brpc/brpc
    InfoQ:谈谈 brpc 的一些基本情况?什么时候开始研发的?经过了怎么样的迭代和升级?目前在内部应用情况如何?
    戈君:brpc 于 2014 年创建,在百度内部称为“baidu-rpc”。到目前为止,brpc 一共进行了 3000 次左右的改动,现在仍在持续优化中,百度内的 wiki 上可以查询到每次改动的描述。brpc 的主要语言是 C++ 和 Java,对其他语言的支持主要是通过包装 C++ 版本,比如 brpc 的 Python 版包含 C++ 版的大部分功能。
    brpc 目前支撑百度内部大约 75 万个同时在线的实例(不含 client),超过 500 种服务(去年的统计,现在已不统计这类数据)。Hadoop、Table、Mola(另一种广泛使用的存储)、高性能计算、模型训练、大量的在线检索服务都使用了 brpc。brpc 第一次统一了百度内分布式系统和业务线的通信框架。
    InfoQ:为什么百度当时要研发 brpc?
    戈君:我们在实践中意识到,RPC 作为最基础的通信组件,当时的百度已经不领先了。我当时的经理刘炀曾是 Google 的工程师,非常重视基础架构的建设,也愿意在这个方向投入资源。
    我们在内部会更加深入地讨论这些问题。“好用”有时看起来很主观,但其实还是有据可循的,它的关键点是能不能真正地提高用户的效率:开发、调试、维护都要考虑到,如果用户效率真的被提高了,用户会想着你的,靠吹嘘或政令推广的东西得不了人心。我们创建 brpc 的初衷是解决百度业务所面临的实际挑战,同时也希望成为百度同学最喜爱的工具,哪怕离开百度也会怀念 brpc。我们希望在提供了一个好用框架的同时,也展现了一种工作方法:注释怎么写,日志怎么打,ChangeLog 怎么写,版本怎么发布,文档怎么组织,甚至对未来不在百度的同学的工作也有帮助,所以从这点来说 brpc 从一开始就是拥抱开源的。事实上,我们在口碑上做得还不错,brpc 的 wiki 可能是百度内被点赞最多的内容之一。
    InfoQ:与其他的一些开源的 RPC 框架相比,brpc 的优势是什么?
    戈君:brpc 主打的是深度和易用性。一方面我们没有精力像 gRPC 那样摊大饼,什么都做。另一方面我们也注意到 gRPC(包括更早的 Thrift)的深度和易用性并不够。技术方面的东西就是这样,看示例程序,文档非常牛逼,但实战中可能就是另一回事了,为什么各个公司都要造自己的轮子,一个隐藏原因就是表面高大上的东西在一些细节上让你无法忍受。
    RPC 真正的痛点是什么?是可靠性、易用性和定位问题的便利性。服务中不要出现不可解释的长尾,程序的可变项要尽量少,各种诡异问题要有工具支持快速排查。而这些在目前开源的 RPC 框架中做的并不好,它们大多看着很牛,但就是无法在自己组织中推广开来。回到前面那三点,brpc 是如何做的呢?
    可靠性。这一方面是代码质量问题,通过为 brpc 团队设立很高的招聘门槛,以及在团队中深入的技术讨论,我们确保了稳固的代码基础。另一个问题是长尾问题,这是设计问题,brpc 其实包含了很多模块,其中的 bthread 是一个 M:N 线程库,就是为了更好地提高并发避免阻塞。brpc 中的读和写都是 wait-free 的,这是最高程度的并发。技术细节请点击以下链接查看。https://github.com/brpc/brpc/blob/master/docs/cn/bthread.md
    https://github.com/brpc/brpc/blob/master/docs/cn/io.md
    易用性。有种设计是什么选择都做成选项丢给用户,号称功能都有,但一旦出问题,则是用户“配置错了”。而且这样用户还非常依赖开发团队,没有开发团队的支持基本用不了,开发团队有足够的理由扩充团队。这么做其实非常不负责任,用户面对海量的选项也很难受。brpc 对于增加选项非常谨慎,框架能自己做判断的绝不扔给用户,所有用户选项都有最合理的默认值,不设也能用。我们认为这对用户体验来说非常重要。
    定位问题的便利性。这点其它开源框架目前做的都不好,正常使用是可以的,但出问题就麻烦了。这个问题在百度内部其实也很严重,brpc 之前用户排查问题都要拉 RPC 同学一起排查,RPC 框架对用户是个黑盒,用户根本不知道里面发生了什么。按我们的经验,基本每天都有几个用户在群里问 server 卡顿,client 超时之类的问题,排查问题是常态,人手必然不够。时间长了用户就觉得你这个框架各种问题,人还拽的不行很少回他们消息。brpc 的解决办法是给 server 内加入各种 HTTP 接口的内置服务,通过这些服务,用户可以很快看到 server 的延时、错误、连接、跟踪某个 RPC、CPU 热点、内存分配、锁竞争等信息,用户还可以使用 bvar 来自定义各类统计信息,并在百度的运维平台 NOAH 上汇总。这样大部分问题用户可以自助解决。其实我们去看也是看这些,只是会更加专业。内置服务的具体说明可以看这里:https://github.com/brpc/brpc/blob/master/docs/cn/builtin_service.md
    InfoQ:作为公司内部的 RPC 框架,在服务治理方面有什么考虑?
    戈君:百度内部 RPC 使用非常广泛,基本都是 RPC 调用,一些产品线还会通过 local RPC 隔离工程框架和策略代码。这么多年下来,服务周边的系统也比较全面了:编译是 BCLOUD,发布是 Agile,服务注册和发现是 BNS,认证是 Giano,监控和运维是 NOAH。在百度内部,brpc 和这些系统做了比较紧密的绑定,用户体验是一站式的。虽然在开源版本中,这些结合大都删掉了,但用户可以根据自己组织中的基础设施来进行定制:交互协议,名字服务,负载均衡算法都可以定制。对于其中一些特别通用的,我们希望用户反馈到开源版本中来以方便所有人。
    InfoQ:之前百度还开源过 sofa-pbrpc,brpc 与它的区别是什么?
    戈君:sofa-pbrpc 也是百度开发的一个比较早期的 RPC 框架,属于 sofa 编程框架的一部分,在搜索有应用。brpc 相比 sofa-pbrpc 有如下优点:
    对协议的抽象更一般化,并统一了全百度的通信架构。bprc 能容纳非常多的协议,基于 Protobuf 的,基于 HTTP 的,百度内的 nshead/mcpack,开源的 Redis/Memcached,甚至 RTMP/FLV/HLS 直播协议,brpc 能逐渐地嵌入现有系统,而不需要彻底重构,但 sofa-pbrpc 则不具备扩展协议的能力。类似的,sofa-pbrpc 也无法定制负载均衡算法,brpc 默认提供 round-robin、随机、一致性哈希,Locality-aware(局部性感知)四种算法,用户还能定制。
    多线程质量更好。多线程编程是非常困难的,看起来简单的 RPC 遍布多线程陷阱,比如处理超时的代码可能在 RPC 还没发出去时就运行了;发送函数还没结束,处理回复的回调就被运行了;一个回复还在被处理另一个回复回来了,诸如此类。另外,一个异步 RPC 的回调里发起一个同步 RPC 会发生什么,带着锁做同步 RPC 会发生什么。这些问题我们都不能在 sofa-pbrpc 中找到满意的答案。
    完备的调试和运维支持。解决这个问题的本质还在可扩展性,你如何让用户参与进来定制他们感兴趣的指标,为此我们设计了 bvar,让用户能用比原子变量代价还小的方式自由地定制各种指标,用户能在浏览器上看到指标的变化曲线,或在运维平台 NOAH 看到汇总的监控数据。brpc 还加入了大量内置服务方便用户调试程序,查看连接,在线修改 gflags,追踪 RPC,分析 CPU 热点,内存分配,锁竞争等一应俱全。
    无需讳言,brpc 在诞生之初和 sofa-pbrpc 在百度内部是有竞争关系的,但就像其他地方一样,这种竞争带来了活力。类似的,brpc 和其他已经开源的 RPC 框架也是良性的竞争关系,在比拼谁能真正提高用户效率的过程中共同进步。每个用户都可以去对比代码、文档质量,接口设计,易用程度,扩展能力等,投出自己的一票。
    InfoQ:谈谈 brpc 的整体架构?
    戈君:技术栈无外乎是从传输层垒到应用层,就略过不讲了,具体可以去看下开源出来的文档。brpc 在架构上强调“在不牺牲易用性的前提下增强可扩展性”,比如 brpc 支持非常多的协议,在百度内部一个 brpc server 同端口可以支持二十几种协议,这对于服务的平滑迁移就非常好用。
    Client 端的协议也非常多,用户用 brpc 和 bthread 用得很爽,所以希望我们最好能统一所有的客户端,像对 Redis 和 Memcached 的客户端支持也是在这个背景下做的,这两个客户端比官方 Client 好用多了,感兴趣的读者可以去尝试一下。但这么多协议的配置非常简单,填个字符串就行了,比如 HTTP 就是把 ChannelOptions.protocol 设为“http”,Redis 就是“redis”。Server 端甚至不用设,它会自动判断每个 client 的协议,怎么做到的开源文档里也有,具体见这个链接:
    https://github.com/brpc/brpc/blob/master/docs/cn/new_protocol.md
    名字服务、负载均衡也都可以定制。但为了对用户负责,我们也不鼓励“太自由”的定制,比如一点点需求的变化就要搞个新的,这时更需要想清楚本质区别是什么。这个事情我们在百度内的支持群里每天都在做,我们是开放的”乙方”,但我们也是严厉的”乙方”。
    InfoQ:brpc 的性能如何?这么高的性能是怎么做到的?
    戈君:性能是我们非常看中的一点,它和用户体验也是紧密联系的。好用但性能不行,或不好用但性能很牛,用户会很难受,我们不希望用户纠结。从另一个角度来看,在推广初期,我们要说服产品线用 brpc 靠什么?最直观的就是性能提升。而且这儿的性能不能停留在 benchmark 的图片上,而是能在真实应用中体现出来。开放出来的案例文档中或多或少都包含了性能提升,具体如下:
    百度地图 API 入口:
    https://github.com/brpc/brpc/blob/master/docs/cn/case_apicontrol.md
    联盟 DSP:
    https://github.com/brpc/brpc/blob/master/docs/cn/case_baidu_dsp.md
    ELF 学习框架:
    https://github.com/brpc/brpc/blob/master/docs/cn/case_elf.md
    云平台代理服务:
    https://github.com/brpc/brpc/blob/master/docs/cn/case_ubrpc.md
    和其他 RPC 框架(包含 thrift、gRPC)的性能对比可以见:
    https://github.com/brpc/brpc/blob/master/docs/cn/benchmark.md
    开源文档中概括了性能上的设计, “RPC in depth”这一节下的文档会谈的更细点。这里我不赘述,还请直接阅读文档:
    https://github.com/brpc/brpc#better-latency-and-throughput
    InfoQ:为什么要将 brpc 开源?接下来在开源项目的迭代方面有什么计划吗?
    戈君:因为马上还有不少依赖 RPC 的百度系统要开源啊。RPC 作为最基础的组件,开源不仅仅是为了自身,也是为其它开源项目铺路,比如说我们马上还会开源基于 brpc 的 RAFT 库,搭建高可用分布式系统非常方便;以及使用 brpc 的 bigflow,让流式计算变得很顺手。这些年百度对开源的认识也在不断加深,开源看似曝光了百度的核心技术,但带来的生态影响力更重要。从 Apollo、PaddlePaddle 开始,百度真的开始拥抱开源了。brpc 的开源版和内部版很接近,只是去掉了对百度内部独有的一些基础设施的支持,我们在内网写的深入分析 RPC 技术细节的文档也都一并开源了,后续也会及时推送改动,请大家放心。这是一个活项目,不会拉个开源分支就不管了。
    嘉宾介绍
    戈君,百度主任架构师,brpc 主要作者,在系统编程,数据结构,设计和实现大规模分布式系统方面有广泛的实践。
    强相关会议推荐
    就像戈君所说,百度在 2017 年会认真拥抱开源,诸多核心技术开始对外分享,例如即将到来的 QCon 上海站里,百度安全事业部首席架构师武广柱将分享如何将机器学习应用于风控,详解图关联分析在数据挖掘和风控中的核心应用。

发表评论

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

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>