English Version below

Das Team hinter Power BI: Jeffrey Wang

Beschäftigt man sich mit Power BI/ Power Pivot, dann dauert es nicht lange, bis man das erste Mal auf die Sprache DAX trifft. Jeffrey Wang ist Principal Software Engineer Manager bei Microsoft und gilt als der Vater von DAX und der dahinterliegenden VertiPaq-Engine.

Lars: Jeffrey, ich freue mich sehr, dass Du Dich bereit erklärt hast, Dich meinen Fragen zu stellen 🙂 Magst Du kurz beschreiben, was Deine wesentlichen Aufgaben bei Microsoft sind?

Jeffrey: Ich arbeite im Power BI-Team und bin verantwortlich für die Entwicklung der DAX-Engine.

 

Lars: In der Community wird Dein Name häufig mit dem Label „Vater von DAX“ versehen. Wie würdest Du Deine Rolle bei der Erfindung von DAX beschreiben?

Jeffrey: Die Erfindung von DAX war eine Gemeinschaftsarbeit vieler Menschen. Ich war nur einer der Erfinder, nicht einmal der wichtigste. Mein Beitrag für DAX wurde später, als ich die Leitung des Entwicklungsteams übernahm, noch prominenter. In meinem Bestreben, DAX-Wissen zu verbreiten, begann ich auf Community-Meetings zu präsentieren und einige Organisatoren begannen, mich auf diese Weise vorzustellen, um mehr Menschen zu meinen Vorträgen zu bewegen 🙂

 

Lars: Aus welchem Grund wart Ihr damals der Meinung, eine neue Sprache erfinden zu müssen? Was kann DAX, was die existierenden Sprachen nicht konnten?

Jeffrey: Wir brauchten eine Sprache, die die Kern-BI-Konzepte elegant ausdrücken kann, die ohne formale Programmierkenntnisse für Geschäftsanwendern leicht bedienbar ist und sich leicht implementieren lässt, um Milliarden von Datenzeilen effizient zu handhaben. Wir hatten drei bestehende Programmiersprachen in Betracht gezogen: Excel-Formeln, SQL, MDX. Excel-Formeln sind die Sprache der Wahl für Business-Analysten, die Zielgruppe, die wir für Self-Service-BI anvisierten, aber es fehlten grundlegende Konstrukte, um mit relationalen Datenbankoperationen auf der Grundlage von strukturierten Daten in Tabellen und Spalten umzugehen. SQL ist eine großartige Sprache, um Operationen auf strukturierten Daten jeder Größe auszudrücken. Es fehlt nur das BI-Kernkonzept der Measures und ist zu ausschweifend, um gängige BI-Query-Patterns auszudrücken. Einige BI-Anbieter haben sich dafür entschieden, SQL zu erweitern, um BI Measures zu unterstützen. Sie alle waren sehr hackig und verwirrend, da sie SQL durch SQL-ähnliche Ausdrücke zu SQL-unähnlichen Ergebnissen führten. Schließlich war MDX eine erfolgreiche Nischensprache im BI-Markt, aber es ist für Geschäftsleute zu schwierig, da sie zu viele mehrdimensionale Konzepte wie Dimensionen, Attribute, Hierarchien usw. lernen mussten, bevor sie die Sprache verstehen konnten. Wir haben DAX auf einfachen relationalen Datenbankkonzepten wie Tabellen, Spalten und Beziehungen aufgebaut, die im Gegensatz zu mehrdimensionalen von Business-Analysten intuitiv verstanden werden, und dann haben wir Measures als BI-Kernkomponente hinzugefügt und das freundliche Format von Excel-Formeln sowie viele Excel-Funktionen übernommen, mit denen Business-Anwender bereits vertraut sind.

 

Lars: Wenn Du DAX jemandem beschreiben müßtest, der davon noch nie gehört hat: Wie würde das aussehen?

