Partisi dalam model tabular

Artikel
05/08/2023

Berlaku untuk: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Partisi membagi bagian data yang perlu sering Anda proses (refresh) dari data yang dapat diproses lebih jarang. Misalnya, tabel fakta mungkin menyertakan kumpulan baris tertentu yang berisi data yang jarang berubah, tetapi kumpulan baris lain memiliki data yang sering berubah. Tidak perlu memproses semua data ketika hanya sebagian dari data yang perlu diproses.

Partisi bekerja dengan membagi tabel menjadi objek partisi logis. Partisi individu, masing-masing berisi segmen data yang unik, kemudian dapat diproses secara bertahap baik secara berurutan atau secara paralel terlepas dari partisi lain, atau dikecualikan dari operasi pemrosesan sama sekali.

Granularitas

Secara default, setiap tabel dalam model memiliki satu partisi. Dalam banyak kasus, seperti dengan tabel fakta, memba lagi partisi tunggal tabel menjadi beberapa partisi dapat lebih baik memanfaatkan sumber daya yang tersedia untuk diproses.

Strategi desain dan pemrosesan model yang efektif menggunakan partisi untuk menghilangkan beban prosesor dan konsumsi memori yang tidak perlu, sementara pada saat yang sama memastikan bahwa data cukup sering disegarkan untuk mencerminkan data terbaru dari sumber data. Misalnya, model tabular dapat memiliki tabel Penjualan yang mencakup data penjualan untuk tahun fiskal saat ini dan masing-masing tahun fiskal sebelumnya. Tabel Penjualan model memiliki partisi berikut:

Partisi	Data dari
Sales2020	Tahun fiskal saat ini
Sales2019-2010	Tahun fiskal 2010, 2011, 2012, 2013, 2014, 2015. 2016, 2017, 2018, 2019
SalesOld	Semua tahun fiskal sebelum sepuluh tahun terakhir.

Karena data penjualan baru ditambahkan untuk tahun fiskal 2020 saat ini, data tersebut harus diproses setiap hari agar tercermin secara akurat dalam analisis data penjualan tahun fiskal saat ini, oleh karena itu partisi Sales2020 diproses setiap malam.

Tidak perlu memproses data di partisi Sales2019-2010 per malam. Namun, karena data penjualan untuk sepuluh tahun fiskal sebelumnya masih dapat berubah karena pengembalian produk dan penyesuaian lainnya, data tersebut masih harus diproses secara teratur, oleh karena itu data dalam partisi Sales2019-2010 diproses setiap bulan. Data dalam partisi SalesOld jarang berubah, oleh karena itu hanya diproses setiap tahun.

Saat memasuki tahun fiskal 2021, partisi Sales2021 baru ditambahkan ke tabel Penjualan model. Partisi Sales2020 kemudian dapat digabungkan dengan partisi Sales2019-2010 dan diganti namanya menjadi Sales2020-2011. Data dari tahun fiskal 2010 dihilangkan dari partisi Sales2020-2011 dan dipindahkan ke partisi SalesOld. Semua partisi kemudian diproses untuk mencerminkan perubahan. Ini umumnya dikenal sebagai pola jendela bergulir - data di setiap partisi berada dalam rentang tanggal yang telah ditentukan dan bertambah seperlunya, menjaga memori dan memproses penggunaan sumber daya dalam rentang yang dapat diprediksi dari waktu ke waktu.

Granularitas dipengaruhi oleh berbagai faktor termasuk berapa banyak data yang diperlukan untuk diproses secara bertahap dalam jumlah waktu yang dapat diterima. Misalnya, jika hanya sepanjang hari terakhir yang perlu diproses setiap hari, mungkin bermanfaat untuk menggunakan granularitas harian. Granularitas campuran dapat dikonfigurasi untuk skenario seperti refresh hampir real time pada butiran rendah ditambah dengan partisi statis historis pada granularitas yang lebih tinggi. Ini menghasilkan lebih sedikit partisi, tetapi juga meningkatkan overhead manajemen untuk memastikan rentang partisi didefinisikan dengan benar.

Partisi juga efektif untuk tabel yang berisi data dari lebih dari satu sumber data. Sumber data yang berbeda dapat memperbarui data pada waktu yang berbeda, yang dapat menentukan granularitas dan persyaratan pemrosesan yang berbeda untuk data tabel model. Misalnya, tabel Pesanan dalam model berisi transaksi pesanan dari dua tabel fakta yang berbeda, factInternetOrders dan factRetailOrders. Di sumber data, factInternetOrders diperbarui per jam. factRetailOrders di sisi lain diperbarui hanya sekali sehari setelah semua toko ritel ditutup. Dengan membuat partisi terpisah pada granularitas yang berbeda dalam tabel Pesanan model untuk data yang diimpor dari factInternetOrders dan factRetailOrders, operasi pemrosesan pada tabel Pesanan dapat dipisahkan dan dijalankan lebih sejajar dengan data pesanan di sumber data.

