Artikel ini adalah terjemahan dari artikel saya di medium - , yang ternyata cukup populer, mungkin karena kesederhanaannya. Oleh karena itu, saya memutuskan untuk menulisnya dalam bahasa Rusia dan menambahkan sedikit untuk memperjelas kepada orang biasa yang bukan spesialis data apa itu gudang data (DW), dan apa itu danau data (Data Lake), dan bagaimana mereka rukun bersama.
Mengapa saya ingin menulis tentang data lake? Saya telah bekerja dengan data dan analitik selama lebih dari 10 tahun, dan sekarang saya benar-benar bekerja dengan data besar di Amazon Alexa AI di Cambridge, yang berada di Boston, meskipun saya tinggal di Victoria di Pulau Vancouver dan sering mengunjungi Boston, Seattle , dan Di Vancouver, dan terkadang bahkan di Moskow, saya berbicara di konferensi. Saya juga menulis dari waktu ke waktu, tetapi saya kebanyakan menulis dalam bahasa Inggris, dan saya sudah menulisnya , Saya juga memiliki kebutuhan untuk berbagi tren analitik dari Amerika Utara, dan terkadang saya menulisnya .
Saya selalu bekerja dengan gudang data, dan sejak tahun 2015 saya mulai bekerja sama dengan Amazon Web Services, dan umumnya beralih ke analisis cloud (AWS, Azure, GCP). Saya telah mengamati evolusi solusi analitik sejak tahun 2007 dan bahkan bekerja untuk vendor gudang data Teradata dan menerapkannya di Bank Tabungan, dan saat itulah Big Data dengan Hadoop muncul. Semua orang mulai mengatakan bahwa era penyimpanan telah berlalu dan sekarang semuanya ada di Hadoop, dan kemudian mereka mulai berbicara tentang Data Lake, sekali lagi, bahwa akhir dari gudang data pasti telah tiba. Namun untungnya (mungkin sayangnya bagi sebagian orang yang menghasilkan banyak uang dengan menyiapkan Hadoop), gudang data tidak hilang.
Pada artikel ini kita akan melihat apa itu data lake. Artikel ini ditujukan bagi orang-orang yang memiliki sedikit atau tidak sama sekali pengalaman dengan gudang data.
Dalam gambar tersebut adalah Danau Bled, ini adalah salah satu danau favorit saya, walaupun saya hanya sekali ke sana, saya mengingatnya seumur hidup. Tapi kita akan berbicara tentang jenis danau lain - danau data. Mungkin banyak dari Anda yang sudah mendengar istilah ini lebih dari satu kali, namun definisi lain tidak akan merugikan siapa pun.
Pertama-tama, berikut adalah definisi paling populer dari Data Lake:
“penyimpanan file dari semua jenis data mentah yang tersedia untuk dianalisis oleh siapa pun di organisasi” - Martin Fowler.
“Jika Anda mengira data mart adalah sebotol air yang dimurnikan, dikemas, dan dikemas agar mudah dikonsumsi, maka data lake adalah reservoir air yang sangat besar dalam bentuk alaminya. Pengguna, saya bisa mengambil air untuk diri saya sendiri, menyelam lebih dalam, menjelajah” - James Dixon.
Sekarang kita tahu pasti bahwa data lake adalah tentang analitik, ini memungkinkan kita untuk menyimpan data dalam jumlah besar dalam bentuk aslinya dan kita memiliki akses yang diperlukan dan nyaman ke data tersebut.
Saya sering suka menyederhanakan sesuatu, jika saya bisa menjelaskan istilah yang kompleks dengan kata-kata sederhana, maka saya mengerti sendiri cara kerjanya dan untuk apa istilah itu diperlukan. Suatu hari, saya melihat-lihat galeri foto iPhone, dan saya sadar, ini adalah data lake yang nyata, saya bahkan membuat slide untuk konferensi:
Semuanya sangat sederhana. Kita mengambil foto di ponsel, foto tersebut disimpan di ponsel dan dapat disimpan ke iCloud (penyimpanan file cloud). Ponsel ini juga mengumpulkan metadata foto: apa yang ditampilkan, tag geografis, waktu. Hasilnya, kita dapat menggunakan antarmuka iPhone yang ramah pengguna untuk menemukan foto kita dan bahkan kita melihat indikatornya, misalnya ketika saya mencari foto dengan kata api, saya menemukan 3 foto dengan gambar api. Bagi saya, ini seperti alat Business Intelligence yang bekerja sangat cepat dan akurat.
Dan tentunya kita tidak boleh melupakan keamanan (otorisasi dan autentikasi), jika tidak, data kita dapat dengan mudah masuk ke domain publik. Ada banyak berita tentang perusahaan besar dan startup yang datanya tersedia untuk umum karena kelalaian pengembang dan kegagalan mengikuti aturan sederhana.
Bahkan gambaran sederhana seperti itu membantu kita membayangkan apa itu data lake, perbedaannya dengan gudang data tradisional, dan elemen utamanya:
- Memuat Data (Penyerapan) adalah komponen kunci dari data lake. Data dapat masuk ke gudang data dengan dua cara - batch (memuat secara berkala) dan streaming (aliran data).
- Penyimpanan berkas (Penyimpanan) adalah komponen utama Data Lake. Kami membutuhkan penyimpanan yang mudah diskalakan, sangat andal, dan berbiaya rendah. Misalnya, di AWS adalah S3.
- Katalog dan Pencarian (Katalog dan Pencarian) - agar kita menghindari Rawa Data (ini adalah saat kita membuang semua data dalam satu tumpukan, dan kemudian tidak mungkin untuk mengerjakannya), kita perlu membuat lapisan metadata untuk mengklasifikasikan data sehingga pengguna dapat dengan mudah menemukan data yang mereka perlukan untuk dianalisis. Selain itu, Anda dapat menggunakan solusi pencarian tambahan seperti ElasticSearch. Pencarian membantu pengguna menemukan data yang diperlukan melalui antarmuka yang ramah pengguna.
- pengolahan (Proses) - langkah ini bertanggung jawab untuk memproses dan mengubah data. Kita dapat mentransformasikan data, mengubah strukturnya, membersihkannya, dan masih banyak lagi.
- keamanan (Keamanan) - Penting untuk meluangkan waktu pada desain keamanan solusi. Misalnya, enkripsi data selama penyimpanan, pemrosesan, dan pemuatan. Penting untuk menggunakan metode otentikasi dan otorisasi. Terakhir, diperlukan alat audit.
Dari sudut pandang praktis, kita dapat mengkarakterisasi data lake dengan tiga atribut:
- Kumpulkan dan simpan apa saja — data lake berisi semua data, baik data mentah yang belum diproses untuk jangka waktu tertentu maupun data yang diproses/dibersihkan.
- Memindai dengan seksama — data lake memungkinkan pengguna menjelajahi dan menganalisis data.
- Akses fleksibel — Data lake menyediakan akses fleksibel untuk berbagai data dan skenario berbeda.
Sekarang kita bisa membahas perbedaan antara data warehouse dan data lake. Biasanya orang bertanya:
- Bagaimana dengan gudang data?
- Apakah kita mengganti data warehouse dengan data lake atau memperluasnya?
- Apakah masih mungkin dilakukan tanpa data lake?
Singkatnya, tidak ada jawaban yang jelas. Itu semua tergantung pada situasi spesifik, keterampilan tim, dan anggaran. Misalnya, memigrasikan gudang data ke Oracle ke AWS dan membuat danau data oleh anak perusahaan Amazon - Woot - .
Di sisi lain, vendor Snowflake mengatakan bahwa Anda tidak perlu lagi memikirkan data lake, karena platform data mereka (sampai tahun 2020 adalah gudang data) memungkinkan Anda menggabungkan data lake dan data warehouse. Saya belum banyak bekerja dengan Snowflake, dan ini benar-benar produk unik yang dapat melakukan hal ini. Harga dari masalah ini adalah masalah lain.
Kesimpulannya menurut saya pribadi, kita masih memerlukan data warehouse sebagai sumber data utama untuk pelaporan kita, dan apa pun yang kurang sesuai kita simpan di data lake. Seluruh peran analitik adalah memberikan akses mudah bagi bisnis untuk mengambil keputusan. Apa pun yang dikatakan orang, pengguna bisnis bekerja lebih efisien dengan gudang data daripada danau data, misalnya di Amazon - ada Redshift (gudang data analitik) dan ada Redshift Spectrum/Athena (antarmuka SQL untuk danau data di S3 berdasarkan sarang/Presto). Hal yang sama berlaku untuk gudang data analitik modern lainnya.
Mari kita lihat arsitektur gudang data pada umumnya:
Ini adalah solusi klasik. Kami memiliki sistem sumber, dengan menggunakan ETL/ELT kami menyalin data ke dalam gudang data analitis dan menghubungkannya ke solusi Business Intelligence (favorit saya adalah Tableau, bagaimana dengan milik Anda?).
Solusi ini memiliki kelemahan sebagai berikut:
- Operasi ETL/ELT memerlukan waktu dan sumber daya.
- Biasanya, memori untuk menyimpan data di gudang data analitik tidaklah murah (misalnya Redshift, BigQuery, Teradata), karena kita perlu membeli seluruh cluster.
- Pengguna bisnis memiliki akses ke data yang telah dibersihkan dan sering kali dikumpulkan serta tidak memiliki akses ke data mentah.
Tentu saja, itu semua tergantung pada kasus Anda. Jika Anda tidak memiliki masalah dengan data warehouse Anda, maka Anda tidak memerlukan data lake sama sekali. Namun ketika masalah yang muncul karena kurangnya ruang, listrik, atau harga memainkan peran penting, maka Anda dapat mempertimbangkan opsi data lake. Inilah sebabnya mengapa data lake sangat populer. Berikut adalah contoh arsitektur data lake:
Dengan menggunakan pendekatan data lake, kami memuat data mentah ke dalam data lake kami (batch atau streaming), lalu kami memproses data tersebut sesuai kebutuhan. Data lake memungkinkan pengguna bisnis membuat transformasi data mereka sendiri (ETL/ELT) atau menganalisis data dalam solusi Business Intelligence (jika driver yang diperlukan tersedia).
Tujuan dari setiap solusi analitik adalah untuk melayani pengguna bisnis. Oleh karena itu, kita harus selalu bekerja sesuai dengan kebutuhan bisnis. (Di Amazon, ini adalah salah satu prinsipnya - bekerja mundur).
Bekerja dengan gudang data dan data lake, kita dapat membandingkan kedua solusi:
Kesimpulan utama yang dapat ditarik adalah bahwa data warehouse tidak bersaing dengan data lake, melainkan saling melengkapi. Namun terserah Anda untuk memutuskan apa yang tepat untuk kasus Anda. Selalu menarik untuk mencobanya sendiri dan menarik kesimpulan yang tepat.
Saya juga ingin memberi tahu Anda salah satu kasus ketika saya mulai menggunakan pendekatan data lake. Semuanya cukup sepele, saya mencoba menggunakan alat ELT (kami punya Matillion ETL) dan Amazon Redshift, solusi saya berhasil, tetapi tidak memenuhi persyaratan.
Saya perlu mengambil log web, mengubahnya, dan menggabungkannya untuk menyediakan data untuk 2 kasus:
- Tim pemasaran ingin menganalisis aktivitas bot untuk SEO
- TI ingin melihat metrik kinerja situs web
Log yang sangat sederhana dan sangat sederhana. Berikut ini contohnya:
https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"Satu file berbobot 1-4 megabyte.
Tapi ada satu kesulitan. Kami memiliki 7 domain di seluruh dunia, dan 7000 ribu file dibuat dalam satu hari. Volumenya tidak lebih besar, hanya 50 gigabyte. Namun ukuran cluster Redshift kami juga kecil (4 node). Memuat satu file dengan cara tradisional membutuhkan waktu sekitar satu menit. Artinya, permasalahan tersebut tidak diselesaikan secara langsung. Dan inilah yang terjadi ketika saya memutuskan untuk menggunakan pendekatan data lake. Solusinya terlihat seperti ini:
Ini cukup sederhana (saya ingin mencatat bahwa keuntungan bekerja di cloud adalah kesederhanaannya). Saya menggunakan:
- AWS Elastic Map Reduce (Hadoop) untuk Daya Komputasi
- AWS S3 sebagai penyimpanan file dengan kemampuan mengenkripsi data dan membatasi akses
- Spark sebagai kekuatan komputasi InMemory dan PySpark untuk logika dan transformasi data
- Parket sebagai hasil dari Spark
- AWS Glue Crawler sebagai pengumpul metadata tentang data dan partisi baru
- Redshift Spectrum sebagai antarmuka SQL ke data lake untuk pengguna Redshift yang sudah ada
Cluster EMR+Spark terkecil memproses seluruh tumpukan file dalam 30 menit. Ada kasus lain untuk AWS, terutama banyak yang terkait dengan Alexa, di mana terdapat banyak data.
Baru-baru ini saya mengetahui salah satu kelemahan data lake adalah GDPR. Masalahnya adalah ketika klien meminta untuk menghapusnya dan datanya ada di salah satu file, kita tidak bisa menggunakan Bahasa Manipulasi Data dan operasi DELETE seperti di database.
Saya harap artikel ini menjelaskan perbedaan antara data warehouse dan data lake. Jika Anda tertarik, saya dapat menerjemahkan lebih banyak artikel saya atau artikel profesional yang saya baca. Dan juga ceritakan tentang solusi yang saya gunakan dan arsitekturnya.
Sumber: www.habr.com