Suatu hari, kami memutuskan untuk berbicara dengan Dmitry Bugaychenko ( dmitrybugaychenko ), salah satu guru kami dari Analisis Data pada program Scala, dan mendiskusikan dengannya masalah aktual penggunaan Scala dalam tugas-tugas Ilmu Data dan Teknik Data. Dmitry adalah seorang insinyur analitik di Odnoklassniki.
- Dima, kamu bekerja di Odnoklassniki. Katakan padaku, apa yang kamu lakukan disana?
Di Odnoklassniki, saya mulai bekerja pada 2011 dengan rekomendasi musik konsep. Itu adalah tugas yang sangat menarik dan sulit - sebagian besar layanan rekomendasi musik pada saat itu didasarkan pada konten penerbitan yang dikatalogkan dengan baik, sementara kami memiliki UGC nyata (konten yang dibuat pengguna), yang harus disisir dan disortir terlebih dahulu ke rak. Secara umum, sistem yang dihasilkan terbukti cukup baik dan mereka memutuskan untuk memperluas pengalaman ke bagian lain dari situs: rekomendasi grup, persahabatan, peringkat umpan, dll. Pada saat yang sama, tim tumbuh, infrastruktur berkembang, algoritma dan teknologi baru diperkenalkan. Sekarang saya memiliki tanggung jawab yang cukup luas: koordinasi data Ilmuwan, pengembangan infrastruktur DS, proyek penelitian, dll.
- Berapa lama Anda mulai menggunakan Spark? Apa yang dibutuhkan?
Upaya pertama untuk berteman dengan Spark kembali pada 2013, tetapi tidak berhasil. Kami memiliki kebutuhan mendesak akan alat interaktif yang kuat yang memungkinkan kami untuk dengan cepat menguji hipotesis, tetapi Percikan waktu itu tidak dapat memberikan stabilitas dan skalabilitas yang kami butuhkan. Upaya kedua kami lakukan setahun kemudian, pada 2014, dan kali ini semuanya ternyata jauh lebih baik. Pada tahun yang sama, kami mulai memperkenalkan alat analisis streaming berdasarkan Kafka dan Samza, mencoba Spark Streaming, tetapi kemudian tidak dapat memulai. Karena implementasi yang relatif awal, pada 2017 kami berada dalam posisi mengejar ketinggalan untuk sementara waktu - sejumlah besar kode pada Spark pertama mencegah kami beralih ke yang kedua, tetapi pada musim panas 2018 kami menyelesaikan masalah ini dan sekarang bekerja pada 2.3.3. Dalam versi ini, streaming sudah bekerja lebih stabil dan kami telah melakukan beberapa tugas prod baru di atasnya.
- Seperti yang saya pahami, Anda menggunakan Scala API, bukan Python, seperti kebanyakan. Kenapa begitu
Saya dengan tulus tidak melihat alasan untuk menggunakan Python untuk bekerja dengan Spark, kecuali untuk kemalasan. Scala API lebih fleksibel dan jauh lebih efisien, tetapi tidak lebih rumit. Jika Anda menggunakan fitur standar Spark SQL, maka kode Scala hampir identik dengan kode Python yang sesuai, dan kecepatannya akan sama. Tetapi jika Anda mencoba membuat fungsi sederhana yang ditentukan pengguna, perbedaannya menjadi jelas - pekerjaan kode Scala tetap seefisien, dan kode Python mengubah kluster multi-inti menjadi labu dan mulai membakar kilowatt / jam untuk aktivitas yang sama sekali tidak produktif. Pada skala di mana kita harus bekerja, kita tidak mampu menanggung pemborosan seperti itu.
- C Python bisa dimengerti. Dan bila dibandingkan dengan Java, apakah Scala sesuatu yang lebih baik untuk analisis data? Di Jawa, banyak hal ditulis dalam tumpukan data besar.
Kami menggunakan Java sangat luas, termasuk dalam pembelajaran mesin. Kami mencoba untuk tidak menarik ke dalam aplikasi Scala paling banyak dimuat. Tapi ketika datang ke analisis interaktif dan prototyping cepat, singkatnya Scala menjadi nilai tambah. Benar, Anda harus selalu ingat bahwa ketika pemrograman di Scala, sangat mudah untuk menembakkan kaki Anda ke telinga - banyak desain mungkin tidak berperilaku seperti yang Anda harapkan dari posisi akal sehat, dan beberapa operasi sederhana menyebabkan penyalinan yang tidak perlu dan upaya untuk mewujudkan besar dataset dalam memori.
- Dengan semua kelebihan ini, mengapa Scala belum begitu populer? Apakah itu jelas mengungguli Python dan Java?
Scala adalah alat yang sangat kuat yang membutuhkan kualifikasi yang cukup tinggi dari orang yang menggunakannya. Selain itu, selama pengembangan tim, persyaratan tambahan juga diberlakukan pada tingkat umum budaya pengembangan: kode pada Scala sangat mudah untuk ditulis, tetapi tidak selalu berhasil dibaca oleh penulis setelah beberapa waktu, dan di bawah kap API sederhana dapat membuat beberapa jenis permainan. Oleh karena itu, perhatian khusus harus diberikan untuk mempertahankan gaya terpadu, fungsional dan pengujian stres dari solusi.
Nah, ketika membandingkan bahasa JVM, orang tidak bisa tidak menyebutkan Kotlin - itu semakin populer, dianggap oleh banyak orang lebih "diverifikasi secara ideologis", dan bahkan mendukung Spark sebagai bagian dari proyek sparklin, meskipun masih sangat terbatas. Kami sendiri belum menggunakannya untuk Spark, tetapi kami terus mengikuti perkembangannya.
- Kembali ke Spark. Seperti yang saya pahami, Anda masih tidak menyukai bahkan fungsi Scala API ini dan Anda menulis semacam garpu untuk Spark?
Akan salah jika memanggil garpu proyek PravdaML kami: pustaka ini tidak menggantikan, tetapi menambah fungsionalitas SparkML dengan fitur-fitur baru. Kami sampai pada keputusan yang diterapkan di sana, mencoba untuk menskalakan dan menempatkan pada rel yang dapat direproduksi model pemeringkatan tape. Faktanya adalah bahwa ketika mengembangkan algoritma pembelajaran mesin terdistribusi yang efektif, Anda perlu mempertimbangkan banyak faktor "teknis": bagaimana cara menguraikan data dengan benar menjadi node, pada titik apa untuk cache, downsample, dll. Tidak ada cara untuk mengelola aspek-aspek ini dalam SparkML standar, dan mereka harus dipindahkan melampaui pipa ML, yang secara negatif mempengaruhi pengelolaan dan reproduktifitas.
- Saya ingat Anda memiliki dua opsi untuk nama ...
Ya, nama asli ok-ml-pipeline tampak membosankan bagi mereka, jadi kita sekarang dalam proses “rebranding” dengan nama baru PravdaML.
- Banyak orang menggunakannya di luar tim Anda?
Saya tidak banyak berpikir, tetapi kami sedang mengusahakannya. J
- Mari kita bicara tentang peran dan profesi di bidang bekerja dengan data. Katakan padaku, apakah seorang ilmuwan data harus menulis kode dalam produksi atau apakah ini sudah merupakan profesi dan peran lain?
Jawaban atas pertanyaan ini adalah pendapat saya, dan ada kenyataan pahit. Saya selalu percaya bahwa untuk keberhasilan implementasi solusi ML, seseorang harus memahami di mana dan mengapa itu semua dilaksanakan (siapa pengguna, apa kebutuhannya, dan apa kebutuhan bisnis), ia perlu memahami metode matematika apa yang dapat diterapkan untuk mengembangkan solusi, dan bagaimana metode ini dapat bekerja dari sudut pandang teknis. Oleh karena itu, dalam Odnoklassniki kita masih mencoba untuk mematuhi model tanggung jawab tunggal, ketika seseorang datang dengan beberapa inisiatif, mengimplementasikan dan mengimplementasikannya. Tentu saja, untuk menyelesaikan masalah pribadi, apakah itu DBMS yang efektif atau tata letak interaktif, Anda selalu dapat menarik orang-orang dengan pengalaman luas di bidang-bidang ini, tetapi integrasi semua ini ke dalam satu mekanisme tetap ada pada Ilmuwan, sebagai orang yang paling mengerti apa yang sebenarnya dan bagaimana seharusnya bekerja pada keluaran.
Tetapi ada kenyataan pahit di pasar tenaga kerja, yang sekarang sangat panas di bidang ML, yang mengarah pada fakta bahwa banyak spesialis muda tidak menganggap perlu mempelajari apa pun selain ML itu sendiri. Akibatnya, semakin sulit untuk menemukan spesialis siklus penuh. Meskipun alternatif yang baik baru-baru ini muncul: praktik telah menunjukkan bahwa pemrogram yang baik belajar ML cukup cepat dan cukup baik. J
- Teknisi kencan perlu tahu Scala? Seberapa baik omong-omong? Apakah saya perlu pergi ke hutan pemrograman fungsional?
Sangat penting untuk mengetahui Scala, jika hanya karena dua alat mendasar seperti Kafka dan Spark tertulis di dalamnya, dan Anda harus dapat membaca kode sumbernya. Adapun "hutan pemrograman fungsional", saya akan sangat menyarankan mereka untuk tidak menyalahgunakan terlalu banyak: semakin banyak pengembang dapat membaca dan memahami kode, semakin baik. Bahkan jika untuk ini kadang-kadang Anda harus menyebarkan desain fungsional "elegan" dalam siklus dangkal.
- Semesta profesi di bidang ini telah berhenti berkembang, atau haruskah kita masih menunggu munculnya profesi baru di dalamnya?
Saya pikir di masa yang akan datang dalam ML dan DS akan ada titik balik terkait dengan otomatisasi: pola utama yang diikuti orang ketika bekerja dengan atribut, memilih model dan parameternya, dan memeriksa kualitas akan otomatis. Ini akan mengarah pada kenyataan bahwa permintaan untuk spesialis yang "memilih parameter" akan menurun secara signifikan, tetapi para insinyur AutoML yang dapat menerapkan dan mengembangkan solusi otomatis akan diminati.
"Kamu aktif mengajar, seperti yang aku mengerti." Mengapa Anda menganggap ini penting? Apa motivasi di balik ini?
Kita semua suatu hari akan pensiun dan kualitas hidup kita akan sangat tergantung pada siapa yang akan menggantikan kita. Oleh karena itu, investasi dalam pendidikan generasi berikutnya adalah salah satu yang paling penting.
- Pada program kami "Analisis Data pada Scala" Anda akan melakukan beberapa kelas. Ceritakan secara singkat tentang mereka. Apa pentingnya mereka?
Di kelas-kelas ini, kita hanya akan mempelajari bagaimana teknik dan matematika cocok bersama: bagaimana mengatur proses dengan benar, tanpa memperkenalkan hambatan yang tidak perlu untuk ETL-> ML-> Prod. Kursus ini akan dibangun di sekitar kemampuan Spark ML: konsep dasar, konversi yang didukung, algoritma yang diterapkan, dan batasannya. Kami akan menyentuh area di mana fitur SparkML yang ada tidak cukup, dan menjadi perlu untuk menggunakan ekstensi seperti PravdaML. Yah, pasti akan ada latihan, tidak hanya pada tingkat "merakit solusi dari kubus siap pakai", tetapi juga tentang bagaimana memahami bahwa "kubus" baru diperlukan di sini dan bagaimana menerapkannya.
- Apakah ada permainan favorit dengan Scala? Dinding panjat, pemanjat tebing, seni cadas - apa yang Anda gunakan dalam rutinitas harian Anda?
Kecuali julukan "indoskal", yang kami gunakan untuk menangani bagian open source yang luar biasa, penulis yang jelas ingin menunjukkan kemampuan luar biasa untuk membangun kode yang tidak dapat dibaca menggunakan abstraksi fungsional.
- Moskow atau Peter?
Setiap kota memiliki semangatnya sendiri. Moskow adalah kota yang kaya dan terawat dengan irama cepat. Peter lebih tenang dan penuh dengan pesona bekas ibu kota Eropa. Oleh karena itu, saya suka datang ke Moskow untuk berkunjung, tetapi saya lebih suka tinggal di St. Petersburg.