我们可能会看到有更多的开放接口和元框架，但它们也有缺点。
深度学习、无服务器功能和流处理有何共同之处?它们除了成为计算领域的大趋势之外，支持这些变化的开源项目正在以一种全新的、也许是独特的方式进行构建。在每一领域中，都出现了仅限 API 专用的开源接口，这些接口必须与许多受支持的独立后端之一一起使用。这种模式可能会对业界带来好处，因为这种模式为开发者带来了较少的重写，且易于采用、性能改进和为公司带来盈利的承诺。我将在本文中阐述这种模式，并提供有关它的第一手资料，讨论它对开源的意义，然后探讨我们应该如何培育这种模式。
通常，新的开源项目既提供了新的执行技术，也提供了用户编程时所要用到的 API。API 的定义在一定程度上可以视为一种创造性活动，它从历史上借鉴了类似的概念(如 Storm 的 spouts 和 bolts ，或 Kubernetes 的 pods)来帮助用户快速了解如何使用这一新事物。API 特定于项目执行引擎：它们一起构成一个单独的整体。用户阅读项目文档来安装软件，与接口交互，并从执行引擎中受益。
几个重要的新项目结构不同。它们没有执行引擎;相反，它们是为几个不同的执行引擎提供公共接口的元框架(metaframeworks)。Keras 是第二大流行的深度学习框架，就是这种趋势的一个例子。正如创建者 Fran?ois Chollet 最近试图解释的那样，“Keras 是一个接口，而不是一个端到端的框架。”同样的，Apache Beam，一种大型数据处理框架，也是一种自我描述的“编程模型”。这是什么意思呢?你能用自己的编程模型来做什么呢?答案是：真的并不能做什么，因为这两个项目都需要外部的后端。就拿 Beam 这种例子来说，用户编写的管道可以在八个不同的“运行器(runner)”上执行，包括六个开源系统(其中五个来自 Apache)和三个专有的厂商系统。同样的，Keras 也支持 TensorFlow、微软认知工具包(Microsoft’s Cognitive Toolkit，CNTK)、Theano、Apache MxNet 等。Chollet 在 GitHub 最近的一次交流中简要描述了这种方法：“事实上，我们将来甚至会扩展 Keras 的多后端的方面。……Keras 是深度学习的前端，而不是 TensorFlow 的前端。”
相似之处不止于此。Beam 和 Keras 最初都是由 Google 员工在同一时间(2015 年)以及相关领域(数据处理和机器学习)创建的。然而，似乎这两个小组都独立地得到了这个模型。这究竟是怎么发生的?这对于这个模型意味着什么呢?
Beam 的故事
2015 年，我在 Google 担任产品经理，专注于 Cloud Dataflow(云数据流)。Dataflow 工程团队的传奇地位可以追溯到 Jeff Dean 和 Sanjay Ghemawat 于 2004 年发表的著名论文 MapReduce。与大多数项目一样，MapReduce 定义了一种执行方法和一种编程模型来利用它。虽然执行模型仍然是批处理的最新技术，但使用编程模型的体验并不那么令人愉快，因此 Google 很快就开发了一个更简单的抽象编程模型 Flume(图 1 的第一步)同时，对低延迟处理的需求，导致了一个新的项目，该项目使用通常的执行模型和编程模型，成为 MillWheel(即图 1 中的第二步)。有趣的是，这些团队围绕着这样的一个想法走到了一起，Flume 是用于批处理的抽象编程模型，带有一些扩展，也可以是流的编程模型(第三步)。这一关键见解是 Beam 编程模型的核心，当时称为 Dataflow Model(数据流模型)。
郑州不孕不育医院排名:http://wapyyk.39.net/zz3/zonghe/1d427.html
郑州不孕不育医院:http://jbk.39.net/yiyuanzaixian/zztjyy/