Students Save 30%! Learn & create with unlimited courses & creative assets Students Save 30%! Save Now
Advertisement
  1. Code
  2. Data Science
Code

Data Science dan Analisis untuk Bisnis: Tantangan dan Solusi

by
Length:LongLanguages:

Indonesian (Bahasa Indonesia) translation by Imam Firmansyah (you can also view the original English article)

Karena semakin banyak perusahaan yang sadar akan pentingnya data science dan analisis lanjutan untuk keuntungan mereka, maka benturan budaya telah dimulai. Bagaimana bidang-bidang yang tumbuh dengan cepat ini menjadi bagian dari ekosistem perusahaan, terutama untuk perusahaan-perusahaan mapan yang telah ada selama satu dekade atau lebih lama?

Para data scientist dan profesional IT memiliki kebutuhan yang sangat berbeda dalam hal infrastruktur. Di sini, saya akan memberikan beberapa persyaratannya dan membahas cara untuk bergerak melampaui mereka — dan berevolusi bersama. 

Departemen Perspektif

Ketika memulai program data science dalam perusahaan, masalah terbesar sering muncul bukan dari teknologi itu sendiri, tetapi dari miskomunikasi sederhana. Kesalahpahaman antardepartemen dapat menyebabkan banyak dendam antara tim data science yang baru dan departemen IT.

Untuk mengatasi ini, kita akan memeriksa kedua perspektif dan mempertimbangkan setiap kebutuhan mereka. Kita akan mulai dengan mendefinisikan apa yang dibutuhkan oleh profesional IT untuk mempertahankan alur kerja yang sukses, dan kemudian kita akan melihat apa yang dibutuhkan oleh data scientist untuk efisiensi maksimum.  Akhirnya, kita akan menemukan kesamaan: bagaimana menggunakannya untuk mengimplementasikan infrastruktur yang sehat agar keduanya berkembang.

Kebutuhan IT

Mari kita mulai dengan melihat infrastruktur data yang khas untuk IT dan Pengembangan Perangkat Lunak.

Mengenai data, ada tiga prasyarat penting yang akan dipusatkan oleh setiap departemen IT:

  • data yang aman
  • data yang efisien
  • data yang konsisten

Karena itu, banyak IT menggunakan skema berbasis tabel, dan sering menggunakan SQL (Structured Query Language) atau salah satu variannya.

Pengaturan ini berarti bahwa ada sejumlah besar tabel untuk setiap tujuan. Masing-masing tabel ini terpisah satu sama lain, dengan foreign key yang menghubungkannya. Karena pengaturan ini, kueri dapat dijalankan dengan cepat, efisien, dan dengan mempertimbangkan keamanan. Ini penting untuk pengembangan perangkat lunak, di mana data perlu tetap utuh dan dapat diandalkan.

Dengan struktur ini, perangkat keras yang diperlukan seringkali minimal bila dibandingkan dengan kebutuhan data science. Data yang disimpan didefinisikan dengan baik, dan itu berkembang pada kecepatan yang dapat diprediksi. Sedikit pengulangan data, dan proses query mengurangi jumlah sumber daya pemrosesan yang diperlukan.

Mari kita lihat bagaimana data science berbeda.

Kebutuhan Data Science

Di sisi lain, data science memiliki seperangkat kebutuhan yang berbeda. Para data scientist membutuhkan kebebasan bergerak dengan data mereka — dan fleksibilitas untuk memodifikasi data mereka dengan cepat.  Mereka harus dapat memindahkan data dengan cara yang tidak standar dan memproses dalam jumlah besar pada suatu waktu.

Kebutuhan ini sulit untuk diimplementasikan menggunakan database yang sangat terstruktur. Data science membutuhkan infrastruktur yang berbeda, bergantung pada data yang tidak terstruktur dan skema tanpa tabel.

