Механізм зберігання – його роль в оптимізації запитів DAX у LuckyTemplates

У цьому підручнику ми збираємося поглянути на другу систему внутрішніх служб аналізу — систему зберігання.

Ми обговорювали двигун найвищого рівня, у минулому підручнику. Коли користувачі розуміють, як працюють обидва механізми, легше оптимізувати та підвищити продуктивність ваших запитів DAX.

Основне призначення механізму зберігання — працювати безпосередньо з базою даних.

Механізм формул не має прямого доступу до бази даних, тому для цієї мети він зазвичай проходить через механізм зберігання.

Механізм зберігання буває двох типів — режим імпорту та DirectQuery . Ви можете поєднувати обидва типи в одній моделі даних, щоб створити складену модель.

Зміст

• Робота в режимі імпорту в системі зберігання
• Робота з DirectQuery в системі зберігання
• Робота зі складеними моделями
• Інші критичні моменти щодо системи зберігання даних
• Робота над складними запитами
• Висновок

Робота в режимі імпорту в системі зберігання

Спочатку поговоримо про режим імпорту. Це також більше відомо як Vertipaq, але також називається xVelocity або In Memory Columnar Database.

Є чотири важливі речі, які слід розуміти щодо роботи режиму імпорту.

По-перше, Vertipaq створює копію даних безпосередньо з джерела даних і зберігає її в оперативній пам’яті у стисненому форматі .

По-друге, дані, оброблені в режимі імпорту, базуються на останній операції оновлення . Це означає, що якщо ви востаннє оновлювали свої дані минулого тижня, то дані, з якими ви маєте справу, залишаються тими самими даними минулого тижня. Це особливо важливо, якщо ви використовуєте складене налаштування, де одна таблиця знаходиться в режимі імпорту, а інша – у режимі DirectQuery.

Припустімо, у вас є таблиця Products, яка була оновлена ​​минулого тижня, у режимі імпорту. Що стосується таблиці Sales, ви вирішили провести її через DirectQuery через її розмір. Давайте також припустимо, що ви створюєте свій звіт на основі обох таблиць, де ви додаєте стовпець «Бренд» і створюєте показник «Загальний обсяг продажів» над тією самою таблицею «Продажі». Ви також хочете візуалізувати обсяг продажів на основі бренду.

Вам доведеться спочатку оновити дані, що надходять із режиму імпорту, оскільки ви можете отримати свіжі та оновлені дані з DirectQuery та застарілі дані з Vertipaq. Це залишить кілька порожніх рядків у вашій матриці та візуалізації.

Наступне, що вам потрібно знати про Vertipaq, це те, що лише базові операції, такі як , , або , доступні спочатку . Це означає, що якщо план запиту містить інші складніші операції, механізм зберігання повинен викликати механізм формул, щоб вирішити цю частину коду.

Нарешті, система зберігання даних є високооптимізованою базою даних завдяки стовпчастій структурі Vertipaq . Це означає, що всі дані зберігаються стовпець за стовпцем, а не рядок за рядком. Завдяки цій структурі Vertipaq завжди буде швидшим за з’єднання DirectQuery, навіть якщо ви створюєте індекси у своїй реляційній моделі даних.

Робота з DirectQuery в системі зберігання

Наступний параметр, який ми маємо в службах аналізу LuckyTemplates, це DirectQuery. Якщо ви використовуєте з’єднання DirectQuery, служби аналізу діють лише як пропуск для запитів, які надсилаються механізмом формул.

Отже, припустимо, ви пишете запит. Механізм формул створить план запиту. Потім він перешле запит до механізму зберігання, уже перекладений на рідну мову бази даних. У більшості випадків ці запити надходять у SQL.

Якщо запит використовує DirectQuery, очікуйте, що він буде постійно оновлюватися. Не потрібно турбуватися про те, коли ви востаннє оновлювали дані.

Процес оптимізації коду DAX і моделі даних також залежатиме від способу створення реляційної бази даних. Якщо у ваших стовпцях є індекси, ваші запити завжди будуть оптимізовані. Але якщо ваша база даних не оптимізована для створення звітів за допомогою служб аналізу або LuckyTemplates, ви можете зіткнутися з кількома проблемами продуктивності. Тому будьте свідомі, створюючи свої бази даних для розробки звітів.

Робота зі складеними моделями

Третій варіант — створити складену модель, щоб мати одну таблицю в режимі імпорту, а іншу — у DirectQuery.