Setiap skenario unik. Pastikan untuk menentukan granularitas untuk model data Anda yang paling efektif membagi data menjadi partisi yang harus sering diproses dibandingkan dengan yang tidak.

Batas partisi

Terlepas dari platform, tidak ada batasan keras pada jumlah objek partisi dalam model. Namun, setiap partisi memiliki setidaknya satu segmen data dengan jejak memori. Terlalu banyak partisi kecil dapat menyebabkan terlalu banyak segmen kecil. Performa kueri dapat terpengaruh secara negatif ketika mesin penyimpanan harus memindai jumlah segmen yang berlebihan. Kecepatan operasi metadata melalui terlalu banyak partisi juga dapat berdampak buruk pada sumber daya pemrosesan.

Buat jumlah minimum partisi sambil tetap secara efektif memenuhi tujuan partisi Anda. Lebih penting untuk memfokuskan strategi partisi yang efektif berdasarkan granularitas, dan hanya memproses partisi tersebut dengan perubahan data yang paling relevan dalam pemrosesan yang tersedia dan sumber daya memori pada saat kueri pengguna rendah.

Juga tidak ada batasan jumlah data dalam partisi. Meskipun tidak mungkin, model dapat memiliki satu tabel dengan satu partisi default, dan tabel tersebut dapat berisi semua data dalam model. Jumlah data dalam partisi hanya akan dibatasi oleh sumber daya memori yang tersedia untuk paket layanan atau perangkat keras.

Membuat dan mengelola partisi

Saat menulis model dengan perancang model Tabular di Visual Studio, Anda membuat partisi baru, mengedit, menggabungkan, atau menghapus partisi di database ruang kerja model dengan menggunakan Pengelola Partisi. Bergantung pada tingkat kompatibilitas model yang Anda tulis, Partition Manager menyediakan dua mode untuk memilih data yang akan disertakan dalam partisi: Untuk model tabular 1400 dan yang lebih tinggi dengan sumber data terstruktur, partisi ditentukan dengan menggunakan ekspresi Power Query M. Misalnya, kueri berikut menentukan partisi untuk tahun kalender 2019:

let
    Source = #"SQL/sqlserver database windows net;Contoso",
    dbo_Sales = Source{[Schema="dbo",Item="Sales"]}[Data],
    #"Filtered Rows" = Table.SelectRows(dbo_Sales, each [OrderDateKey] >= 20190101 and [OrderDateKey] <= 20191231)
in
    #"Filtered Rows"

Untuk sumber data penyedia, partisi ditentukan dengan menggunakan kueri SQL. Misalnya,

SELECT [dbo].[Sales].* FROM [dbo].[Sales]
WHERE (([OrderDateKey] >= '20190101') AND ([OrderDateKey] <= '20191231'))

Perhatikan argumen Baris Yang Difilter dalam ekspresi Power Query M dan klausa WHERE dalam pernyataan SQL menentukan tepat satu tahun kalender dengan menggunakan operator yang lebih besar dari (>), kurang dari (<), dan sama dengan (=). Saat menentukan partisi, kueri penting setiap partisi menentukan rentang data unik yang tidak dapat menyebabkan duplikasi data dengan partisi lain.

SQL Server Management Studio (SSMS)

Setelah menyebarkan model, partisi muncul sebagai objek di SQL Server Management Studio (SSMS). Buat, edit, gabungkan, dan hapus partisi untuk model yang disebarkan dengan menggunakan kotak dialog Partisi di SSMS, dengan menjalankan skrip Tabular Model Scripting Language (TMSL), atau secara terprogram dengan menggunakan Model Objek Tabular (TOM).

Tabular Model Scripting Language (TMSL)

Partisi untuk model didefinisikan dalam objek Partisi. Dalam contoh berikut, partisi Sales2019 didefinisikan sebagai:

