Diterjemahkan dari bahasa Inggris ke bahasa Indonesia - www.onlinedoctranslator.

com

(IJACSA) Jurnal Internasional Ilmu Komputer dan Aplikasi Tingkat Lanjut,

Jil. 11, No. 8, 2020

Arsitektur Gudang Data Danau untuk Big Data

Solusi
Emad Saddad1
Hoda MO Mokhtar3
Pusat Informasi Perubahan Iklim dan Energi Terbarukan
Fakultas Komputer dan Kecerdasan Buatan
dan Sistem Pakar
Universitas Kairo
Pusat Penelitian Pertanian (ARC)
Giza, Mesir
Giza, Mesir

Maryam Hazman4
Ali El-Bastawissy2
Pusat Informasi Perubahan Iklim dan Energi Terbarukan
Fakultas Ilmu Komputer
dan Sistem Pakar
Universitas MSA
Pusat Penelitian Pertanian (ARC), Giza, Mesir
Giza, Mesir

Abstrak—Traditional Data Warehouse adalah gudang
multidimensi. Ini adalah data nonvolatile, berorientasi subjek,
terintegrasi, timevariant, dan non-operasional. Ini dikumpulkan
dari berbagai sumber data heterogen. Kita perlu mengadaptasi
arsitektur Data Warehouse tradisional untuk menghadapi
tantangan baru yang ditimbulkan oleh banyaknya data dan
karakteristik data besar saat ini, yang berisi volume, nilai, variasi,
validitas, volatilitas, visualisasi, variabilitas, dan tempat. Arsitektur
baru juga perlu menangani kelemahan yang ada, termasuk
ketersediaan, skalabilitas, dan kinerja kueri. Makalah ini
memperkenalkan arsitektur Data Warehouse baru, bernamaDanau
Arsitektur Gudang Data, untuk menyediakan Gudang Data
tradisional dengan kemampuan untuk mengatasi tantangan.
Arsitektur Gudang Data Danau bergantung pada penggabungan
arsitektur Data Warehouse tradisional dengan teknologi data
besar, seperti kerangka Hadoop dan Apache Spark. Ini memberikan
solusi hibrida dengan cara yang saling melengkapi. Keuntungan
utama dari arsitektur yang diusulkan adalah mengintegrasikan
fitur saat ini di Gudang Data tradisional dan fitur data besar yang
diperoleh melalui integrasi Gudang Data tradisional dengan
ekosistem Hadoop dan Spark. Selain itu, ini disesuaikan untuk
menangani volume data yang luar biasa sambil mempertahankan
ketersediaan, keandalan, dan skalabilitas.
Kata kunci—gudang data tradisional; data besar; data semi
terstruktur; data tidak terstruktur; data baru arsitektur
gudang; Hadop; percikan
sayaPENDAHULUAN
Data warehouse (DW) memiliki banyak manfaat; itu meningkatkan
Intelijen Bisnis, kualitas data, dan konsistensi, menghemat waktu, dan
mendukung analisis dan kueri data historis [1]. Dalam dua dekade
terakhir, gudang data telah memainkan peran penting dalam
membantu para pengambil keputusan. Namun, di era data besar
dengan peningkatan besar dalam volume dan jenis data, ada
kebutuhan besar untuk menerapkan arsitektur dan teknologi yang
lebih memadai untuk menghadapinya.
Oleh karena itu, menjadi penting untuk meningkatkan DW tradisional
untuk menangani data besar di berbagai bidang untuk mengakomodasi
evolusi ini dalam volume, variasi, kecepatan, dan kebenaran data besar.
[2], [3]. Untuk mencapai ini, kami mengusulkan arsitektur DW baru
yang disebutArsitektur Gudang Data Danau.Arsitektur Gudang
Data Danauadalah sistem hybrid yang mempertahankan fitur DW
tradisional. Itu menambahkan fitur dan kemampuan tambahan
yang memfasilitasi bekerja dengan teknologi dan alat data besar
(Hadoop, Data Lake, Delta Lake, dan Apache Spark) sebagai
pelengkap untuk mendukung dan meningkatkan arsitektur yang
ada.
Kontribusi yang kami usulkan memecahkan beberapa masalah yang dihadapi dalam
mengintegrasikan data dari penyimpanan data besar seperti:
-Mengintegrasikan teknik DW tradisional, Hadoop
Framework, dan Apache Spark.
-Menangani tipe data yang berbeda dari berbagai sumber
seperti data terstruktur (DB, spreadsheet), data semi
terstruktur (file XML, file JSON), dan data tidak terstruktur
(video, audio, gambar, email, word, PowerPoint, file pdf).
-Menangkap, menyimpan, mengelola, dan menganalisis volume
data yang tidak dapat ditangani oleh DW tradisional.
- Menggunakan teknologi terkini seperti kerangka Hadoop, Data Lake,
Delta Lake, dan Apache Spark untuk mengurangi waktu yang dihabiskan
untuk menganalisis data dan mengurangi biaya penyimpanan tidaklah
mahal.
- Dukung semua pengguna, terutama ilmuwan data, karena mereka
perlu melakukan analisis data mendalam.
Sisa makalah ini disusun sebagai berikut: Bagian II
menjelaskan latar belakang dan pendahuluan untuk Data
Warehouse tradisional dan keterbatasannya, pentingnya DW,
serta karakteristik dan jenis data besar. Bagian III ikhtisar
karya-karya terkait dengan arsitektur DW. Bagian IV
menyajikan arsitektur DW yang diusulkan bernama Arsitektur
Gudang Data Danau. Bagian V menjelaskan studi kasus dengan
menerapkan kontribusi kami yang disebutArsitektur Danau DW
. Terakhir, kesimpulan disajikan pada Bagian VI.

417 |Halaman
www.ijacsa.thesai.org
 (IJACSA) Jurnal Internasional Ilmu Komputer dan Aplikasi Tingkat Lanjut,