Ketika mengacu pada data tidak terstruktur, kita berbicara tentang data tanpa definisi intrinsik. Ini samar-samar sampai diberikan bentuk oleh data scientist.  Untuk sebagian besar pengembangan, setiap bidang harus memiliki tipe yang ditentukan — seperti integer atau string. Untuk data science, bagaimanapun, ini tentang mendukung titik data yang tidak jelas.

Table-less schemas menambahkan lebih banyak keserbagunaan ke pengaturan rumit ini, yang memungkinkan semua informasi untuk hidup di satu tempat. Ini sangat berguna untuk data scientist yang secara teratur perlu menggabungkan data dengan cara yang kreatif dan tidak terstruktur. Pilihan populer termasuk varian atau struktur NoSQL yang memungkinkan beberapa dimensi, seperti kubus OLAP.

Akibatnya, perangkat keras yang diperlukan untuk data science sering kali lebih penting. Ini diperlukan untuk menyimpan keseluruhan data yang digunakan, serta himpunan bagian dari data itu (meskipun ini sering tersebar di antara berbagai struktur atau layanan). Perangkat keras juga memerlukkan sumber daya pemrosesan yang besar karena sejumlah besar data dipindahkan dan dikumpulkan.

Kebutuhan Mendistribusikan Menjadi Tindakan

Dengan dua set kebutuhan ini, kita sekarang dapat melihat bagaimana miskomunikasi dapat terjadi. Mari kita ambil perspektif ini dan gunakan mereka untuk menentukan perubahan apa yang kita cari dan bagaimana. Masalah apa yang perlu dipecahkan saat membawa data science ke dalam pengaturan IT tradisional?

Kemudahan Manipulasi Data

Dalam pengaturan IT tradisional, setiap database bisnis yang diberikan mungkin mengikuti struktur yang kaku, dengan tabel yang dibagi untuk memenuhi kebutuhan khusus, skema yang tepat untuk menentukan setiap bagian data, dan foerign key untuk mengikatnya bersama-sama. Ini membuat sistem data query menjadi efisien. Sifat eksplorasi dari beberapa metode data science dapat mendorong ini hingga batasnya.

Ketika tugas umum mungkin memerlukan untuk menggabungkan selusin atau lebih banyak tabel, manfaat dari struktur berbasis tabel menjadi kurang jelas. Metode populer untuk menangani ini adalah dengan menerapkan NoSQL sekunder atau database multi-dimensi. Database sekunder ini menggunakan ETL biasa (Extract, Transform, Load) untuk menjaga informasinya tetap segar. Ini menambah biaya perangkat keras tambahan atau penggunaan layanan cloud, tetapi meminimalkan kerugian lainnya.

Perlu diingat bahwa dalam beberapa kasus, menambahkan sebuah database yang terpisah untuk data ilmu bisa lebih terjangkau daripada menggunakan database yang sama (terutama ketika masalah perizinan yang rumit datang ke dalam bermain).

Kemudahan Data Scaling

Masalah khusus ini mencakup dua mismatches disebutkan:

  1. peningkatan reguler dalam data dari prosedur
  2. kebutuhan untuk tipe data yang tidak terstruktur

Tradisional, ukuran database Anda didefinisikan dengan baik, baik tinggal dengan ukuran yang sama atau tumbuh pada kecepatan yang sederhana. Bila menggunakan basis data ilmu, bahwa pertumbuhan dapat eksponensial. Hal ini umum untuk menambahkan gigabyte data setiap hari (atau lebih). Dengan ukuran tipis jenis data ini, bisnis perlu untuk memasukkan sebuah rencana untuk scaling arsitektur internal atau menggunakan solusi tepat awan.

Untuk data terstruktur, itu dapat mengambil banyak sumber daya dalam hal penyimpanan dan pengolahan daya, tergantung pada spesifik Anda menggunakan. Karena ini, hal ini sering tidak efisien untuk menyimpannya dalam database yang dapat digunakan untuk tujuan lain. Solusinya mirip dengan penskalaaan secara umum. Kita memerlukan rencana untuk mengukur arsitektur internal kita untuk memenuhi kebutuhan ini atau kita harus menemukan solusi cloud yang tepat.

