Real-Time Data WarehousingTantangan dan Solusi

Dwiyono Ariyadi11917131

Mengaktifkan Real-time ETLTantangan 1

Hampir semua alat ETL dan sistem, baik berdasarkan off-the-shelf produk atau kebiasaan-kode, beroperasi dalam mode batch. 

Proses ini biasanya melibatkan downtime dari data warehouse, sehingga tidak ada pengguna dapat mengaksesnya saat beban terjadi

Periode terberat dalam hal penggunaan gudang data mungkin sangat baik bertepatan dengan periode puncak data masuk. Persyaratan untuk update terus menerus tanpa downtime gudang umumnya tidak konsisten dengan alat ETL tradisional dan sistem. 

Solusi: "Near Real-time" ETL

Cara termurah dan termudah untuk memecahkan masalah real-time ETL adalah untuk tidak mencoba di tempat pertama. 

Sebuah beban data yang saat ini terjadi mingguan mungkin dapat dilakukan bukan sehari, atau dua kali sehari. Sebuah beban data harian dapat dikonversi ke beban data per jam

Direct trickle feed

Java Messaging Service (JMS) dapat digunakan untuk mengirimkan setiap elemen data baru dari sistem sumber ke aplikasi pendengar ringan yang di insert gilirannya data baru ke dalam tabel gudang.

Untuk data yang diterima melalui Internet, data dapat ditransmisikan dalam XML melalui HTTP menggunakan standar SOAP, dan kemudian dimasukkan ke gudang.

Solu

si:

Trickle & Balik

Memuat data secara real-time ke dalam tabel gudang yang sebenarnya, data terus dimasukkan ke dalam pementasan tabel yang disimpan dalam format yang sama persis seperti tabel target. tabel pementasan baik berisi salinan hanya data untuk hari, atau untuk tabel fakta kecil dapat berisi salinan lengkap dari semua data historis. Kemudian secara periodik tabel pementasan diduplikasi dan copy swap dengan tabel fakta, membawa data warehouse langsung up-to-date

Eksternal Real-time data Cache

Aplikasi yang baik berhubungan dengan volume besar data real-time (ratusan atau ribuan perubahan per detik), atau mereka yang membutuhkan kinerja query sangat cepat, mungkin manfaat dari menggunakan database di memori (IMDB) untuk cache data real-time . IMDBs tersebut diberikan oleh perusahaan seperti Angara, Cacheflow, Kx, TimesTen, dan InfoCruiser.

Modeling Real-time Tabel Fakta Tantangan 2

Pengenalan data real-time ke dalam gudang data yang ada, atau pemodelan data real-time untuk data warehouse baru membawa beberapa masalah pemodelan data menarik. 

Sebagai contoh, sebuah gudang yang memiliki semua data yang dikumpulkan di berbagai tingkatan berdasarkan dimensi waktu perlu mempertimbangkan kemungkinan bahwa informasi yang dikumpulkan mungkin tidak selaras dengan data real-time. Juga beberapa metrik seperti bulan-to-date dan minggu-to-date mungkin berperilaku aneh dengan hari sebagian data yang berubah terus menerus

Solusi: Pemodelan seperti Biasa dengan Pakan Tabel Fakta Langsung

Hal utama yang perlu dipertimbangkan ketika menggunakan pendekatan ini adalah caching. Banyak permintaan, pelaporan, dan alat OLAP akan cache laporan dan hasil set, dan menganggap bahwa cache tersebut perlu disegarkan hanya pada beban gudang malam atau mingguan.

Pisahkan Real-time Partisi

Salah satu pendekatan untuk pemodelan data real-time adalah untuk menyimpan data real-time dalam tabel fakta gudang terpisah. Tergantung pada jenis tabel fakta, alat query banyak yang mendukung tabel partisi akan cukup pintar untuk secara otomatis mengambil data real-time dari real-time tabel jika diperlukan.

Integrated Real-time through Views

data real-time pendekatan pemodelan lain adalah untuk menyimpan data real-time dalam tabel yang berbeda dari data historis, tetapi dalam struktur tabel yang sama. Kemudian dengan menggunakan pandangan database, data historis dan real-time tabel digabungkan bersama sehingga mereka terlihat seperti satu tabel logis dari perspektif alat query tersebut. Hal ini membantu mengurangi banyak masalah yang terkait dengan pendekatan partisi terpisah, sebagai alat query atau pengguna akhir tidak perlu bergabung dengan dua tabel.

