前几天，我们决定与Scala数据分析计划的老师之一Dmitry Bugaychenko（ dmitrybugaychenko ）进行交谈，并与他讨论在数据科学和数据工程任务中使用Scala的实际问题。 Dmitry是Odnoklassniki的分析工程师。
-Dima，您在Odnoklassniki工作。 告诉我，你在那儿做什么？
在Odnoklassniki，我从2011年开始研究音乐建议草稿。 这是一项非常有趣且艰巨的任务-当时的大多数音乐推荐服务都基于精心编排的发行内容，而我们拥有真正的UGC（用户生成的内容），必须首先对其进行梳理和分类。 总的来说，最终的系统被证明是非常好的，他们决定将体验扩展到站点的其他部分：小组推荐，友谊，对提要进行排名等。 同时，团队不断壮大，开发了基础架构，并引入了新的算法和技术。 现在，我负有相当广泛的责任：协调科学家的数据，开发DS基础架构，研究项目等。
-您开始使用Spark多久了？ 有什么需要
与Spark交朋友的第一次尝试可以追溯到2013年，但没有成功。 我们迫切需要一个功能强大的交互式工具，该工具可以快速检验假设，但是那个时候的Spark无法提供我们所需的稳定性和可伸缩性。 一年后，2014年，我们进行了第二次尝试，这次结果一切都好得多。 同年，我们开始实施基于Kafka和Samza的流分析工具，尝试了Spark Streaming，但此后无法启动。 由于相对较早的实施，到2017年我们处于追赶状态-第一个Spark上的大量代码阻止我们切换到第二个，但是在2018年夏天，我们解决了这个问题，目前正在研究2.3.3。 在此版本中，流式传输已经更加稳定，我们已经在其上完成了一些新的生产任务。
-据我了解，您像大多数人一样使用Scala API，而不是Python。 为什么这样
我真诚地看到，除了懒惰之外，没有理由使用Python与Spark一起工作。 Scala API更灵活，更高效，但并不复杂。 如果使用Spark SQL的标准功能，则Scala代码几乎与相应的Python代码相同，并且速度将相同。 但是，如果您尝试制作最简单的用户定义函数，则区别将变得显而易见-Scala代码的工作效率仍然很高，而Python代码将多核集群变成南瓜，并开始燃烧千瓦/小时来完全没有生产力。 在我们工作的规模上，我们根本负担不起这种浪费。
-C Python是可以理解的。 与Java相比，Scala在数据分析方面是否更好？ 在Java中，很多东西都写在大数据堆栈中。
我们非常广泛地使用Java，包括在机器学习中。 我们尽量不要进入负载最大的Scala应用程序。 但是，当涉及到交互式分析和快速原型制作时，Scala的简单性成为一个加分项。 没错，您应该始终牢记，在Scala中进行编程时，将双腿伸向耳朵很容易-许多设计的行为可能与您从常识位置所期望的不一样，并且一些简单的操作会导致不必要的复制并尝试实现巨大的复制内存中的数据集。
-具有所有这些优点，为什么Scala尚未那么受欢迎？ 它明显胜过Python和Java吗？
Scala是一种非常强大的工具，需要使用它的人具有足够的资格。 此外，随着团队的发展，对开发文化的一般水平也提出了额外的要求：Scala上的代码很容易编写，但一段时间后作者并不总是能够成功读取，并且在简单的API的支持下，它可以创建某种游戏。 因此，应特别注意保持解决方案的统一样式，功能和压力测试。
好吧，在比较JVM语言时，不能不提及Kotlin，它变得越来越流行，被许多人认为是经过“意识形态验证”的，甚至还支持Spark作为sparklin项目的一部分，尽管它仍然非常有限。 我们自己尚未将其用于Spark，但我们一直在密切关注开发过程。
-回到星火。 据我了解，您甚至都不喜欢Scala API功能，并且为Spark写了一些fork？
调用我们的PravdaML项目分叉是错误的：此库不会替代，而是用新功能补充SparkML功能。 我们做出了在那里执行的决定，试图扩展磁带排名模型并将其放到可复制的轨道上。 事实是，在开发有效的分布式机器学习算法时，您需要考虑许多“技术”因素：如何将数据正确地分解为节点，在什么位置进行缓存，下采样等。 在标准SparkML中无法管理这些方面，因此必须将它们移到ML管道之外，这会对可管理性和可重复性产生负面影响。
-我记得您有两个名字可以选择...
是的，最初的名称ok-ml-pipelines似乎无聊，所以我们现在正在使用新名称PravdaML进行“品牌重塑”。
-很多人在您的团队之外使用它吗？
我考虑不多，但我们正在努力。 Ĵ
-让我们谈谈在数据处理领域中的角色和专业。 告诉我，数据科学家应该在生产中编写代码吗？或者这已经是其他职业和角色了？
这个问题的答案是我的观点，这是一个残酷的现实。 我一直相信，为了成功实施ML解决方案，一个人必须了解在哪里以及为什么全部实施它（用户是谁，他的需求是什么以及业务有什么需求），他需要了解可以使用哪些数学方法来开发解决方案，以及从技术角度来看这些方法如何工作。 因此，在Odnoklassniki中，当一个人提出一些倡议，执行并执行该倡议时，我们仍然尝试遵循单一责任模型。 当然，要解决单个的私人问题，无论是有效的DBMS还是交互式布局，您始终可以吸引在这些领域具有丰富经验的人员，但是将所有这些集成到单个机制中的仍然是科学家，因为该人员最了解确切的含义和工作方式。输出。
但是，劳动力市场上也存在着严酷的现实，现在在机器学习领域已经非常过热，这导致了一个事实，即许多年轻的专家认为除了机器学习本身以外，没有必要学习其他任何东西。 结果，找到全职专家变得越来越困难。 尽管最近出现了一个很好的替代方法：实践表明，优秀的程序员可以很快且非常好地学习ML。 Ĵ
-日期工程师需要了解Scala吗？ 顺便说一句好吗？ 我需要进入函数式编程的丛林吗？
了解Scala绝对是必要的，因为仅仅是因为上面写了两个基本工具（如Kafka和Spark），并且您需要能够阅读它们的源代码。 至于“函数式编程的混乱”，我强烈建议他们不要滥用太多：开发人员可以阅读和理解代码的越多越好。 即使为此，有时您也必须以平淡的周期“优雅地”进行功能设计。
-这个领域的专业领域已经停止扩大，还是我们应该等待它出现一些新的专业？
我认为，在可预见的ML和DS未来，将出现与自动化有关的转折点：人们在使用属性，选择模型及其参数以及检查质量时将遵循的主要模式将实现自动化。 这将导致以下事实：对“选择参数”的专家的需求将大大减少，但是将需要能够实施和开发自动化解决方案的AutoML工程师。
“据我所知，您正在积极教学。” 您为什么认为这很重要？ 这背后的动机是什么？
我们所有人都将有一天退休，而我们的生活质量将在很大程度上取决于谁将取代我们。 因此，对下一代教育的投资是最重要的之一。
-在我们的“ Scala数据分析”程序中，您将进行几节课。 简单介绍一下。 它们的重要性是什么？
在这些课程中，我们将研究工程与数学如何融合在一起：如何正确地组织过程，而不会给ETL-> ML-> Prod带来不必要的障碍。 该课程将围绕Spark ML的功能构建：基本概念，支持的转换，已实现的算法及其局限性。 我们将介绍现有SparkML功能还不够的领域，因此有必要使用诸如PravdaML之类的扩展。 好吧，肯定会有实践，不仅是在“从现成的多维数据集组装解决方案”的级别，而且还将是关于如何理解这里需要一个新的“多维数据集”以及如何实现它的实践。
-Scala中有没有最喜欢的双关语？ 攀岩墙，攀岩，岩石艺术品-您是否在日常活动中使用？
除非使用“ indoskal”这个称呼（我们用来解决特别出色的开源代码），否则其作者显然想证明其使用功能抽象构造不可读代码的卓越能力。
-莫斯科还是彼得？
每个城市都有自己的热情。 莫斯科是一个富裕且整齐的城市，节奏快。 彼得比较镇定，充满了前欧洲首都的魅力。 因此，我喜欢来莫斯科参观，但我更喜欢住在圣彼得堡。