作者：Galina Olejnik
在撰写这篇文章之前，我首先需要说的是，我并不认为自己是一名优秀的数据科学家或机器学习工程师。但我有一些有趣且不可思议的（对我而言）工作经历，我仅仅是想分享从中学到的一些见解。
我是一名自然语言处理/机器学习科学家，而我不认为具有良好的计算机科学背景就能够成功地在这个领域工作。我所认识的杰出研究人员可能由于某些原因而不具有熟练的技能，无法成为实时开发和存储库团队的一部分。所以，我仍然想分享它们，也许有人会发现这些信息很有用。
我希望人们会喜欢我所讲的故事。
（1）处理异常是至关重要的
当我第一次尝试连接到存储在谷歌云上的这个特定MySQL数据库时，曾遇到许多不同的错误。当设置代理时，对很多代理进行了体验。问题是，在代码开发的第一阶段，最好是处理所有的错误，特别是与连接有关的错误，如果需要的话，引发这些错误，否则调用Exchange语句。
这听起来很简单，但在我的例子中，可能有环境变量，其中有UNIX套接字名称和节点环境名称，它们的值可能不正确，数据库凭据也可能不正确，我可以拥有它所有的东西。我在处理这些例子期间花费几个小时，但节省了很多时间，我很高兴将这段时间用于这个阶段的项目开发。
（2）适当的抽象类是无价的
在处理抽象类时，你需要记住的最重要的事情是，可能需要花费大量时间和注意力来定义它，并且也确实需要它。我的存储库的结构基于这样一个事实，即我必须创建许多.csv文件，这些文件具有非常相似的模式（唯一键）。事实上，我有很多类似的提取器、算法、数据后置处理器等工具，所有这些都被简化为基本抽象类，这使得下一个模块的创建更加容易。
当你编写第n个模块时，可以意识到你的类已经完成了，并且明白编译过程中没有定义的构造函数和一些方法已经实现了，因此不需要为它们烦恼。
（3）灵活的存储库结构总是最好的
有时它可能看起来有点难看（例如，在一个文件夹中有1个文件），但如果看到需要更改一些关键模块（例如文本预处理器）并且这样做，只需更改1-2个文件，那就很好了。
我并不是一名软件架构师，所以很难说出这个领域的优点和错误，但我认为组件的高度碎片化和独立性总是良好的。我自己开发的repoI有大量的小文件夹，并且引向它们比尝试使整个架构更加容易（也许更漂亮）。
（4）数据科学模型的测试是值得的
我没有足够的时间来完成涵盖所有案例的完美测试。我仍然提到这一点的原因是，如果你没有那么明显的ML/NLP模型行为，最好至少为了自己而进行测试。
我没有很多NLP/ML算法（其中大部分算法都很简单），但如果没有实施哪怕最简单的测试的话，它们的其他部分就无法支持。此外，在更好的模型理解方面，测试通常是有用的，这是因为通过断言语句，当希望在头脑中刷新算法时，一些算法概念可能变得更加清晰。
（5）使数据库符合第三范式
有时这可能是人们讨论的一部分，但是如果不使所有3个语句完全适用于数据库，就无法编写有效的数据处理系统。如果没有它们，一些不明显的查询问题经常发生，甚至无法找到问题所在。
这里有一个简短而简单的SQL NF指南，我认为最好多看几遍。（ https://www.geeksforgeeks.org/database-normalization-normal-forms/ ）
（6）记录错误
在实现记录时，通常不会查看收到三年所有的警告和错误，但有些错误可能不可重复，而且日志记录帮助理解发生了什么事。我是在我的本地机器上实施的，当服务器上的某些东西没有工作时，通过查看类似的案例，可以节省几个小时的时间。
（7）除非数据库非常简单，否则不需要对象关系映射（ORM）
在这个项目工作的很长一段时间里，我真的很担心需要用对象关系映射（ORM）重写所有内容。但是我错了。
实际上，像SQLAlchemy和Peewee这样的东西适合小型的简单数据库，但是它们不适合像复杂数据库（有时它需要4个分组和5个连接来编写一个查询）。它们很优雅，有时非常简单和美观，但无论如何，如果你只使用连接器API，就不能拥有尽可能多的控制权。我决定使用MySQL Connector，因为用对象关系映射（ORM）编写所有内容可能会使棘手的事情变得更加复杂。
结论
这个注释与ML/ NLP算法解释及其性能讨论无关，但我仍然认为它很有用。我希望在开始研究这个项目之前已经知道了上面描述的所有陈述，但也确定，只有花费一些时间来修复bug，并寻找实际问题之后，它们中的一些问题才会变得清晰易懂。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31509949/viewspace-2212923/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/31509949/viewspace-2212923/
扫一扫
426
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
