Data Warehouse Architecture
Data warehouse memiliki 2 arsitektur utama yaitu arsitektur aliran data ( data flow architecture) dan arsitektur sistem (system architecture).
Arsitektur Aliran Data ( Data Flow Architecture)
Arsitektur aliran data ( data flow architecture) adalah konfigurasi penyimpanan data dalam sistem data warehouse, beserta pengaturan bagaimana data mengalir dari sumber sistem melalui penyimpanan data untuk sebuah aplikasi yang digunakan oleh pengguna akhir. hal ini termasuk bagaimana arus data yang di kendalikan ,dicatat dan di pantau serta mekanisme guna memastikan kualitas data dalam menyimpan data.
Data stories atau lebih database atau file yang berisi data data warehouse, disusun dalam format tertentu dan terlibat dalam proses data warehouse. Berdasarkan aksesibilitas pengguna, Anda dapat mengklasifikasikan menyimpan data data warehouse menjadi tiga jenis:
A user-facing data store adalah penyimpanan data yang tersedia bagi pengguna akhir dan dipertanyakan oleh pengguna akhir dan aplikasi pengguna akhir.
An internal data store adalah semua penyimpanan data yang digunakan secara internal oleh komponen data warehouse untuk tujuan mengintegrasikan, pembersihan, penebangan, dan menyiapkan data, dan tidak terbuka untuk permintaan oleh pengguna akhir dan aplikasi pengguna akhir.
A hybrid data storeis digunakan untuk kedua mekanisme data warehouse internal dan untuk permintaan oleh pengguna akhir dan aplikasi pengguna akhir.
Sebuah data master storeis menyimpan data user facing atau hybrid yang berisi satu set lengkap data dalam data warehouse, termasuk semua versi dan semua data historis. Berdasarkan format data, Anda dapat mengklasifikasikan menyimpan data data warehouse menjadi empat jenis:
Tahap(stage) adalah sebuah penyimpan data internal digunakan untuk mengubah dan mempersiapkan data yang diperoleh dari sistem sumber, sebelum data dimuat ke penyimpan data lain dalam data warehouse.
Penyimpan data dinormalisasi(normalized data store (NDS)) adalah penyimpanan data master internal dalam bentuk satu atau lebih normalisasi database relasional untuk tujuan mengintegrasikan data dari berbagai sistem sumber diambil dalam tahapan (stage), sebelum data tersebut dimuat ke penyimpan data user facing.
Dimensional menyimpan data( dimensional data store(DDS) )adalah semua penyimpanan data user facing dalam bentuk satu atau lebih database relasional, dimana data tersebut disusun dalam format dimensi untuk tujuan mendukung permintaan analitis.
Saya membahas istilah relasional, normalisasi, denormalized, dan dimensionalin Bab 1, tapi aku akan mengulangi definisi sini sebentar:
Database relasional adalah database yang terdiri dari tabel entitas dengan hubungan orangtua-anak di antara mereka.
Database normalisasi adalah database dengan sedikit atau tanpa redundansi data dalam bentuk normal ketiga atau lebih tinggi.
Database denormalized adalah database dengan beberapa redundansi data yang tidak melalui proses normalisasi.
Database dimensi adalah database denormalized terdiri dari fakta tabel dan tabel dimensi umum yang mengandung pengukuran kegiatan bisnis, dikategorikan berdasarkan dimensi mereka.
Dalam empat bagian berikut, saya akan membahas empat arsitektur aliran data dengan kelebihan dan kekurangan:
Single DDS
Dalam arsitektur DDS tunggal, Anda memiliki menyimpan data satu dimensi. The DDS terdiri dari satu atau beberapa data mart dimensi. Dimensi Data mart adalah sekelompok tabel fakta terkait dan tabel dimensi yang sesuai mereka yang berisi pengukuran kegiatan usaha, yang dikategorikan berdasarkan dimensi mereka. Sebuah paket ETL ekstrak data dari sistem sumber yang berbeda dan menempatkan mereka di atas tahap (stage)
.Gamabar.Single DDS data warehouse architecture
Keuntungan dari arsitektur DDS tunggal adalah bahwa hal itu lebih sederhana dari tiga arsitektur berikutnya. Hal ini lebih sederhana karena data dari panggung (stage) yang dimuat langsung ke menyimpan data dimensi, tanpa pergi ke setiap jenis penyimpanan normalisasi terlebih dahulu. Kerugian utama adalah bahwa hal itu lebih sulit dalam arsitektur untuk membuat DDS kedua. DDS dalam arsitektur DDS tunggal adalah penyimpanan data master yang berisi satu set lengkap data dalam data warehouse, termasuk semua versi dan semua data historis. Kadang-kadang Anda perlu membuat DDS kecil yang berisi bagian dari data di DDS master untuk tujuan analisis tertentu di mana Anda ingin dapat mengubah data atau Anda ingin data sebagai data statis. Untuk membuat ini DDS lebih kecil, Anda akan perlu untuk membuat paket ETL baru yang mengambil data dari DDS induk dan populates DDS kecil. Anda perlu membangun paket ETL ini dari awal. Anda tidak dapat menggunakan kembali paket ETL ada karena paket ETL mengambil data yang ada dari panggung (stage) dan populates DDS utama. Ini adalah aliran data sangat berbeda sekali.
arsitektur DDS tunggal digunakan ketika Anda hanya perlu sebuah penyimpanan satu dimensi dan Anda tidak perlu menyimpan data normalisasi. Hal ini digunakan untuk solusi BI analitis sederhana, cepat, dan mudah di mana data yang digunakan hanya untuk memberi ruang data warehouse dimensi. Sebuah solusi DDS tunggal yang terutama berlaku bila Anda hanya memiliki satu sistem sumber karena Anda tidak perlu tambahan NDS atau ODS untuk mengintegrasikan data dari sistem sumber yang berbeda. Dibandingkan dengan NDS + DDS atau ODS + arsitektur DDS, arsitektur DDS tunggal adalah yang paling sederhana untuk membangun dan memiliki waktu tercepat ETL run karena data yang dimuat langsung ke DDS tanpa pergi ke NDS atau menyimpan data ODS pertama.
NDS + DDS
Dalam arsitektur aliran data NDS + DDS, ada tiga menyimpan data: panggung (stage), NDS, dan DDS. Arsitektur ini mirip dengan arsitektur DDS tunggal, tetapi memiliki menyimpan data dinormalkan di depan DDS. NDS dalam bentuk relasional normal ketiga atau lebih tinggi. Tujuan memiliki NDS ada dua. Pertama, mengintegrasikan data dari beberapa sistem sumber. Kedua, ia mampu memuat data ke dalam beberapa DDSS. Berbeda dengan arsitektur DDS tunggal, dalam arsitektur NDS + DDS Anda dapat memiliki beberapa DDSS. Gambar 2-5 menunjukkan arsitektur aliran data NDS + DDS.
Gambar .NDS + DDS data flow architecture
ODS + DDS
Arsitektur ini mirip dengan arsitektur NDS + DDS, tetapi memiliki ODS di tempat NDS. Seperti NDS, ODS adalah dalam bentuk normal ketiga atau lebih tinggi. Berbeda dengan NDS, ODS hanya berisi versi terbaru dari data master, ia tidak memiliki data master historis. Struktur badan adalah seperti sebuah database OLTP. The ODS tidak memiliki kunci pengganti. Tombol pengganti diselenggarakan dalam ETL DDS. The ODS mengintegrasikan data dari berbagai sistem sumber. Data dalam ODS dibersihkan dan terintegrasi. Data mengalir ke ODS telah melewati penyaringan DQ. Gambar 2-6 menunjukkan arsitektur aliran data ODS + DDS.
Figure 2-6.ODS + DDS data flowarchitecture
Seperti NDS, ODS berisi tabel transaksi dan tabel induk. Tabel transaksi berisi kegiatan bisnis, dan tabel induk berisi orang atau benda yang terlibat dalam kegiatan bisnis. Tabel fakta di DDS dihuni dari tabel transaksi di ODS. Tabel dimensi di DDS dihuni dari tabel induk di ODS. Tidak seperti NDS, tabel Master ODS yang hanya berisi versi terakhir dari data master. ODS tidak mengandung versi sejarah data master.
Seperti NDS, ODS berisi tabel transaksi dan tabel induk. Tabel transaksi berisi kegiatan bisnis, dan tabel induk berisi orang atau benda yang terlibat dalam kegiatan bisnis. Tabel fakta di DDS dihuni dari tabel transaksi di ODS. Tabel dimensi di DDS dihuni dari tabel induk di ODS. Tidak seperti NDS, tabel Master ODS yang hanya berisi versi terakhir dari data master. ODS tidak mengandung versi sejarah data master.
Tidak seperti NDS, yang merupakan sebuah penyimpanan data internal, ODS adalah menyimpan data hibrid. Ini berarti ODS dapat diakses oleh pengguna akhir dan aplikasi pengguna akhir. Dalam aplikasi NDS + DDS, NDS tidak dapat diakses oleh pengguna akhir dan aplikasi pengguna akhir. Tidak seperti NDS, ODS diupdate. Aplikasi pengguna akhir dapat mengambil data dari ODS, tetapi mereka juga dapat memperbarui ODS. Untuk menjamin kualitas data dalam ODS, aturan kualitas data juga diterapkan untuk pembaruan tersebut. Aplikasi pengguna akhir tidak harus memperbarui data yang berasal dari sumber sistem, yang dapat memperbarui hanya data itu sendiri untuk melengkapi systems'data sumber. Jika ODS digunakan untuk mendukung aplikasi dukungan pelanggan CRM, data seperti status dan komentar dapat ditulis pada ODS secara langsung, tapi semua data pelanggan masih dari sistem sumber.
Dalam arsitektur ODS + DDS, aplikasi dapat mengakses data warehouse dalam tiga tempat di tiga format yang berbeda: mereka yang membutuhkan data dalam bentuk dinormalkan dapat mengakses ODS, mereka yang membutuhkan data dalam format dimensi relasional dapat mengakses DDS, dan mereka yang membutuhkan data dalam format multidimensi dapat mengakses MDB.
Arsitektur ini memiliki keunggulan ini:
• Bentuk normal ketiga lebih ramping dari NDS karena hanya berisi nilai-nilai saat ini.
Hal ini membuat kinerja kedua ETL ODS dan DDS ETL lebih baik daripada yang di
Arsitektur NDS + DDS.
• Seperti arsitektur NDS + DDS, dalam ODS + arsitektur DDS Anda memiliki pusat
tempat untuk mengintegrasikan, memelihara, dan mempublikasikan data master.
• penyimpanan relasional normalisasi diupdate oleh aplikasi pengguna akhir, sehingga
mampu mendukung aplikasi operasional pada tingkat transaksi
Kerugian arsitektur ini adalah bahwa untuk membangun baru, kecil DDS (katakanlah 2007 Q4 data penjualan), Anda harus mendapatkannya dari DDS utama dan tidak dapat memanfaatkan DDS ETL yang ada untuk melakukan itu. Anda perlu baik untuk menulis query kustom (dengan kata lain, membuat tabel dari pilih), yang tidak disukai karena standardisasi dan konsistensi alasan, atau untuk membangun ETL baru, yang tidak disukai baik karena usaha, terutama jika itu adalah satu-off, membuang hal.
arsitektur ODS + DDS digunakan ketika Anda hanya perlu menyimpan data satu dimensi dan Anda membutuhkan sebuah pusat penyimpan data yang dinormalisasi yang akan digunakan untuk keperluan operasional seperti CRM. Para ODS mengandung rinci, data yang terintegrasi saat ini bernilai yang berguna untuk querie transaksional.
Federated Data Warehouse
Sebuah data warehouse federasi terdiri dari beberapa gudang data dengan lapisan pengambilan data di atasnya. Sebuah data warehouse federasi mengambil data dari gudang data yang ada menggunakan ETL dan beban data ke dalam dimensi penyimpanan data baru .Misalnya, karena kegiatan penggabungan dan pembebasan, Anda bisa memiliki tiga gudang data. Mungkin yang pertama adalah data warehouse dimensi, yang kedua adalah bentuk data yang dinormalisasi gudang normal ketiga, dan yang ketiga adalah gudang data relasional dengan beberapa tabel transaksi besar referensi banyak tabel referensi.
Gambar alur data FDW
Keuntungan utama dari arsitektur ini adalah bahwa Anda dapat menampung data werehouse yang ada, dan oleh karena itu waktu pembangunan akan lebih pendek . Kerugian utama adalah secara praktis, sulit untuk membangun sebuah gudang berkualitas baik dari beragam standar-standar yang ditemukan dalam sumber data mart atau data werehouse.
Anda akan menggunakan arsitektur FDW ketika Anda ingin memanfaatkan gudang data yang ada atau di mana Anda ingin mengintegrasikan data dari beberapa data mart.
System Architecture
Bagian sebelumnya mencakup arsitektur aliran data. Mereka menunjukkan bagaimana data diatur dalam menyimpan data dan bagaimana data mengalir dalam sistem data warehouse. Setelah Anda memilih arsitektur aliran data tertentu, maka Anda perlu untuk merancang arsitektur sistem, yang merupakan susunan fisik dan hubungan antara server, jaringan, perangkat lunak, sistem penyimpanan, dan klien. Merancang arsitektur sistem membutuhkan pengetahuan tentang hardware (terutama server), jaringan (khususnya yang berkaitan dengan keamanan dan kinerja dan dalam beberapa tahun terakhir juga jaringan serat), dan penyimpanan (storage area networks [SAN]), redundant array of inexpensive disks [RAID], dan otomatis tape backup solusi).
gambar.Example of a system architecture for data warehouse
Untuk merancang arsitektur sistem data warehouse , Anda terlebih dahulu menetapkan teknologi tumpukan (stack) yang ingin Anda gunakan untuk ETL , database , dan BI , seperti Microsoft SQL Server ( SSIS , SSAS , SSIS ) , Informatica + Oracle 9i + Cognos , dan sebagainya . Hal ini ditentukan berdasarkan kemampuan produk dan didasarkan pada standar perusahaan.setelah itu lakukan desain desain tingkat tinggi pada server , konfigurasi jaringan , dan penyimpanan konfigurasi yang mendukung teknologi yang dipilih , termasuk desain ketersediaan tinggi . Kemudian tentukan spesifikasi teknis rinci dari server , jaringan , dan penyimpanan . Hal ini dilakukan berdasarkan kemampuan dan persyaratan kinerja sistem . kemudian pesan perangkat keras dan perangkat lunak dan bangun sistem di pusat data bersama-sama dengan vendor perangkat keras dan jaringannya lalu instal dan mengkonfigurasi perangkat lunak. Merancang dan membangun lingkungan adalah fundamental dan penting untuk kinerja dan stabilitas sistem data warehouse yang akan membangun di atasnya .
Dalam hal perangkat lunak, ada dua jenis perangkat lunak database: Symmetric Multiprocessing (SMP) dan massively parallel processing (MPP). Sebuah sistem database SMP adalah sistem database yang berjalan pada satu atau lebih mesin dengan beberapa prosesor yang identik berbagi storage disk yang sama. Ketika sebuah sistem database SMP berjalan pada lebih dari satu mesin, hal itu disebut aclustered Database configuration.The secara fisik terletak di sistem penyimpanan disk tunggal. Contoh sistem database SMP adalah SQL Server, Oracle, DB / 2, Informix, dan Sybase. Sebuah sistem database MPP adalah sistem database yang berjalan pada lebih dari satu mesin di mana setiap mesin memiliki penyimpanan disk sendiri. Database secara fisik terletak di beberapa sistem penyimpanan disk yang saling berhubungan satu sama lain. Sebuah sistem database MPP juga dikenal sebagai sistem database paralel. Contoh sistem database MPP adalah Teradata, Neoview, Netezza, dan DATAllegro.
Case Study (studi kasus)
Studi kasus perlu mencakup semua aspek Anda ingin belajar dalam buku ini: arsitektur, metodologi, persyaratan, pemodelan data, desain database, ETL, kualitas data, metadata, menyimpan data, laporan, database multidimensi, BI, CRM, pengujian, dan administrasi data warehouse. Idealnya, studi kasus harus cukup sederhana untuk dipahami dan memberikan sebagai sebuah proyek, tapi saya tidak ingin menjadi terlalu sederhana karena tidak akan mencakup beberapa daerah yang disebutkan sebelumnya. Jadi, perlu sederhana tetapi tidak terlalu sederhana.