Arsitektur Gudang Data: Tradisional dan Cloud

Halo, Habr! Banyak yang telah ditulis pada topik arsitektur data warehouse, tetapi belum bertemu secara ringkas dan ringkas seperti dalam artikel yang sengaja saya temukan.

Saya mengundang Anda untuk berkenalan dengan artikel ini dalam terjemahan saya. Komentar dan tambahan dipersilahkan!


(Sumber gambar)

Pendahuluan


Jadi, arsitektur gudang data berubah. Dalam artikel ini, kami akan membandingkan gudang data perusahaan tradisional dan solusi cloud dengan biaya awal yang lebih rendah, peningkatan skalabilitas, dan kinerja.

Gudang data adalah sistem di mana data dikumpulkan dari berbagai sumber dalam suatu perusahaan dan data ini digunakan untuk mendukung keputusan manajemen.

Perusahaan semakin pindah ke gudang data berbasis cloud alih-alih sistem tradisional di tempat. Penyimpanan data cloud memiliki beberapa perbedaan dari penyimpanan tradisional:

  • Tidak perlu membeli peralatan fisik;
  • Gudang data cloud lebih cepat dan lebih murah untuk dikonfigurasi dan diukur;
  • Gudang data cloud biasanya dapat melakukan kueri analitik yang rumit jauh lebih cepat karena mereka menggunakan pemrosesan paralel masif.

Arsitektur gudang data tradisional


Konsep-konsep berikut menyoroti beberapa ide dan prinsip desain mapan yang digunakan untuk membuat gudang data tradisional.

Arsitektur tiga tingkat


Cukup sering, arsitektur data warehouse tradisional memiliki struktur tiga tingkat yang terdiri dari tingkatan berikut:

  • Level lebih rendah : level ini berisi server database yang digunakan untuk mengambil data dari berbagai sumber, misalnya, dari basis data transaksional yang digunakan untuk aplikasi front-end.
  • Mid-tier : Mid-tier berisi server OLAP yang mengubah data menjadi struktur yang lebih cocok untuk analisis dan permintaan kompleks. Server OLAP dapat bekerja dalam dua cara: baik sebagai sistem manajemen basis data relasional canggih yang memetakan operasi data multidimensi ke operasi OLAP relasional standar, atau menggunakan model OLAP multidimensi yang secara langsung mengimplementasikan data dan operasi multidimensi.
  • Tingkat Atas : Tingkat atas adalah tingkat klien. Level ini berisi alat yang digunakan untuk analisis, pelaporan, dan analisis data tingkat tinggi.


Kimball vs. Inmon


Dua pelopor gudang data: Bill Inmon dan Ralph Kimball, menawarkan pendekatan desain yang berbeda.

Pendekatan Ralph Kimball didasarkan pada pentingnya data mart, yang merupakan gudang data milik bisnis tertentu. Gudang data hanyalah kombinasi dari berbagai data mart yang memfasilitasi pelaporan dan analisis. Proyek data warehouse berbasis Kimball menggunakan pendekatan bottom-up.

Pendekatan Bill Inmon didasarkan pada kenyataan bahwa data warehouse adalah penyimpanan terpusat dari semua data perusahaan. Dengan pendekatan ini, organisasi pertama-tama menciptakan model data warehouse yang dinormalisasi . Kemudian, data mart dimensi dibuat berdasarkan model gudang. Ini dikenal sebagai pendekatan data warehouse top-down.

Model Gudang Data


Dalam arsitektur tradisional, ada tiga model umum gudang data: penyimpanan virtual, penyimpanan data, dan gudang data perusahaan:

  • Gudang data virtual adalah kumpulan database terpisah yang dapat digunakan bersama sehingga pengguna dapat secara efektif mengakses semua data seolah-olah disimpan dalam satu gudang data;
  • Model menampilkan data digunakan untuk melaporkan dan menganalisis lini bisnis tertentu. Dalam model penyimpanan ini, kumpulan data dari sejumlah sistem sumber yang terkait dengan area bisnis tertentu, seperti penjualan atau keuangan;
  • Model gudang data perusahaan melibatkan penyimpanan data agregat yang mencakup seluruh organisasi. Model ini menganggap gudang data sebagai jantung dari sistem informasi perusahaan dengan data terintegrasi dari semua unit bisnis.

Bintang vs. Kepingan salju


Skema bintang dan kepingan salju adalah dua cara untuk menyusun gudang data Anda.

Skema bintang memiliki gudang data terpusat, yang disimpan dalam tabel fakta. Bagan membagi tabel fakta menjadi serangkaian tabel dimensi denormalized. Tabel fakta berisi data agregat yang akan digunakan untuk pelaporan, dan tabel dimensi menjelaskan data yang disimpan.

