Bagikan melalui

Praktik terbaik untuk menggunakan Azure Data Lake Storage

Artikel ini menyediakan panduan praktik terbaik yang membantu Anda mengoptimalkan performa, mengurangi biaya, dan mengamankan akun Azure Storage yang diaktifkan Data Lake Storage Anda.

Untuk saran umum sekeliling penataan data lake, lihat artikel berikut ini:

Cari dokumentasi

Azure Data Lake Storage bukan layanan khusus atau jenis akun. Ini adalah serangkaian kemampuan yang mendukung beban kerja analitik throughput tinggi. Dokumentasi Data Lake Storage memberikan praktik dan panduan terbaik untuk menggunakan kemampuan ini. Untuk semua aspek lain dari manajemen akun seperti menyiapkan keamanan jaringan, merancang ketersediaan tinggi, dan pemulihan bencana, lihat konten dokumentasi penyimpanan Blob .

Mengevaluasi dukungan fitur dan masalah yang diketahui

Gunakan pola berikut saat Mengonfigurasi akun untuk menggunakan fitur penyimpanan Blob.

  1. Tinjau artikel dukungan fitur Blob Storage di akun Azure Storage untuk menentukan apakah fitur didukung sepenuhnya di akun Anda. Beberapa fitur belum didukung atau memiliki dukungan parsial di akun yang diaktifkan Data Lake Storage. Dukungan fitur selalu berkembang, jadi pastikan untuk meninjau artikel ini secara berkala untuk pembaruan.

  2. Tinjau artikel Masalah yang diketahui dengan Azure Data Lake Storage untuk melihat apakah ada batasan atau panduan khusus sekeliling fitur yang ingin Anda gunakan.

  3. Pindai artikel fitur untuk panduan apa pun yang khusus untuk akun yang diaktifkan Data Lake Storage.

Memahami istilah yang digunakan dalam dokumentasi

Saat Anda berpindah di antara set konten, Anda melihat beberapa perbedaan terminologi sedikit. Misalnya, konten yang ditampilkan dalam dokumentasi penyimpanan Blob, akan menggunakan istilah blob alih-alih file. Secara teknis, file yang Anda serap ke akun penyimpanan Anda menjadi blob di akun Anda. Oleh karena itu, istilah tersebut benar. Namun, istilah blob dapat menyebabkan kebingungan jika Anda terbiasa dengan istilah file. Anda juga akan melihat istilah kontainer yang digunakan untuk merujuk ke sistem file. Pertimbangkan istilah-istilah ini sebagai sinonim.

Pertimbangkan premium

Jika beban kerja Anda memerlukan latensi konsisten rendah dan/atau memerlukan sejumlah besar operasi output input per detik (IOP), pertimbangkan untuk menggunakan akun penyimpanan blob blok premium. Jenis akun ini membuat data tersedia melalui perangkat keras berkinerja tinggi. Data disimpan pada solid-state drive (SSD) yang dioptimalkan untuk latensi rendah. SSD menyediakan throughput yang lebih tinggi dibanding hard drive tradisional. Biaya penyimpanan performa premium lebih tinggi, tetapi biaya transaksi lebih rendah. Oleh karena itu, jika beban kerja Anda menjalankan sejumlah besar transaksi, akun block blob dengan performa premium dapat menjadi pilihan yang ekonomis.

Jika akun penyimpanan Anda akan digunakan untuk analitik, kami sangat menyarankan Anda menggunakan Azure Data Lake Storage bersama dengan akun penyimpanan blob blok premium. Kombinasi penggunaan akun penyimpanan blob blok premium bersama dengan akun yang diaktifkan Data Lake Storage ini disebut sebagai tingkat premium untuk Azure Data Lake Storage.

Optimalkan untuk pemasukan data

Saat menyerap data dari sistem sumber, perangkat keras sumber, perangkat keras jaringan sumber, atau konektivitas jaringan ke akun penyimpanan Anda dapat menjadi hambatan.

Diagram yang menunjukkan faktor-faktor yang perlu dipertimbangkan saat menyerap data dari sistem sumber ke Data Lake Storage.

Perangkat keras sumber

Baik Anda menggunakan komputer lokal atau Komputer Virtual (VM) di Azure, pastikan untuk memilih perangkat keras yang sesuai dengan hati-hati. Untuk perangkat keras disk, pertimbangkan untuk menggunakan Solid State Drives (SSD) dan pilih perangkat keras disk yang memiliki spindel yang lebih cepat. Untuk perangkat keras jaringan, gunakan Pengontrol Antarmuka Jaringan (NIC) tercepat mungkin. Di Azure, kami merekomendasikan Azure D14 VM, yang memiliki disk dan perangkat keras jaringan yang kuat dengan tepat.