Jeffrey: Den Geschäftsanwendern werde ich sagen, dass DAX eine Programmiersprache ist, die über eine Excel-formelähnliche Syntax verfügt und es Ihnen ermöglicht, Geschäftskennzahlen zu definieren, die im BI-Jargon auch als Measures bezeichnet werden und für viele Geschäftsberichte und Analysen wiederverwendbar sind. Den BI-Professionals werde ich sagen, dass DAX eine Programmier- und Abfragesprache ist, die die Kernfunktionen von SQL und MDX in einer Excel-formelähnlichen Syntax kombiniert, damit BI-Entwickler eine funktionsreiche BI-Semantikschicht definieren und die volle Leistungsfähigkeit der Vertipaq Engine, der spaltenbasierten In-Memory-Datenbank, nutzen können.

 

Lars: Vor kurzem wurde durch das Excel-Team angekündigt, dass Power Pivot demnächst in allen Excel-Versionen für Windows vorhanden sein wird. Auf absehbare Zeit werden durch diese Entscheidung alle Excelnutzer Zugriff auf die DAX Engine haben! Erhoffst Du Dir dadurch eine noch größere Popularität von DAX?

Jeffrey: Das hoffe ich sehr. Ich hoffe sogar, dass das Excel-Team eines Tages DAX-Abfragen zu Pivot-Tabellen und Pivot-Charts hinzufügen wird, um die volle Leistung der Power Pivot-Engine zu nutzen.

 

Lars: Als Ihr DAX damals entworfen habt, welche potentiellen Nutzer hattet Ihr damals im Blick? Hat sich dieses Bild in der Zwischenzeit gewandelt?

Jeffrey: Das Ziel damals war es, eine Reihe von Kerntechnologien zu entwickeln, die den unterschiedlichen Bedürfnissen der Anwender in den Bereichen Self Service-BI, Team-BI und Corporate-BI gerecht werden. Deshalb benötigten wir eine Programmiersprache, die einfach genug für Business-Analysten ist, um sie in ihrer täglichen Arbeit zu verwenden, aber dennoch leistungsstark genug ist, um komplexe Modellierungskonzepte, wie sie von großen Unternehmensanwendungen benötigt werden, auszudrücken. Es war ein ehrgeiziges Ziel, das auch heute noch aktuell ist, und wir haben eine stetig wachsende Zahl von Fachanwendern und BI-Spezialisten erlebt, die die Technologie wie erhofft einsetzen.

 

Lars: DAX hat viele „verborgene“ Eigenschaften und Konzepte. Angefangen bei Filter- und Row-Context, über interne Konvertierungen (implizite CALCULATE statements etc.), Context transitions, etc. Die Sprache erscheint zu Beginn sehr einfach, wird dann aber relativ schnell zunehmend komplex. Ich weiß, dass viele Nutzer von DAX durch diese „versteckten“ Konzepte verunsichert sind. Ein Beispiel: Du hast auf Deinem alten Blog bereits Anfang 2011 beschrieben, dass es drei unterschiedliche Formen in DAX gibt, wie die Datumsspalte innerhalb einer Time Intelligence-Funktion referenziert werden kann. Intern werden diese drei Formen jedoch unterschiedlich durch DAX interpretiert, was gewissen Nebeneffekte haben kann. Ich bin mir sicher, dass es bei der Entwicklung von DAX notwendig war, die Sprache genau so zu bauen, wie ihr das getan habt. Könntest Du dem interessierten Leser dennoch bitte einen Einblick geben, warum es so viele versteckte Eigenschaften und Sonderfälle gibt?

Jeffrey: Ein einfacher DAX-Ausdruck verbirgt oft komplexe Berechnungen unter der Haube. Der Anschein der Einfachheit einiger gängiger DAX-Ausdrücke ist ein zweischneidiges Schwert. Einerseits ermöglichen syntaktische Einfachheit und Flexibilität dem Anfänger, relativ einfach und schnell leistungsfähige Berechnungen zu erstellen. Andererseits haben die komplexen Berechnungen hinter den Kulissen oft Nebeneffekte, wenn der Anwender über grundlegende Szenarien hinausgeht, ohne ein tieferes Verständnis für die einem berechneten Ergebnis zugrunde liegenden Schritte zu haben. Das ursprüngliche Designziel war es, die Syntax so einfach wie möglich zu gestalten und gleichzeitig einem kohärenten und semantisch fundierten Sprachmodell zu entsprechen. Zum Beispiel ist

