Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Data Science
Code

Sains Data dan Analisis untuk Perniagaan: Cabaran dan Penyelesaian

by
Length:LongLanguages:

Malay (Melayu) translation by Muhamad Zulfiqor (you can also view the original English article)

Oleh kerana lebih banyak syarikat menemui kepentingan sains data dan analisis lanjutan untuk garis bawah mereka, pertembungan budaya telah bermula. Bagaimanakah bidang yang berkembang dengan pesat ini menjadi sebahagian daripada ekosistem syarikat, terutama bagi syarikat-syarikat yang sudah ada selama sekitar satu dekad atau lebih?

Para saintis data dan profesional IT mempunyai keperluan yang sangat berbeza ketika datang ke infrastruktur. Di sini, saya akan meletakkan beberapa keperluan tersebut dan membincangkan bagaimana untuk bergerak melampaui mereka-dan berkembang bersama-sama.

Perspektif Jabatan

Apabila memulakan program sains data dalam syarikat, isu-isu terbesar sering timbul bukan dari teknologi itu sendiri, tetapi dari miskomunikasi yang mudah. Kesalahpahaman antara jabatan antara lain boleh mengakibatkan banyak dendam antara kumpulan sains data dan jabatan IT.

Untuk memerangi ini, kita akan mengkaji kedua-dua perspektif dan mengambil setiap keperluan mereka. Kami akan mula dengan menentukan apa yang profesional IT memerlukan untuk mengekalkan aliran kerja yang berjaya, dan kemudian kita akan melihat apa yang diperlukan oleh saintis data untuk kecekapan maksimum. Akhirnya, kita akan mendapati asas yang sama: bagaimana untuk menggunakannya untuk melaksanakan infrastruktur yang sihat untuk kedua-duanya berkembang.

Keperluan IT

Mari kita mulakan dengan melihat infrastruktur data tipikal untuk IT dan Pembangunan Perisian.

Mengenai data, terdapat tiga prasyarat penting bahawa mana-mana jabatan IT akan memberi tumpuan kepada:

  • data yang selamat
  • data yang cekap
  • data yang konsisten

Oleh sebab itu, banyak IT menggunakan skema berasaskan jadual, dan sering menggunakan SQL (Structured Query Language) atau salah satu variannya.

Persediaan ini bermaksud terdapat sejumlah besar jadual bagi setiap tujuan. Setiap jadual ini terpisah dari satu sama lain, dengan kunci asing menyambungkannya. Kerana persediaan ini, pertanyaan boleh dilaksanakan dengan cepat, cekap, dan dengan keselamatan dalam fikiran. Ini penting untuk pembangunan perisian, di mana data perlu kekal utuh dan boleh dipercayai.

Dengan struktur ini, perkakasan yang diperlukan seringkali minimum jika dibandingkan dengan keperluan sains data. Data yang disimpan adalah jelas, dan ia berubah mengikut kadar yang boleh diramal. Sedikit data mengulangi, dan proses pertanyaan mengurangkan jumlah sumber pemprosesan yang diperlukan.

Mari lihat bagaimana sains data berbeza.

Keperluan Sains Data

Di sisi lain, ilmu data memiliki seperangkat kebutuhan yang berbeda. Para ilmuwan data 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. Ilmu data membutuhkan infrastruktur yang berbeda, bergantung pada data yang tidak terstruktur dan skema tanpa tabel.

Ketika mengacu pada data tidak terstruktur, kami berbicara tentang data tanpa definisi intrinsik. Tidak jelas sampai diberikan formulir oleh ilmuwan data. Untuk sebagian besar pengembangan, setiap bidang harus memiliki tipe yang ditentukan — seperti integer atau string. Namun, untuk ilmu data, ini tentang mendukung titik data yang tidak jelas.

Table-less schemas menambahkan lebih banyak keserbagunaan ke pengaturan semu-kekacauan ini, yang memungkinkan semua informasi untuk hidup di satu tempat. Ini sangat berguna bagi para ilmuwan data 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 ilmu data sering kali lebih penting. Ini akan perlu 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 dapat membutuhkan sumber daya pemrosesan yang besar karena sejumlah besar data dipindahkan dan dikumpulkan.

Menghilangkan Keperluan Ke Tindakan

Dengan kedua-dua set keperluan ini, kami dapat melihat bagaimana ketidakpuasan berlaku. Mari kita ambil perspektif ini dan gunakannya untuk menentukan perubahan yang kita cari dan bagaimana. Masalah apa yang perlu diselesaikan apabila membawa sains data ke dalam tetapan IT tradisional?

Kemudahan Manipulasi Data