Proyek yang didenormalkan kurang kompleks karena data dikelompokkan. Tabel fakta hanya menggunakan satu tautan untuk melampirkan ke setiap tabel dimensi. Desain berbentuk bintang yang lebih sederhana sangat menyederhanakan penulisan pertanyaan kompleks.


Pola kepingan salju berbeda karena menggunakan data yang dinormalisasi. Normalisasi berarti organisasi data yang efisien sehingga semua dependensi data didefinisikan dan setiap tabel berisi redundansi minimum. Dengan demikian, tabel pengukuran individual dipecah menjadi tabel pengukuran terpisah.

Skema kepingan salju menggunakan lebih sedikit ruang disk dan lebih baik menjaga integritas data. Kerugian utama adalah kompleksitas kueri yang diperlukan untuk mengakses data - setiap kueri harus melalui beberapa tabel bergabung untuk mendapatkan data yang sesuai.


ETL vs. ELT


ETL dan ELT adalah dua cara berbeda untuk memuat data ke dalam penyimpanan.

ETL (Ekstrak, Transformasi, Muat) pertama-tama mengambil data dari kumpulan sumber data. Data disimpan dalam database sementara. Kemudian, operasi konversi dilakukan untuk menyusun dan mengubah data menjadi bentuk yang sesuai untuk sistem gudang data target. Kemudian data terstruktur dimuat ke dalam penyimpanan dan siap untuk dianalisis.


Dalam kasus ELT (Extract, Load, Transform), data segera dimuat setelah ekstraksi dari kumpulan data sumber. Tidak ada database perantara, yang berarti bahwa data segera diunggah ke repositori terpusat tunggal.
Data dikonversi ke sistem gudang data untuk digunakan dengan intelijen bisnis dan alat analisis.


Kedewasaan organisasi


Struktur gudang data organisasi juga tergantung pada situasi dan kebutuhan saat ini.

Struktur dasar memungkinkan pengguna akhir penyimpanan untuk secara langsung mengakses data ringkasan dari sistem sumber, membuat laporan, dan menganalisis data ini. Struktur ini berguna untuk kasus-kasus di mana sumber data berasal dari jenis sistem database yang sama.


Penyimpanan dengan area perantara adalah langkah logis berikutnya dalam organisasi dengan sumber data yang heterogen dengan berbagai jenis dan format data. Area pementasan mengubah data menjadi format terstruktur umum yang lebih mudah untuk diminta menggunakan alat analisis dan pelaporan.


Salah satu variasi struktur menengah adalah penambahan data mart ke data warehouse. Mart data menyimpan data ringkasan pada bidang aktivitas tertentu, yang membuat data ini mudah diakses untuk bentuk analisis tertentu.

Misalnya, menambahkan data mart dapat memungkinkan analis keuangan untuk lebih mudah melakukan pertanyaan terperinci tentang data penjualan dan memprediksi perilaku pelanggan. Data mart memudahkan analisis dengan menyesuaikan data secara khusus untuk memenuhi kebutuhan pengguna akhir.


Arsitektur Gudang Data Baru


Dalam beberapa tahun terakhir, gudang data pindah ke cloud. Gudang data cloud baru tidak mematuhi arsitektur tradisional dan masing-masing menawarkan arsitektur uniknya sendiri.

Bagian ini menjelaskan secara singkat arsitektur yang digunakan oleh dua penyimpanan cloud paling populer: Amazon Redshift dan Google BigQuery.

Pergeseran merah Amazon


Amazon Redshift adalah tampilan berbasis cloud dari gudang data tradisional.

Redshift mengharuskan sumber daya komputasi disiapkan dan dikonfigurasikan sebagai cluster yang berisi kumpulan satu atau lebih node. Setiap node memiliki prosesor, memori, dan RAM sendiri. Leader Node mengkompilasi permintaan dan meneruskannya ke node komputasi yang menjalankan permintaan.

Di setiap node, data disimpan dalam blok yang disebut irisan . Redshift menggunakan penyimpanan kolom, yaitu, setiap blok data berisi nilai dari satu kolom dalam beberapa baris, dan bukan dari satu baris dengan nilai dari beberapa kolom.


Redshift menggunakan arsitektur MPP (Massively Parallel Processing), memecah set data besar menjadi potongan yang ditugaskan untuk irisan di setiap node. Permintaan lebih cepat karena menghitung node memproses permintaan di setiap slice secara bersamaan. Node Leader menggabungkan hasil dan mengembalikannya ke aplikasi klien.

Aplikasi klien seperti BI dan alat analitik dapat terhubung langsung ke Redshift menggunakan open source PostgreSQL JDBC dan driver ODBC. Dengan cara ini, analis dapat melakukan tugas mereka secara langsung pada data Redshift.

Redshift hanya dapat memuat data terstruktur. Anda dapat memuat data ke Redshift menggunakan sistem pra-terintegrasi, termasuk Amazon S3 dan DynamoDB, dengan mentransfer data dari host lokal apa pun dengan koneksi SSH atau dengan mengintegrasikan sumber data lain menggunakan Redshift API.

