El otro día, decidimos hablar con Dmitry Bugaychenko ( dmitrybugaychenko ), uno de nuestros maestros del programa Análisis de datos en Scala, y discutir con él los problemas reales de usar Scala en las tareas de Ciencia de datos e Ingeniería de datos. Dmitry es ingeniero analítico en Odnoklassniki.
- Dima, trabajas en Odnoklassniki. Dime, que haces ahí?
En Odnoklassniki, comencé a trabajar en 2011 en un borrador de recomendación musical. Fue una tarea muy interesante y difícil: la mayoría de los servicios de recomendación de música en ese momento se basaban en contenido de publicación bien catalogado, mientras que teníamos UGC real (contenido generado por el usuario), que primero tenía que peinarse y clasificarse en estantes. En general, el sistema resultante demostró ser bastante bueno y decidieron extender la experiencia a otras secciones del sitio: recomendaciones grupales, amistades, clasificación de los feeds, etc. Al mismo tiempo, el equipo creció, se desarrolló la infraestructura, se introdujeron nuevos algoritmos y tecnologías. Ahora tengo una amplia gama de responsabilidades: coordinación de los datos de los científicos, desarrollo de infraestructura DS, proyectos de investigación, etc.
- ¿Cuánto tiempo llevas usando Spark? Cual es la necesidad?
Los primeros intentos de hacerse amigo de Spark fueron en 2013, pero no tuvieron éxito. Teníamos una necesidad urgente de una poderosa herramienta interactiva que nos permitiera probar hipótesis rápidamente, pero Spark de esa época no podía proporcionar la estabilidad y escalabilidad que necesitábamos. El segundo intento lo hicimos un año después, en 2014, y esta vez todo salió mucho mejor. En el mismo año, comenzamos a presentar herramientas de análisis de transmisión basadas en Kafka y Samza, probamos Spark Streaming, pero luego no pudo comenzar. Debido a la implementación relativamente temprana, para 2017 estábamos en condiciones de ponernos al día por un tiempo: una gran cantidad de código en el primer Spark nos impidió cambiar al segundo, pero en el verano de 2018 resolvimos este problema y ahora estamos trabajando en 2.3.3. En esta versión, la transmisión ya ha funcionado de manera más estable y ya hemos realizado algunas nuevas tareas de producción.
- Según tengo entendido, usas la API de Scala, no Python, como la mayoría. Por qué
Sinceramente, no veo ninguna razón para usar Python para trabajar con Spark, excepto por la pereza. Scala API es más flexible y mucho más eficiente, pero no más complicado. Si usa las características estándar de Spark SQL, entonces el código Scala es casi idéntico al código Python correspondiente, y la velocidad será idéntica. Pero si intenta hacer la función definida por el usuario más simple, la diferencia se vuelve obvia: el trabajo del código Scala sigue siendo tan eficiente, y el código Python convierte un clúster de múltiples núcleos en una calabaza y comienza a quemar kilovatios / hora para una actividad completamente improductiva. En la escala con la que tenemos que trabajar, simplemente no podemos permitirnos tal despilfarro.
- C Python es comprensible. Y en comparación con Java, ¿Scala es algo mejor para el análisis de datos? En Java, se escriben muchas cosas en la pila de Big Data.
Usamos Java muy ampliamente, incluso en el aprendizaje automático. Intentamos no entrar en las aplicaciones Scala más cargadas. Pero cuando se trata de análisis interactivo y creación rápida de prototipos, el laconismo de Scala se convierte en una ventaja. Es cierto, siempre debe tener en cuenta que al programar en Scala es muy fácil disparar las piernas a los oídos: muchos diseños pueden no comportarse como se esperaría de una posición de sentido común, y algunas operaciones simples causan copias innecesarias e intentos de materializar enormes conjuntos de datos en la memoria.
- Con todas estas ventajas, ¿por qué Scala no es tan popular todavía? ¿Supera claramente a Python y Java?
Scala es una herramienta muy poderosa que requiere una calificación suficientemente alta de quien la usa. Además, con el desarrollo del equipo, también se imponen requisitos adicionales en el nivel general de la cultura de desarrollo: el código en Scala es muy fácil de escribir, pero el autor no siempre lo lee con éxito después de un tiempo y, bajo el capó de una API simple, puede crear algún tipo de juego. Por lo tanto, se debe prestar especial atención a mantener un estilo unificado, funcional y pruebas de estrés de la solución.
Bueno, cuando se comparan los lenguajes JVM, no se puede dejar de mencionar Kotlin: está ganando popularidad, muchos lo consideran más "ideológicamente verificado" e incluso admite Spark como parte del proyecto sparklin, aunque todavía es muy limitado. Nosotros mismos todavía no lo usamos para Spark, pero seguimos de cerca el desarrollo.
- De vuelta a Spark. Según tengo entendido, ¿aún no te gustó esta funcionalidad de API Scala y escribiste algún tipo de bifurcación para Spark?
Sería un error llamar a nuestra bifurcación del proyecto PravdaML : esta biblioteca no reemplaza, pero complementa la funcionalidad de SparkML con nuevas características. Llegamos a las decisiones que se implementaron allí, tratando de escalar y poner en los rieles reproducibles los modelos de clasificación de cintas. El hecho es que al desarrollar algoritmos de aprendizaje automático distribuidos efectivos, debe tener en cuenta muchos factores "técnicos": cómo descomponer adecuadamente los datos en nodos, en qué punto almacenar en caché, reducir la muestra, etc. No hay forma de gestionar estos aspectos en el SparkML estándar, y tienen que moverse más allá de la tubería ML, lo que afecta negativamente la capacidad de gestión y la reproducibilidad.
- Recuerdo que tenías dos opciones para el nombre ...
Sí, el nombre original ok-ml-pipelines parecía aburrido para los chicos, por lo que ahora estamos en el proceso de "cambio de marca" con el nuevo nombre PravdaML.
- Mucha gente lo usa fuera de su equipo?
No pienso mucho, pero estamos trabajando en ello. J
- Hablemos de roles y profesiones en el campo de trabajar con datos. Dime, ¿debería un científico de datos escribir código en producción o ya es alguna otra profesión y función?
La respuesta a esta pregunta es mi opinión, y hay una dura realidad. Siempre pensé que para la implementación exitosa de soluciones ML, una persona debe comprender dónde y por qué se está implementando todo (quién es el usuario, cuáles son sus necesidades y qué necesidades tiene el negocio), necesita comprender qué métodos matemáticos se pueden aplicar para desarrollar la solución, y cómo pueden funcionar estos métodos desde un punto de vista técnico. Por lo tanto, en Odnoklassniki todavía tratamos de adherirnos al modelo de responsabilidad única, cuando una persona presenta alguna iniciativa, la implementa y la implementa. Por supuesto, para resolver problemas privados individuales, ya sea un DBMS efectivo o un diseño interactivo, siempre puede atraer a personas con una amplia experiencia en estas áreas, pero la integración de todo esto en un solo mecanismo permanece con el Científico, como la persona que mejor comprende exactamente qué y cómo debería funcionar salida.
Pero también existe una dura realidad en el mercado laboral, que ahora está muy sobrecalentado en el campo de la ML, lo que lleva al hecho de que muchos especialistas jóvenes no consideran necesario estudiar nada más que la propia ML. Como resultado, se hace cada vez más difícil encontrar un especialista de ciclo completo. Aunque recientemente apareció una buena alternativa: la práctica ha demostrado que los buenos programadores aprenden ML bastante rápido y bastante bien. J
- Fecha ingeniero necesita saber Scala? ¿Qué tan bueno por cierto? ¿Necesito entrar en la jungla de la programación funcional?
Definitivamente es necesario conocer Scala, aunque solo sea porque dos herramientas fundamentales como Kafka y Spark están escritas en él, y necesita poder leer su código fuente. En cuanto a la "jungla de la programación funcional", les recomiendo encarecidamente que no abusen demasiado: cuanto más los desarrolladores puedan leer y comprender el código, mejor. Incluso si para esto a veces hay que desplegar un diseño funcional "elegante" en un ciclo banal.
- El universo de profesiones en esta área ya ha dejado de expandirse, ¿o deberíamos esperar la aparición de nuevas profesiones en él?
Creo que en el futuro previsible en ML y DS habrá un punto de inflexión relacionado con la automatización: los patrones principales que las personas siguen al trabajar con atributos, elegir un modelo y sus parámetros y verificar la calidad se automatizarán. Esto conducirá al hecho de que la demanda de especialistas que "seleccionan los parámetros" disminuirá significativamente, pero los ingenieros de AutoML que pueden implementar y desarrollar soluciones automatizadas tendrán demanda.
"Estás enseñando activamente, según tengo entendido". ¿Por qué consideras esto importante? ¿Cuál es la motivación detrás de esto?
Todos nosotros algún día nos jubilaremos y la calidad de nuestra vida dependerá en gran medida de quién nos reemplazará. Por lo tanto, la inversión en la educación de la próxima generación es una de las más importantes.
- En nuestro programa "Análisis de datos en Scala" llevará a cabo varias clases. Cuéntame brevemente sobre ellos. ¿Cuál es su importancia?
En estas clases, solo estudiaremos cómo encajan la ingeniería y las matemáticas: cómo organizar el proceso correctamente, sin introducir barreras innecesarias para ETL-> ML-> Prod. El curso se desarrollará en torno a las capacidades de Spark ML: conceptos básicos, conversiones compatibles, algoritmos implementados y sus limitaciones. Tocaremos el área donde las características existentes de SparkML no son suficientes, y se hace necesario usar extensiones como PravdaML. Bueno, definitivamente habrá práctica, no solo a nivel de "ensamblar una solución a partir de cubos ya hechos", sino también sobre cómo entender que se necesita un nuevo "cubo" aquí y cómo implementarlo.
- ¿Hay algún juego de palabras favorito con Scala? Muro de escalada, escalador, arte rupestre: ¿lo utiliza en su rutina diaria?
A menos que el epíteto "indoskal", que utilizamos para abordar piezas de código abierto particularmente notables, cuyo autor claramente quería demostrar la notable capacidad de construir código ilegible utilizando abstracciones funcionales.
- Moscú o Peter?
Cada ciudad tiene su propio entusiasmo. Moscú es una ciudad rica y cuidada con un ritmo rápido. Peter está más tranquilo y lleno del encanto de la antigua capital europea. Por lo tanto, me gusta visitar Moscú, pero prefiero vivir en San Petersburgo.