Dalam tetapan IT tradisional, mana-mana pangkalan data perniagaan tertentu mungkin mengikuti struktur yang tegar, dengan jadual dibahagikan untuk memenuhi keperluan khusus, skema yang sesuai untuk menentukan setiap data, dan kunci asing untuk mengikatnya bersama-sama. Ini menjadikan sistem data pertanyaan yang cekap. Sifat penerokaan beberapa kaedah sains data boleh mendorong ini ke hadnya.

Apabila tugas biasa mungkin memerlukan menyertai satu dozen atau lebih jadual, faedah struktur berasaskan jadual menjadi kurang jelas. Kaedah yang popular untuk mengendalikan ini adalah untuk melaksanakan pangkalan data NoSQL sekunder atau pelbagai dimensi. Pangkalan data sekunder ini menggunakan ETL biasa (Extract, Transform, Load) untuk memastikan maklumatnya segar. Ini menambah kos perkakasan tambahan atau penggunaan perkhidmatan awan, tetapi meminimumkan kelemahan lain.

Perlu diingat bahawa dalam sesetengah kes, menambah pangkalan data yang berasingan untuk sains data boleh menjadi lebih murah daripada menggunakan pangkalan data yang sama (terutamanya apabila isu pelesenan rumit dimainkan).

Kemudahan Peningkatan Data

Masalah khusus ini merangkumi dua ketidakpadanan yang disebutkan:

  1. kenaikan data secara teratur dari prosedur
  2. keperluan untuk jenis data yang tidak berstruktur

Dalam IT tradisional, saiz pangkalan data anda ditakrifkan dengan baik, sama ada tinggal saiz yang sama atau berkembang pada kadar yang sederhana. Apabila menggunakan pangkalan data untuk sains data, pertumbuhan itu boleh menjadi eksponen. Adalah perkara biasa untuk menambah gigabait data setiap hari (atau lebih). Dengan saiz data semacam itu, perniagaan perlu memasukkan rancangan untuk mengukur seni bina dalaman atau menggunakan penyelesaian awan yang sesuai.

Bagi data yang tidak berstruktur, ia boleh mengambil banyak sumber dari segi penyimpanan dan daya pemprosesan, bergantung kepada kegunaan khusus anda. Kerana itu, ia sering tidak cekap untuk menyimpan semua dalam pangkalan data yang mungkin digunakan untuk tujuan lain. Penyelesaiannya adalah sama dengan skala umum. Kita sama ada perlu merancang untuk mengukur seni bina dalaman kita untuk memenuhi keperluan ini atau kita perlu mencari penyelesaian awan yang sesuai.

Penggunaan sumber

Perbezaan utama yang akan kita bicarakan ialah penggunaan sumber. Untuk IT, penggunaan sumber biasanya cekap, jelas, dan konsisten. Jika pangkalan data menguasai tapak eCommerce, terdapat kekangan yang diketahui. Profesional IT akan mengetahui kira-kira berapa banyak pengguna yang akan ada dalam tempoh tertentu, supaya mereka boleh merancang perkakasan perkakasan mereka berdasarkan berapa banyak maklumat yang diperlukan untuk setiap pengguna.

Dengan infrastruktur IT tradisional, tidak akan ada masalah yang dihadapi jika projek hanya menggunakan beberapa ratus baris dari segelintir jadual. Tetapi satu projek yang memerlukan setiap baris dari dua meja lusin dengan cepat boleh menjadi masalah. Dalam sains data, keperluan dari segi pemprosesan dan perubahan penyimpanan dari projek ke projek-dan jenis ketidakprediksi itu sukar untuk disokong.

Dalam IT tradisional, sumber boleh dikongsi dengan pihak lain, yang mungkin tapak pengeluaran langsung atau pasukan dev dalaman. Risiko di sini ialah menjalankan projek sains data berskala besar berpotensi untuk mengunci pengguna lain untuk jangka masa tertentu. Satu lagi risiko adalah bahawa pelayan yang memegang pangkalan data mungkin tidak dapat mengendalikan jumlah pemprosesan yang diperlukan. Memanggil 200,000 baris dari 15 jadual, dan meminta pengagregatan data di atas, menjadi masalah. Magnitud pertanyaan ini boleh sangat dikenakan cukai pada pelayan yang mungkin biasanya mengendalikan seribu atau lebih pengguna serentak.

Penyelesaian yang ideal datang ke pemproses awan. Ini menangani dua faktor utama. Yang pertama adalah bahawa ia membolehkan prestasi pertanyaan dari mana-mana pangkalan data penting. Yang kedua adalah bahawa ia menyediakan sumber skala yang dapat memenuhi setiap projek.

Jadi Apa Senarai Akhir Keperluan untuk Kedua-duanya?