II. BLATAR BELAKANG DANPRELIMINARIS
Di bagian ini, kami akan meninjau latar belakang topik terkait,
seperti DW tradisional, batasannya, dan mengapa kami perlu
mengembangkannya kembali. Selain itu, kami akan membahas
berbagai teknologi terkait
A. Gudang Data Tradisional (DWs)
DW tradisional terintegrasi, berorientasi subjek, nonvolatile, dan
data varian waktu untuk mendukung pengambil keputusan [4], seperti
yang disajikan pada Gambar. 1. Keempat properti membedakan DW
dari sistem penyimpanan data lainnya, seperti sistem basis data
relasional [ 5].
Gambar 1. Arsitektur Data Warehouses (DWs) Tradisional
Biasanya di DW primer ada data mart (DM). Data mart
(DM) adalah DW kecil yang hanya berisi sebagian data yang
diperoleh dari DW pusat. Isi DM mewakili informasi dari
domain tertentu yang diminati. Banyak server DW
digunakan untuk mengelola data. Server ini menyajikan
tampilan data multidimensi ke berbagai alat front-end.
B. Keterbatasan Arsitektur DW Tradisional
Dalam [6], [7], dan [8], penulis meninjau beberapa keterbatasan
DW, seperti hanya mendukung data terstruktur, sebaliknya, tidak
mendukung data semi terstruktur, atau data tidak terstruktur.
Selain di atas, pembatasan penanganan volume data dalam
terabyte, yang tidak berskala ke ukuran petabyte, tersedia secara
luas. Selain itu, mahal karena tergantung pada perangkat keras
dan perangkat lunak berpemilik.
Selain itu, DW tradisional melakukan kueri analitik, yang
akibatnya memengaruhi keseluruhan kinerja kueri, pengaksesan,
dan pemrosesan data. Proses pengambilan keputusan juga dapat
terpengaruh jika: 1) data yang benar tidak tersedia pada waktu
yang tepat, dan 2) pertumbuhan bisnis memerlukan metode baru
untuk manajemen data selain mengadaptasi arsitektur DW
tradisional.
C. Tujuan dari DW tradisional yang dibangun kembali
Salah satu tujuan utama kami adalah untuk mengatasi
keterbatasan arsitektur DW tradisional yang dibangun di atas teknologi
usang [4]. Kami memulai arsitektur keseluruhan yang mendukung
fungsionalitas DW tradisional dengan kemampuan untuk memasukkan
[6], [9] :
- Memenuhi kebutuhan bisnis baru. Tergantung
- pada infrastruktur berbiaya lebih rendah.
- Menangani data yang heterogen serta struktur dan format
data baru.
www.ijacsa.thesai.org
Jil. 11, No. 8, 2020
- Mengelola harapan pelanggan.
- Memenuhi pertumbuhan bisnis.
- Menggunakan kemajuan teknologi baru dan
perbaikannya.
- Menangani keberadaan dan status produk.
-Meningkatkan efisiensi bisnis dan keunggulan
kompetitif.
- Mengurangi risiko operasional dan keuangan.
- Mengevaluasi dan meramalkan tren dan perilaku.
D. Zaman Data Besar
Big Data adalah volume data yang tersedia dalam berbagai
tingkat kerumitan. Ini dihasilkan pada berbagai kecepatan dan
tingkat ketidakpastian; karenanya tidak ditangani menggunakan
pendekatan tradisional, teknologi tradisional, atau algoritma
tradisional [6]. Saat ini, big data dicirikan oleh sepuluh karakteristik
utama yaitu volume, variasi, kecepatan, kebenaran, nilai, validitas,
variabilitas, visualisasi, volatilitas, dan tempat [3], [10], [2], [11],
[12] , [13] sebagai berikut:
-Volume: sejumlah besar data yang dihasilkan secara terus-
menerus setiap jam atau setiap hari dari berbagai
sumber. Seperti terabyte yang dihasilkan per jam untuk
aplikasi seperti YouTube, Instagram, dan Google.
- Variasi: jenis data besar yang diserap dari sumber
data yang berbeda.
- Kecepatan: kecepatan data yang dihasilkan. Aspek data
dapat berupa data batch atau data streaming.
- Kebenaran: kualitas data yang sedang ditangani untuk
memperoleh wawasan yang berharga. Seperti data yang
ambigu, tidak konsisten, tidak lengkap, anomali, tidak pasti,
dan bias.
- Nilai: mewakili nilai bisnis yang akan diperoleh dari data
besar.
- Keabsahan: mengacu pada kebenaran data yang digunakan untuk
mengekstrak output dalam bentuk informasi.
- Variabilitas: mengacu pada aliran data yang tidak konsisten.
- visualisasi: mengacu pada kemampuan menganalisis dan wawasan
visual sebagai output dari analisis data besar.
- Keriangan: data yang disimpan tentang berapa lama itu berharga
bagi konsumen.
- Lokasi: mengacu pada berbagai platform tempat
berbagai jenis data dari berbagai sumber oleh
beberapa platform.
Secara umum, data adalah seperangkat nilai kualitatif atau
variabel kuantitatif; Big Data dapat dikategorikan menjadi tiga jenis
[2], [9]:
- Data terstruktur.Data memiliki struktur yang ditentukan atau
skema yang terorganisir baik dalam bentuk database relasional
atau dengan cara lain yang mudah dioperasikan. Misalnya, data
yang disimpan dalam database relasional (dalam
418 |Halaman
 (IJACSA) Jurnal Internasional Ilmu Komputer dan Aplikasi Tingkat Lanjut,
membentuk baris dan kolom), dalam spreadsheet (seperti file CSV),
dan data yang telah dibersihkan (yang telah diproses dengan
banyak pembersihan dan penyaringan).
- Data Semi-Terstruktur: Data sulit diambil, dianalisis, dan
disimpan sebagai data terstruktur. Ini membutuhkan
kerangka kerja perangkat lunak data besar (seperti Apache
Hadoop) untuk mencapai operasi ini. Misalnya, file XML, file
JSON, dan file BibTex.
-Data Tidak Terstruktur: Data yang sepenuhnya tidak terorganisir
sulit untuk ditangani, dan memerlukan perangkat lunak dan
alat canggih untuk mengaksesnya. Contohnya termasuk video,
audio, gambar, email, kata, PowerPoint, file pdf, halaman web,
koordinat lokasi, dan data streaming.
E. Kerangka Hadoop dan Data Lake
Hadoop adalah kerangka kerja perangkat lunak sumber terbuka. Ini
memungkinkan eksekusi proses MapReduce untuk pemrosesan data. Ini
menyediakan penyimpanan besar untuk semua jenis data, pemrosesan
paralel besar-besaran, dan menyimpan data dan menjalankan aplikasi pada
cluster untuk menyelesaikan sumber daya komputasi yang lebih baik [14].
Hadoop memiliki komponen utama sebagai berikut [15], [16], [17]:
- Sistem File Terdistribusi Hadoop (HDFS)adalah sistem
file, yang mengelola penyimpanan dan akses ke data
yang tersebar di berbagai node dari cluster Hadoop.
- BENANGadalah manajer sumber daya cluster Hadoop yang digunakan
untuk menetapkan sumber daya sistem untuk aplikasi dan jadwal
pekerjaan.
- Peta-Kurangiadalah mesin pemrosesan dan kerangka kerja
pemrograman yang digunakan untuk mengelola data batch skala besar
dalam sistem Hadoop.
- Hadoop Umumadalah seperangkat layanan dan institusi yang
menyediakan kemampuan dasar yang dibutuhkan oleh bagian
lain Hadoop.
Data Lake adalah penyimpanan data yang dapat mengumpulkan semua
jenis data: data terstruktur, semi terstruktur, atau tidak terstruktur, yang
disimpan satu sama lain terlepas dari struktur, format, atau jenisnya [18],
[19]. Ini adalah ide konseptual yang biasanya diimplementasikan dengan
satu atau lebih teknologi seperti database Hadoop dan NoSQL. Saat
melakukan query ke Data Lake, hanya kebutuhan data yang akan berubah
yang relevan dengan kebutuhan bisnis [20].
Membuat Data Lake bergantung pada teknologi Hadoop,
yang merupakan komponen (sebagai platform) untuk data
lake. Ini adalah hubungan komplementer antara Data Lake dan
Hadoop [21], [22], [23]
Data Lake mirip dengan DW tradisional karena keduanya
merupakan tempat penyimpanan data. Namun, ada perbedaan nyata
dalam fitur di antara mereka [7]—skema membaca di Data Lake, tetapi
skema menulis di DW. Skala data di Data Lake sangat besar, sementara
itu adalah volume data yang besar di DW. Sumber data dapat berupa
data semi-terstruktur atau/dan data tidak terstruktur, tetapi sebagian
besar adalah data terstruktur dalam DW [24], [25], [26], [27].
www.ijacsa.thesai.org
Jil. 11, No. 8, 2020
F. Apache Spark dan Danau Delta
Apache Spark adalah sumber terbuka yang diterapkan untuk analitik
data besar dan sistem terdistribusi. Ini menyediakan perpustakaan
streaming, SQL, analisis grafik, dan pembelajaran mesin. Ini memiliki dua
komponen utama Spark streaming, yang digunakan untuk mengelola data
waktu nyata, dan mesin Spark, yang secara langsung memproses setiap
potongan data dengan streaming Spark [28], [29], [30].
Delta Lake adalah lapisan penyimpanan Spark sumber terbuka. Ini
adalah lapisan penyimpanan ekstra yang membuat keandalan data lake
kami dibangun di atas The Hadoop Distributed File System (HDFS) dan
penyimpanan cloud [31]. Delta Lake menyediakan serangkaian fitur lain
termasuk:
- Bergabung dengan streaming dan pemrosesan data batch.
- Memberikan pendekatan metadata yang skalabel.
- Melayani transaksi ACID itu terjamin
konsistensi data yang disimpan di dalam data lake dengan
memastikan bahwa hanya penulisan lengkap yang
dilakukan.
- Perjalanan waktu yang memungkinkan seseorang untuk mengakses dan
mengembalikan versi data sebelumnya.
-Evolusi skema saat data berkembang, Delta memungkinkan tabel
Spark berubah dalam skema dan banyak lagi saat kami
menggunakan Delta.
- Mengaktifkan Data Lake untuk memperbarui data tanpa
melalui seluruh repositori Data Lake .
AKU AKU AKU. RGEMBIRAWORKS
Beberapa upaya telah dilakukan untuk mengadaptasi DW tradisional
untuk menangani kebutuhan pengguna baru dan perubahan dalam sumber
data yang mendasarinya. Banyak pendekatan berfokus pada DW yang
berhubungan dengan database relasional. Namun, mereka tidak dapat
disesuaikan untuk menangani data besar. Dalam [32], beberapa
metodologi mencoba memecahkan masalah dengan mengembangkan
proses ETL (Extracting, Transforming, and Loading). Dalam [33], penulis
mencoba memperbarui Skema DW untuk mencerminkan modifikasi yang
telah terjadi. Seperti disebutkan dalam [33], [33], [34], [5], [35], [36] , penulis
menggunakan versi temporal DW dan skema untuk memperbarui Struktur
DW dengan menyimpan lebih dari satu DW Versi: kapan. Karya-karya ini
tidak menggambarkan bagaimana kebutuhan pengguna memengaruhi
perubahan evolusi.
Pendekatan yang terbatas telah menangani aspek pengembangan
big data. Pendekatan yang disebutkan dalam [37] menjelaskan
spesifikasi skema data dan pemrosesan evolusi, tetapi tidak
bergantung pada DW. Karya yang disajikan dalam [38] menjelaskan
metode untuk menangani pertumbuhan sumber data dalam area
integrasi menggunakan ontologi integrasi big data. Ini dapat
menangani beberapa perubahan dalam sumber data, tetapi tidak
menentukan bagaimana menjawab semua persyaratan.
Beberapa jenis penelitian telah berkonsentrasi pada penggunaan
DWs dalam analisis data besar. Penulis di [39] menampilkan metode
OLAP untuk data besar yang dieksekusi dengan Hadoop. Mereka fokus
pada analisis multidimensi untuk analisis data besar. Namun, mereka
tidak membahas evolusi data besar, yang berlaku untuk pekerjaan
penelitian yang diusulkan di [40] dan [26].
419 |Halaman
 (IJACSA) Jurnal Internasional Ilmu Komputer dan Aplikasi Tingkat Lanjut,
