Hai, nama saya Victoria, dan saya bertanggung jawab untuk pemasaran di Layanan Cloud CROC. Sekarang kami secara teratur meng-host mitaps cloud. Baru-baru ini saya mendapatkan kinerja paling keren dari Dmitry Anoshin, yang sekarang bekerja di Amazon, dan saya ingin membagikannya.
Saya memiliki perasaan yang kuat bahwa perusahaan komersial besar memutuskan untuk mengumpulkan secara umum semua data yang mungkin di dunia yang dapat mereka jangkau. Di satu sisi, ini diterjemahkan ke dalam analitik canggih, peningkatan penjualan dan daya tarik produk. Di sisi lain, data telah menjadi begitu berani dan komprehensif sehingga lelucon tentang truk dengan CD-ROM sudah lama menjadi hal biasa.
Mari kita lihat mengapa mungkin perlu untuk bermigrasi ke cloud, dan apa yang Amazon dapatkan dari memindahkan infrastruktur internal ke Redshift dan NoSQL DynamoDB. Mari kita menganalisis perbedaan antara konsep SMP dan MPP, ETL dan ELT dan mencoba memahami mengapa awan diperlukan untuk data besar.
Nah, jika Anda mengetahui apa yang telah terjadi di industri dalam beberapa tahun terakhir, segera telusuri langsung ke kasus tertentu. Di bawah potongan, saya menyiapkan ringkasan poin utama kinerja.
Telemetri dari setiap bola lampu
Perusahaan besar memiliki kecenderungan yang sangat nyata terhadap pembentukan ekosistem terintegrasi di sekitar penggunanya. Artinya, Anda bangun, pergi menyikat gigi dan pada saat yang sama Anda melihat berita di cermin multimedia. Kolom Alexa termasuk musik semangat di pagi hari dan mengingatkan pertemuan hari ini. Di sini Anda memesan kopi segar dengan pengiriman ke rumah, karena yang lama sudah hampir habis. Anda masuk ke mobil, dan sekali lagi Alexa, yang terintegrasi dengan sistem multimedia mobil dan terus menemani di jalan. Ditambah gelang pintar, headphone, aplikasi di ponsel dan ribuan sumber informasi lainnya.
Pada saat yang sama ini adalah masa depan yang sedikit menakutkan yang dengan cepat datang dari segala arah, upaya untuk menciptakan nilai tambahan bagi konsumen akhir dari perusahaan. Anda harus setuju bahwa itu keren ketika, misalnya, menurut program Amazon Key In-Car, pembelian Anda akan dikirimkan langsung ke bagasi mobil di tempat parkir. Saya sekarang tinggal di Kanada, dan integrasi seperti itu membuat hidup jauh lebih nyaman. Bagi perusahaan, ini juga data yang sangat berharga dalam hal penargetan penjualan, perkiraan permintaan, optimasi logistik dan banyak lagi. Menang-menang.
Satu masalah. Seperti yang sudah saya katakan, ada perasaan kuat bahwa perusahaan sering mengumpulkan data pada skala yang berlebihan dengan harapan dapat menghasilkan uang di masa depan. Dan ini adalah terabyte. Sebenarnya terabyte informasi terstruktur buruk yang terus mengalir ke server perusahaan, memakan sumber daya jaringan, komputasi dan penyimpanan. Itulah sebabnya masalah pemanfaatan sumber daya yang optimal dan memastikan kecepatan komputasi sangat penting. Dan Anda juga perlu memberikan analis bisnis antarmuka normal yang tidak mengharuskan mereka memiliki pengetahuan ahli dalam membangun infrastruktur cloud. Karena itu, banyak perusahaan besar telah bergerak ke arah awan.
Tidak ada awan
Teknologi cloud adalah kata-buzz yang cukup banyak didapat semua orang. Tidak, tidak diragukan lagi, dia terlihat solid dalam laporan keuangan perusahaan dan pada presentasi resmi. Namun demikian, pada tingkat besi, ini semua adalah server lama yang sama baik yang berlokasi di pusat data di seluruh dunia. Namun, komputasi awan membutuhkan lebih dari sekadar konsol virtualisasi yang nyaman. Fitur utama cloud adalah manajemen sumber daya yang sepenuhnya dinamis dan penskalaan otomatisnya jika diperlukan:
- Perhitungannya.
- Penyimpanan.
- Sumber daya jaringan dan transportasi.
- Basis data.
Ketika Anda memiliki infrastruktur seperti itu, Anda akan menggunakan sumber daya Anda jauh lebih lengkap, yang dengan kasus bisnis skala besar dapat menghasilkan penghematan yang signifikan.
Untuk perusahaan kecil, pendekatan ini juga bisa sangat menarik. Bayangkan Anda berencana membeli besi baru untuk infrastruktur Anda tahun depan. Pada saat yang sama, sangat sulit bagi Anda untuk memprediksi beban yang tepat, yang dapat bervariasi dari banyak faktor. Misalnya, produk Anda tiba-tiba menjadi sangat populer karena publikasi yang sukses di Habré, segerombolan pelanggan menyerbu Anda dan sangat kecewa karena Anda tidak merencanakan beban puncak seperti itu. Dan mungkin ada situasi sebaliknya ketika Anda melebih-lebihkan permintaan, membeli kelebihan kapasitas dan, akibatnya, mendapatkan peralatan menganggur, yang sebenarnya menghilangkan banyak uang yang sangat dibutuhkan dari omset perusahaan. Taruhan hanya pada pembelian kapasitas besi hampir selalu merupakan proses yang sangat lembam, dan tentu saja kehilangan kemampuan beradaptasi di pasar yang berubah dengan cepat.
Migrasi khusus atau lengkap ke cloud cocok untuk situasi seperti itu, yang berfungsi sebagai sejenis kapasitor yang menghaluskan lonjakan konsumsi puncak. Atau bahkan sepenuhnya menyediakan Anda dengan infrastruktur.
Jenis awan
Bahkan, tergantung pada model bisnis mereka, perusahaan biasanya datang dengan salah satu dari tiga bentuk membangun sistem cloud. Sebuah bisnis kecil biasanya menggunakan cloud publik dan menyimpan spesialis yang sesuai, dengan fokus pada produknya. Khususnya yang besar itu sendiri mirip dengan banyak perusahaan terpisah yang dihubungkan oleh tujuan dan merek yang sama. Oleh karena itu, mereka sering membangun cloud pribadi, mencapai pemanfaatan sumber daya yang optimal. Bagian menggunakan model hibrid, yang memungkinkan Anda memproses data sensitif dan terlindungi secara hukum secara lokal dan mentransfer tugas kecil ke cloud eksternal. Pizza sebagai layanan:
Saya selalu sangat menyukai ilustrasi ini, yang menunjukkan dengan baik tingkat pendelegasian tugas infrastruktur perusahaan Anda kepada vendor.
Pilihan On-Premises tradisional adalah membeli makanan, memanaskan oven, dan memasak pizza sendiri. Sempurna! Tetapi Anda harus memiliki semua peralatan, bahan-bahan dan banyak lagi.
IaaS adalah opsi sewa infrastruktur. Anda menyewa dapur dengan semua peralatan, membawa produk Anda dan memasak pizza yang lezat. Orang yang terlatih secara khusus akan mencuci oven dari lemak, dan Anda tidak perlu khawatir tentang ketajaman pisau dan hal-hal sepele lainnya.
PaaS adalah platform sebagai layanan. Layanan ini memberi Anda beberapa barang tambahan selain infrastruktur kosong. Misalnya, Amazon Redshift - sebagai gudang data, yang memungkinkan Anda menghemat DBA dan fokus pada produk. Dalam contoh pizza kami, itu dapat berupa, misalnya, adonan berbentuk siap pakai yang hanya dapat dicairkan, disebarkan dengan saus aromatik, ditaburi jamur, irisan daging asap dan parmesan parut.
Opsi terakhir adalah SaaS. Dalam hal ini, Anda mendapatkan produk yang paling selesai berdasarkan yang Anda bangun bisnis Anda. Misalnya, jalankan blog berdasarkan platform publik orang lain. Dalam contoh kita, ini akan menjadi pilihan yang paling mahal, tetapi sederhana untuk memesan pizza yang sudah jadi di rumah.
Data truk. Ponsel salju
Ada anekdot tua berjanggut dari masa "nol" tahun: “Satu tim pengemudi truk mampu mengirimkan 100.000 CD dari Odessa ke Kiev semalam. Dengan demikian, mereka mencapai kecepatan transfer data 2,43 terabyte per detik selama jarak lebih dari 500 km tanpa menggunakan kabel mahal. "
Saat itu itu hanya lelucon. Namun, dengan volume modern dari aliran foto yang berkelanjutan dari masing-masing ponsel, audio, video dan telemetri lainnya, itu menjadi sama sekali tidak dapat digerakkan dan berubah menjadi masalah nyata. Ketika Anda tidak memiliki tautan optik tebal yang disewa langsung ke pusat data, memindahkan sejumlah besar data ke cloud dapat menjadi masalah besar. Layanan seperti Snowball Amazon datang untuk menyelamatkan.
Mereka membawa Anda kasus terlindung yang brutal yang dikemas dengan 50 terabyte disk berkecepatan tinggi dan antarmuka jaringan 10-gigabit. Kemudian Anda menghubungkannya langsung ke toko Anda dan menggabungkan semua data dengan kecepatan maksimum. Dalam kasus pencurian atau masalah lain, data meninggalkan ruang server Anda hanya dalam bentuk terenkripsi. Ada modul TPM dalam kasus ini, dan kunci enkripsi dikelola menggunakan AWS Key Management Service (KMS). Kunci enkripsi tidak disimpan di perangkat itu sendiri.
Dalam kasus yang sangat canggih, Anda dapat memanggil Snowball Truck - pusat data seluler dengan kapasitas 100 petabyte. Ketika skala data mendekati exabytes, koneksi 10-gigabit khas akan membutuhkan 26 tahun untuk transfer data. Dan truk putih seperti itu akan dapat menarik dan melepaskan data selama enam bulan.
Amazon Bermigrasi dari Oracle ke Redshift
Apa yang kita milikiSaya akan ceritakan sedikit tentang kasus saya bekerja dengan di Amazon. Platform perdagangan utama seperti Amazon memiliki pekerjaan yang sangat menyakitkan - Prime Days. Ini adalah penjualan puncak Black Friday dan penjualan Natal. Pada titik ini, server meleleh di bawah beban, gudang dipenuhi dengan loader, dan logistik tersedak di bawah aliran barang yang berkelanjutan. Ini adalah waktu yang sangat penting dari sudut pandang penjualan, dan setiap jam downtime atau tidak dapat diaksesnya layanan ini menimbulkan kerugian yang sangat besar.
Masalahnya berasal dari Oracle DB. Basis data hanya berhenti mengekspor volume permintaan simultan, mengalami masalah dengan penskalaan. Situs ini hampir berkembang di bawah serangan pelanggan, dan database menjadi masalah dalam hal penskalaan.
Setelah analisis yang cermat, mereka sampai pada kesimpulan bahwa database SQL tradisional tidak cocok sebagai backend untuk platform perdagangan sebesar ini. Plus, Oracle juga sangat mahal dalam hal lisensi dan dukungan. Akibatnya, diputuskan untuk bermigrasi ke platform cloud mereka, yang didasarkan pada Redshift dan NoSQL DynamoDB.
DynamoDB adalah pengembangan internal dengan replikasi sinkron antara pusat data dan mekanisme yang sangat efektif untuk mengurangi redundansi data, yang memungkinkan untuk secara signifikan menghemat penyimpanan mereka. Fitur yang sangat penting adalah Penskalaan Otomatis - penskalaan basis data dinamis untuk jumlah data yang diperlukan. Integrasi hebat dengan Hadoop juga telah berhasil.
Apa masalah utama dari database tradisional?
Masalahnya adalah bahwa versi lama dengan Oracle mengacu pada arsitektur SMP, yang hanya melibatkan penskalaan vertikal. Artinya, Anda memiliki mesin yang kuat dengan memori tertentu, banyak penyimpanan cepat, dan semua permintaan mengalir dengan satu atau lain cara ke sana. Ini adalah model Oracle klasik yang berfokus pada pengiriman server mandiri yang kuat. Pada saat yang sama, perusahaan tidak terlalu percaya pada cloud, dan komputasi paralel tidak dianggap sebagai solusi yang menjanjikan. Dan kami membutuhkan MPP - arsitektur paralel yang memungkinkan Anda untuk menodai permintaan untuk banyak mesin terpisah dan memproses data lebih cepat.
Ada poin penting lainnya - ETL vs ELT-pendekatan untuk memasukkan data ke dalam basis data.
ETL - Extract -> Transform -> Load. Artinya, kami pertama-tama menerima data dari sumber kami, menyusunnya dengan cermat, dan baru kemudian mengisinya ke gudang kami. Pendekatan ELT melibatkan pengisian data berisik mentah ke dalam penyimpanan dan pemrosesan sudah di sisinya. Pada prinsipnya, RedShift mendukung kedua pendekatan, tetapi ETL memiliki keuntungan: akses ke data yang difilter lebih cepat dan lebih mudah untuk dimanipulasi. Meskipun pada saat yang sama lebih banyak sumber daya dihabiskan untuk analisis awal informasi mentah. Ada satu lagi momen yang tidak terlihat. ETL mengurangi risiko dalam hal GDPR dalam hukum Eropa dengan menyaring informasi sensitif terlebih dahulu sebelum mencapai repositori umum. Ini mengurangi risiko akses yang tidak sah ke data. Alat utama untuk pemrosesan data primer dalam arsitektur baru adalah Matillion. Sudah ada GUI yang bagus di sana, sangat dapat dikonfigurasi dan sudah tersedia dalam opsi yang dirancang untuk Amazon RedShift. Berkat dia, ternyata menurunkan ambang masuk. Sekarang manajer produk dapat mengonfigurasi aliran data yang masuk dalam bentuk desainer visual tanpa bantuan insinyur data kami.
Hasilnya, kami mendapatkan fleksibilitas, penskalaan, dan pemulusan beban puncak yang kami butuhkan. Misalnya, mereka dapat memecahkan masalah menyapu 50 GB log server web per hari untuk memprediksi perilaku pengunjung.
Kami juga memperkenalkan Tableau, yang memungkinkan kami untuk beralih dari tabel yang tidak terhubung dengan baik di Excel ke dasbor tunggal, nyaman untuk manajemen.
Dan saya akan menjelaskan kalau-kalau: ada Oracle OLTP (backend) di toko, ada Oracle DW - gudang data analitik. Proyek ini ditujukan untuk kedua hal tersebut, tetapi saya berbicara secara spesifik tentang Oracle DW! Artinya, diagram dan deskripsi yang diberikan adalah lokal, mereka hanya menyangkut tim Amazon. Hal yang sama berlaku untuk Tableau. Ketika saya mengatakan "kami telah mengimplementasikan Papan Skor", maksud saya adalah proyek lokal, karena di Amazon semuanya dibagi menjadi beberapa tim, dan semua orang memilih apa yang harus dilakukan dan apa yang harus diterapkan dan digunakan.
Awan, meskipun hype agak tidak sehat di sekitar mereka, sudah menjadi kenyataan saat ini. Kemungkinan besar, sebagian besar proyek bisnis akan dibangun di sekitar infrastruktur tersebut. Ya, mungkin tidak setiap perusahaan akan memiliki solusi seperti itu. Tetapi perlu perencanaan untuk pengembangan lebih lanjut sekarang, jika tidak maka akan sulit untuk dengan cepat menanggapi parameter pasar yang berubah dengan cepat dan persaingan yang ketat.
Jika ada yang tertarik dengan topik analitik cloud dan solusi modern,
buka di sini . Saya menjatuhkan konten yang bermanfaat di sana.
Datanglah ke pertemuan kami
Layanan Cloud CROC telah melewati serangkaian pidato oleh pembicara yang sangat baik, misalnya, topik satu mitap adalah penggunaan praktis layanan AWS dalam kehidupan. Tahun depan kami telah merencanakan beberapa acara lagi, kami akan membicarakannya secara rinci. Ikuti acara.