Коли ви використовуєте дві таблиці з різних джерел, система формул надсилатиме один запит до Vertipaq, а інший – до джерела даних DirectQuery. В обох випадках служби аналізу також отримають кеш даних із Vertipaq і DirectQuery. Потім механізм формул використовуватиме JOIN,або будь-яку ітерацію в обох кешах даних перед наданням результатів кінцевому користувачеві.

Припустімо, ви намагаєтеся візуалізувати обсяг продажів за брендом продукту у своєму звіті. Механізм формул надішле запит до Vertipaq, де він отримає продукт, бренд і ключ продукту. Потім із DirectQuery він спробує отримати продажі, чисту ціну, кількість продажу та ключ продукту продажу.

Отримавши два кеші даних на основі ключа продукту, він об’єднає два кеші даних і обчислить загальну суму продажів. Потім він представить результати кінцевому користувачеві.

Інші критичні моменти щодо системи зберігання даних

Тепер, коли ми розглянули його різні типи, є кілька інших важливих факторів, які вам потрібно знати про механізм зберігання, щоб допомогти вам оптимізувати свої запити DAX.

Як я вже згадував раніше, механізм зберігання надає кеш даних назад механізму формул у формі нестисненого кешу даних. Коли ви перебуваєте в режимі імпорту, запит, який у процесі надсилається назад до Vertipaq, виконується мовою xmSQL.

Мова xmSQL дещо схожа на SQL, але не зовсім ідентична. Ми збираємося поговорити про xmSWL детально, коли будемо говорити про плани запитів в іншому посібнику.

Також важливо пам’ятати, що система зберігання даних використовує всі ядра, доступні у вашому ЦП. Можливість використовувати кілька ядер є корисною, якщо у вас є кілька сегментів у вашій моделі даних.

Припустімо, у вас є таблиця в LuckyTemplates із 12 мільйонами рядків. Потім цю таблицю буде розділено на 12 сегментів, оскільки в Power Pivot і LuckyTemplates кожен сегмент містить 1 мільйон рядків. Це на відміну від служб аналізу загалом, де один сегмент містить 8 мільйонів рядків.

Отже, якщо я маю шість ядер у моєму процесорі, усі шість ядер скануватимуть перші шість із 12 сегментів одночасно. Коли вони закінчать, вони перейдуть до наступних шести сегментів.

Але якщо я працюю зі службами аналізу, де сегмент за замовчуванням містить 8 мільйонів рядків, використовуватимуться лише два з моїх шести ядер — один сегмент оброблятиме 8 мільйонів рядків, а інший — 4 мільйони.

Робота над складними запитами

Раніше я згадував, що режим імпорту підтримує лише основні операції, такі як MIN, MAX, SUM, COUNT і GROUPBY. Отже, що станеться, якщо працювати над складнішими запитами?

Припустімо, ви вирішили використати оператор IF у контексті рядка або вкладену ітерацію, наприклад SUMX, над таблицями Products і Sales.

У цьому випадку механізм зберігання даних не зможе вирішити запит самостійно. Потім він викличе механізм формул, який почне розв’язувати складні обчислення рядок за рядком у механізмі зберігання. Хтось може подумати, що це сприятливий сценарій, коли обидва двигуни працюють разом, але це далеко від істини.

Розумієте, коли це відбувається, кеш даних, створений механізмом зберігання, не може бути кешований, якщо в цьому конкретному запиті є callbackdataID. Отже, якщо ви оновите візуальне зображення, те саме обчислення доведеться виконати як механізмом формул, так і механізмом зберігання, навіть якщо ви щойно виконали той самий запит кілька секунд тому. Це призведе до затримок продуктивності та поганої взаємодії з користувачем.

Зауважте також, що механізм зберігання не знає, чи запити виконувалися за допомогою DAX або MDX. Як ми вже зазначали раніше, завданням механізму формул є перетворення запитів на правильну мову перед передачею плану запиту.

Нарешті, механізм формул надсилає запити до механізму зберігання один за одним. Це означає, що мати кілька сегментів справді краще, тому загальний час сканування у Vertipaq можна скоротити, оскільки декілька сегментів скануються одночасно.

Висновок

Розуміння тонкощів механізму зберігання справді допомагає оптимізувати ваші запити DAX, особливо якщо ви використовуєте DAX Studio. Якщо ви також пройшли підручник із поясненням механізму формул, ви зможете прийняти кращі рішення щодо створення ефективніших запитів.

Незважаючи на те, що механізм формули є механізмом найвищого рівня, немає сумніву, що він не зможе працювати так добре, як може, якщо ми не максимізуємо обидва двигуни.

Все найкраще,