=
CALCULATE ( [Total Sales], Product[Color] = „Red“ )

eine syntaktische Vereinfachung für

=
CALCULATE (
[Total Sales],
    FILTER ( ALL ( Product[Color] ), Product[Color] = „Red“ ).
) 

Die einfachere Form ist intuitiver für Anfänger, die oft an Filter als boolesche Ausdrücke denken, die für eine bestimmte Zeile wahr oder falsch zurückgeben. In Wirklichkeit sind alle DAX-Filter im Filterkontext Tabellenausdrücke auf der einen Seite eines Semi-Join-Operators in relationaler Algebra und der anderen Seite mit offenem Ende. Ich denke nicht, dass es klug ist, das Konzept des Semi-Join am ersten Tag des DAX-Abenteuers den Geschäftskunden vorzustellen. Andererseits zeigt das Beispiel, dass DAX auf einem soliden theoretischen Fundament steht, so dass fortgeschrittene Anwender beliebig viele interessante Features miteinander kombinieren können, um beliebig komplexe Geschäftslogik zu formulieren. In diesem Zusammenhang sind DAX-Einsteiger an ihre erste Hürde geraten, als sie begannen, nicht-triviale DAX Measures zu schreiben, welches ein wiederverwendbarer, dynamischer Ausdruck, der sowohl für Excel-Anwender als auch für SQL-Entwickler ein neues Konzept ist.

 

Lars: Gibt es etwas, was Du uns über die künftige Entwicklung von DAX sagen willst/ darfst?

Jeffrey: DAX, gepaart mit umfangreichen Modellierungsfunktionen, verschafft Microsoft BI einen Vorteil gegenüber den Lösungen vieler Wettbewerber. Wir planen, noch mehr Flexibilität in DAX und Modellierung einzuführen, so dass BI-Anwender aller Ebenen Analyse- und Reporting-Anwendungen erstellen können, die sie sich heute noch nicht vorstellen können.

 

Lars: Jeffrey, ich danke Dir vielmals für die Beantwortung meiner Fragen und wünsche Dir und Deinem Team weiterhin so viel Schaffenskraft, die uns das Arbeitsleben erleichtert 🙂

The Team behind Power BI: Jeffrey Wang

If you are dealing with Power BI/Power Pivot, it doesn’t take long before you encounter the DAX language for the first time. Jeffrey Wang is Principal Software Engineer Manager at Microsoft and is considered the father of DAX and the VertiPaq engine behind it.

Lars: Jeffrey, I’m so glad you agreed to answer my questions. 🙂 Would you like to briefly describe what your main tasks at Microsoft are?

Jeffrey: I work on the Power BI team and am in charge of the development of the DAX engine.

 

Lars: In the community your name is often labelled „the father of DAX„. How would you describe your role in the invention of DAX?

Jeffrey: The invention of DAX was a joint effort of many people. I was just one of the inventors, not even the most important ones. My contribution to DAX became more prominent later on when I became the manager of the development team. In my effort to spread DAX knowledge, I started to present at community meetings and some organizers began to introduce me that way in order to get more people to come to my talks 🙂

 

Lars: Why did you think you had to invent a new language then? What can DAX do that the existing languages could not?

Jeffrey: We needed a language that can elegantly express core BI concepts, is friendly to business users without formal programming training, and can be easily implemented to handle billions of rows of data efficiently. We had considered three existing programming languages: Excel formulas, SQL, MDX. Excel formulas are the language of choice for business analysts, the audience we were targeting for self-service BI, but it lacked basic constructs to deal with relational database operations on top of structured data stored in tables and columns. SQL is a great language to express operations on structured data of any size. It just lacks the core BI concept of measure and is too verbose to express common BI query patterns. Some BI vendors chose to extend SQL to support BI measures. They all ended up being very hacky and confusing since they kind of broke SQL by making SQL-like expressions return un-SQL-ly results. Finally, MDX was a successful niche language in the BI market but it’s too hard for business people since it required users to learn too many multi-dimensional concepts, such as dimensions, attributes, hierarchies, etc. before they could understand the language. We built DAX on top of simple relational database concepts like tables, columns, and relationships which, unlike multi-dimensional ones, are intuitively understood by business analysts, and then we added the core BI ingredient of measures as a first-class citizen, and adopted the friendly format of Excel formulas along with a lot of Excel functions with which business users are already familiar.

 