"partition": {
      "name": "Sales2019",
      "mode": "import",
      "source": {
        "type": "m",
        "expression": [
          "let",
          "    Source = #\"SQL/sqlserver database windows net;Contoso\",",
          "    dbo_Sales = Source{[Schema=\"dbo\",Item=\"Sales\"]}[Data],",
          "    #\"Filtered Rows\" = Table.SelectRows(dbo_Sales, each [OrderDateKey] >= 20190101 and [OrderDateKey] <= 20191231)",
          "in",
          "    #\"Filtered Rows\""
        ]
      },

Tindakan pada objek Partisi dapat ditentukan dalam perintah TMSL berikut:

Skrip TMSL dapat dijalankan dalam SQL Server Management Studio, dengan PowerShell dengan menjalankan perintah Invoke-ASCmd, atau oleh tugas Skrip SQLServer Integration Services (SSIS).

Untuk model pada tingkat kompatibilitas 1100 dan 1103, Analysis Services Scripting Language (ASSL) digunakan sebagai gantinya jika TMSL.

Tabular Object Model (TOM)

Dalam Model Objek Tabular, partisi ditentukan oleh kelas Partisi di namespace Microsoft.AnalysisServices.Tabular. Untuk mempelajari selengkapnya tentang solusi terprogram menggunakan TOM sebagai API, lihat Membuat tabel, partisi, dan kolom (TOM), dan Strategi pemartisian tingkat lanjut nanti di artikel ini.

Untuk model pada tingkat kompatibilitas 1100 dan 1103, gunakan Analysis Management Objects (AMO).

Memproses partisi

Ketika data tabel dipartisi, partisi tersebut kemudian dapat diproses pada satu waktu dan irama yang sesuai untuk solusi Anda. Saat operasi proses (refresh) dijalankan, koneksi ke sumber data dibuat menggunakan koneksi sumber data. Analysis Services menggunakan kueri yang ditentukan untuk setiap partisi untuk mengkueri sumber data. Data baru dan yang diperbarui dimuat ke dalam tabel model, hubungan dan hierarki dibangun kembali, dan kolom terhitung dihitung ulang.

Saat menulis model di Visual Studio, Anda dapat menjalankan operasi proses secara manual pada partisi database ruang kerja dari menu atau toolbar. Untuk model yang disebarkan, operasi pemrosesan dipanggil secara manual dengan menggunakan dialog Tabel Proses di SSMS, dengan menjalankan skrip yang mencakup perintah Refresh (TMSL), atau secara terprogram dengan menggunakan Model Objek Tabular (TOM).

Pemrosesan paralel

Analysis Services menggunakan pemrosesan paralel untuk dua partisi atau lebih, meningkatkan performa pemrosesan. Tidak ada pengaturan konfigurasi untuk pemrosesan paralel. Pemrosesan paralel terjadi secara default saat Anda Memproses Tabel atau memilih beberapa partisi untuk tabel dan Proses yang sama. Namun, ada pengaturan yang membatasi operasi pemrosesan paralel.

MaxConnections

Secara default, setiap operasi pemrosesan akan terhubung ke dan mengkueri sumber data untuk setiap partisi. Jumlah maksimum default koneksi, yang ditentukan sebagai properti MaxConnections ke satu sumber data adalah 10. Analysis Services menentukan jumlah operasi pemrosesan bersamaan yang akan dijalankan berdasarkan jumlah inti dan utas yang tersedia. Utas ini dibagikan di seluruh instans server. Satu perintah seperti proses mungkin tidak menerima semua utas yang tersedia. Utas yang diluncurkan untuk pemrosesan, satu untuk setiap operasi pemrosesan paralel, dapat ditunda untuk tetap berada dalam batas MaxConnections.

MaxParallelism

Secara default, operasi pemrosesan berjalan secara paralel sebanyak mungkin. Namun, Anda dapat memilih untuk memproses partisi secara berurutan atau paralel dengan menentukan opsi properti maxParallism dengan perintah Urutan (TMSL). Mengatur nilai ke 1 berarti tidak paralel - satu utas digunakan untuk pemrosesan. Mengatur nilai ke 2 atau lebih menentukan jumlah alur tetap yang dapat digunakan untuk operasi pemrosesan paralel.

Monitor

Untuk menentukan penggunaan alur yang tersedia secara efektif selama operasi proses, untuk Azure Analysis Services, gunakan Azure Metrics Explorer untuk memantau CommandPoolIdleThreads dan CommandPoolBusyThreads. Untuk mempelajari selengkapnya, lihat Memantau metrik server. Untuk SQL Server Analysis Services, gunakan Monitor Performa untuk memantau utas non-I/O kumpulan pemrosesan yang diam dan Alur non-I/O kumpulan pemrosesan yang sibuk. Untuk mempelajari selengkapnya, lihat Penghitung kinerja (SSAS).

Catatan

Jika pengodean ulang terdeteksi, pemrosesan paralel dapat menyebabkan peningkatan penggunaan sumber daya. Ini karena beberapa operasi partisi perlu diinterupsi dan dimulai ulang dengan pengodean baru secara paralel.

Strategi partisi tingkat lanjut

Artikel .pdf Model Tabular Automated Partition Management for Analysis Services , bersama dengan sampel kode AsPartitionProcessing yang menyertainya di GitHub menyediakan informasi mendalam dan contoh solusi untuk perusahaan fiktif, Advenure Works, dengan menggunakan Model Objek Tabular (TOM) untuk membuat dan mengelola partisi. Konsep yang dijelaskan dalam artikel ini dan proyek berlaku untuk semua platform Analysis Services.

Lihat juga

Membuat dan mengelola partisi model tabular
Objek partisi (TMSL)
Membuat Tabel, Partisi, dan Kolom dengan Model Objek Tabular (TOM)
Membuat partisi (pelajaran tutorial)