Jil. 11, No. 8, 2020

Peneliti lain mempelajari masalah evolusi data besar. Dalam [41],
penulis membahas metodologi untuk membangun sistem untuk
analisis data besar. Namun, itu tidak dapat diterapkan dalam keadaan
data yang digunakan sebelumnya tidak disediakan.
Penulis di [42] mempresentasikan pendekatan DW untuk analisis
Big Data yang diimplementasikan menggunakan Map-Reduce.
Pendekatan ini menangani dua jenis perubahan: (1) versi skema dalam
variasi kontrol metadata dari tabel fakta dan (2) dimensi yang berubah
secara perlahan. Pendekatan ini tidak memproses perubahan dalam
sumber data besar yang dapat memengaruhi proses dan hasil analisis.
IV. TDIA MELAMARLAKEDGUDANG ATA
SEBUAHRSITEKTUR
Kontribusi kami bertujuan untuk mengadaptasi DW tradisional
untuk memecahkan tantangan baru dengan menangani data semi-
terstruktur dan tidak terstruktur. Selain mengelola pertumbuhan
kebutuhan bisnis dan menangani dua kelemahan utama, yaitu
ketersediaan dan kinerja sistem. Selain itu, ini meningkatkan kinerja
kueri dengan menyediakan data yang diperlukan dari pengguna kapan
saja.
Di bagian ini, kami menyajikan arsitektur DW baru yang
meningkatkan kinerja DW tradisional untuk menghadapi
tantangan ini. Kontribusi kami mengintegrasikan arsitektur DW
tradisional dengan teknologi data besar seperti Hadoop dan
Apache Spark.
Di era data besar, Kita perlu meningkatkan arsitektur DW untuk
menangani tantangan baru yang ditimbulkan oleh data besar. Kerangka
Hadoop dan Apache Spark merupakan pelengkap untuk menangani
tantangan DW tradisional; masing-masing memiliki kelebihan dalam
keadaan yang berbeda. Dalam beberapa kasus, kita memerlukan Hadoop
Framework dan Apache Spark untuk memproses data tidak terstruktur atau
semi terstruktur (data mentah) dan kumpulan data volume besar (data
besar). Dengan kata lain, kami masih bergantung pada DW tradisional untuk
data yang konsisten dan berkualitas tinggi (data terstruktur), serta latensi
rendah dan laporan interaktif.
Pada Gambar. 2, kami menjelaskan Arsitektur Danau DW yang
diusulkan. Dimana Hadoop dan Spark tidak menggantikan DW
tradisional dan Big Data akan mengubah arsitektur DW tradisional
tetapi tidak menggantikannya. Kontribusi kami bergantung pada
integrasi teknik DW tradisional, Hadoop Framework, dan Apache Spark
ke dalam solusi hybrid.
database operasional dan kemudian, memproses data, membersihkan
dan mengubah (T) sebelum memuat (L) ke dalam DW atau data mart
atau data mart virtual. DW dirancang untuk menangani dan menganalisis
beban kerja yang berat untuk dibaca. DW perlu mendefinisikan model
data sebelum memuat data. Kemudian, mereka menyebut pendekatan
Schema-On-Write, seperti yang disajikan pada Gambar. 2.
- Mengumpulkan atau menangkap data dari sumber data Semi-
Terstruktur atau Tidak Terstruktur menggunakan Arsitektur ELT. Big
Data membutuhkan proses yang berbeda untuk mengumpulkan
data di mana ETL tradisional tidak bekerja dengan baik pada data
semi-Struktur atau tidak terstruktur. Big Data membutuhkan ELT.
Data mentah akan disimpan dalam format aslinya. Langkah
preprocessing tidak akan digunakan sampai query atau aplikasi lain
mengakui/meminta data ini. Dimana Data Lake berbeda dengan
DW melalui pengolahan data dalam urutan ELT dan memanfaatkan
pendekatan Schema-on-Read, seperti terlihat pada Gambar 2.
Gambar. 2 menyajikan satu set komponen penting dari model
kontribusi kami sebagai berikut:
A. Arsitektur Data Lake Berbasis Hadoop di
Lingkungan Cloud
Menggunakan Hadoop sebagai staging area untuk DW dengan
menambahkan Data Lake berbasis Hadoop yang merupakan storage
repository yang digunakan untuk melengkapi DW tradisional. Ini digunakan
sebagai sumber data yang hanya meneruskan data yang diperlukan ke Data
Lake dan menyerap data mentah dalam jumlah tak terbatas yang terkait
dengan tujuan bisnis. Seperti ditunjukkan pada Gambar 2, kami
mengeksplorasi arsitektur Data Lake berbasis Hadoop yang memiliki banyak
lapisan sebagai berikut:
1) Menyerap lapisan data:menyerap data mentah dalam format asli,
di mana data yang diserap dapat berupa micro-batch, macro-batch,
batch, real-time, atau hybrid.
2) Lapisan data pendaratan:Tipe data yang berbeda (ditelan dalam
lapisan sebelumnya) disimpan dalam format asli (tanpa pemrosesan).
Di lapisan ini, pengguna dapat menemukan versi data asli dari analisis
mereka untuk membantu penanganan selanjutnya.

