这是一个社区博客，来自johnsnow实验室的工程团队，解释了他们对开源apachespark自然语言处理（NLP）库的贡献。该博客阐述了该库的三个顶层技术要求和考虑事项。apachespark是一个通用的集群计算框架，支持分布式SQL、流式处理、图形处理和机器学习。现在，Spark生态系统还有一个Spark自然语言处理库。在GitHub上获取johnsnow Labs NLP库使用apache2.0许可证，使用Scala编写，不依赖于其他NLP或ML库。它本机扩展了Spark-ML管道API。该框架提供了注释器的概念，并提供了：分词器标准化器词干测定器柠檬酸盐实体提取器日期提取器词性标记命名实体识别句子边界检测情绪分析拼写检查器此外，考虑到与Spark-ML的紧密集成，在构建NLP管道时，您可以立即使用更多的工具。这包括单词嵌入、主题建模、停止词删除、各种特征工程功能（tf-idf、n-grams、相似性度量等）以及在机器学习工作流中使用NLP注释作为特征。如果您不熟悉这些术语，本指南将为您理解NLP任务提供一个良好的开端。我们的虚拟团队多年来一直在开发严重依赖自然语言理解的商业软件。因此，我们在spaCy、CoreNLP、OpenNLP、Mallet、GATE、Weka、UIMA、nltk、gensim、Negex、word2vec、glow等方面都有实践经验。我们是超级粉丝，我们模仿这些图书馆的许多地方都是为了真诚地奉承他们。但我们也曾多次与它们的局限性相撞——我们不得不为真正的生产使用交付可伸缩、高性能、高精度的软件。这篇文章描述了johnsnow Labs NLP库的优势，以及在您自己的项目中应该考虑使用它的用例。性能我们处理的三个顶层需求中的第一个是运行时性能。你可能会认为，随着spaCy的出现，这在很大程度上已经解决了问题，它的公共基准反映了一套经过深思熟虑和巧妙实现的权衡。然而，当在其上构建Spark应用程序时，仍然会获得不合理的低吞吐量。要理解原因，请考虑NLP管道始终只是更大数据处理管道的一部分：例如，问答涉及加载培训、数据、转换数据、应用NLP注释器、构建特征、训练值提取模型、评估结果（训练/测试分离或交叉验证），以及超参数估计。将数据处理框架（Spark）与NLP框架分开意味着大部分处理时间都花在序列化和复制字符串上。TensorFrames是一个很好的并行工具，它极大地提高了在Spark数据帧上运行TensorFlow工作流的性能。这张图片归功于Tim Hunter出色的TensorFrames概述：Spark和TensorFlow都针对性能和规模进行了优化。但是，由于数据帧存在于JVM中，而TensorFlow运行在Python进程中，这两个框架之间的任何集成都意味着每个对象都必须序列化，经过进程间通信（！）在这两种情况下，至少在内存中复制了两次。TensorFrames公共基准测试报告说，只需在JVM进程中复制数据（在使用GPU时，速度会提高4倍）。在spaCy和Spark一起使用时，我们看到了同样的问题：Spark对于加载和转换数据进行了高度优化，但是运行NLP管道需要复制钨丝优化格式之外的所有数据，将其序列化，将其推送到Python进程中，运行NLP管道（这一位速度非常快），然后将结果重新序列化回JVM进程。这自然会扼杀从Spark的缓存或执行计划器获得的任何性能优势，至少需要两倍的内存，并且不会随着扩展而提高。使用CoreNLP可以消除复制到另一个进程，但仍然需要从数据帧复制所有文本并将结果复制回。因此，我们的第一项业务是直接对优化的数据帧执行分析，就像Spark ML已经做的那样（信贷：Databricks发布的ML管道介绍文章）：生态系统我们的第二个核心需求是对现有Spark库的无摩擦重用。部分原因是我们自己的恼火-为什么每个NLP库都必须构建自己的主题建模和单词嵌入实现？另一部分是务实的——我们是一个小团队，在紧迫的期限内，需要充分利用现有的资源。当我们开始考虑Spark NLP库时，我们首先要求Databricks指出已经在构建它的人。当答案是没有的时候，下一个问题是帮助我们确保库的设计和API完全符合sparkml的API指南。这种协作的结果是，该库是Spark ML的无缝扩展，因此您可以构建这种管道：val管道=新mllib.管道（）.setStages（数组(docAssembler公司，标记器，词干测定器，停止字删除程序，哈希尔，以色列国防军，dtree公司，标签索引）在这段代码中，文档汇编程序、标记器和词干分析器来自Spark NLP库-网址：com.jsl.nlp*包装。TF hasher、IDF和labelDeIndex都来自MLlib'索格。阿帕奇。斯帕克.ml.特征*包装。dtree阶段是一个spark.ml.分类.DecisionTreeClassifier。所有这些阶段都在一个管道中运行，该管道以完全相同的方式可配置、可序列化和可测试。它们还运行在一个数据帧上，不需要任何数据拷贝（不像spark corenlp），享受spark的内存优化、并行性和分布式横向扩展。这意味着johnsnow Labs NLP库具有完全分布式、经过大量测试和优化的主题建模、单词嵌入、n-gram生成和现成的余弦相似性。不过，我们不必建造它们——它们都有火花。最重要的是，这意味着您的NLP和ML管道现在是统一的。上面的代码示例是典型的，在某种意义上，它不仅仅是一个NLP管道，NLP用于生成特性，然后用于训练决策树。这是典型的问答任务。一个更复杂的例子还将应用命名实体识别，通过POS标记和共指解析进行过滤；训练一个随机森林，同时考虑基于NLP的特征和来自其他来源的结构化特征；使用网格搜索进行超参数优化。无论何时需要测试、复制、序列化或发布这样一个管道，使用统一的API会带来好处，甚至超出了性能和重用的好处。企业级我们的第三个核心需求是提供一个关键任务的企业级NLP库。我们制作我们的生活建筑制作软件。当今许多最流行的NLP软件包都有其学术根源，这体现在设计上的取舍：相对于运行时性能，它更倾向于简单的原型设计，而不是简单的极简API，以及淡化可伸缩性、错误处理、节省内存消耗和代码重用。johnsnow Labs NLP库是用Scala编写的。它包括Scala和Python api，可供Spark使用。它不依赖于任何其他NLP或ML库。对于每种类型的注释器，我们都会进行学术文献回顾，以了解最新的技术，进行团队讨论并决定要实现哪种算法。根据三个标准评估实施情况：准确度——如果一个好的框架有低于标准的算法或模型，那就没有意义了。性能——运行时应该与任何公共基准相当或更好。没有人应该放弃准确性，因为注释器运行速度不够快，无法处理流式处理用例，或者在集群设置中伸缩性不好。可训练性或可配置性——NLP本质上是一个特定于领域的问题。美国证券交易委员会（SEC）发表的学术论文和学术论文中使用的词汇是不同的。该库已经在企业项目中使用，这意味着第一级的bug、重构、意外的瓶颈和序列化问题已经得到解决。单元测试覆盖率和参考文档的级别使我们能够轻松地将代码开源。约翰·斯诺实验室是一家领导和赞助Spark NLP库开发的公司。公司为其提供商业支持、赔偿和咨询。这为图书馆提供了长期的资金支持，一个有资金支持的活跃的开发团队，以及不断增长的现实世界项目流，这些项目推动了健壮性和路线图优先级的确定。参与其中如果您当前的项目需要NLP，请访问johnsnow Labs NLP for Apache Spark主页或快速入门指南，尝试一下。提供了预构建的mavencentral（Scala）和pip install（Python）版本。向我们发送问题或反馈nlp@johnsnowlabs.com或者通过Twitter、LinkedIn或GitHub。告诉我们您下一步需要什么功能。以下是我们收到的一些请求，我们正在寻求更多的反馈，以设计和确定优先级：提供SparkR客户端提供"Spark free"Java和Scala版本添加一个最先进的注释器用于共指解析为极性检测添加最先进的注释器为时间推理添加一个最先进的注释器发布常见用例的示例应用程序，如问答、文本摘要或信息检索为新的域或语言训练和发布模型发布可复制的、同行评审的准确性和性能基准如果你愿意的话