Sekarang kita telah membincangkan keperluan-keperluan yang mendalam, mari kita buatkan jumlahnya. Jabatan IT dan data sains akan memerlukan yang berikut untuk kejayaan jangka panjang:

  • pangkalan data yang berasingan untuk mengurangkan kesan kepada pihak berkepentingan yang lain
  • penyelesaian penyimpanan berskala untuk menampung perubahan dalam data
  • penyelesaian pemprosesan skala untuk menampung pelbagai jenis projek
  • pangkalan data yang tidak berstruktur untuk menyediakan pengambilan dan penyimpanan data yang sangat berbeza

Membina Kes untuk Sains Data

Mari memecah semuanya ke dalam spesifikasi supaya kita boleh menyusun penyelesaian yang saling menguntungkan. Sekarang kita akan melihat bagaimana untuk menentukan sumber-sumber tertentu yang diperlukan untuk sesebuah organisasi:

Meneliti Spesifikasi

Dari sisi IT, terdapat tiga definisi utama yang diperlukan untuk mewujudkan infrastruktur yang diperlukan. Ini adalah:

  1. jumlah data
  2. sejauh mana ia memerlukan pemprosesan
  3. bagaimana data akan sampai kepada penyelesaian storan

Berikut adalah cara anda boleh menentukan setiap.

Keperluan Penyimpanan Data

Semuanya bermula dengan saiz data awal yang diperlukan dan anggaran penambahan data yang berterusan.

Untuk keperluan data awal anda, ambil saiz yang ditetapkan dalam pangkalan data semasa anda. Sekarang tolak mana-mana lajur atau jadual yang anda tidak perlukan dalam projek sains data anda. Ambil nombor ini dan tambahkan saiz data mana-mana sumber baru yang anda akan memperkenalkan. Sumber baru mungkin termasuk data atau maklumat Google Analitis dari sistem Point of Sale anda. Jumlah ini akan menjadi penyimpanan data yang kami akan cari untuk mencapai muka.

Walaupun keperluan penyimpanan awal adalah awal yang berguna, anda masih perlu mempertimbangkan keperluan data yang berterusan-kerana anda mungkin akan menambahkan lebih banyak maklumat ke pangkalan data dari masa ke masa. Untuk mengetahui maklumat ini, anda boleh mengira data tambahan harian anda dari data anda yang ada sekarang. Lihatlah jumlah maklumat yang telah ditambah pada pangkalan data anda dalam 30 hari yang lalu, kemudian bahagikannya dengan 30. Kemudian ulangi itu untuk setiap sumber maklumat yang akan anda gunakan, dan tambahnya bersama-sama.

Walaupun ini tidak tepat, ada mantra perkembangan lama yang anda perlu menggandakan anggaran anda, dan kami akan menggunakannya di sini. Mengapa? Kami ingin menyumbang perubahan yang tidak menentu yang mungkin mempengaruhi pertumbuhan perusahaan seperti kebutuhan pertumbuhan, keperluan setiap projek, atau hanya kawasan umum.

Dengan nombor yang ditakrifkan sekarang, kalikan dengan 365. Ini kini merupakan pertumbuhan data yang diunjurkan selama satu tahun, yang, apabila ditambah pada jumlah awal anda, akan menentukan berapa banyak storan yang harus dilihat.

Memproses Keperluan Sumber

Tidak seperti keperluan penyimpanan data, keperluan pemprosesan jauh lebih sukar untuk dikira dengan tepat. Matlamat utama di sini adalah untuk menentukan sama ada anda mahu meletakkan pengangkat berat pada pertanyaan atau pada mesin tempatan (atau contoh awan). Perlu diingat bahawa apabila saya bercakap tentang mesin tempatan, saya tidak bermaksud hanya komputer yang biasa anda gunakan-anda mungkin memerlukan beberapa jenis workstation yang dioptimumkan untuk pengiraan yang lebih intensif.

Untuk membuat pilihan ini, ia membantu memikirkan projek sains data terbesar yang mungkin anda jalankan dalam tahun hadapan. Bolehkah penyelesaian data anda mengendalikan pertanyaan saiz itu tanpa menjadi tidak dapat diakses oleh semua pemegang kepentingan yang lain? Jika boleh, maka anda baik untuk pergi tanpa sumber tambahan yang diperlukan. Jika tidak, maka anda perlu merancang untuk mendapatkan stesen kerja bersaiz yang sesuai atau skala awan skala.

ETL (Extract, Transform, Load) Proses

Selepas memutuskan di mana untuk menyimpan dan memproses data anda, keputusan seterusnya adalah bagaimana. Mewujudkan proses ETL akan memastikan pangkalan data sains data anda teratur dan dikemas kini dan menghalangnya daripada menggunakan sumber yang tidak perlu dari tempat lain.