Google bigquery


Arsitektur BigQuery tidak memerlukan server, yang berarti bahwa Google secara dinamis mengontrol alokasi sumber daya komputer. Oleh karena itu, semua keputusan manajemen sumber daya disembunyikan dari pengguna.

BigQuery memungkinkan pelanggan mengunduh data dari Google Cloud Storage dan sumber data lainnya yang dapat dibaca. Alternatifnya adalah streaming data, yang memungkinkan pengembang untuk menambahkan data ke gudang data secara real time, baris demi baris, saat tersedia.

BigQuery menggunakan mesin kueri yang disebut Dremel, yang dapat memindai miliaran baris data hanya dalam beberapa detik. Dremel menggunakan kueri paralel masif untuk memindai data dalam sistem manajemen file dasar Colossus. Colossus mendistribusikan file menjadi potongan-potongan 64 megabyte di antara berbagai sumber daya komputasi yang disebut node, yang dikelompokkan dalam kelompok.
Dremel menggunakan struktur data kolom yang mirip dengan Redshift. Arsitektur pohon mengirimkan permintaan ke ribuan mesin dalam hitungan detik.

Perintah SQL sederhana digunakan untuk melakukan kueri data.



Panoply


Panoply menyediakan manajemen data yang komprehensif sebagai layanan. Arsitektur optimalisasi diri yang unik menggunakan pembelajaran mesin dan pemrosesan bahasa alami (NLP) untuk memodelkan dan merampingkan transfer data dari sumber ke analisis, mengurangi waktu dari data ke nilai yang mendekati nol sedapat mungkin.

Infrastruktur Data Cerdas Panoply mencakup beberapa fitur berikut:

  • Analisis kueri dan data - menentukan konfigurasi terbaik untuk setiap kasus penggunaan, menyesuaikannya dari waktu ke waktu dan membuat indeks, kunci penyortiran, kunci disk, tipe data, evakuasi dan partisi.
  • Identifikasi kueri yang tidak mengikuti praktik terbaik - misalnya, yang menyertakan loop bersarang atau gips tersirat - dan menulis ulang kueri menjadi kueri yang setara yang memerlukan sebagian kecil dari waktu eksekusi atau sumber daya.
  • Optimalkan konfigurasi server dari waktu ke waktu berdasarkan pola permintaan dan pelajari pengaturan server mana yang paling berhasil. Platform ini secara mulus mengganti tipe server dan mengukur kinerja keseluruhan.


Melampaui Penyimpanan Cloud


Pergudangan data berbasis cloud merupakan peningkatan besar dibandingkan pendekatan arsitektur tradisional. Namun, pengguna masih menemukan sejumlah masalah saat mengonfigurasinya:

  • Mengunggah data ke gudang data berbasis cloud bukanlah hal sepele, dan jaringan pipa data skala besar membutuhkan konfigurasi, pengujian, dan dukungan untuk proses ETL. Bagian dari proses ini biasanya dilakukan oleh alat pihak ketiga;
  • Pembaruan, penyisipan, dan penghapusan bisa menjadi rumit dan harus dilakukan dengan hati-hati untuk mencegah penurunan kinerja permintaan;
  • Data semi-terstruktur sulit untuk ditangani - perlu dinormalisasi dalam format basis data relasional, yang membutuhkan otomatisasi aliran data besar;
  • Struktur bersarang biasanya tidak didukung di gudang data cloud. Anda perlu mengonversi tabel bersarang ke format yang dipahami oleh gudang data;
  • Optimasi cluster . Ada berbagai opsi untuk mengonfigurasi cluster Redshift untuk menjalankan beban kerja Anda. Beban kerja yang berbeda, kumpulan data, atau bahkan berbagai jenis kueri mungkin memerlukan konfigurasi yang berbeda. Untuk mencapai kinerja yang optimal, perlu untuk selalu meninjau dan, jika perlu, mengkonfigurasi konfigurasi tambahan;
  • Optimalisasi kueri - kueri pengguna mungkin tidak mengikuti praktik terbaik dan karenanya akan membutuhkan waktu lebih lama untuk diselesaikan. Anda bisa bekerja dengan pengguna atau aplikasi klien otomatis untuk mengoptimalkan kueri sehingga gudang data dapat berfungsi seperti yang diharapkan
  • Pencadangan dan pemulihan - meskipun penyedia penyimpanan data menyediakan banyak opsi untuk mencadangkan data Anda, mereka tidak mudah untuk dikonfigurasi dan memerlukan pemantauan dan perhatian khusus.

Tautan ke teks asli: panoply.io/data-warehouse-guide/data-warehouse-architecture-traditional-vs-cloud

Source: https://habr.com/ru/post/id441538/


All Articles