Konektivitas jaringan ke akun penyimpanan

Konektivitas jaringan antara data sumber dan akun penyimpanan Anda terkadang dapat menjadi hambatan. Saat data sumber Anda lokal, pertimbangkan untuk menggunakan tautan khusus dengan Azure ExpressRoute. Jika data sumber Anda berada di Azure, performanya adalah yang terbaik saat data berada di wilayah Azure yang sama dengan akun yang diaktifkan Data Lake Storage Anda.

Mengonfigurasi alat penyerapan data untuk paralelisasi maksimum

Untuk mencapai performa terbaik, gunakan semua throughput yang tersedia dengan melakukan pembacaan dan penulisan sebanyak mungkin.

Kinerja Data Lake Storage

Tabel berikut ini meringkas pengaturan kunci untuk beberapa alat penyerapan populer.

Alat Pengaturan
DistCp -m (pemeta)
Azure Data Factory parallelCopies
Sqoop fs.azure.block.size, -m (pemeta)
AzCopy AZCOPY_CONCURRENCY_VALUE

Nota

Performa keseluruhan operasi penyerapan Anda bergantung pada faktor lain yang khusus untuk alat yang Anda gunakan untuk menyerap data. Untuk panduan penanggalan terbaik up-to-date, lihat dokumentasi untuk setiap alat yang ingin Anda gunakan.

Akun Anda dapat meningkatkan kapasitas untuk menyediakan throughput yang diperlukan untuk semua skenario analitik. Secara default, akun yang diaktifkan Data Lake Storage menyediakan throughput yang cukup dalam konfigurasi defaultnya untuk memenuhi kebutuhan kategori kasus penggunaan yang luas. Jika Anda mencapai batas default, akun tersebut dapat dikonfigurasi untuk menyediakan lebih banyak throughput dengan menghubungi layanan Dukungan Azure.

Menyusun himpunan data

Pertimbangkan pra-perencanaan struktur data Anda. Format file, ukuran file, dan struktur direktori semuanya dapat memengaruhi performa dan biaya.

Format Berkas

Data dapat diserap dalam berbagai format. Data dapat muncul dalam format yang dapat dibaca manusia seperti JSON, CSV, atau XML atau sebagai format biner terkompresi seperti .tar.gz. Data juga dapat datang dalam berbagai ukuran. Data dapat terdiri dari file besar (beberapa terabyte) seperti data dari ekspor tabel SQL dari sistem lokal Anda. Data juga dapat datang dalam bentuk sejumlah besar file kecil (beberapa kilobyte) seperti data dari peristiwa real-time dari solusi Internet of things (IoT). Anda dapat mengoptimalkan efisiensi dan biaya dengan memilih format file dan ukuran file yang sesuai.

Hadoop mendukung serangkaian format file yang dioptimalkan untuk menyimpan dan memproses data terstruktur. Beberapa format umum adalah format Avro, Parquet, dan Optimized Row Columnar (ORC). Semua format ini adalah format file biner yang dapat dibaca mesin. Mereka dikompresi untuk membantu Anda mengelola ukuran file. Mereka memiliki skema yang disematkan di setiap file, yang membuatnya menjelaskan sendiri. Perbedaan antara format ini adalah bagaimana data disimpan. Avro menyimpan data dalam format berbasis baris dan format Parquet dan ORC menyimpan data dalam format kolom.

Pertimbangkan untuk menggunakan format file Avro jika pola I/O Anda lebih banyak melakukan penulisan, atau pola permintaan mendukung pengambilan beberapa baris rekaman secara keseluruhan. Misalnya, format Avro berfungsi dengan baik dengan bus pesan seperti Azure Event Hubs atau Kafka yang menulis beberapa peristiwa/pesan secara berturut-turut.

Pertimbangkan format file Parquet dan ORC saat pola I/O lebih banyak berfokus pada pembacaan, atau ketika pola kueri difokuskan pada subset kolom dari data. Transaksi baca dapat dioptimalkan untuk mengambil kolom tertentu alih-alih membaca seluruh rekaman.

Apache Parquet adalah format file sumber terbuka yang dioptimalkan untuk membaca alur analitik berat. Struktur penyimpanan kolom Parquet memungkinkan Anda melewati data yang tidak relevan. Kueri Anda jauh lebih efisien karena dapat secara sempit mencakup data mana yang akan dikirim dari penyimpanan ke mesin analitik. Selain itu, karena jenis data serupa (untuk kolom) disimpan bersama-sama, Parquet mendukung kompresi data yang efisien dan skema pengodean yang dapat menurunkan biaya penyimpanan data. Layanan seperti Azure Synapse Analytics, Azure Databricks , dan Azure Data Factory memiliki fungsionalitas asli yang memanfaatkan format file Parquet.

