By Pedra Navid, Kepala Data di Hightouch.

Sepertinya sekali lagi SQL sudah mati. Beberapa dari kita ingat ketika NoSQL berjanji untuk melepaskan kita dari beban SQL. Kami melihat MongoDB, Redis, DynamoDB, dan lainnya muncul sebagai pembunuh SQL. Orang-orang berbondong-bondong ke solusi ini tetapi kemudian segera menyadari bahwa mungkin mereka peduli dengan hal-hal seperti konsistensi, transaksi ACID, dan tidak kehilangan semua data Anda. Mungkin SQL tidak mati saat itu, tetapi akan selalu ada orang lain yang mencoba membunuhnya. Sepertinya ini salah satunya.

Jadi pergi Manifesto Jamie Brandon melawan SQL. Dia berpendapat bahwa SQL itu buruk dan sangat buruk sehingga mempengaruhi seluruh industri. Masalah SQL bermuara pada tidak ekspresif, tidak dapat dimampatkan, dan tidak berpori. Tujuan saya bukan untuk membantah pendapatnya, tetapi jika kekhawatiran Anda tentang SQL adalah kurangnya Jenis Serikat dan bahwa panda dan Flink adalah model yang harus kita perjuangkan dan tidak hindari, maka setidaknya, Jamie dan saya punya pandangan yang sangat berbeda dari dunia di mana SQL beroperasi.

Saya tidak ragu bahwa ada dunia di mana:

churn[['State','Score']].groupby('State').mean().sort_values(by='Score', ascending=False) 

lebih bermanfaat daripada:

PILIH status, AVG(skor) DARI churn GROUP BY urutan status berdasarkan skor; 

Tetapi ada banyak dunia di mana yang terakhir lebih dari sekadar baik-baik saja. Sebagian besar argumen Jamie bertentangan dengan bagian bahasa yang hampir tidak ada orang yang berinteraksi dengannya, dan sisanya sudah memiliki beberapa solusi yang cukup bagus. Saya tidak pernah peduli bahwa saya tidak bisa menulis:

pilih x2 dari grup foo dengan x+1 sebagai x2; 

Dan sementara dia membuat beberapa kasus yang valid dalam hal komposisi, alat seperti dbt telah membantu menjembatani kesenjangan itu membawa kekuatan templating jinja ke SQL sambil mengaktifkan DAG yang selalu disukai yang memberi kekuatan pada setiap gudang sesuai dengan bobotnya.

Ketika saya melihat argumen-argumen yang menentang SQL ini, dan argumen-argumen tersebut muncul lagi dan lagi, hampir selalu berasal dari para insinyur perangkat lunak dan sepenuhnya merupakan lensa rekayasa perangkat lunak. Kekhawatiran saya dengan artikel seperti ini bukanlah, untuk lebih jelasnya, bahwa SQL akan mati. SQL akan hidup lama setelah saya pergi. Ketakutan saya yang sebenarnya adalah hal itu membuat orang enggan belajar SQL dan membuat mereka yang bahasa utamanya adalah SQL merasa tidak mampu.

Ada aura tak terucap yang terus-menerus dalam rekayasa perangkat lunak di sekitar data secara umum. Hampir kelas-membagi antara 'Rekayasa Perangkat Lunak' dan 'Orang Data.' Insinyur Data, Analis Data, Ilmuwan Data, Insinyur Analitik: Saya sudah terlalu sering melihat peran lain dan pengelompokan kedua dari peran ini. Fakta yang semakin meresahkan ketika Anda mempertimbangkan bahwa orang data cenderung lebih beragam dan kurang didominasi laki-laki (dan umumnya lebih menyenangkan berada di sekitar). Saya juga merasakan kecemasan serius pada orang-orang di bidang yang tidak berasal dari latar belakang rekayasa perangkat lunak tradisional, sering kali meragukan diri mereka sendiri dan meremehkan keterampilan dan kemampuan mereka sendiri. Sindrom penipu tampaknya hampir merupakan sifat dominan di antara semua orang yang saya ajak bicara.

Tidak ada gunanya ketika artikel seperti ini keluar dan naik ke puncak di Situs Oranye. Ini melanggengkan mitos bahwa analisis data adalah keterampilan kelas dua, lebih rendah daripada ilmu komputer keras yang sebenarnya dari rekayasa perangkat lunak. Saya telah melihat para insinyur perangkat lunak ini, dan izinkan saya memberi tahu Anda, jika mereka peduli dengan keahlian mereka setidaknya sebanyak orang peduli dengan analisis mereka, kami akan memiliki perangkat lunak yang lebih baik.

Yang benar adalah data itu sulit. Ekosistemnya keras. Datanya berantakan. Sulit untuk menguji. Kami belum menemukan alat yang tepat, debugging yang tepat, lingkungan yang tepat, atau bahkan cara yang tepat untuk mengajarkannya.

Mendapatkan sesuatu seperti dbt, gudang data, dan menjalankan python bukanlah hal yang sepele. Masih belum ada antarmuka yang bagus untuk memasukkan volume data ke dalam gudang. Bahkan jika Anda berhasil menjalankan Docker dan Postgres secara lokal, semoga berhasil membuat tabel dan menyemai database hanya untuk mulai bermain-main.

Pengujian masih merupakan masalah yang belum terpecahkan. Alat seperti Harapan Besar membantu, tetapi mereka hanya benar-benar mencakup data setelah fakta. Kami masih memiliki cara untuk mencari tahu cara menguji unit bagian yang lebih kecil dari kode kami atau cara menguji integrasi dengan benar tanpa mengejek setengah perpustakaan.

Ini semua adalah pekerjaan besar yang sedang berlangsung, dan pekerjaan itu tidak kalah pentingnya dengan membangun situs web, aplikasi backend, atau infrastruktur. Anda hanya perlu melihat di dbt #jobs-posting slack untuk melihat berapa banyak perusahaan yang mencoba mengisi peran sebagai analis dan insinyur data untuk membantu memecahkan masalah bisnis penting terkait data. Tingkat kecanggihan dan peralatan selama beberapa tahun terakhir telah meledak, begitu pula harapan pelanggan akan personalisasi—semuanya didorong oleh data.

Orang-orang yang melakukan pekerjaan itu tidak kalah terampilnya. Dan alat dan bahasa yang mereka gunakan tidak kalah berguna karena tidak memiliki fitur bahasa lain. Seorang analis yang baik sepadan dengan bobotnya dalam emas. Mereka kejam dalam ketepatan dan komunikator yang sangat baik. Mereka berempati terhadap bisnis dan memiliki rasa ingin tahu yang tak ada habisnya. Orang data adalah beberapa orang paling cerdas dan paling baik yang pernah saya temui.

Jadi, sementara mungkin ada orang di luar sana Melawan SQL, ketahuilah bahwa ada banyak dari kita yang sangat banyak Untuk SQL. Dan dunia lebih baik untuk itu.

Original. Diposting ulang dengan izin.

Terkait:

• Pandas vs SQL: Kapan Ilmuwan Data Harus Menggunakan Setiap Alat
• Persiapan Data di SQL, dengan Cheat Sheet!
• Cara mulai mengelola kualitas data dengan SQL dan skala