Modeling dengan Cache Real-time Data Eksternal Bila menggunakan cache real-time data eksternal, tidak ada

pemodelan data khusus yang diperlukan dalam data warehouse. Database data cache eksternal umumnya dimodelkan identik dengan gudang data, tetapi biasanya hanya berisi tabel yang real-time.

Jika cache data eksternal diakses secara terpisah dari data warehouse (menggunakan proyek OLAP terpisah, misalnya), beberapa tabel tambahan mungkin diperlukan di cache, seperti tabel lookup. Tapi data eksternal cache adalah yang paling berguna saat data mulus diintegrasikan dengan data historis untuk keperluan query dan analisis.

Solu

si:

Query OLAP vs Perubahan Data Tantangan 3

Relational OLAP alat sangat sensitif terhadap masalah ini karena mereka melakukan semua tapi operasi analisis data sederhana dengan mengeluarkan multi-pass SQL. Multi-pass pernyataan SQL terdiri dari banyak pernyataan SQL yang lebih kecil yang berurutan beroperasi pada satu set tabel sementara

Masalah pertama adalah bahwa hasil dari query yang mengambil bahkan satu menit yang dibilang tidak benar-benar real-time lagi.

Masalah kedua adalah bahwa dengan melewati beberapa dari SQL diperlukan untuk melakukan hampir semua pelaporan relasional OLAP atau operasi analitis, setiap gudang real-time akan menderita dari hasil set masalah inkonsistensi internal. 

Solu

si:

Gunakan Pendekatan Real-time Dekat

Masalah konsistensi laporan hanya masalah ketika data berubah cukup cepat sehingga data akan berbeda pada akhir siklus eksekusi multi-pass permintaan daripada di awal. Baik menggunakan pendekatan Hampir-real-time ETL atau trickle & pendekatan flip dengan waktu siklus yang relatif panjang akan mengatasi masalah ini jika server OLAP diinstruksikan untuk tidak mengirim pekerjaan baru untuk data gudang selama beban atau flip.

Mitigasi Risiko untuk True Real-time

Ada beberapa cara untuk mengurangi efek dari inkonsistensi data laporan. Yang paling sederhana adalah untuk tidak mengizinkan pengguna melakukan query yang paling kompleks pada data real-time. 

Alternatif adalah untuk memiliki snapshot yang kurang sering update dari real-time data dalam partisi yang terpisah yang dapat digunakan untuk query analisis yang kompleks.

Gunakan Cache Real-time Eksternal Data

Satu-satunya cara untuk benar-benar memecahkan masalah ini tanpa mengorbankan konsistensi laporan internal, latency data, atau pengalaman pengguna adalah dengan menggunakan cache real-time data eksternal. Dengan menjaga data real-time yang terpisah dari data historis, laporan tidak akan pernah tidak konsisten secara internal. 

Skalabilitas & Query Contention Tantangan 4

Isu pertentangan query dan skalabilitas adalah hal yang paling sulit dihadapi organisasi deploying solusi data real-time gudang. Data warehouse terpisah dari sistem transaksi di tempat pertama karena jenis query analisis yang kompleks dijalankan terhadap gudang tidak "bermain baik" dengan banyak menyisipkan simultan, update, atau menghapus.

Solusi : Sederhanakan dan Batasi Real-time Pelaporan Banyak aplikasi real-time pergudangan relatif sederhana. Pengguna

yang ingin melihat up-to-the-kedua data tersebut memiliki persyaratan pelaporan yang relatif sederhana. Jika laporan berdasarkan data real-time dapat terbatas sederhana dan cepat single-pass query, banyak sistem database relasional akan dapat menangani pertikaian yang diperkenalkan

Penerapan Lebih Horsepower database Selalu ada pilihan untuk menambahkan perangkat keras yang lebih

untuk menangani masalah skalabilitas. Node lebih lanjut dapat ditambahkan ke sistem database high-end SMP, atau kotak gudang yang berdiri sendiri dapat ditingkatkan dengan prosesor lebih cepat dan lebih banyak memori. Meskipun pendekatan ini dapat mengatasi masalah jangka pendek skalabilitas, kemungkinan hanya merupakan pendekatan band-bantuan. 