Ukuran file

File yang lebih besar menyebabkan performa yang lebih baik dan mengurangi biaya.

Biasanya, mesin analitik seperti HDInsight memiliki overhead per file yang melibatkan tugas seperti mencantumkan, memeriksa akses, dan melakukan berbagai operasi metadata. Jika Anda menyimpan data sebanyak file kecil, ini dapat berdampak negatif pada performa. Secara umum, atur data Anda ke dalam file berukuran lebih besar untuk performa yang lebih baik (berukuran 256 MB hingga 100 GB). Beberapa mesin dan aplikasi mungkin mengalami kesulitan memproses file yang berukuran lebih besar dari 100 GB secara efisien.

Meningkatkan ukuran file juga dapat mengurangi biaya transaksi. Operasi baca dan tulis ditagihkan dalam kelipatan 4 megabyte, sehingga Anda dibebankan biaya untuk operasi tersebut, terlepas dari apakah file berisi 4 megabyte atau hanya beberapa kilobyte. Untuk informasi harga, lihat Harga Azure Data Lake Storage.

Terkadang, alur data memiliki kontrol terbatas atas data mentah, yang memiliki banyak file kecil. Secara umum, kami sarankan sistem Anda memiliki semacam proses untuk mengagregasi file kecil menjadi file yang lebih besar untuk digunakan oleh aplikasi hilir. Jika memproses data secara real time, Anda dapat menggunakan mesin streaming real time (seperti Azure Stream Analytics atau Spark Streaming) bersama dengan broker pesan (seperti Event Hubs atau Apache Kafka) untuk menyimpan data Anda sebagai file yang lebih besar. Saat Anda menggabungkan file kecil menjadi file yang lebih besar, pertimbangkan untuk menyimpannya dalam format yang dioptimalkan untuk dibaca seperti Apache Parquet untuk pemrosesan hilir.

Struktur direktori

Setiap beban kerja memiliki persyaratan yang berbeda tentang bagaimana data dikonsumsi, tetapi ini adalah beberapa tata letak umum yang perlu dipertimbangkan saat bekerja dengan Internet of Things (IoT), skenario batch atau saat mengoptimalkan data rangkaian waktu.

Struktur IoT

Dalam beban kerja IoT, mungkin ada banyak data yang diserap yang mencakup berbagai produk, perangkat, organisasi, dan pelanggan. Penting untuk merencanakan tata letak direktori untuk organisasi, keamanan, dan pemrosesan data yang efisien untuk konsumen down-stream. Template umum yang perlu dipertimbangkan mungkin adalah tata letak berikut:

  • {Region}/{SubjectMatter(s)}/{yyyy}/{mm}/{dd}/{hh}/

Misalnya, struktur telemetri pendaratan untuk pesawat di Inggris mungkin akan terlihat seperti berikut:

  • UK/Planes/BA1293/Engine1/2017/08/11/12/

Dalam contoh ini, dengan meletakkan tanggal di akhir struktur direktori, Anda dapat menggunakan ACL untuk lebih mudah mengamankan wilayah dan subjek untuk pengguna dan grup tertentu. Jika Anda meletakkan struktur tanggal di awal, akan jauh lebih sulit untuk mengamankan wilayah dan subjek ini. Misalnya, jika Anda ingin memberikan akses hanya ke data Inggris atau bidang tertentu, Anda harus menerapkan izin terpisah untuk banyak direktori di bawah direktori setiap jam. Struktur ini juga akan secara eksponensial meningkatkan jumlah direktori seiring berjalannya waktu.

Struktur pekerjaan batch

Pendekatan yang umum digunakan dalam pemrosesan batch adalah menempatkan data ke dalam direktori "in". Kemudian, setelah data diproses, masukkan data baru ke dalam direktori "output" yang akan digunakan oleh proses hilir. Struktur direktori ini terkadang digunakan untuk pekerjaan yang memerlukan pemrosesan pada file individual, dan mungkin tidak memerlukan pemrosesan paralel secara besar-besaran atas himpunan data besar. Seperti struktur IoT yang direkomendasikan di atas, struktur direktori yang baik memiliki direktori tingkat induk untuk hal-hal seperti wilayah dan masalah subjek (misalnya, organisasi, produk, atau produsen). Pertimbangkan tanggal dan waktu dalam struktur untuk memungkinkan organisasi yang lebih baik, pencarian yang difilter, keamanan, dan otomatisasi dalam pemrosesan. Tingkat granuralitas untuk struktur tanggal ditentukan oleh interval di mana data diunggah atau diproses, seperti per jam, hari, atau bahkan bulan.