Jumlah besar data besar yang dihasilkan setiap menit dan setiap
jam membutuhkan danau data yang dapat diskalakan untuk
menangani volume ini. Oleh karena itu, kami menggunakan Hadoop
sebagai platform data untuk data lake untuk memberikan skalabilitas
yang luas dengan biaya yang dapat diterima. Selain itu, Data Lakes
dapat dilengkapi DW selain kerangka Hadoop. Juga, Data Lakes dapat
dilengkapi DW selain kerangka Hadoop. Arsitektur yang kami usulkan
membedakan dirinya dari semua pekerjaan sebelumnya. Ini adalah
lingkungan hibrida yang meningkatkan DW tradisional dengan
lingkungan Hadoop tergantung pada Data Lake berbasis Hadoop
karena dapat memperluas penggunaan dan kemampuan DW
tradisional, sebagai berikut: Gbr. 2. Arsitektur Lake Data Warehouse (DW) yang diusulkan

- Mengumpulkan atau menangkap data dari sumber data

3) Lapisan Metadata:bertanggung jawab untuk membuat data mudah untuk
terstruktur menggunakan Arsitektur ETL. DW bergantung
mengakses dan mengekstrak nilai dari Data Lake. Ini membantu untuk membuat
pada proses ETL tradisional; dari mana ekstrak (E) data dari

420 |Halaman
www.ijacsa.thesai.org
 (IJACSA) Jurnal Internasional Ilmu Komputer dan Aplikasi Tingkat Lanjut,
Jil. 11, No. 8, 2020