Pisahkan & Isolat dalam Data Cache Real-time Dengan semua aktivitas real-time pada database cache yang terpisah,

data gudang tidak menanggung segala beban tambahan. Dengan real-time data eksternal ke gudang, tidak mungkin untuk satu

laporan atau analisis untuk bergabung atau turut menampilkan informasi real-time dan historis. Selanjutnya, jika laporan analisis kompleks dijalankan pada cache real-time, adalah mungkin untuk cache untuk mulai menunjukkan inkonsistensi laporan internal yang sama, pertengkaran database, dan masalah skalabilitas yang gudang akan menunjukkan.

Just-in-time Merge Informasi dari Data Cache Eksternal Aplikasi ini membutuhkan aspek terbaik dari sebuah gudang data

tradisional seperti akses ke sejumlah besar data, kedalaman analisis, dan skalabilitas besar.Mereka juga memerlukan akses ke data real-time dan kecepatan pemrosesan yang disediakan oleh cache data real-time. Untuk aplikasi ini maka perlu menggunakan pendekatan hibrida. Informasi real-time duduk dalam cache data eksternal, dan informasi sejarah duduk di gudang, dan keduanya dihubungkan bersama secara efisien sesuai kebutuhan. Ini dapat dicapai dengan pendekatan yang dikenal sebagai just-in-time information merging (JIM)S

olu

si :

Reverse Just-in-time data Merge Varian dari JIM adalah  Reverse Just-in-time Data Merging

 (RJIM).Sebaliknya JIM berguna untuk query yang terutama didasarkan pada data real-time, tetapi yang mengandung informasi historis yang terbatas juga.

Reverse JIM proses yang sama terjadi, kecuali informasi history diperlukan dimuat dari gudang data ke dalam cache data eksternal secarasementara, dan kemudian query dijalankan dalam cache data. Ini hanya bekerja jika cache data terletak dalam sistem RDBMS dengan dukungan SQL penuh, dan tidak akan bekerja dengan beberapa sistem IMDB yang tidak mendukung banyak fungsi SQL.

Solu

si :

Real-time Alerting Tantangan 5

Ketersediaan data real-time membuat produk seperti NarrowCaster MicroStrategy dan produk serupa dari Cognos dan Business Objects sangat berharga. Tapi real-time alerting menggunakan produk ini membawa menetapkan tantangan tersendiri, mengherankan produk ini, seperti alat query banyak dari vendor yang sama, tidak dirancang untuk beroperasi pada atau diuji terhadap real-time data feed.

Produk ini beroperasi pada jadwal atau dasar acara, sehingga mereka dapat memicu peringatan setiap beberapa menit atau jam, atau perlu dipicu oleh sistem luar

n-Menit Jadwal Siklus Salah satu cara untuk mendekati real-time memperingatkan, tanpa

kerumitan tambahan dari solusi real-time monitoring aliran data, adalah dengan memanfaatkan paket data warehouse mengingatkan secara terjadwal, dengan jadwal biasanya diatur untuk setiap 1, 5, 15, atau 30 menit. Pendekatan ini bekerja cukup baik dan menyediakan near-real-time alerting. 

True real-time data monitoring & triggering Untuk true real-time data alerting, sistem memicu harus di tempat,

sebagai sistem gudang data yang ada mengingatkan tidak mampu memantau real-time data stream mencari kondisi pengecualian.Keperluan umum versi teknologi seperti saat ini sedang dikembangkan oleh perusahaan seperti Apama.

Real-time Alert Threshold Management Jenis manajemen ambang diperlukan untuk sistem real-time waspada

untuk dapat diterima oleh pengguna.  pendekatan terbaik adalah dengan menggunakan layanan pasca-plug-in alat 'kemampuan untuk menjalankan SQL custom atau prosedur untuk langsung memperbarui ambang pengguna berdasarkan kondisi data saat ini. S

olu

si :

Kutipan

Langseth, J., "Real-Time Data Warehousing: Challenges and Solutions", DSSResources.COM, 02/08/2004.

http://dssresources.com/papers/features/langseth/langseth02082004.html data diambil 15/05/2012