Terkadang pemrosesan file tidak berhasil karena rusaknya data atau format yang tidak terduga. Dalam kasus seperti itu, struktur direktori mungkin mendapat manfaat dari folder /bad untuk memindahkan file ke untuk pemeriksaan lebih lanjut. Pekerjaan batch mungkin juga menangani pelaporan atau pemberitahuan file bermasalah ini untuk intervensi manual. Mempertimbangkan struktur templat berikut ini:

  • {Region}/{SubjectMatter(s)}/In/{yyyy}/{mm}/{dd}/{hh}/
  • {Region}/{SubjectMatter(s)}/Out/{yyyy}/{mm}/{dd}/{hh}/
  • {Region}/{SubjectMatter(s)}/Bad/{yyyy}/{mm}/{dd}/{hh}/

Misalnya, sebuah perusahaan pemasaran menerima ekstrak data harian pembaruan pelanggan dari klien mereka di Amerika Utara. Proses sebelum dan sesudahnya mungkin akan terlihat seperti cuplikan berikut:

  • NA/Extracts/ACMEPaperCo/In/2017/08/14/updates_08142017.csv
  • NA/Extracts/ACMEPaperCo/Out/2017/08/14/processed_updates_08142017.csv

Dalam kasus umum data batch yang diproses langsung ke database seperti Apache Hive atau database SQL tradisional, tidak perlu direktori /in atau /out karena output sudah masuk ke folder terpisah untuk tabel Apache Hive atau database eksternal. Misalnya, ekstrak harian dari pelanggan akan masuk ke masing-masing direktori mereka. Kemudian, layanan seperti Azure Data Factory, Apache Oozie, atau Apache Airflow akan memicu pekerjaan Apache Hive atau Spark harian untuk memproses dan menulis data ke dalam tabel Apache Hive.

Struktur data rangkaian waktu

Untuk beban kerja Apache Hive, pemangkasan partisi data rangkaian waktu dapat membantu beberapa kueri hanya membaca subset data, yang meningkatkan performa.

Pipeline yang memproses data deret waktu sering menempatkan berkas mereka dengan penamaan terstruktur untuk berkas dan folder. Di bawah ini adalah contoh umum yang kita lihat untuk data yang disusun berdasarkan tanggal:

/DataSet/YYYY/MM/DD/datafile_YYYY_MM_DD.tsv

Perhatikan bahwa informasi tanggal dan waktu muncul baik sebagai folder maupun dalam nama file.

Untuk tanggal dan waktu, berikut ini adalah pola umum

/DataSet/YYYY/MM/DD/HH/mm/datafile_YYYY_MM_DD_HH_mm.tsv

Sekali lagi, pilihan yang Anda buat mengenai organisasi folder dan berkas seharusnya dioptimalkan untuk ukuran berkas yang lebih besar dan jumlah berkas yang wajar di setiap folder.

Menyiapkan keamanan

Mulailah dengan meninjau rekomendasi di artikel Rekomendasi keamanan untuk penyimpanan Blob . Anda akan menemukan panduan praktik terbaik tentang cara melindungi data Anda dari penghapusan yang tidak disengaja atau berbahaya, mengamankan data di belakang firewall, dan menggunakan ID Microsoft Entra sebagai dasar manajemen identitas.

Kemudian, tinjau artikel Model kontrol akses di Azure Data Lake Storage untuk panduan khusus untuk akun yang diaktifkan Data Lake Storage. Artikel ini membantu Anda memahami cara menggunakan peran kontrol akses berbasis peran Azure (Azure RBAC) bersama dengan daftar kontrol akses (ACL) untuk menerapkan izin keamanan pada direktori dan file dalam sistem file hierarkis Anda.

Menyerap, memproses, dan menganalisis

Ada banyak sumber data yang berbeda dan berbagai cara di mana data tersebut dapat diserap ke dalam akun yang diaktifkan Data Lake Storage.