Berikut adalah apa yang anda harus ada dalam dokumentasi ETL anda:

  • apa-apa prosedur sandaran yang perlu dilakukan
  • di mana data akan datang dan di mana ia akan pergi
  • dimensi yang tepat yang perlu dipindahkan
  • berapa kerap pemindahan mesti berlaku
  • sama ada pemindahan perlu lengkap (menulis semula keseluruhan pangkalan data) atau boleh menjadi tambahan (hanya bergerak ke atas perkara-perkara baru)

Menyediakan Penyelesaian

Dengan semua titik data di tangan, sudah tiba masanya untuk memilih penyelesaian. Bahagian ini akan mengambil sedikit penyelidikan dan akan sangat bergantung kepada keperluan khusus anda, seperti pada permukaan yang mereka cenderung mempunyai banyak persamaan.

Tiga daripada penyelesaian awan terbesar-Perkhidmatan Web Amazon (AWS), Platform Awan Google (GCP), dan Microsoft Azure menawarkan beberapa harga dan ciri terbaik. Ketiga-tiganya mempunyai kos yang agak sama, walaupun AWS adalah lebih sukar untuk mengira kos untuk (disebabkan oleh struktur harga a la carte).

Di luar harga, masing-masing menawarkan penyimpanan data berskala dan keupayaan untuk menambah keadaan pemprosesan, walaupun setiap panggilannya 'contoh' oleh nama yang berbeza. Apabila meneliti yang hendak digunakan untuk infrastruktur anda sendiri, mengambil kira jenis projek yang anda akan gunakan paling banyak, kerana itu boleh mengubah nilai harga dan set ciri masing-masing.

Walau bagaimanapun, banyak syarikat hanya memilih mana-mana yang selari dengan timbunan teknologi mereka yang sedia ada.

Anda juga mungkin ingin menyediakan infrastruktur sendiri di rumah, walaupun ini jauh lebih rumit dan bukan untuk jantung yang lemah.

Tips Tambahan untuk Pelaksanaan Smooth

Dengan semua itik anda berturut-turut, anda boleh memulakan pelaksanaan! Untuk membantu, berikut adalah beberapa petua yang sukar diperoleh untuk membuat projek anda lebih mudah-dari padang ke pelaksanaan.

Uji Proses ETL anda

Apabila anda pertama kali menggabungkan proses ETL anda, jangan menguji keseluruhan perkara sekaligus! Ini boleh menimbulkan beberapa masalah serius pada sumber anda dan meningkatkan kos awan secara drastik jika ada kesilapan, atau jika anda perlu mencuba proses beberapa kali.

Sebaliknya, adalah idea yang baik untuk menjalankan proses anda menggunakan hanya 100 baris pertama atau lebih awal dari jadual asal anda. Kemudian jalankan pemindahan penuh sebaik sahaja anda tahu ia akan berfungsi.

Uji Pertanyaan Anda Terlalu

Begitu juga untuk sebarang pertanyaan besar yang anda jalankan pada contoh awan. Membuat kesilapan yang menarik dalam berjuta-juta keping data jauh lebih sukar pada sistem daripada yang hanya menarik sedikit-terutama apabila anda membayar setiap GB.

Buat Strategi Cadangan Gudang

Kebanyakan pengendali awan menawarkan ini sebagai ciri, jadi anda mungkin tidak perlu bimbang mengenainya. Pasukan anda masih perlu membincangkan sama ada mereka ingin membuat sandaran data mereka sendiri secara tetap, walaupun, atau jika ia mungkin lebih berkesan untuk membina semula data sekiranya keperluan itu timbul.

Keselamatan dan Kebimbangan Privasi

Apabila memindahkan data pelanggan ke awan, pastikan semua orang yang terlibat menyedari dasar tadbir urus data syarikat anda untuk mengelakkan masalah di jalan raya. Ini juga dapat membantu anda menjimatkan sejumlah wang pada jumlah data yang disimpan di awan.

Pengukuran Dimensi Semasa ETL

Apabila melakukan ETL dari pangkalan data berasaskan jadual kepada yang tidak berstruktur, berhati-hati tentang prosedur penamaan. Jika nama hanya borong yang dipindahkan, anda mungkin mempunyai banyak bidang dari jadual yang berbeza yang berkongsi nama yang sama. Cara mudah untuk mengatasi ini pada mulanya adalah untuk menamakan dimensi baru anda dalam pangkalan data tidak terstruktur sebagai {oldtablename} _ {columnname} dan kemudian menamakan semula mereka dari sana.

Dapatkan Motor Anda Berlari!

Sekarang anda boleh merancang asas-asas analisis dan infrastruktur sains data anda. Dengan banyak soalan dan jawapan utama yang ditakrifkan, proses pelaksanaan dan mendapatkan pengurusan pembelian perlu berjalan lancar.

Susahkah datang dengan jawapan untuk syarikat anda sendiri? Adakah saya menyelitkan sesuatu yang penting? Beritahu saya dalam komen!

Advertisement
Advertisement
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.