identifikasi, versi data, entitas dan atribut, distribusi,
kualitas.
4) Lapisan Data Tata Kelola:berlaku untuk lapisan lainnya. Dia
bertanggung jawab atas otentikasi, akses data, keamanan
data, kualitas data, dan siklus hidup data. Ini menentukan
tanggung jawab mengatur hak untuk mengakses dan
menangani data.
B. Arsitektur Delta Lake dengan Apache Spark Cloud
Environment
Teknologi Delta Lake digunakan dengan Apache Spark untuk
mengimplementasikan model yang kami usulkan dengan membuat platform
data cloud untuk memecahkan tantangan Data Lake, seperti )1) kualitas data
rendah, )2) membaca dan menulis tidak dijamin, )3) kinerja tidak memadai
dengan volume data yang terus bertambah, dan )4) sulit memperbarui
catatan [43]. Seperti yang disajikan pada Gambar. 2, Arsitektur Danau Delta
memiliki dua lapisan:
mengumpulkan dan memproses data Internet of Things (IoT). Kami
menyediakan kumpulan data sensor IoT demo untuk tujuan
demonstrasi. Data mensimulasikan data detak jantung yang diukur
oleh perangkat pelacak kesehatan. Setiap file terdiri dari lima
pengguna yang detak jantungnya diukur setiap jam, 24 jam sehari,
setiap hari. Kami menyimpan dataset di data lake sebagai file
JSON. Kami menggunakan dua file data dalam format JSON, file
pertama untuk pembacaan yang direkam oleh perangkat pada
Januari 2020 (health_tracker_data_2020_01.json), dan file kedua
untuk pembacaan yang direkam oleh perangkat untuk Februari
2020 (health_tracker_data_2020_02.json).
Kami menerapkan pada Data Lake, Delta Lake, dan Apache Spark di
Databricks, yang menyediakan platform terintegrasi untuk bekerja
dengan Apache Spark. Saat bekerja dengan Delta Lake, file Parket dapat
dikonversi di tempat ke file Delta. Selanjutnya, kita akan mengubah
tabel data lake berbasis Parket yang telah kita buat sebelumnya
menjadi tabel Delta.

1)Lapisan atom akan menjadi tabel Delta Perak yang dibangun
menggunakan Penyimpanan Objek, dan
2)Lapisan Departemen akan menjadi sejumlah Emas
Tabel Delta juga dibangun di atas Object Storage. Kami menggunakan Spark dan
menyimpan semua data dalam format Apache Parket yang memungkinkan Delta
Lake memanfaatkan kompresi asli yang terorganisir dengan baik ke
Parket.
Apache Spark digunakan untuk membaca dan memproses file dan kumpulan
data berukuran besar. Spark menyediakan mesin kueri yang mampu memproses
data dalam file data besar. Beberapa pekerjaan Spark paling signifikan di dunia
dijalankan dengan data Petabyte. Apache Parket memiliki format sebagai file
kolumnar yang bertanggung jawab untuk optimasi agar kueri lebih cepat [44]. Ini
adalah format file yang lebih efisien daripada file JSON. Sangat cocok untuk
pengolahan data di Hadoop. Ini menyediakan metode yang efisien untuk
menangani kumpulan data yang kompleks.
Perbedaan utama antara kontribusi kami Arsitektur Danau
DW atas DW tradisional sebagai berikut:
A. Konfigurasi Apache Spark
1)Membuat cluster ClustreHelthTracher adalah
sumber daya komputasi yang digunakan untuk menjalankan ilmu
data dan analitik data seperti proses ETL, analitik ad-hoc, dan
analitik streaming.
2)Konfigurasi Apache Spark, kita perlu
melakukan beberapa operasi konfigurasi pada sesi Apache Spark untuk
mendapatkan kinerja yang optimal. Ini akan mencakup pembuatan
database untuk menyimpan data, seperti yang ditunjukkan dalam skrip
Spark SQL berikut:
3)Sebagai tambahan untuk mengonfigurasi jumlah shuffle
partisi seperti yang ditunjukkan dalam skrip Spark SQL berikut:

-Menangani berbagai tipe data (data terstruktur, semi

terstruktur, dan tidak terstruktur) dari berbagai sumber.
-Mengekstrak, menyimpan, mengelola, dan menganalisis volume data
yang tidak dapat ditangani oleh DW tradisional.
- Mengintegrasikan antara teknik DW tradisional, Hadoop
Framework, dan Apache Spark sebagai solusi hybrid. Ini
menggunakan proses ETL atau ELT tergantung pada jenis
sumber data.
B. Mengimpor data dari Data Lake ke Delta Lake oleh
ETL Apache Spark
Kami mengimpor data dari Data Lake kami dan menyimpannya ke
Delta Lake sebagai file Parket.Kami menambahkan catatan bulan
pertama dan disimpan dihealth_tracker_data_2020_02.jsonmengajukan
dengan menggunakan proses ETL dari Apache Spark. Sebagai
tambahan untuk mengkonfigurasi jumlah partisi shuffle seperti yang
disajikan dalam skrip bahasa Python berikut:

- Mendukung berbagai tipe data di berbagai sumber.

- Menentukan dan menganalisis data dari Data Lake dan Delta Lake,
mereka menskalakan ke volume data yang ekstrem.

- Mendukung semua pengguna, khususnya Data scientist, karena dapat

melakukan analisis yang mendalam.

V.CASESTUDY
Tujuan kami dari bagian ini adalah untuk bereksperimen dengan kontribusi kami
untuk membuktikan keefektifannya dalam menangani data besar dan menganalisisnya
untuk pembuat keputusan. Studi kasus ini menunjukkan bagaimana model yang kami
usulkan dapat mengekstrak, mengintegrasikan, dan menganalisis data besar yang tidak
dapat ditangani oleh DW tradisional. Kami menggunakan Data Lake untuk

421 |Halaman
www.ijacsa.thesai.org
 (IJACSA) Jurnal Internasional Ilmu Komputer dan Aplikasi Tingkat Lanjut,
Jil. 11, No. 8, 2020

Pada Gambar. 3, kami memvisualisasikan data sensor dari waktu ke waktu,

seperti yang ditampilkan dalam skrip Spark SQL berikut:

2) Daftarkan Tabel Delta:kami akan mendaftarkan meja di

Metastore. Perintah Spark SQL akan secara otomatis
menyimpulkan skema data dengan membaca footer file Delta,
seperti yang ditunjukkan dalam skrip Spark SQL berikut:

Dengan Delta Lake, tabel Delta siap menggunakan log