Penggunaan sumber daya

Perbedaan utama terakhir kita akan berbicara tentang adalah penggunaan sumber daya. Untuk itu, penggunaan sumber daya biasanya efisien, didefinisikan dengan baik dan konsisten. Jika basis kekuatan situs e-commerce, tidak diketahui kendala. Seorang profesional IT akan tahu kira-kira berapa banyak pengguna akan ada selama periode waktu tertentu, sehingga mereka dapat merencanakan penyediaan perangkat keras mereka berdasarkan pada seberapa banyak informasi yang diperlukan untuk setiap pengguna.

Dengan infrastruktur IT tradisional, tidak akan ada masalah yang dihadapi jika sebuah proyek hanya menggunakan beberapa ratus baris dari beberapa tabel. Tetapi sebuah proyek yang mengharuskan setiap baris dari dua lusin tabel dapat dengan cepat menjadi masalah. Dalam data science, kebutuhan dalam hal pemrosesan dan penyimpanan berubah dari proyek ke proyek — dan ketidakpastian semacam itu sulit untuk didukung.

Dalam IT tradisional, sumber daya dapat dibagikan dengan pihak lain, yang mungkin merupakan tempat produksi langsung atau tim pengembang internal. Risiko di sini adalah bahwa menjalankan proyek data science berskala besar berpotensi dapat mengunci pengguna lain tersebut untuk jangka waktu tertentu. Risiko lain adalah bahwa server yang memiliki database mungkin tidak dapat menangani jumlah pemrosesan yang diperlukan. Memanggil 200.000 baris dari 15 tabel, dan meminta agregasi data di atas, menjadi masalah. Besarnya query ini dapat sangat membebani server yang biasanya menangani seribu atau lebih pengguna secara bersamaan.

Solusi ideal datang ke pemrosesan cloud. Ini membahas dua faktor kunci. Yang pertama adalah memungkinkan kinerja query jauh dari database penting. Yang kedua adalah bahwa ia menyediakan sumber daya skala yang sesuai untuk setiap proyek.

Jadi, Apa Daftar Akhir Persyaratan untuk Keduanya?

Sekarang setelah kita berbicara tentang kebutuhan secara mendalam, mari kita menjumlahkannya. Departemen IT dan data science akan membutuhkan hal-hal berikut untuk kesuksesan jangka panjang:

  • database terpisah untuk mengurangi dampak pada pemangku kepentingan lainnya
  • solusi penyimpanan skala untuk mengakomodasi perubahan data
  • solusi pemrosesan skala untuk mengakomodasi berbagai jenis proyek
  • database tidak terstruktur untuk menyediakan pengambilan dan penyimpanan yang efisien dari data yang sangat bervariasi

Membangun Kasus untuk Data Science

Mari kita pecahkan semuanya menjadi spesifikasi sehingga kita dapat menyusun solusi yang saling menguntungkan. Sekarang kita akan melihat bagaimana mendefinisikan sumber daya khusus yang dibutuhkan untuk suatu organisasi:

Meneliti Spesifikasi

Dari sisi IT, ada tiga definisi utama yang diperlukan untuk menciptakan infrastruktur yang diperlukan. Yaitu:

  1. jumlah data
  2. sejauh mana itu perlu diproses
  3. bagaimana data akan sampai ke solusi penyimpanan

Inilah bagaimana Anda dapat menentukannya masing-masing.

Kebutuhan Penyimpanan Data

Semuanya dimulai dengan ukuran data awal yang dibutuhkan dan perkiraan penambahan data yang ada.

Untuk kebutuhan data awal Anda, ambillah ukuran yang ditentukan dari database Anda saat ini. Sekarang kurangi kolom atau tabel apa pun yang tidak Anda perlukan dalam proyek data science Anda. Ambil nomor ini dan tambahkan ukuran data dari setiap sumber baru yang akan Anda perkenalkan. Sumber-sumber baru mungkin termasuk data Google Analytics atau informasi dari sistem Point of Sale Anda. Jumlah ini akan penyimpanan data yang kita akan melihat untuk mencapai dimuka.