Misalnya, Anda dapat menyerap sekumpulan besar data dari kluster HDInsight dan Hadoop atau set data ad hoc yang lebih kecil untuk aplikasi prototipe. Anda dapat menyerap data yang dialirkan yang dihasilkan oleh berbagai sumber seperti aplikasi, perangkat, dan sensor. Untuk jenis data ini, Anda dapat menggunakan alat untuk mengambil dan memproses data berdasarkan peristiwa demi peristiwa secara real time, lalu menulis peristiwa dalam batch ke akun Anda. Anda juga dapat menyerap log server web, yang berisi informasi seperti riwayat permintaan halaman. Untuk data log, pertimbangkan untuk menulis skrip atau aplikasi kustom untuk mengunggahnya sehingga Anda akan memiliki fleksibilitas untuk menyertakan komponen pengunggahan data Anda sebagai bagian dari aplikasi big data Yang lebih besar.

Setelah data tersedia di akun Anda, Anda dapat menjalankan analisis pada data tersebut, membuat visualisasi, dan bahkan mengunduh data ke komputer lokal Anda atau ke repositori lain seperti database Azure SQL atau instans SQL Server.

Tabel berikut merekomendasikan alat yang bisa Anda gunakan untuk menyerap, menganalisis, memvisualisasikan, dan mengunduh data. Gunakan tautan dalam tabel ini untuk menemukan panduan tentang cara mengonfigurasi dan menggunakan setiap alat.

Tujuan Alat & Panduan alat
Menyerap data ad hoc Portal Microsoft Azure, Azure PowerShell, Azure CLI, REST, Azure Storage Explorer, Apache DistCp, AzCopy
Menyerap data relasional Azure Data Factory
Memasukkan log server web Azure PowerShell, Azure CLI, REST, Azure SDK (.NET, Java, Python, dan Node.js), Azure Data Factory
Menyerap dari kluster HDInsight Azure Data Factory, Apache DistCp, AzCopy
Menyerap dari kluster Hadoop Azure Data Factory, Apache DistCp, WANdisco LiveData Migrator untuk Azure, Azure Data Box
Menyerap himpunan data besar (beberapa terabyte) Azure ExpressRoute
proses dan analisis data Azure Synapse Analytics, Azure HDInsight, Databricks
Memvisualisasikan data Power BI, akselerasi kueri untuk Azure Data Lake Storage
Mengunduh data Portal Microsoft Azure, PowerShell, Azure CLI, REST, Azure SDK (.NET, Java, Python, dan Node.js), Azure Storage Explorer, AzCopy, Azure Data Factory, Apache DistCp

Nota

Tabel ini tidak mencerminkan daftar lengkap layanan Azure yang mendukung Data Lake Storage. Untuk melihat daftar layanan Azure yang didukung, tingkat dukungannya, lihat Layanan Azure yang mendukung Azure Data Lake Storage.

Mengawasi telemetri

Memantau penggunaan dan performa adalah bagian penting untuk mengoperasionalkan layanan Anda. Contohnya termasuk operasi yang sering, operasi dengan latensi tinggi, atau operasi yang menyebabkan pembatasan dari sisi layanan.

Semua telemetri untuk akun penyimpanan Anda tersedia melalui log Azure Storage di Azure Monitor. Fitur ini mengintegrasikan akun penyimpanan Anda dengan Log Analytics dan Event Hubs, sekaligus memungkinkan Anda mengarsipkan log ke akun penyimpanan lain. Untuk melihat daftar lengkap metrik dan log sumber daya dan skema terkaitnya, lihat Referensi data pemantauan Azure Storage.

Di mana Anda memilih untuk menyimpan log Anda tergantung pada cara Anda berencana untuk mengaksesnya. Misalnya, jika Anda ingin mengakses log mendekati real time, dan dapat menghubungkan peristiwa di log dengan metrik lain dari Azure Monitor, Anda dapat menyimpan log Anda di ruang kerja Log Analytics. Kemudian, kueri log Anda dengan menggunakan kueri KQL dan penulis, yang menghitung StorageBlobLogs tabel di ruang kerja Anda.

Jika Anda ingin menyimpan log untuk kueri mendekati real time dan retensi jangka panjang, Anda dapat mengonfigurasi pengaturan diagnostik untuk mengirim log ke ruang kerja Log Analytics dan akun penyimpanan.

Jika Anda ingin mengakses log melalui mesin kueri lain seperti Splunk, Anda dapat mengonfigurasi pengaturan diagnostik untuk mengirim log ke pusat aktivitas dan menyerap log dari hub peristiwa ke tujuan yang Anda pilih.

Log Azure Storage di Azure Monitor dapat diaktifkan melalui portal Microsoft Azure, PowerShell, Azure CLI, dan templat Azure Resource Manager. Untuk penyebaran dalam skala besar, Azure Policy dapat digunakan dengan dukungan penuh untuk tugas remediasi. Untuk informasi selengkapnya, lihat ciphertxt/AzureStoragePolicy.

Lihat juga