随着时间的推移，之前那些新鲜事物给我们带来的未知将逐渐被我们发现。花了一些时间尝试新技术后，我们总结出了一张经验清单，多么希望可以把它送给曾经的我们。下文是我希望在开始构建我们的第一个机器学习管道之前，可以发送给我们团队的清单之一。我相信假如真能这样做，可以让我们少走很多弯路并节省大量时间，也希望它对你们的项目开发能有所帮助。
正如我在之前的一个帖子中所分享的那样，我们正在用 Apache Spark 做一些事情，所以本文中主要涉及一些关于构建机器学习管道和 Apache Spark 的经验建议。
就像任何大而未知的东西一样，很难做出一个时间上的估算。虽然我们知道为了达成目标需要做哪些事情，但随着时间的推移，这些事情都被证明是错的。我们必须勇于面对这些结果，并确保我们能够快速迭代。
结果是个很大的未知数。需要确保团队能够快速迭代。
开始建设机器学习管道之前，我们已经收集了大约 3 年的原始数据 (我们将其推送到我们的解析库中以便聚合)。我们之前并没有使用这些原始数据，为了以防万一，方便必要时进行解析库恢复工作，只是做了简单的存储。原始数据是以 CSV 文件的形式存在的。我们一直没有注意到数据有问题。但由于编写文件的代码随着时间的推移发生了一些变化，因此有些 bug 悄悄地出现了，这些之前我们并没有注意到。在构建机器学习管道之前我们修复了这个产生数据问题的 bug。我们也结束了用 Apache spark 编写代码来完成对历史数据的清理工作。问题是，我们是在任务进程中发现这个问题的，而不是在刚开始时，这给我们团队增加了一些挑战。
在开始之前，确保你的数据是可用的。
为了训练我们的机器学习模型，我们最初尝试加载所有的数据，我们的数据有几 TB。我们发现，每次都加载所有数据，会使得训练变的很慢，这也放慢了模型改进的迭代速度。之后我们意识到我们没必要每次都加载所有的数据，毕竟我们没有使用数据的所有列。我们做了一些预处理，并创建了一个新的更小的数据集，它包含了我们训练模型所需的数据列。当然我们没有删除原始数据源，作为备份，它可以防止我们搞砸了之后恢复数据之用。
不要将 ETL 和模型训练混淆。如果你训练 1000 个模型，那么你不需要做 1000 次预处理。做一次预处理就够了，之后将数据保存在某个地方，然后用它来满足你所有的模型训练需求。
如前所述，我们将原始数据备份存储在 AWS S3 中。从数据科学的角度来看，我们并没有真正让它变得易于研究，这不是我们刚开始将数据转存到 S3 中的初衷。但是当我们开始将机器学习用于工作时，我们发现给每个人提供易于进行数据研究的接入途径是至关重要的。
只给他们提供读取数据的途径是不够的。人们不能仅仅将数据下载到笔记本上，对吗? 比方说有人下载了几 TB 的数据，那么他们又能在笔记本上做什么呢? 人们不会随身携带通常能够在合理时间内处理几 TB 数据的 32 核的笔记本电脑。这只是在浪费大家的时间。
我们发现，使用像 notebook 这样的 Apache Spark 支持的环境就可以达到我们最初期望的目标。notebook 可以选择 jupyter、zeppelin。我们发现 jupyter 可以在我们的持久化集群中很好的工作，而 zeppelin 因为其 AWS EMR 内置集成因素，可以很好的运行在 AWS EMR（AWS 管理的 spark 集群）上。
让人们读取几 TB 的数据，并希望他们能理解，这是很荒谬的。你必须给他们正确的工具，帮助他们理解。像 jupyter、zeppelin 支持的基于云的 spark 集群就很有用处。
当你使用大数据物理变化定律时，开玩笑的说，用传统的软件工程方法就行不通了。普通的程序运行需要几分钟的时间，大数据运行可能需要数小时甚至几天时间，这取决于你在做什么以及你是怎样做的。但是，当我们需要等待几天的时间来完成我们的批处理作业时，我们就不想活了。也许十年前还行，但现在不可以了。
与传统的软件编程相比，在大数据的情况下如何减少批量作业的完成时间的问题更加复杂。使用云，我们可以横向扩展我们使用的机器数量并减少运行时间。但是我们应该增加机器数量还是彻底改变机器的类型? 我们是用 CPU 绑定、RAM 绑定、网络绑定还是磁盘绑定? 在这种分布式环境中，我们的瓶颈在哪里? 这是我们为减少执行时间必须要解决的问题。
对于 Apache Spark，很难找到所需的机器类型。Amazon EMR 提供了 ganglia，它可以让我们很简单的就能监控我们的集群内存 /CPU。但有时我们还需要去检查底层的 EC2 实例，因为 ganglia 并不是面面俱到的。二则兼用效果明显。我们发现，与训练机器学习模型的任务相比，ETL 任务的执行情况会有所不同。ETL 会消耗大量的网络资源和内存，机器学习训练则需要更多的计算资源。我们为这两类工作选择了不同的实例类型。
优化成本需要从 CPU/ 内存 / 网络 /IO 监控入手。我们发现不同的工作任务 (ETL, ML) 需要对应着不同的机器需求。
你对机器学习模型的预测有延迟要求吗? 如果有，在你开始投入使用特定的框架之前，需要弄清楚框架的训练模型是否能够满足你的延迟需求。我们可以很容易掌握数学模型的基本理论知识，从理论上确认它运行的高效率。然而事实证明，还会有其他的事情可能导致预测不像你预期的那么快。就像有些聪明人总结的——如果不经过测试就不会知道可不可行。
构建一个简单的模型并对其进行基准测试。如果你在建立了管道之后才发现需要做这件事，就可能会浪费你很多时间。我们也是很不容易才发现 spark 并不能满足我们的延迟需求的。之前博客文章有分享，我们使用了一个名为 mleap 的库来提高预测延迟。
如果你有延迟需求，那么用你想要使用的框架创建一个简单的模型。准确性、精度或任何其他指标都不重要，只是将其作为预测延迟的基准。
使用 AWS 的 GUI 或 CLI，很容易忘记 S3 其实不是一个文件系统。其实它是一个对象存储仓库。对象存储仓库是一个键值存储，它的值是一个对象，此对象可以是 json、图像等。
这种区别很重要，因为在 S3 中重命名东西并不像在真正的文件系统中那样快。如果你在文件系统中移动一个对象，速度可能是极快的，当然这也取决于你使用的是什么，但是在 S3 中不要期望会有同样的速度。
为什么这个很重要? 因为当通过 Apache spark 将数据写入 S3 时，Apache spark 会写入临时文件，然后将它们移动到新 key 中。如果你使用的是文件系统而不是 S3，这可能没什么问题。Apache spark 中有一个设置项，可以让它不要写临时文件，而是直接写入最终输出。我们开启了这个属性，这为我们节省了很多本应该用于写入 AWS S3 的时间。到目前为止，我们还没出现过问题。
如果你使用过 Apache spark，你应该知道它主要是基于 Scala 语言的。Java 和 Python API 也是可用的，但是网上的示例大多是基于 Scala。如果你通过邮件请求帮助，人们也会很乐意提供帮助，但主要是使用 Scala 语言，因为这是他们正在使用的 API。
我们使用的是 Java 语言，因为我们的技术栈主要都是基于 Java 的。当我们刚起步的时候，我们在机器学习和 Scala 方面的专业知识都比较缺乏。我们认为机器学习对于我们的业务来说是必不可少的，而 Scala 则不是。我们不能让我们的团队同时学习 Scala 和机器学习。这些只是基于一些现实的考虑，以确保整个项目不会成为一场灾难。
这很好地保证了我们能够完成最终产品的开发，但是当遇到 Apache Spark 出问题时，它就会成为项目中一个烧脑的点。我们碰到过问题并且找到了解决方案。即便是 Scala 的解决方案，将 Scala 翻译成 Java 并不难，但是将 Spark Scala 翻译为 Spark Java 是很困难的，因为 api 在 Java 中使用起来稍微困难一些。
如果你不懂 Scala 还想要使用 Spark Mllib，那么你可能需要考虑在选择语言方面做出妥协。这不是一个理想的工程解决方案，但却是一个实用的解决方案。记住软件工程是在迭代过程中产生的。先让它运作起来，然后再让它变得更好。比起创造一种永远不能用于生产的完美解决方案，让产品在生产中先运行起来要重要得多。
如果你正在将机器学习与已有的系统集成，你将不可避免的会与其他开发人员打交道。你还需要和商务人士、运营人员、市场营销人员等进行交流，除非你们做过人工智能产品，否则这些人对机器学习可能不会了解很多。因为机器学习只是商业解决方案的一部分，而不是整个解决方案，他们没有必要一定和其它同事一起研究。他们更不会坐下来学习机器学习课程。
分享一些机器学习的知识。你不需要教他们算法相关的东西，但你需要解释明白什么是机器学习。解释一些常见的术语，如训练 / 测试 / 验证集、模型、算法等等。
人们很容易忽视机器学习中繁多的术语。你可能很熟悉它们，但其他人不是。这对团队中的其他人来说可能是陌生的语言，他们可能会为此感到困惑。并不是每个人都学习了机器学习的课程。
你可能想要为你的数据构建一个版本控制方案，并使其能够切换到不同的模型训练代码，以使用不同的数据集，而无需重新部署整个软件。我们创建了一些模型，并用一些数据对它们进行了测试，结果发现仅这些数据是不够的。模型是工作的，但还不够好。
因此，我们为我们的数据建立了一个版本控制方案，这样我们就可以在 v1 上训练模型，并继续生成下一个版本，并且在新版本中有足够的数据之后，我们可以切换模型训练代码来使用新的数据。我们还做了一个 UI，它可以让我们控制机器学习算法的参数，允许我们对一些特定的参数进行基本的过滤，并且能够指定我们想要用于训练的数据量。基本上，通过 UI 可以轻松地配置一些东西，这样便可以确保更改训练的数据量时不需要重新部署了。
如果你对上文感兴趣，你可能也会有兴趣看下我们关于如何选择一个易于接入的数据仓库的文章分享。
英文原文链接：
https://medium.com/infinity-aka-aseem/things-we-wish-we-had-known-before-we-started-our-first-machine-learning-project-336d1d6f2184
联系客服