Sementara kebutuhan penyimpanan awal berguna dimuka, Anda masih harus mempertimbangkan kebutuhan data berkelanjutan — seperti Anda akan kemungkinan menambahkan informasi lebih lanjut ke database dari waktu ke waktu. Untuk menemukan informasi ini, Anda dapat menghitung data yang ditambahkan setiap hari dari data yang tersedia saat ini. Lihatlah jumlah informasi yang telah ditambahkan ke database Anda dalam 30 hari terakhir, dan kemudian bagilah dengan 30. Kemudian ulangi untuk setiap sumber informasi yang akan Anda gunakan, dan tambahkan bersama-sama.

Meskipun ini tidak tepat, ada mantra pengembangan lama bahwa Anda harus menggandakan perkiraan Anda, dan kita akan menggunakannya di sini. Mengapa? Kita ingin memperhitungkan perubahan tak terduga yang mungkin memengaruhi kebutuhan penyimpanan data Anda — seperti pertumbuhan perusahaan, kebutuhan per proyek, atau hanya area umum.

Dengan angka yang sekarang ditentukan, kalikan dengan 365. Ini sekarang adalah proyeksi pertumbuhan data Anda selama satu tahun, yang ketika ditambahkan ke jumlah awal Anda, akan menentukan berapa banyak penyimpanan yang harus Anda lihat.

Memproses Kebutuhan Sumber Daya

Tidak seperti kebutuhan penyimpanan data, kebutuhan pemrosesan jauh lebih sulit untuk dihitung secara tepat. Tujuan utama di sini adalah memutuskan apakah Anda ingin menempatkan pengangkatan yang berat pada kueri atau pada mesin lokal (atau cloud instance). Perlu diingat di sini bahwa ketika saya berbicara tentang komputer lokal, saya tidak bermaksud hanya komputer yang biasa Anda gunakan — Anda mungkin akan membutuhkan semacam workstation yang dioptimalkan untuk penghitungan yang lebih intensif.

Untuk membuat pilihan ini, ada baiknya untuk memikirkan proyek data science terbesar yang mungkin Anda jalankan dalam tahun depan. Dapatkah solusi data Anda menangani kueri ukuran itu tanpa menjadi tidak dapat diakses oleh semua pemangku kepentingan lainnya? Kalau memang bisa, maka Anda akan baik untuk pergi dengan tidak ada sumber daya tambahan yang diperlukan. Jika tidak, maka Anda akan perlu berencana mendapatkan komputer berukuran tepat atau scaling awan contoh.

Proses ETL (Extract, Transform, Load)

Setelah memutuskan di mana akan menyimpan dan memproses data Anda, keputusan selanjutnya adalah bagaimana. Membuat proses ETL akan menjaga database data science Anda teratur dan diperbarui dan mencegahnya menggunakan sumber daya yang tidak perlu dari tempat lain.

Inilah yang harus Anda miliki dalam dokumentasi ETL Anda:

  • prosedur pencadangan apa pun yang harus dilakukan
  • dimana data akan datang dari dan di mana itu akan akan
  • dimensi yang tepat yang harus pindah
  • seberapa sering transfer harus terjadi
  • Apakah transfer perlu (penulisan ulang lengkap seluruh database) atau dapat menjadi aditif (hanya bergerak atas hal-hal yang baru)

Mempersiapkan Solusi

Dengan semua titik data di tangan, saatnya untuk memilih solusi. Bagian ini akan mengambil sedikit riset dan akan sangat bergantung pada kebutuhan khusus Anda, karena pada permukaan mereka cenderung memiliki banyak kesamaan.

