T-SQL Notebooks in Fabric? Das geht? Ja. In der aktuellen Version von Microsoft Fabric kann jetzt auch in einem Notebook mit T-SQL gearbeitet werden. Bekannt gegeben wurde das im letzten Fabric-Newsletter von September 2024. Das es kommen wird, wurde schon vor einigen Monaten erwähnt.
Um was geht es überhaupt?
Bisher konnte ich mit meinem Notebook in Fabric die Sprachen PySpark, Scala, Spark SQL oder R verwenden. Ab jetzt gibt es eine Sprache mehr: T-SQL. So ganz stimmt das aber nicht. T-SQL kann in verschiedenen Situationen eingesetzt werden, aber ein bisheriges Notebook kann ich damit nicht so richtig ersetzen. Ich kann zum Beispiel nicht zwischen den Sprachen hin- und herspringen. Microsoft unterscheidet daher die Sprachauswahl nach Spark (die obigen vier Sprachen) und T-SQL Analytics. Das ist dann T-SQL.
Worin liegt der Unterschied? Wenn ich T-SQL auswähle, dann kann ich nicht mehr in eine andere Sprache ändern. Das hat etwas damit zu tun, dass die Spark-Sprachen gegen ein Lakehouse gehen und mit T-SQL verbinde ich mich an ein Warehouse. Also gehe ich mit einem (Spark-)Notebook bisher an einen SQL Analytics Endpoint. T-SQL geht dagegen an ein Warehouse. Dahinter steckt dann ein SQL Server bzw. ein Azure SQL.
Versuche ich mit einer T-SQL-Abfrage gegen ein Lakehouse zu starten, dann bekomme ich folgende Fehlermeldung:
InvalidOperationException: Data warehouse id is empty. Please check if the notebook is connected to a data warehouse.
Es geht also nur mit einem Data Warehouse. ABER: Ich kann in einem Data Warehouse ein Lakehouse verbinden. Klingt zunächst komisch. Konnte ich aber in Azure Synapse aber auch schon immer machen. Das geht dann natürlich auch in Microsoft Fabric.
Hier an einem Beispiel:
Obwohl ich in Warehouses bin, kann ich darunter ein Lakehouse verbinden. Am Ende ist es nichts anderes als die Lakehouse-Tabellen mit External Table in den SQL Server einzubinden. Auch das geht schon seit vielen Jahren im SQL Server. Hier kann ich dann mit T-SQL arbeiten und meine bekannte Sprache einsetzen um Sichten (Views), Funktionen (Functions), Prozeduren (Procedures) oder einfach nur Abfragen (Queries) zu schreiben.
Beispiel
Ein kurzes Beispiel mit dem Befehl TOP um nur die obersten Zeilen zu bekommen. Wir erinnern uns: In Spark SQL lautet der Befehl LIMIT.
Auch CTEs (Common Table Expressions) können verwendet werden. Wer CTEs nicht kennt, der sollte sich damit mal befassen.
Einschränkungen
Es gibt aber auch ein paar Limitierungen. Ich habe ein paar rausgesucht, die ich am ehesten vermissen würde
- ALTER TABLE: Das geht nur sehr eingeschränkt (nur Primary Key anlegen und sowas). Wir erinnern uns, dass es sich um eine Externe Tabelle handelt. Dann geht ALTER TABLE natürlich nicht.
- IDENTITY COLUMN: Auch das geht nicht. Auch das liegt an External Tables. Es gibt keine Identity auf einer Externen Tabelle. Am Ende ist es ja nur eine Datei und keine Tabelle in einer Datenbank.
- MERGE: Das ein MERGE nicht geht, dass tut schon weh. Das ist auch etwas schade, da ein wenig suggeriert wird, dass ich ein Data Warehouse von einem SQL Server portieren kann. Spätestens beim MERGE ist es dann aber vorbei. Wenn ich MERGE in Prozeduren verwendet habe, dann muss ich das in Insert/Update/Delete umschreiben.
- Es gibt noch weitere Einschränkungen, die in einem Data Warehouse aber eher seltener vorkommen. Nachzulesen auf der Microsoft-Seite zum Thema.
Fazit
Ich habe T-SQL bisher noch nicht in Fabric vermisst. Spark SQL geht auch. Ich gehe aber trotzdem davon aus, dass ich T-SQL das ein oder andere Mal in Zukunft verwenden werde. Wenn ich eine komplexere Abfrage brauche, dann ist mir T-SQL halt doch etwas geläufiger als Spark SQL. Ich glaube genau damit wird Fabric wieder etwas näher an die Entwickler rücken, die bisher den Umstieg in die Cloud nicht vollzogen haben und bisher „nur“ mit ihrem SQL Server (oder Azure SQL) arbeiten. EIn Vorteil ist natürlich auch die Mächtigkeit von T-SQL und die starke Verbreitung. Auch wird T-SQL immer wieder weiterentwickelt: Wie Microsoft die Sprache „T-SQL“ weiterentwickelt – arelium GmbH.