Gambar 3. Data sensor dari waktu ke waktu.
C. Membuat Tabel Data Lake berbasis Parket
Kami mengonversi file Parket yang ada ke tabel data lake
berbasis Parket yang akan digunakan ke tabel Delta. Kami akan
menulis file ke lokasi root Databricks File System (DBFS) di
penyimpanan objek cloud kami. Kami membuat tabel
menggunakanBuat Tabel Sebagai Pilihan(CTAS) pola Spark SQL
seperti yang ditunjukkan pada skrip berikut:
transaksi yang disimpan dengan file Delta yang berisi semua
metadata yang diperlukan untuk kueri segera. Kami menghitung
catatan dikesehatan_pelacak_peraktabel dengan kueri Spark SQL
sebagai berikut:
E. Membuat Tabel Delta agregat: Lapisan
Departemen Danau Delta
Kami membuat tabel Delta baru (tabel agregat) dari data di
kesehatan_track_silvermeja delta. Kami membuat
health_tracker_user_analyticsDelta tabel statistik ringkasan untuk
setiap perangkat. Kami menggunakan Create Table As Select
(CTAS) Spark SQL seperti yang ditunjukkan pada skrip berikut:

Hitung catatan dikesehatan_pelacak_perakmeja. Kami berharap

memiliki 3720 catatan: lima pengukuran perangkat, 24 jam sehari
selama 31 hari,seperti yang ditunjukkan dalam skrip Spark SQL berikut:

F. Menggali hasil analisis

Tabel health_tracker_user_analytics dapat digunakan untuk
menentukan dasbor untuk menganalisis hasil sesuai dengan
D. Mengonversi Tabel Data Lake berbasis Parket yang Ada kebutuhan bisnis seperti yang disediakan pada Gambar. 4 yang
menjadi tabel Delta: Lapisan Atom Delta Lake menggambarkan hasil agregasi seperti data maksimum, minimum, dan
Tabel Delta terdiri dari tiga hal: (1) File Delta yang berisi data dan rata-rata, seperti yang disajikan dalam skrip Spark SQL berikut:
disimpan dalam penyimpanan objek. (2) Tabel Delta yang terdaftar di
meta-store Hive pusat yang dapat diakses oleh semua cluster untuk
menyimpan metadata tabel. (3) Log Transaksi Delta (catatan berurutan
dari setiap transaksi) disimpan dengan file Delta di penyimpanan objek.
Untuk Mengonversi Tabel Data Lake berbasis Parket yang Ada menjadi
tabel Delta dengan menggunakan langkah-langkah berikut:

1) Konversi File ke File Delta:Kami mengonversi file

di tempat untuk file Parket. Konversi membuat log transaksi
Delta Lake yang melacak file. Sekarang, direktori adalah
direktori file Delta, seperti yang ditunjukkan pada skrip Spark
SQL berikut:
Gambar 4. Analisis hasil sesuai kebutuhan bisnis.

422 |Halaman
www.ijacsa.thesai.org
 (IJACSA) Jurnal Internasional Ilmu Komputer dan Aplikasi Tingkat Lanjut,
G. Menambahkan File ke Tabel Delta yang Ada (Tulisan data
batch ke Tabel Delta)
Kami mengonversi file Parket yang ada ke tabel data lake
berbasis Parket yang akan digunakan ke tabel Delta. Kami akan
menulis file ke lokasi root Databricks File System (DBFS) di
penyimpanan objek cloud kami. Kami membuat tabel
menggunakanBuat Tabel Sebagai Pilihan(CTAS) pola Spark SQL
seperti yang ditunjukkan pada skrip berikut:
H. Menggali hasil analisis
Kita dapat memodifikasi tabel Delta yang ada dengan
menambahkan file ke direktori file Delta yang ada. Kami menambahkan
catatan bulan berikutnya, disimpan didata_pelacak_kesehatan_2020_02
tabel dengan menggunakanINSERT INTOPerintah Spark SQL seperti
yang ditunjukkan pada skrip berikut:
I. Menilai Catatan yang Hilang
Setelah pembaruan batch darikesehatan_pelacak_peraktabel,
kami menghitung jumlah catatan dalam tabel. Kami menemukan
bahwa beberapa catatan hilang olehHitung Jumlah Catatan per
Perangkat.
J. Menilai Catatan yang Hilang
Setelah pembaruan batch tabel health_tracker_silver, kami
menghitung jumlah catatan di tabel . Kami menemukan bahwa
beberapa catatan hilang dengan Hitung Jumlah Catatan per
Perangkat.
TABEL I. TDIANJUMLAHREKORPERDPERANGKAT
ID Perangkat Jumlah Catatan
0 1440
1 1440
2 1440
3 1440
4 1345
Pada Tabel I, perangkat nomor 4 terlihat kehilangan 95 record. Kami
menjalankan kueri untuk menemukan waktu catatan yang hilang dengan
menampilkan jumlah catatan per hari. Kami tidak memiliki catatan untuk
perangkat 4 selama beberapa hari terakhir dalam sebulan, seperti yang
ditunjukkan dalam kueri Spark SQL berikut:
PILIH dte sebagai Tanggal, p_device_id sebagai Device_Id,
detak jantung sebagai Heart_Rate_Reading
DARI health_tracker_silver
DI MANA p_device_id IN (1, 4) dan dte > "20-2-2020"
Pada Gambar 5, tidak adanya catatan dari beberapa hari terakhir dalam
sebulan menunjukkan fenomena yang mungkin sering terjadi dalam jalur
data produksi: data yang datang terlambat. Delta Lake memungkinkan kami
untuk memproses data saat tiba dan siap menangani terjadinya data yang
datang terlambat.
www.ijacsa.thesai.org
Jil. 11, No. 8, 2020
Gambar 5. Tidak adanya catatan.
K. Identifikasi Bacaan Rusak pada Tabel
Dalam pemuatan awal data ke dalamkesehatan_pelacak_perak
tabel, kami mencatat bahwa ada catatan yang rusak dalam data. Secara
khusus, kami mencatat fakta bahwa beberapa pembacaan negatif ada
meskipun tidak mungkin untuk merekam detak jantung negatif. Mari
kita menilai sejauh mana pembacaan yang rusak ini di tabel kita.
Pertama, kami membuat tampilan sementara untuk pembacaan yang
rusak di tabel health_tracker_silver, seperti yang ditunjukkan dalam
skrip Spark SQL berikut:
Selanjutnya, kami menjumlahkan catatan dalam tampilan, seperti yang ditunjukkan
dalam kueri Spark SQL berikut:
PILIH SUM(broken_readings_count) DARI
broken_readings
Hasil: 67
VI. CKESIMPULAN
Banyak perusahaan menggunakan DW di berbagai area untuk
membantu proses pengambilan keputusan. Selain itu, DW
meningkatkan kecerdasan bisnis, kualitas dan konsistensi data,
menghemat waktu, dan menyimpan data historis. Di era Big Data,
jumlah data yang dibutuhkan untuk menyerap dan menyimpan adalah
tingkat yang belum pernah terjadi sebelumnya. Namun, arsitektur DW
tradisional tidak dapat mengelola data dalam jumlah besar tersebut.
Tipe barunya dari sumber data saat ini bersifat otonom, heterogen,
terukur, dan terdistribusi, yang membutuhkan teknologi modern dan
arsitektur DW modern untuk menanganinya.
Dalam makalah ini, kami mengusulkan arsitektur DW baru
yang disebut Arsitektur Gudang Data Danau. Lake Data Warehouse
Architecture adalah struktur DW baru yang bergantung pada
integrasi antara teknik DW tradisional, Hadoop Framework, dan
Apache Spark sebagai solusi hybrid. Ini membiasakan DW
tradisional. Ini menggunakan teknologi dan alat data besar
(Hadoop, Apache Spark, Data Lake, dan Delta Lake) sebagai
pelengkap untuk mendukung dan meningkatkan arsitektur yang
ada. Selain itu, dapat meningkatkan skalabilitas dan mengurangi
biaya pengembangan arsitektur DW tradisional.
Arsitektur Gudang Data Lake memiliki banyak kompetensi dibandingkan
Arsitektur DW tradisional, seperti memecahkan beberapa masalah yang
dihadapi mengintegrasikan data dari penyimpanan data besar,
423 |Halaman
 (IJACSA) Jurnal Internasional Ilmu Komputer dan Aplikasi Tingkat Lanjut,