Tiga solusi cloud terbesar — ​​Amazon Web Services (AWS), Google Cloud Platform (GCP), dan Microsoft Azure — menawarkan beberapa harga dan fitur terbaik. Ketiganya memilik i biaya yang relatif sama, meskipun AWS terutama lebih sulit untuk menghitung biaya (karena struktur harga a la carte

Di luar harga, masing-masing menawarkan penyimpanan data yang skalabel dan kemampuan untuk menambahkan pemrosesan instance, meskipun masing-masing memanggil 'instance' dengan nama yang berbeda. Saat meneliti mana yang akan digunakan untuk infrastruktur Anda sendiri, perhitungkan jenis proyek mana yang paling banyak Anda manfaatkan, karena itu dapat menggeser nilai masing-masing harga dan kumpulan fitur.

Namun, banyak perusahaan cukup memilih mana yang selaras dengan tumpukan teknologi yang ada.

Anda mungkin juga ingin membangun infrastruktur perusahaan Anda sendiri, meskipun ini jauh lebih kompleks dan bukan untuk orang-orang yang mudah menyerah.

Tips Ekstra untuk Implementasi yang Halus

Dengan semua bebek Anda berturut-turut, Anda dapat mulai menerapkan! Untuk membantu, berikut adalah beberapa kiat untuk membuat proyek Anda lebih mudah — dari pitch ke eksekusi.

Uji Proses ETL Anda

Ketika Anda pertama kali menyusun proses ETL Anda, jangan menguji semuanya sekaligus! Ini dapat menyebabkan tekanan serius pada sumber daya Anda dan meningkatkan biaya cloud Anda secara drastis jika ada kesalahan, atau jika Anda harus mencoba beberapa kali proses.

Sebaliknya, itu ide yang baik untuk menjalankan proses Anda hanya menggunakan 100 baris pertama atau lebih dari tabel asal Anda pada awal. Kemudian jalankan transfer penuh setelah Anda tahu itu akan berhasil.

Uji Kueri Anda Juga

Hal yang sama berlaku untuk kueri besar apa pun yang Anda jalankan pada instance cloud. Membuat kesalahan yang menarik jutaan bagian data jauh lebih sulit pada sistem daripada yang hanya menarik beberapa — terutama ketika Anda membayar per GB.

Membuat Strategi Cadangan Warehouse

Sebagian besar operator cloud menawarkan ini sebagai fitur, jadi Anda mungkin tidak perlu mengkhawatirkannya. Tim Anda masih harus mendiskusikan apakah mereka ingin membuat cadangan data sendiri, atau jika mungkin lebih efektif untuk merekonstruksi data jika diperlukan.

Kekhawatiran Keamanan dan Privasi

Saat memindahkan data pelanggan ke cloud, pastikan bahwa semua orang yang terlibat mengetahui kebijakan tata kelola data perusahaan Anda untuk mencegah masalah di jalan. Ini juga dapat membantu Anda menghemat uang pada jumlah data yang disimpan di cloud.

Penamaan Dimensi Selama ETL

Ketika melakukan ETL Anda dari database berbasis tabel ke yang tidak terstruktur, berhati-hatilah tentang prosedur penamaan. Jika nama hanya ditransfer secara keseluruhan, Anda mungkin memiliki banyak bidang dari tabel yang berbeda yang berbagi nama yang sama. Cara mudah untuk mengatasi ini pada awalnya adalah menamai dimensi baru Anda dalam basis data tidak terstruktur sebagai {oldtablename}_{columnname} dan kemudian mengganti namanya dari sana.

Pastikan Anda Tetap Semangat Menjalaninya!

Sekarang Anda dapat merencanakan dasar-dasar analitik dan infrastruktur data sciene anda. Dengan banyak pertanyaan kunci dan jawaban yang ditetapkan, proses implementasi dan mendapatkan dukungan manajerial akan berjalan lebih lancar.

Kesulitan mendapatkan jawaban untuk perusahaan Anda sendiri? Apakah saya mengabaikan sesuatu yang penting? Beri tahu saya di komentar!

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.