Kami sering menemukan artikel berbahasa Inggris keren yang tampaknya bermanfaat bagi tim kami, dan memutuskan akan lebih baik untuk berbagi terjemahan mereka dengan pembaca Habra. Hari ini kami telah menyiapkan terjemahan artikel oleh Tristan Handy, pendiri Fishtown Analytics.
Peran seorang insinyur data dalam startup modern berubah dengan cepat. Apakah Anda yakin bahwa Anda memahami dengan baik kapan dan mengapa tim Anda mungkin membutuhkan spesialis seperti itu?
Saya sering berkomunikasi dengan perwakilan terkemuka dunia analitik dan memperhatikan bahwa pemahaman mereka tentang peran seorang insinyur data dalam tim tidak benar. Ini dapat membuat kesulitan bagi seluruh tim analisis data, dan saya ingin perusahaan untuk belajar bagaimana menghindari masalah seperti itu.
Pada artikel ini saya ingin membagikan ide-ide saya tentang kapan, bagaimana, dan mengapa layak mempekerjakan seorang insinyur data. Diskusi saya didasarkan pada pengalaman saya di Fishtown Analytics , di mana saya bekerja dengan lebih dari seratus startup dengan dukungan modal ventura dan membantu mereka membangun tim analisis dan pemrosesan data, serta pengetahuan yang diperoleh melalui komunikasi dengan perwakilan dari berbagai perusahaan pemrosesan data.
Jika Anda memimpin tim pakar data, pos ini untuk Anda.
Peran seorang insinyur data berubah
Perangkat lunak modern memungkinkan untuk mengotomatisasi pekerjaan yang lebih membosankan terkait dengan analisis dan pemrosesan data.
Pada 2012, setidaknya satu insinyur data diperlukan untuk menganalisis seluruh dataset dalam startup yang didanai ventura. Spesialis seperti itu harus mengekstraksi data dari sistem yang berbeda sehingga analis dan klien korporat dapat bekerja dengan mereka lebih lanjut. Seringkali diperlukan untuk mengubah data sehingga entah bagaimana lebih mudah untuk dianalisis. Tanpa seorang insinyur data, spesialis analisis dan pemrosesan data tidak akan memiliki data yang dapat digunakan untuk bekerja, sehingga sering kali dengan insinyur data itulah tim mulai terbentuk.
Pada 2019, sebagian besar ini dapat dilakukan dengan solusi yang sudah jadi. Dalam kebanyakan kasus, Anda dan tim analis dapat membangun jalur pemroses data sendiri, tanpa bantuan orang dengan pengalaman luas dalam ilmu data. Dan saluran pipa ini tidak akan buruk sama sekali - alat modern yang siap pakai sempurna untuk memecahkan masalah seperti itu.
Analis dan ilmuwan data baru-baru ini memiliki kesempatan untuk membangun jaringan pipa sendiri - hanya 2-3 tahun yang lalu. Ini terjadi terutama karena tiga produk: Stitch , Fivetran dan dbt (perlu dikatakan bahwa dbt adalah produk dari perusahaan saya, Fishtown Analytics). Mereka dirilis segera setelah Amazon Redshift, ketika tim analis startup menyadari bahwa mereka perlu membuat gudang data. Butuh beberapa tahun lagi untuk membuat produk-produk ini berkualitas tinggi - pada tahun 2016 kami masih pelopor.
Sekarang pipa yang dibangun menggunakan Stitch, Fivetran atau dbt jauh lebih dapat diandalkan daripada apa yang dirancang khusus menggunakan Airflow. Saya tahu ini bukan dari teori, tetapi dari pengalaman saya sendiri. Saya tidak mengatakan bahwa tidak mungkin untuk membangun infrastruktur yang andal dengan Airflow, kebanyakan startup tidak melakukannya. Di Fishtown Analytics, kami telah bekerja dengan lebih dari seratus tim analitik di berbagai startup, dan skenario ini telah diulang berkali-kali. Kami terus membantu orang beralih dari saluran pipa mereka sendiri ke solusi turnkey, dan setiap kali efeknya positif.
Insinyur Data Jangan Menulis ETL
Pada 2016, Jeff Magnusson menulis posting mendasar, Insinyur Data Tidak Harus Menulis ETL . Ini adalah posting pertama di ingatan saya yang menyerukan perubahan seperti itu. Inilah bagian favorit saya dari sana:
* “Selama 5 tahun terakhir, alat dan teknologi pemrosesan data telah berkembang. Sebagian besar teknologi telah berkembang sangat banyak sehingga mereka dapat beradaptasi dengan kebutuhan Anda, kecuali, tentu saja, Anda perlu memproses petabyte data atau milyaran peristiwa per hari.
Jika Anda tidak perlu melampaui kemampuan teknologi ini, kemungkinan besar Anda tidak membutuhkan tim programmer yang sangat terspesialisasi untuk mengembangkan solusi tambahan.
Jika Anda berhasil mempekerjakan mereka, mereka akan segera bosan. Jika mereka bosan, mereka akan meninggalkan Anda di Google, Facebook, LinkedIn, Twitter - tempat di mana pengalaman mereka benar-benar diperlukan. Jika mereka tidak bosan, kemungkinan besar mereka agak biasa-biasa saja. Dan programmer biasa-biasa saja benar-benar berhasil membangun sejumlah besar rumit, tidak cocok untuk omong kosong kerja normal, yang mereka sebut "solusi". "*
Saya sangat suka kutipan ini karena tidak hanya menekankan bahwa hari ini Anda tidak memerlukan insinyur data untuk menyelesaikan sebagian besar masalah ETL, tetapi juga menjelaskan mengapa Anda sebaiknya tidak meminta mereka untuk menyelesaikan masalah ini sama sekali .
Jika Anda menyewa insinyur data dan meminta mereka membangun saluran pipa, mereka akan berpikir bahwa tugas mereka adalah membangun saluran pipa. Ini berarti bahwa alat seperti Stitch, Fivetran dan dbt akan menjadi ancaman bagi mereka, bukan sumber kekuatan yang kuat. Mereka akan menemukan alasan mengapa saluran pipa yang sudah selesai tidak memenuhi kebutuhan data pribadi Anda dan mengapa analis tidak boleh secara independen terlibat dalam konversi data. Mereka akan menulis kode yang rapuh, sulit dipelihara, dan tidak efisien. Dan Anda akan bergantung pada kode ini karena mendasari segala hal lain yang dilakukan tim Anda.
Lari dari spesialis seperti wabah. Tingkat pertumbuhan dalam tim analis Anda akan turun tajam, dan Anda akan menghabiskan seluruh waktu Anda untuk menyelesaikan masalah infrastruktur, dan ini sama sekali bukan apa yang mendatangkan penghasilan bagi bisnis Anda.
Jika bukan ETL, lalu apa?
Apakah tim Anda benar-benar membutuhkan seorang insinyur data? Ya
Bahkan dengan alat baru yang memungkinkan analis data dan pakar ilmu data untuk membuat jalur pipa sendiri, para insinyur data masih merupakan bagian penting dari tim data profesional apa pun. Namun, tugas-tugas yang harus mereka kerjakan telah berubah, dan urutan di mana layak mempekerjakan karyawan untuk bekerja dengan data. Di bawah ini saya akan berbicara tentang kapan harus melakukan ini, dan sekarang mari kita bicara tentang apa yang bertanggung jawab atas insinyur data dalam startup modern.
Insinyur data masih merupakan bagian penting dari tim data profesional apa pun.
Insinyur data Anda tidak boleh membuat jalur pipa yang sudah ada solusi siap pakai dan menulis transformasi data SQL. Inilah yang harus mereka fokuskan:
- organisasi dan optimalisasi infrastruktur data yang mendasarinya,
- membangun dan mendukung jalur pipa khusus,
- mendukung tim spesialis data dengan meningkatkan desain dan kinerja jaringan pipa dan permintaan,
- membangun transformasi data non-SQL.
Organisasi dan optimalisasi infrastruktur data yang mendasarinya
Meskipun insinyur data di startup tidak perlu lagi mengelola cluster Hadoop atau mengkonfigurasi peralatan untuk Vertica, pekerjaan masih diperlukan di area ini. Setelah memastikan bahwa teknologi Anda untuk mengumpulkan, mentransmisikan, dan memproses data berada pada puncaknya, Anda mendapatkan peningkatan yang signifikan dalam kinerja, biaya, atau keduanya. Ini biasanya melibatkan tugas-tugas berikut:
- pembuatan infrastruktur pemantauan untuk melacak status jalur pipa,
- pemantauan semua tugas yang mempengaruhi kinerja cluster,
- perawatan rutin
- skema penyetelan tabel (partisi, kompresi, distribusi) untuk meminimalkan biaya dan meningkatkan produktivitas,
- pengembangan infrastruktur data khusus ketika tidak ada solusi siap pakai.
Tugas-tugas ini sering diabaikan pada tahap awal pengembangan, tetapi mereka menjadi kritis ketika tim tumbuh dan jumlah data. Dalam satu proyek, kami dapat secara bertahap mengurangi biaya membangun tabel di BigQuery dari $ 500 menjadi $ 1 per hari dengan mengoptimalkan partisi tabel. Ini sangat penting.
Uber adalah contoh yang baik dari perusahaan yang telah berhasil. Spesialis pemrosesan data di Uber telah menciptakan alat yang disebut Queryparser yang secara otomatis melacak semua permintaan ke infrastruktur data mereka dan mengumpulkan statistik tentang sumber daya yang digunakan dan pola penggunaan. Insinyur Data Uber dapat menggunakan metadata untuk menyesuaikan infrastruktur.
Insinyur data juga sering bertanggung jawab untuk membangun dan memelihara pipa CI / CD yang mengelola infrastruktur data. Pada 2012, banyak perusahaan memiliki infrastruktur yang sangat lemah untuk kontrol versi, manajemen dan pengujian, tetapi sekarang semuanya berubah, dan inilah yang dilatar belakangi oleh para insinyur data.
Akhirnya, para insinyur data di perusahaan-perusahaan terkemuka sering berpartisipasi dalam pembuatan alat-alat yang tidak ada yang sudah jadi. Misalnya, insinyur Airbnb menciptakan Airflow karena mereka tidak punya cara untuk menghasilkan digraf pemrosesan data secara efisien. Dan insinyur Netflix bertanggung jawab untuk membuat dan memelihara infrastruktur canggih untuk mengembangkan dan mengoperasikan puluhan ribu Notebook Jupyter .
Anda hanya dapat membeli sebagian besar infrastruktur dasar Anda, tetapi seseorang masih harus melayaninya. Dan jika Anda adalah perusahaan yang benar-benar progresif, Anda mungkin ingin memperluas kemampuan alat yang ada. Insinyur data dapat membantu keduanya.
Membangun dan memelihara jalur pipa khusus
Meskipun insinyur data tidak lagi perlu mentransfer data secara manual ke Postgres atau Salesforce, vendor memiliki "hanya" sekitar 100 opsi integrasi. Sebagian besar pelanggan kami dapat langsung mencapai 75 hingga 90% dari sumber data yang mereka gunakan.
Dalam praktiknya, integrasi dilakukan oleh gelombang. Biasanya, tahap pertama mencakup basis data aplikasi utama dan pelacakan peristiwa, dan tahap kedua mencakup sistem pemasaran seperti ESP dan platform iklan. Saat ini, solusi turnkey untuk kedua fase sudah tersedia untuk dijual. Ketika Anda menggali lebih dalam untuk bekerja dengan data dari vendor SaaS di area subjek Anda, Anda akan membutuhkan insinyur data untuk membangun dan memelihara pipa pemroses data niche ini.
Misalnya, perusahaan yang bergerak dalam penjualan melalui Internet, berinteraksi dengan sejumlah produk yang berbeda di bidang ERP, logistik, dan pengiriman. Banyak dari produk ini sangat spesifik dan hampir tidak ada yang tersedia secara komersial. Harapkan dari teknisi data Anda bahwa mereka akan membuat produk serupa di masa mendatang.
Membangun dan memelihara jaringan pipa pemrosesan data yang andal adalah tugas yang sulit. Jika Anda memutuskan untuk menginvestasikan sumber daya Anda dalam kreasi mereka, bersiaplah bahwa itu akan membutuhkan lebih banyak dana daripada yang diperkirakan sebelumnya dalam anggaran, dan pemeliharaan juga akan membutuhkan lebih banyak upaya dari yang Anda rencanakan. Versi pertama dari pipa dapat dibangun secara sederhana, tetapi sulit untuk membuatnya mempertahankan konsistensi data dalam penyimpanan Anda. Jangan berkomitmen untuk memelihara pipa pemrosesan data Anda sendiri sampai Anda yakin bahwa bisnis Anda berfungsi. Setelah Anda melakukannya, luangkan waktu untuk membuatnya dapat diandalkan. Pikirkan tentang menggunakan Singer, kerangka kerja open-source dari pencipta Stitch, kami membangun sekitar 20 integrasi yang menggunakannya.
Dukungan untuk tim spesialis data dengan meningkatkan desain dan kinerja jaringan pipa dan permintaan
Salah satu perubahan yang telah kita lihat di bidang rekayasa data selama lima tahun terakhir adalah munculnya ELT - versi baru ETL, yang mengubah data setelah memuatnya ke penyimpanan, dan bukan sebelumnya. Esensi dan penyebab perubahan semacam itu sudah tercakup dengan baik dalam sumber-sumber lain. Saya ingin menekankan bahwa perubahan ini memiliki dampak besar pada siapa yang membangun jaringan pipa ini.
Jika Anda menulis kode pada Scalding untuk memindai terabyte data acara dalam S3 dan kemudian mengunggahnya ke Vertica, Anda mungkin perlu seorang insinyur data. Tetapi jika data acara Anda (diekspor dari Google Analytics 360) sudah ada di BigQuery, maka data itu sudah sepenuhnya tersedia di lingkungan kinerja tinggi dan dapat diskalakan. Perbedaannya adalah bahwa lingkungan ini berbicara SQL. Ini berarti bahwa analis sekarang dapat membuat jalur pipa transformasi data mereka sendiri.
Tren ini berkembang pada 2014 ketika Looker merilis alat PDT . Tren ini meningkat ketika seluruh tim ahli data mulai membangun digraf pemrosesan data dari 500+ node dan memproses set data besar menggunakan dbt selama dua tahun terakhir. Pada tahap ini, model ini berakar dalam di tim modern dan telah memberikan analis kebebasan sebanyak sebelumnya.
Beralih ke ELT berarti insinyur data tidak lagi perlu melakukan sebagian besar tugas konversi data . Ini juga berarti bahwa tim tanpa insinyur dapat menggunakan alat transformasi data yang dirancang untuk analis. Namun, para insinyur data masih memainkan peran penting dalam membangun jalur pipa konversi data. Ada dua situasi ketika partisipasi mereka sangat penting:
1. Ketika Anda perlu meningkatkan produktivitas
Kadang-kadang logika proses bisnis memerlukan beberapa transformasi yang sangat kompleks, dan penting untuk melibatkan seorang insinyur data untuk mengevaluasi bagaimana pendekatan tertentu untuk membuat tabel mempengaruhi kinerja. Banyak analis tidak memiliki banyak pengalaman dalam mengoptimalkan kinerja di gudang data analitis, dan ini merupakan alasan yang sangat baik untuk mulai bekerja dengan spesialis yang lebih sempit.
2. Ketika kode menjadi terlalu rumit
Analis sangat pandai memecahkan masalah bisnis dengan menggunakan data, tetapi seringkali tidak memikirkan bagaimana cara menulis kode yang dapat diperluas. Sepintas, mulai membangun tabel dalam basis data itu mudah, tetapi semuanya bisa dengan cepat lepas kendali. Libatkan seorang insinyur data yang dapat memikirkan arsitektur umum penyimpanan Anda dan mengembangkan transformasi yang kompleks, jika tidak, Anda berisiko ditinggal sendirian dengan kusut yang hampir tidak mungkin terurai.
Membangun transformasi data non-SQL
SQL awalnya dapat memenuhi sebagian besar kebutuhan konversi data, tetapi tidak dapat menyelesaikan semua masalah. Sebagai contoh, seringkali perlu menambahkan data geo ke database dengan mengambil garis lintang dan bujur dan menghubungkannya ke wilayah tertentu. Banyak repositori analitik modern belum dapat menyelesaikan masalah seperti itu (walaupun ini mulai berubah! ), Jadi solusi terbaik adalah membangun saluran pipa dengan Python, yang akan menambah data dalam repositori Anda dengan informasi tentang wilayah tersebut.
Kasus penggunaan lain yang jelas untuk Python (atau bahasa lain selain SQL) adalah untuk pembelajaran mesin. Jika Anda memiliki rekomendasi produk yang dipersonalisasi, model peramalan permintaan, atau algoritma peramalan aliran keluar yang mengambil data dari penyimpanan Anda dan mengatur bobotnya, Anda dapat menambahkannya sebagai simpul akhir dari digraf pemrosesan data SQL Anda.
Sebagian besar perusahaan modern yang memecahkan masalah seperti itu menggunakan non-SQL menggunakan Airflow. dbt digunakan untuk bagian berbasis SQL dari data diggraph, dan node non-SQL ditambahkan sebagai daun. Pendekatan ini mengambil yang terbaik dari kedua pendekatan - analis data masih dapat bertanggung jawab terutama untuk konversi berbasis SQL, dan insinyur data dapat bertanggung jawab atas kode ML untuk penggunaan industri.
Kapan tim Anda membutuhkan seorang insinyur data?
Mengubah peran seorang insinyur data juga menyiratkan memikirkan kembali urutan mempekerjakan karyawan. Sebelumnya dianggap bahwa Anda terutama membutuhkan insinyur data, karena analis dan spesialis sains data tidak dapat bekerja tanpa platform pemrosesan dan analisis data yang sudah jadi. Saat ini, spesialis analisis dan pemrosesan data dapat bekerja secara mandiri dan membuat versi pertama dari infrastruktur data menggunakan alat yang sudah jadi. Pikirkan tentang mempekerjakan seorang insinyur data ketika startup Anda memiliki salah satu dari 4 tanda skala:
- ada 3 analis / spesialis ilmu data di tim Anda,
- platform BI Anda memiliki 50 pengguna aktif,
- meja terbesar di penyimpanan Anda mencapai 1 miliar baris,
- Anda tahu bahwa Anda perlu membangun 3 atau lebih jalur pemroses data khusus selama beberapa kuartal berikutnya, dan semuanya penting.
Jika Anda belum menemukan salah satu dari situasi ini, tim pakar data Anda mungkin dapat bekerja sendiri, menggunakan teknologi siap pakai, dukungan dari konsultan eksternal dan saran dari kolega (misalnya, di komunitas Optimis Lokal atau komunitas dbt di Slack).
Hal utama yang harus dipahami adalah bahwa seorang insinyur data dengan sendirinya tidak memiliki nilai untuk bisnis, tugas utamanya adalah untuk meningkatkan produktivitas analis Anda. Tim pakar data Anda berinteraksi dengan pemangku kepentingan, mengukur KPI dan membuat laporan dan model - inilah yang membantu bisnis Anda bergerak ke arah yang benar setiap hari. Pekerjakan seorang insinyur data untuk memperkuat tim besar yang sudah ada: jika setelah Anda merekrut seorang insinyur data, efisiensi keempat analis Anda meningkat sebesar 33%, ini kemungkinan besar merupakan solusi yang baik.
Insinyur pemrosesan data menguntungkan bisnis dengan membantu analis dan ilmuwan data Anda menjadi lebih produktif.
Menurut pendapat saya, jika Anda memutuskan untuk memperluas tim spesialis data Anda, rasio terbaik adalah sekitar 5 banding 1: lima analis / spesialis ilmu data per insinyur data. Jika Anda bekerja dengan kumpulan data yang sangat besar atau tidak biasa, rasio ini dapat berubah, tetapi ini adalah panduan yang baik.
Siapa yang layak disewa?
Karena peran insinyur data berubah, demikian pula persyaratan untuk kandidat ideal. Kolega saya yang terkasih Michael Kaminsky mengatakan dengan sangat baik tentang hal ini dalam korespondensi kami mengenai hal ini, jadi saya akan mengutipnya di sini:
“Saya berpikir tentang semua perubahan ini, pertama-tama, tentang peran seorang insinyur data dalam tim. Dari pencipta infrastruktur, ia berubah menjadi tautan pendukung untuk kelompok spesialis yang lebih luas. Ini adalah perubahan yang signifikan, dan beberapa insinyur data (yang ingin fokus membangun infrastruktur) tidak selalu senang dengan hal ini.
Saya pikir hal yang paling penting bagi startup adalah untuk merekrut seorang insinyur data yang penuh energi dan keinginan untuk membuat alat untuk tim analis / spesialis ilmu data. Jika Anda menyewa seorang insinyur data yang hanya ingin mempelajari backend dan benci bekerja dengan orang-orang yang kurang memiliki keterampilan teknis, ini mungkin berakhir dengan buruk. Saya mencari insinyur data yang senang bekerja dengan analis dan peneliti dan siap untuk mengatakan: "Apa yang Anda lakukan tampaknya bagi saya sama sekali tidak efektif, dan saya ingin membuat perbedaan menjadi lebih baik."
Saya sangat setuju dengan Michael. Sekarang insinyur data terbaik di startup adalah dukungan dan dukungan dari tim, mereka berpartisipasi dalam hampir semua yang dilakukan oleh tim data. Mereka harus menyukai kerja tim dan mereka harus termotivasi untuk berhasil sebagai sebuah tim.
Jika Anda sampai di tempat ini, terima kasih sudah membaca :) Topik ini sangat mengkhawatirkan saya. Silakan tulis komentar jika Anda merasa saya salah - Saya tertarik untuk mengetahui pengalaman Anda bekerja dengan para insinyur data di tim Anda.
Akhirnya, jika Anda membuat keputusan untuk menyewa seorang insinyur data saat ini, perusahaan saya melakukan banyak wawancara dengan spesialis seperti itu - kami percaya bahwa ini adalah cara yang baik untuk tetap mengikuti perkembangan industri. Jika Anda ingin mengatur tes kinerja terakhir dari anggota tim potensial baru sebelum mengajukan penawaran, kami akan dengan senang hati melakukan wawancara akhir dengan kandidat Anda, cukup kirimkan kepada kami!
Komentar dari Gleb Sologub, Direktur Analytics di Skyeng :
Kami di Skyeng sekarang memiliki 30+ analis stack penuh dan belum ada insinyur data. Ini dimungkinkan karena seluruh infrastruktur data kami dibangun di atas layanan cloud yang Tristan bicarakan. Kami menggunakan Amazon Redshift sebagai repositori analitik, Stitch dan Matillion ETL untuk mengumpulkan data dari 40+ basis data produksi, Segmen untuk mengumpulkan acara, Redash dan Tableau untuk laporan dan dasbor, Amazon SageMaker untuk ML.
— - . , MVP- , , . , , , Tableau .
, , , - . , , : , .
- -, , , , . 90% , . , Skyeng.