menangani tipe data yang berbeda dari berbagai sumber. Seperti data
terstruktur (DB, spreadsheet), data semi terstruktur (file XML, file JSON),
dan data tidak terstruktur (file video, audio, gambar, email, kata,
PowerPoint, pdf). Selain itu, ia menangkap, menyimpan, mengelola, dan
menganalisis volume data yang tidak dapat ditangani oleh DW
tradisional. Selanjutnya, ia menggunakan teknologi terbaru seperti
Hadoop Platform, Data Lake, Delta Lake, dan Apache Spark yang murah
untuk meminimalkan waktu yang dihabiskan untuk menganalisis data
dan untuk mengurangi biaya penyimpanan.
REFERENSI
[1] F. Silvers, Membangun dan memelihara gudang data. CRC Pers,
2008.
[2] T. John, Data Lake untuk Perusahaan. Packt Publishing Ltd, 2017.
[3] MZ Zgurovsky dan YP Zaychenko, Data Besar: Analisis Konseptual
dan Aplikasi. Springer Nature Swiss AG, 2020.
[4] WH Inmon, Membangun Gudang Data, Edisi Keempat, vol. 13, tidak.
401. 2005.
[5] E. Saddad, A. El-Bastawissy, O. Hegazy, dan M. Hazman, Towards an
Alternative Data Warehouses Architecture, in 14th International
Conference on Hybrid Intelligent Systems (HIS 2014), Kuwait, 14-16
Desember , 2014 (IEEE, Poster), 2014, vol. 6, hlm. 48–53.
[6] K. Krishnan, Data Warehousing di Era Big Data. Elsevier Inc., 2013.
[7] RG Goss dan K. Veeramuthu, Menuju big data membangun gudang data yang
lebih baik untuk lebih banyak data, lebih banyak kecepatan, dan lebih
banyak pengguna, di ASMC 2013 SEMI Advanced Semiconductor
Manufacturing Conference, 2013, hlm. 220–225.
[8] A. Sebaa, F. Chikh, A. Nouicer, dan A. Tari, Research in Big Data Warehousing
using Hadoop, J. Inf. Sistem Ind. Manajemen., vol. 2, tidak. 2, hlm. 1-5, 2017.
[9] WH Inmon dan D. Linstedt, Arsitektur Data: A Primer untuk Data Scientist:
Big Data, Data Warehouse dan Data Vault. 2014.
[10] CL Philip Chen dan CY Zhang, Aplikasi, tantangan, teknik, dan
teknologi Data-intensif: Sebuah survei tentang Big Data, vol.
275. Elsevier Inc., 2014.
[11] VKA Arockia Panimalar. S, Varnekha Shree. S, The 17 V dari Big Data,‖
Int. Res. J. Eng. Teknologi., vol. 4, tidak. 9, hlm. 3–6, 2017.
[12] N. Khan, M. Alsaqer, H. Shah, G. Badsha, AA Abbasi, dan S.
Salehian, The 10 Vs, isu dan tantangan big data,‖ ACM Int. Kon.
Lanjutkan Ser., no. Maret, hlm. 52–56, 2018.
[13] R. Rialti dan G. Marzi, Organisasi Ambidextrous di Era Big Data.
Cham: Penerbitan Internasional Springer, 2019.
[14] A. Khaleel dan H. Al-Raweshidy, Optimasi Komputasi dan Sumber Daya
Jaringan dari Cluster Hadoop Berdasarkan Jaringan yang Ditentukan
Perangkat Lunak,‖ IEEE Access, vol. 6, tidak. c, hlm. 61351–61365, 2018.
[15] IB Lars George, Jan Kunigk, Paul Wilkinson, Merancang Platform Data Modern:
Panduan untuk Enterprise Hadoop dalam Skala Besar. O'Reilly Media, 2019.
[16] Z. Yang dan X. Guo, Mengajar Hadoop Menggunakan Role Play Games,‖ Putus. Sci. J.
Inovasi. Pendidikan, vol. 18, tidak. 1, hlm. 6–21, 2020.
[17] J. Liu, S. Tang, G. Xu, C. Ma, dan M. Lin, Metode Penyetelan Konfigurasi
Novel Berdasarkan Seleksi Fitur untuk Hadoop MapReduce, IEEE
Access, vol. 8, hlm. 63862–63871, 2020.
[18] C. Walker dan H. Alrehamy, Danau Data Pribadi dengan Tarik Gravitasi
Data,‖ Proc. - 2015 IEEE 5th Int. Kon. Komputasi Awan Data Besar.
BDCloud 2015, hlm. 160–167, 2015.
[19] PP Khine and ZS Wang, Data lake: a new ideology in big data era, ITM
Web Conf., vol. 17, tidak. Desember, hal. 03025, 2018.
[20] A. Panwar dan V. Bhatnagar, Arsitektur Danau Data: Repositori Baru
untuk Insinyur Data,‖ Int. J.Organ. Mengumpulkan. Intel., vol. 10, tidak.
1, hlm. 63–75, 2020.
[21] P. Russom, Danau data: tujuan, praktik, pola, dan platform, hlm. 1–
42, 2017.
www.ijacsa.thesai.org
Jil. 11, No. 8, 2020
[22] Tantangan HD, S. Gupta, dan V. Giri, Wawasan Danau Data Perusahaan
Praktis. Apres, 2018.
[23] A. Gorelik, Danau data besar perusahaan: Menyampaikan janji tentang data
besar dan ilmu data. O'Reilly Media, 2019.
[24] C. Madera dan A. Laurent, Evolusi arsitektur informasi berikutnya:
Gelombang danau data,‖ 8th Int. Kon. Kelola. Angka. ekosistem.
MEDES 2016, hlm. 174–180, 2016.
[25] Lei Zhang, Apa perbedaan antara database, data mart, gudang
data, danau data, dan kubus?,‖ quora, 2016. [Online]. Tersedia:
https://www.quora.com/. [Diakses: 15-Feb-2019].
[26] MY Santos, B. Martinho, dan C. Costa, Memodelkan dan mengimplementasikan
gudang data besar untuk dukungan keputusan, J. Manag. Anal., vol. 4, tidak. 2, hlm.
111–129, 2017.
[27] F. Ravat dan Y. Zhao, Data Lakes: Trends and Perspectives, di Springer
Nature Switzerland AG 2019, 2019, vol. 2, tidak. Umr 5505, hlm. 304–
313.
[28] AT Spark, Apache Spark,‖ no. 1, hlm. 39–53, 2018.
[29] MM Rathore, H. Son, A. Ahmad, A. Paul, dan G. Jeon, Pemrosesan Aliran Data
Besar Waktu Nyata Menggunakan GPU dengan Ekosistem Spark Over
Hadoop,‖ Int. J. Program Paralel., vol. 46, tidak. 3, hlm. 630–646, 2018.
[30] T. Mahapatra dan C. Prehofer, Pemrograman Spark berbasis Aliran
Grafis, vol. 7, tidak. 1. Penerbitan Internasional Springer, 2020.
[31] Microsoft Team, Pengantar Delta Lake - Azure Databricks |
MicrosoftDocs,‖2020.[Online].Tersedia: https://
docs.microsoft.com/en-us/azure/databricks/delta/delta-intro.
[Diakses: 26-Mei-2020].
[32] A. Wojciechowski, ETL alur kerja reparasi melalui penalaran berbasis kasus,‖
Inf. Sistem Depan., vol. 20, tidak. 1, hlm. 21–43, 2018.
[33] F. Bentayeb, C. Favre, dan O. Boussaid, Pendekatan evolusi gudang data yang
digerakkan pengguna untuk kebutuhan analisis pribadi yang bersamaan,‖ Integr.
Hitung. Dibantu. Ind., vol. 15, tidak. 1, hlm. 21–36, 2008.
[34] G. Thakur dan A. Gosain, DWEVOLVE: kerangka kerja berbasis
kebutuhan untuk evolusi gudang data,‖ ACM SIGSOFT Softw. Ind.
Catatan, vol. 36, tidak. 6, hlm. 1–8, 2011.
[35] W. Ahmed, E. Zimányi, dan R. Wrembel, Model logis untuk gudang data
multiversi, dalam Konferensi Internasional tentang Pergudangan Data
dan Penemuan Pengetahuan, 2014, hlm. 23–34.
[36] M. Thenmozhi dan K. Vivekanandan, Sebuah pendekatan ontologis untuk
menangani evolusi skema multidimensi untuk gudang data,‖ Int. J.
Manajemen Basis Data. Sistem, vol. 6, tidak. 3, hal. 33, 2014.
[37] C. Olston et al., Nova: alur kerja babi/hadoop berkelanjutan, dalam
Prosiding Konferensi Internasional ACM SIGMOD 2011 tentang
Pengelolaan data, 2011, hlm. 1081–1090.
[38] S. Nadal, O. Romero, A. Abello, P. Vassiliadis, dan S. Vansummeren,
Ontologi berorientasi integrasi untuk mengatur evolusi dalam ekosistem big
data,‖ Inf. Sistem, vol. 79, hlm. 3–19, 2017.
[39] J. Song, C. Guo, Z. Wang, Y. Zhang, G. Yu, dan J.-M. Pierson,
HaoLap: Sistem OLAP berbasis Hadoop untuk data besar,‖ J. Syst. Softw., vol.
102, hlm. 167–181, 2015.
[40] W. Chen, H. Wang, X. Zhang, dan Q. Lin, Sistem OLAP terdistribusi yang
dioptimalkan untuk data besar, pada Konferensi Internasional IEEE ke-2
2017 tentang Kecerdasan dan Aplikasi Komputasi (ICCIA), 2017, hlm. 36– 40.
[41] R. Tardio, A. Mate, dan J. Trujillo, Metodologi iteratif untuk manajemen,
analisis, dan visualisasi big data,‖ pada 2015 IEEE International
Conference on Big Data (Big Data), 2015, hlm. 545–550 .
[42] S. Chen, Cheetah: kinerja tinggi, gudang data kustom di atas
MapReduce,‖ Proc. VLDB Endow., vol. 3, tidak. 1–2, hlm. 1459–
1468, 2010.
[43] K. Akepanidtaworn, 'Apakah 'Danau Delta' Menggantikan 'Danau Data'? -
Dev Dream Team - Medium,‖ 2020. [Online]. Tersedia: https://
medium.com/dev-dream-team/is-delta-lake-replacing-data-
lakes-49f1caddc646. [Diakses: 26-Mei-2020].
[44] Tim Databricks, Parquet files — Databricks Documentation,‖ 04/03,
2020. [Online]. Tersedia: https://docs.databricks.com/data/datasources/
read-parquet.html#parquet-files. [Diakses: 25-Mei-2020]
424 |Halaman