Lars: If you had to describe DAX to someone who’d never heard of it: How would that look?

Jeffrey: To business users, I’ll tell them that DAX is a programming language that has Excel formula-like syntax and empowers you to define business metrics, also known as measures in BI jargon, which are reusable across many business reporting and analytics. To  BI professionals, I’ll tell them that DAX is a programming and query language that combines core features of SQL and MDX in an Excel formula-like syntax to enable BI developers to define a feature rich BI semantic layer and to unleash the full power of the Vertipaq Engine, the in-memory columnar database.

 

Lars: When you designed DAX back then, which potential users were you looking for at that time? Has this picture changed in the meantime?

Jeffrey: The goal back then was to build a set of core technologies that can serve the diversified needs of users across the spectrum of self-service BI, team BI, and corporate BI, therefore we needed a programming language that’s simple enough for business analysts to use in their daily work yet powerful enough to express complex modeling concepts as required by large enterprise applications. It was an ambitious goal that is still relevant today and we have seen a steadily increasing number of business users as well as BI specialists adopt the technology as we had hoped.

 

Lars: Recently, the Excel team announced that Power Pivot will soon be available in all Excel versions for Windows. In the foreseeable future all Excel users will have access to the DAX Engine! Do you hope that this will make DAX even more popular?

Jeffrey: I certainly hope so. I even hope one day Excel team will add DAX queries to pivot tables and pivot charts to unleash the full power of the Power Pivot engine.

 

Lars: DAX has many „hidden“ characteristics and concepts. Starting with filter and row contexts, via internal conversions (implicit CALCULATE statements, etc.), context transitions, etc. The language appears very simple at the beginning, but then becomes relatively fast increasingly complex. I know that many DAX users are unsettled by these „hidden“ concepts. An example: You already described on your old blog in early 2011 that there are three different forms in DAX how the date column can be referenced within a Time Intelligence function. Internally, however, these three forms are interpreted differently by DAX, which can have certain side effects. I am sure that in the development of DAX it was necessary to build the language exactly as you did. Nevertheless, could you please give the interested reader an insight into why there are so many hidden characteristics and special cases?

Jeffrey: A simple DAX expression often belies complex calculations under the hood. The appearance of simplicity of some common DAX expressions is a double-edged sword. On the one hand, syntactical simplicity and flexibility enable beginners to write powerful calculations relatively easily and quickly. On the other hand, the behind-the-scene complex calculations often have side-effects when users move beyond basic scenarios without a deeper understanding of a breakdown of steps underlying a calculated result. The original design goal was to make the syntax as simple as possible in common usage patterns while conforming to a coherent and semantically sound language model. For example,

=
CALCULATE ( [Total Sales], Product[Color] = „Red“ )

is syntax sugar for

=
CALCULATE (
[Total Sales],
    FILTER ( ALL ( Product[Color] ), Product[Color] = „Red“ )
)

The simpler form is more intuitive for beginners who often think of filters as Boolean expressions which return true or false for a given row. In reality, all DAX filters in filter context are table expressions on one side of a semi-join operator in relational algebra with the other side open-ended. I don’t think it’s wise to introduce the concept of semi-join to business users on their first day of DAX adventure. On the other hand, the example illustrates that DAX stands on a solid theoretical foundation so advanced users can freely combine any number of interesting features together to formulate arbitrarily complex business logic. On a related note, DAX beginners ran into their first hurdle once they started writing non-trivial DAX because measure, which is a reusable, dynamic expression, is a new concept to both Excel users and SQL developers.

 

Lars: Is there anything else you want to/ can tell us about the future development of the DAX?

Jeffrey: DAX, coupled with rich modeling capabilities, gives Microsoft BI an edge over many competitors’ solutions. We plan to introduce even more flexibilities in DAX and modeling so that BI users of all levels can build analytical and reporting applications they can’t imagine today.

 

Lars: Jeffrey, thank you very much for answering my questions and I wish you and your team the continued creative power that already made our working lives so much easier. 🙂