Problem:
Masz już wyczyszczone, połączone, załadowane i gotowe do konsumpcji przez warstwę raportową dane. Teraz Power BI będzie pobierało dane do dataflow. Następne ładowanie zaczyna się za chwilę i zmieni, kształt danych. Chcesz jednak załadowane dane wysłać do raportów. Żeby zapewnić spójny obraz danych potrzebujesz zrobić snapshot (migawkę) danych. Potrzebujesz zduplikować istniejące dane. Masz do wyboru: create table as select (CTAS), deep (głęboki) oraz shallow (płytki) klon danych.
Rozwiązanie:
W moim przypadku najlepszym rozwiązaniem będzie użycie głębokiego klonowania (deep clone). Płytkie klonowanie ma niestety ograniczenia, które wykluczają jego zastosowanie. CTAS jest zbyt wolny, to było dopiero odkrycie! Tabela, na której testowałem nie jest duża ma 0,5 GB ale to wystarczający wolumen żeby wyciągnąć wnioski.
Porównanie wydajności CTAS vs Deep Clone
Deep Clone kopiuje wszystkie dane oraz metadane ze źródłowej tabeli. Będziesz więc miał całą historię zmian skopiowaną z poprzedniej tabeli. Będzie też dodana jeszcze jedna wersja, która będzie wskazywała na to, że dane zostały sklonowane.
Create Table as Select (CTAS) tworzy nową tabele z tymi samymi danymi co tabela źródłowa ale bez metadanych.
Jak podpowiada Ci intuicja, co będzie szybsze CTAS czy deep clone?
Mi intuicja podpowiadała CTAS, ale na przykładach które sprawdzałem, szybszy okazał się deep clone. Utworzenie tabeli przy pomocy deep clona trwało nawet 8 razy szybciej(!!) niż stworzenie tabeli przy pomocy CTAS.
Niekwestionowanym zwycięzcą tego pojedynku okazał się deep clone!
Porównanie deep i shallow clone
Płytkie klonowanie (shallow clone) nie klonuje danych ani metadanych. Tworzy migawkę (snapshot) danych z tabeli źródłowej. Jakie to tworzy ograniczenia i możliwości:
- Możesz modyfikować dane w tabeli utworzonej przez płytkie klonowanie. Nie ma to wpływu na tabelę źródłową. Jeżeli zastanawiasz się jak to działa, to tworzone są dodatkowe pliki, które przechowują zmienione rekordy
- Możesz też modyfikować (dodawać, usuwać, aktualizować) dane w tabeli źródłowej i nie ma to wpływu na tabelę stworzoną płytkim kopiowaniem
Brzmi dobrze? Bardzo dobrze. Czas "tworzenia tabeli" jest jeszcze krótszy niż przy głębokim klonowaniu. W moim przypadku tabela powstała przez szybsze klonowanie powstawała 150% szybciej.
Niestety szybkie klonowanie ma wady, które sprawiają, że nie będę go stosował w swoim rozwiązaniu. Ale może to nie jest ograniczenie dla Ciebie?
- Vacuum - Po uruchomieniu sprzątania na tabeli źródłowej, shallow clone przestaje działać, i nie masz już dostępu do danych
- CTAS - Odtworzenie tabeli źródłowej przy użyciu Create Table As Select również niszczy sklonowaną tabelę.
Błąd który widzisz, gdy zrobiłeść CTAS i próbujesz dostać się do tabeli stworzonej przez płytkie kopiowanie:
W jakich scenariuszach używać shallow clone?
Jeżeli potrzebujesz tabeli do wykonania analizy, modyfikacji, stworzenia szybkiego POC, wtedy płytki klon wydaje się idealny. Zaakcentować tutaj należy, że musisz uważać, żeby nie utracić swoich zmian dokonanych na tabeli stworzonej przez płytkie kopiowanie. Shallow clone daje Ci doskonałe narzędzie do eksperymentowania na danych bez obawy, że nadpiszesz dane w tabeli źródłowej.
Składnie polecenia pewnie znasz, jeżeli nie, to zapraszam do dokumentacji:
https://learn.microsoft.com/en-us/azure/databricks/sql/language-manual/delta-clone