zillion
v0.12.0
Zillion ist ein Datenmodellierungs- und Analyse -Tool, mit dem Daten aus mehreren Datenquellen über eine einfache API kombiniert und analysiert werden können. Es fungiert als semantische Schicht über Ihren Daten, schreibt SQL, sodass Sie nicht über SQLALCHEMY CORE die vorhandene Datenbankinfrastruktur überschreiten müssen. Die Zillion NLP-Erweiterung unterstützt experimentelle Unterstützung für Abfragen der KI-angetriebenen natürlichen Sprache und die Warehouse-Konfiguration.
Mit Zillion können Sie:
Warnung : Dieses Projekt befindet sich in einem Alpha -Zustand und kann sich ändern. Bitte testen Sie sorgfältig auf Produktionsnutzung und melden Sie Probleme.
$ pip install zillion
or
$ pip install zillion[nlp] Das Folgende soll einen kurzen Überblick über eine Theorie und Nomenklatur geben, die in Data Warehousing mit Zillion verwendet wird, was nützlich ist, wenn Sie neuer in diesem Bereich sind. Sie können auch nach unten überspringen, um ein Nutzungsbeispiel oder ein Lager-/DataSource -Erstellungs -QuickStart -Optionen zu erstellen.
Kurz gesagt: Zillion schreibt SQL für Sie und macht Daten über eine sehr einfache API zugänglich:
result = warehouse . execute (
metrics = [ "revenue" , "leads" ],
dimensions = [ "date" ],
criteria = [
( "date" , ">" , "2020-01-01" ),
( "partner" , "=" , "Partner A" )
]
) In Zillion gibt es zwei Haupttypen von Fields , die in Ihren Berichtsanforderungen verwendet werden:
Dimensions : Attribute von Daten, die zum Kennzeichnung, Gruppieren und Filterung verwendet werdenMetrics : Fakten und Maßnahmen, die entlang der Abmessungen abgebaut werden können Ein Field fasst das Konzept einer Spalte in Ihren Daten zusammen. Zum Beispiel haben Sie möglicherweise ein Field namens "Einnahmen". Dieses Field kann über mehrere Datenquellen oder möglicherweise in mehreren Tabellen in einer einzigen Datenquelle erfolgen. Zillion versteht, dass alle diese Spalten das gleiche Konzept darstellen, und es kann versuchen, eine von ihnen zu verwenden, um Berichte zu erfüllen, die "Einnahmen" beantragen.
Ebenso gibt es zwei Haupttabellen Arten von Tabellen, um Ihr Lagerhaus zu strukturieren:
Dimension Tables : Referenz-/Attributtabellen, die nur verwandte Dimensionen enthaltenMetric Tables : Faktentabellen, die Metriken und einige verwandte Dimensionen/Attribute enthalten könnenDimensionstabellen sind oft statisch oder wachsen in Bezug auf die Zeilenzahl und enthalten Attribute, die an einen Primärschlüssel gebunden sind. Einige gängige Beispiele wären Listen von US -Postleitzahlen oder Firmen-/Partnerverzeichnissen.
Metrische Tabellen sind im Allgemeinen transaktionaler. Einige gängige Beispiele wären Aufzeichnungen für Webanfragen, E -Commerce -Umsätze oder Aktienprei -Historien.
Wenn Sie sich wirklich mit der dimensionalen Modellierung und der Drill-Across-Abfrage-Technik, Zillion verwendet, eingehen möchten, empfehle ich, das Buch von Ralph Kimball über Data Warehousing zu lesen.
Zusammenfassend lässt sich sagen, dass das Abfragen von Drill-Across eine oder mehrere Abfragen zur Erfüllung einer Berichtsanforderung für metrics in mehreren Datenquellen und/oder Tabellen in einem bestimmten dimension erfüllt.
Zillion unterstützt flexible Lager -Setups wie Snowflake oder Star -Schemas, obwohl es nicht wählerisch ist. Sie können Tabellenbeziehungen über eine Eltern-Kind-Linie angeben, und Zillion können auch akzeptable Verknüpfungen basierend auf dem Vorhandensein von Primärschlüssel der Dimensionstabelle abschließen. Zillion unterstützt zu diesem Zeitpunkt viele viel zu viele Beziehungen, obwohl die meisten analytics-fokussierten Szenarien in der Lage sein sollten, dies bei Bedarf zum Modell zu verarbeiten.
Zillion können als Laufen in zwei Schichten betrachtet werden:
DataSource Layer : SQL -Abfragen an die DataSources des LagerhausesCombined Layer : Eine endgültige SQL -Abfrage gegen die kombinierten Daten aus der DataSource -SchichtDie kombinierte Ebene ist nur eine weitere SQL-Datenbank (standardmäßig in Memory SQLite), mit der die Datenquellendaten miteinander verbunden sind und einige zusätzliche Funktionen wie Rollups, Zeilenfilter, Zeilengrenzen, Sortierungen, Pivots und technische Berechnungen anwenden.
Es gibt mehrere Möglichkeiten, ein Lagerhaus schnell aus einer lokalen oder entfernten Datei zu initialisieren:
# Path/link to a CSV, XLSX, XLS, JSON, HTML, or Google Sheet
# This builds a single-table Warehouse for quick/ad-hoc analysis.
url = "https://raw.githubusercontent.com/totalhack/zillion/master/tests/dma_zip.xlsx"
wh = Warehouse . from_data_file ( url , [ "Zip_Code" ]) # Second arg is primary key
# Path/link to a sqlite database
# This can build a single or multi-table Warehouse
url = "https://github.com/totalhack/zillion/blob/master/tests/testdb1?raw=true"
wh = Warehouse . from_db_file ( url )
# Path/link to a WarehouseConfigSchema (or pass a dict)
# This is the recommended production approach!
config = "https://raw.githubusercontent.com/totalhack/zillion/master/examples/example_wh_config.json"
wh = Warehouse ( config = config ) Zillion bietet auch ein Helfer -Skript, um eine Datenbankkonfigurationsdatei für eine vorhandene Datenbank zu boostrap. Siehe zillion.scripts.bootstrap_datasource_config.py . Das Bootstrap -Skript erfordert eine Verbindungs-/Datenbank -URL und Ausgabedatei als Argumente. Weitere Optionen finden Sie unter --help -Ausgabe, einschließlich des optionalen --nlp -Flags, das OpenAI nutzt, um Konfigurationsinformationen wie Spaltentypen, Tabellentypen und Tabellenbeziehungen zu schließen. Die NLP -Funktion erfordert, dass die NLP -Erweiterung sowie der folgende Satz in Ihrer Zillion -Konfigurationsdatei installiert werden:
Der Hauptzweck von Zillion besteht darin, Berichte gegen ein Warehouse auszuführen. Auf einem hohen Niveau erstellen Sie wie folgt Berichte:
result = warehouse . execute (
metrics = [ "revenue" , "leads" ],
dimensions = [ "date" ],
criteria = [
( "date" , ">" , "2020-01-01" ),
( "partner" , "=" , "Partner A" )
]
)
print ( result . df ) # Pandas DataFrameIm Vergleich zum Schreiben von SQL ist es hilfreich, die Dimensionen als Zielspalten einer Gruppe nach SQL -Anweisung zu betrachten. Stellen Sie sich die Metriken als die Spalten vor, die Sie aggregieren . Stellen Sie sich die Kriterien als die Where -Klausel vor. Ihre Kriterien werden in den SQL -Abfragen der DataSource -Schicht angewendet.
Das ReportResult verfügt über einen Pandas -Datenframe mit den Dimensionen als Index und Metriken als Spalten.
Ein Report soll ein grain haben, das die Abmessungen definiert, zu denen jede Metrik verbinden muss, um die Report zu erfüllen. Das grain ist eine Kombination aller Dimensionen, einschließlich derjenigen, auf die in Kriterien oder in metrischen Formeln verwiesen wird. Im obigen Beispiel wäre das grain {date, partner} . Sowohl "Einnahmen" als auch "Leads" müssen in der Lage sein, sich diesen Dimensionen zu verbinden, damit dieser Bericht möglich ist.
Diese Konzepte können sich Zeit in Anspruch nehmen, um zu sinken und offensichtlich mit den Einzelheiten Ihres Datenmodells zu variieren, aber Sie werden sich mit ihnen vertraut machen, wenn Sie Berichte gegen Ihre Data Warehouses zusammenstellen.
Mit der NLP -Erweiterung hat Zillion experimentelle Unterstützung für die Abfrage Ihres Data Warehouse für natürliche Sprache. Zum Beispiel:
result = warehouse . execute_text ( "revenue and leads by date last month" )
print ( result . df ) # Pandas DataFrame Diese NLP -Funktion erfordert eine laufende Instanz von QDRant (Vector -Datenbank) und die folgenden Werte, die in Ihrer Zillion -Konfigurationsdatei festgelegt sind:
Einbettungen werden sowohl in QDrant als auch in einem lokalen Cache aufbewahrt und gespeichert. Die Vektordatenbank wird initialisiert, wenn Sie das erste Mal versuchen, dies zu verwenden, indem Sie alle Felder in Ihrem Lager analysieren. Eine Beispiel -Docker -Datei zum Ausführen von QDrant finden Sie im Stamm dieses Repo.
Sie haben einige Kontrolle darüber, wie Felder eingebettet werden. In der Konfiguration für jedes Feld können Sie auswählen, ob Sie ein Feld von Einbettungen ausschließen oder überschreiben sollen, was die Karte in dieses Feld einbettet. Alle Felder sind standardmäßig enthalten. Das folgende Beispiel würde das Feld net_revenue von der eingebetteten und kartendrollen revenue Anforderungen an das Feld gross_revenue ausschließen.
{
"name" : "gross_revenue" ,
"type" : "numeric(10,2)" ,
"aggregation" : "sum" ,
"rounding" : 2 ,
"meta" : {
"nlp" : {
// enabled defaults to true
"embedding_text" : "revenue" // str or list of str
}
}
} ,
{
"name" : "net_revenue" ,
"type" : "numeric(10,2)" ,
"aggregation" : "sum" ,
"rounding" : 2 ,
"meta" : {
"nlp" : {
"enabled" : false
}
}
} ,Zusätzlich können Sie Felder über die folgenden Konfigurationseinstellungen auf Lagerebene ausschließen:
{
"meta" : {
"nlp" : {
"field_disabled_patterns" : [
// list of regex patterns to exclude
"rpl_ma_5"
] ,
"field_disabled_groups" : [
// list of "groups" to exclude, assuming you have
// set group value in the field's meta dict.
"No NLP"
]
}
} ,
...
} Wenn ein Feld auf einem der oben genannten Ebenen deaktiviert ist, wird es ignoriert. Diese Art der Steuerung wird nützlich, da Ihr Datenmodell komplexer wird und Sie die NLP -Logik in Fällen leiten möchten, in denen es ähnlich benannte Felder verwirren könnte. Jedes Mal, wenn Sie die Felder anpassen, möchten Sie die Erholung Ihrer Einbettdings -Sammlung mit der force_recreate -Flag auf Warehouse.init_embeddings erzwingen.
Hinweis: Diese Funktion steckt in den Kinderschuhen. Die Nützlichkeit hängt von der Qualität sowohl der Eingabebestand als auch Ihres Datenmodells ab (dh gute Feldnamen)!
Zusätzlich zur Konfiguration der Struktur Ihres Warehouse , die weiter unten erörtert wird, verfügt Zillion eine globale Konfiguration, um einige grundlegende Einstellungen zu steuern. Die Var ZILLION_CONFIG -Umgebung kann auf eine YAML -Konfigurationsdatei verweisen. Weitere Informationen zu den Werten finden Sie examples/sample_config.yaml . Mit Zillion_ vorangestellte Umgebungsvars können Konfigurationseinstellungen überschreiben (dh zillion_db_url überschreiben db_url).
Die Datenbank, mit der Zillionenberichtspezifikationen gespeichert werden, kann durch Einstellen des DB_URL -Werts in Ihrer Zillion -Konfiguration in einer gültigen Datenbankverbindungszeichenfolge konfiguriert werden. Standardmäßig wird ein SQLite DB in /TMP verwendet.
Im Folgenden werden wir ein einfaches hypothetisches Verkaufsdatenmodell durchlaufen, das grundlegende DataSource und Warehouse zeigt und dann einige Beispielberichte anzeigt. Die Daten sind eine einfache SQLite -Datenbank, die Teil des Zillion -Testcode ist. Als Referenz lautet das Schema wie folgt:
CREATE TABLE partners (
id INTEGER PRIMARY KEY ,
name VARCHAR NOT NULL UNIQUE,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE campaigns (
id INTEGER PRIMARY KEY ,
name VARCHAR NOT NULL UNIQUE,
category VARCHAR NOT NULL ,
partner_id INTEGER NOT NULL ,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE leads (
id INTEGER PRIMARY KEY ,
name VARCHAR NOT NULL ,
campaign_id INTEGER NOT NULL ,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE sales (
id INTEGER PRIMARY KEY ,
item VARCHAR NOT NULL ,
quantity INTEGER NOT NULL ,
revenue DECIMAL ( 10 , 2 ),
lead_id INTEGER NOT NULL ,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
); Ein Warehouse kann aus einer JSON- oder YAML -Konfiguration erstellt werden, die seine Felder, Datenquellen und Tabellen definiert. Der folgende Code zeigt, wie er in nur einer Codezeile erfolgen kann, wenn Sie einen Zeiger auf eine JSON/YAML Warehouse haben.
from zillion import Warehouse
wh = Warehouse ( config = "https://raw.githubusercontent.com/totalhack/zillion/master/examples/example_wh_config.json" ) Diese Beispielkonfiguration verwendet eine data_url in seiner DataSource connect , mit denen Zillion diese Daten dynamisch heruntergeladen und als SQLite -Datenbank herstellen kann. Dies ist für schnelle Beispiele oder Analysen nützlich, obwohl Sie in den meisten Szenarien eine Verbindungszeichenfolge in eine vorhandene Datenbank einfügen würden, wie Sie es hier sehen
Die Grundlagen der Zillion's -Lagerkonfigurationsstruktur sind wie folgt:
Eine Warehouse hat die folgenden Hauptabschnitte:
metrics : Optionale Liste der metrischen Konfigurationen für globale Metrikendimensions : Optionale Liste der Dimensionskonfigurationen für globale Dimensionendatasources : Zuordnung von DataSource -Namen in DataSource -Konfigurationen oder Konfigurations -URLs Eine DataSource -Konfiguration hat die folgenden Hauptabschnitte:
connect : Datenbankverbindungs -URL oder Dikte von Connect -Paramsmetrics : Optionale Liste der für diese Datenquelle spezifischen metrischen Konfigurationendimensions : Optionale Liste der Dimensionskonfigurationen, die für diese Datenquelle spezifisch sindtables : Zuordnung von Tabellennamen zu Tabellenkonfigurationen oder Konfigurations -URLsTIPP: DataSource- und Tabellenkonfigurationen können auch durch eine URL ersetzt werden, die auf eine lokale oder Remote -Konfigurationsdatei verweist.
In diesem Beispiel sind alle vier Tabellen in unserer Datenbank in der Konfiguration enthalten, zwei als Dimensionstabellen und zwei als metrische Tabellen. Die Tabellen werden über eine Elternbeziehung (Kampagnen "mit Eltern (Kampagnen" verknüpft und führen zu Verkäufen. Einige Tabellen verwenden auch das Flag create_fields , um automatisch Fields für die Datenquelle aus Spaltendefinitionen zu erstellen. Andere Metriken und Dimensionen werden explizit definiert.
Um die Struktur dieses Warehouse nach init anzuzeigen, können Sie die print_info -Methode verwenden, die alle Metriken, Abmessungen, Tabellen und Spalten anzeigt, die Teil Ihres Data Warehouse sind:
wh . print_info () # Formatted print of the Warehouse structureFür einen tieferen Tauchgang des Konfigurationsschemas finden Sie die vollständigen Dokumente.
Beispiel: Erhalten Sie Verkäufe, Leads und Einnahmen durch Partner:
result = wh . execute (
metrics = [ "sales" , "leads" , "revenue" ],
dimensions = [ "partner_name" ]
)
print ( result . df )
"""
sales leads revenue
partner_name
Partner A 11 4 165.0
Partner B 2 2 19.0
Partner C 5 1 118.5
"""Beispiel: Beschränken wir uns auf Partner A und brechen Sie durch seine Kampagnen auf:
result = wh . execute (
metrics = [ "sales" , "leads" , "revenue" ],
dimensions = [ "campaign_name" ],
criteria = [( "partner_name" , "=" , "Partner A" )]
)
print ( result . df )
"""
sales leads revenue
campaign_name
Campaign 1A 5 2 83
Campaign 2A 6 2 82
"""Beispiel: Die folgende Ausgabe zeigt Rollups auf Kampagnenebene innerhalb jedes Partners und auch eine Rollup von Gesamtsummen auf Partner- und Kampagnenebene.
HINWEIS: Die Ausgabe enthält ein spezielles Zeichen zum Markieren von DataFrame -Rollup -Zeilen, die dem Ergebnis hinzugefügt wurden. Das Reportresult -Objekt enthält einige Helferattribute, um automatisch zugreifen zu können oder Rollups zu filtern, sowie ein
df_display-Attribut, das das Ergebnis mit freundlicheren Anzeigewerten zurückgibt, die für Sonderzeichen ersetzt werden. Der Spezialcharakter unter dem Haus bleibt hier zur Illustration zurückgelassen, kann jedoch in allen Szenarien möglicherweise nicht dasselbe machen.
from zillion import RollupTypes
result = wh . execute (
metrics = [ "sales" , "leads" , "revenue" ],
dimensions = [ "partner_name" , "campaign_name" ],
rollup = RollupTypes . ALL
)
print ( result . df )
"""
sales leads revenue
partner_name campaign_name
Partner A Campaign 1A 5.0 2.0 83.0
Campaign 2A 6.0 2.0 82.0
� 11.0 4.0 165.0
Partner B Campaign 1B 1.0 1.0 6.0
Campaign 2B 1.0 1.0 13.0
� 2.0 2.0 19.0
Partner C Campaign 1C 5.0 1.0 118.5
� 5.0 1.0 118.5
� � 18.0 7.0 302.5
""" Weitere Informationen zum unterstützten Rollup -Verhalten finden Sie im Report .
Beispiel: Speichern Sie eine Berichtspezifikation (nicht die Daten):
Zuerst müssen Sie sicherstellen, dass Sie Ihr Warehouse gespeichert haben, da gespeicherte Berichte auf eine bestimmte Warehouse skopiert werden. Um ein Warehouse zu speichern, müssen Sie eine URL bereitstellen, die auf die vollständige Konfiguration verweist.
name = "My Unique Warehouse Name"
config_url = < some url pointing to a complete warehouse config >
wh . save ( name , config_url ) # wh.id is populated after this
spec_id = wh . save_report (
metrics = [ "sales" , "leads" , "revenue" ],
dimensions = [ "partner_name" ]
)HINWEIS : Wenn Sie Ihr
Warehousein Python aus einer Liste vonDataSourceserstellt oder in einemdictfür denconfigfür Init übergeben haben, gibt es derzeit keine integrierte Möglichkeit, eine vollständige Konfiguration an eine Datei als Referenz beim Speichern auszugeben.
Beispiel: Laden und führen Sie einen Bericht aus einer technischen ID aus:
result = wh . execute_id ( spec_id ) Dies setzt voraus, dass Sie diese Berichts -ID zuvor in der Datenbank gespeichert haben, die von der DB_URL in Ihrer Zillion YAML -Konfiguration angegeben wurde.
Beispiel: Nicht unterstütztes Getreide
Wenn Sie einen unmöglichen Bericht versuchen, erhalten Sie eine UnsupportedGrainException . Der folgende Bericht ist unmöglich, da er versucht, die Leads -Metrik durch eine Dimension abzubauen, die nur in einer Kindertabelle vorhanden ist. Im Allgemeinen können sich Kindertische wieder an Eltern (und "Geschwister" der Eltern) verbinden, um Dimensionen zu finden, aber nicht umgekehrt.
# Fails with UnsupportedGrainException
result = wh . execute (
metrics = [ "leads" ],
dimensions = [ "sale_id" ]
) Manchmal benötigen Sie subfrierartige Funktionen, um einen Bericht auf die Ergebnisse eines anderen zu filtern (für das möglicherweise ein anderes Getreide erforderlich ist). Zillion bietet eine vereinfachende Möglichkeit, dies zu tun, indem der Bericht in report verwendet wird oder not in report Berichtskriterienoperationen. Es gibt zwei unterstützte Möglichkeiten, um den Unterbericht anzugeben: eine Berichtsspezifikations -ID oder ein Diktat der Berichtsparameter zu übergeben.
# Assuming you have saved report 1234 and it has "partner" as a dimension:
result = warehouse . execute (
metrics = [ "revenue" , "leads" ],
dimensions = [ "date" ],
criteria = [
( "date" , ">" , "2020-01-01" ),
( "partner" , "in report" , 1234 )
]
)
# Or with a dict:
result = warehouse . execute (
metrics = [ "revenue" , "leads" ],
dimensions = [ "date" ],
criteria = [
( "date" , ">" , "2020-01-01" ),
( "partner" , "in report" , dict (
metrics = [...],
dimension = [ "partner" ],
criteria = [...]
))
]
) Das in report oder not in report muss eine Dimension im Subrport sein. Beachten Sie, dass Unterberichte in der Initialisierungszeit Report statt bei execute ausgeführt werden - als solche können sie mit Report.kill nicht getötet werden. Dies kann die Straße hinunter ändern.
In unserem Beispiel über unsere Konfiguration enthielt unsere Konfiguration eine formelbasierte Metrik namens "RPL", bei der es sich einfach um revenue / leads handelt. Ein FormulaMetric kombiniert andere Metriken und/oder Abmessungen, um eine neue Metrik in der kombinierten Abfrageberichtungsschicht zu berechnen. Die Syntax muss mit Ihrer kombinierten Layer -Datenbank übereinstimmen, die in unserem Beispiel SQLite ist.
{
"name" : " rpl " ,
"aggregation" : " mean " ,
"rounding" : 2 ,
"formula" : " {revenue}/{leads} "
} Anstatt die Formelmetriken für Ratenvarianten einer Kernmetrik wiederholt definieren zu müssen, können Sie eine Divisor-Metrikkonfiguration auf einer Nicht-Formula-Metrik angeben. Angenommen, Sie haben eine revenue -Metrik und möchten Varianten für revenue_per_lead und revenue_per_sale erstellen. Sie können Ihre Einnahmenmetrik wie folgt definieren:
{
"name" : " revenue " ,
"type" : " numeric(10,2) " ,
"aggregation" : " sum " ,
"rounding" : 2 ,
"divisors" : {
"metrics" : [
" leads " ,
" sales "
]
}
} Weitere Informationen zu Konfigurationsoptionen finden Sie unter zillion.configs.DivisorsConfigSchema .
Eine weitere geringfügige Komfortfunktion ist die Möglichkeit, automatisch Varianten von Metriken für verschiedene Aggregationstypen in einer einzelnen Feldkonfiguration anstelle von mehreren Feldern in Ihrer Konfigurationsdatei zu generieren. Angenommen, Sie haben eine sales in Ihren Daten und möchten Varianten für sales_mean und sales_sum erstellen. Sie können Ihre Metrik wie folgt definieren:
{
"name" : " sales " ,
"aggregation" : {
"mean" : {
"type" : " numeric(10,2) " ,
"rounding" : 2
},
"sum" : {
"type" : " integer "
}
}
} Das resultierende Lagerhaus würde keine sales haben, sondern stattdessen sales_mean und sales_sum . Beachten Sie, dass Sie die Einstellungen für die generierten Felder weiter anpassen können, z. B. das Festlegen eines benutzerdefinierten Namens, indem Sie dies in den verschachtelten Einstellungen für diesen Aggregationstyp angeben. In der Praxis ist dies kein großer Effizienzgewinn, wenn Sie nur die Metriken separat definieren, aber einige mögen diesen Ansatz bevorzugen.
Auch für FormulaDimension gibt es experimentelle Unterstützung. Eine FormulaDimension kann nur andere Dimensionen als Teil ihrer Formel verwenden und wird auch in der kombinierten Schichtdatenbank bewertet. Als zusätzliche Einschränkung kann eine FormulaDimension in den Berichtskriterien nicht verwendet werden, da diese Filter auf der Datenquelle bewertet werden. Im folgenden Beispiel wird eine SQLite -kombinierte Schichtdatenbank angenommen:
{
"name" : " partner_is_a " ,
"formula" : " {partner_name} = 'Partner A' "
} Unser Beispiel enthält auch einen metrischen "Verkauf", dessen Wert über die Formel auf der Datenquerschnittschicht der Abfrage berechnet wird. Beachten Sie Folgendes in der fields für den Param "ID" in der Tabelle "main.sales". Diese Formeln befinden sich in der Syntax der jeweiligen DataSource -Datenbank -Technologie, die in unserem Beispiel auch SQLite ist.
"fields" : [
" sale_id " ,
{ "name" : " sales " , "ds_formula" : " COUNT(DISTINCT sales.id) " }
] Unser Beispiel hat auch automatisch eine Handvoll Dimensionen aus den Spalten "erstellt_at" der Leads und Verkaufstabellen erstellt. Die Unterstützung für automatische Typkonvertierungen ist begrenzt. Für Datums-/Date -Date -Date -Spalten in unterstützten DataSource -Technologien können Sie auf diese Weise eine Vielzahl von Dimensionen kostenlos erhalten.
Die Ausgabe von wh.print_info zeigt die hinzugefügten Dimensionen an, die mit "Lead_" oder "Sale_" vorangestellt sind, wie vom optionalen type_conversion_prefix in der Konfiguration für jede Tabelle angegeben. Einige Beispiele für automatisch generierte Dimensionen in unserem Beispiellager umfassen Sale_Hour, Sale_day_Name, Sale_month, Sale_year usw.
Als Optimierung in der WHERE -Klausel der zugrunde liegenden Berichtsabfragen versucht Zillion , Conversions auf Kriterienwerte anstelle von Spalten anzuwenden. Zum Beispiel ist es im Allgemeinen effizienter, als my_datetime > '2020-01-01' and my_datetime < '2020-01-02' anstelle von DATE(my_datetime) == '2020-01-01' zu abfragen, da diese in vielen Datenbanken-Technologien verhindern kann. Die Fähigkeit, Conversions auf Werte anstelle von Spalten anzuwenden, variiert auch je nach Feld- und DataSource -Technologie.
Um Typkonvertierungen zu verhindern, setzen Sie skip_conversion_fields auf Ihre DataSource -Konfiguration auf true .
Weitere Informationen zu aktuell unterstützten Conversions finden Sie unter zillion.field.TYPE_ALLOWED_CONVERSIONS und zillion.field.DIALECT_CONVERSIONS .
Mit jeder Berichtsanforderung können Sie auch Metriken "Ad -hoc" definieren. Im Folgenden finden Sie ein Beispiel, das im laufenden Fliegen eine Einnahme-pro-Lead-Metrik schafft. Diese existieren nur im Rahmen des Berichts, und der Name kann nicht mit vorhandenen Bereichen in Konflikt stehen:
result = wh . execute (
metrics = [
"leads" ,
{ "formula" : "{revenue}/{leads}" , "name" : "my_rpl" }
],
dimensions = [ "partner_name" ]
) Mit jeder Berichtsanforderung können Sie auch Dimensionen "Ad -hoc" definieren. Im Folgenden finden Sie ein Beispiel, das eine Dimension erzeugt, die im laufenden Fliegen einen bestimmten Dimensionswert verteilt. Ad -hoc -Dimensionen sind eine Unterklasse von FormulaDimension und sind daher die gleichen Einschränkungen, z. Diese existieren nur im Rahmen des Berichts, und der Name kann nicht mit vorhandenen Bereichen in Konflikt stehen:
result = wh . execute (
metrics = [ "leads" ],
dimensions = [{ "name" : "partner_is_a" , "formula" : "{partner_name} = 'Partner A'" ]
) Zillion unterstützt auch die Erstellung oder Synchronisierung von Ad -hoc -Tabellen in Ihrer Datenbank während DataSource oder Warehouse init. Ein Beispiel für eine Tabellenkonfiguration, die dies tut, wird hier angezeigt. Es verwendet die Parameter von data_url und if_exists der Tabellenkonfiguration, um die Synchronisierung und/oder Erstellung der Tabelle "main.dma_zip" aus einem Remote -CSV in einer SQLite -Datenbank zu steuern. Das Gleiche kann auch in anderen Datenbanktypen erfolgen.
Die potenziellen Leistungsnachteile eines solchen Ansatzes sollten offensichtlich sein, insbesondere wenn Sie Ihr Lager häufig initialisieren oder wenn die Remotedatendatei groß ist. Es ist oft besser, Ihre Daten im Voraus zu synchronisieren und zu erstellen, damit Sie eine vollständige Schema -Steuerung haben. Diese Methode kann jedoch in bestimmten Szenarien sehr nützlich sein.
Warnung : Achten Sie darauf, vorhandene Tabellen in Ihrer Datenbank nicht zu überschreiben!
Es gibt eine Vielzahl von technischen Berechnungen, die auf Metriken angewendet werden können, um Rolling-, Kumulations- oder Rangstatistiken zu berechnen. Zum Beispiel kann ein 5-Punkte-Durchschnitt mit dem Umsatz berechnet, um eine neue Metrik wie folgt zu definieren:
{
"name" : " revenue_ma_5 " ,
"type" : " numeric(10,2) " ,
"aggregation" : " sum " ,
"rounding" : 2 ,
"technical" : " mean(5) "
}Technische Berechnungen werden in der kombinierten Ebene berechnet, während die "Aggregation" in der DataSource -Schicht durchgeführt wird (daher müssen Sie beide oben definieren).
Weitere Informationen darüber, wie die technischen Zeichenfolgen analysiert werden, finden Sie im Code Parse_technical_string. Eine vollständige Liste unterstützter technischer Typen finden Sie zillion.core.TechnicalTypes .
Die technischen Daten unterstützen auch zwei Modi: "Group" und "All". Der Modus steuert, wie die technische Berechnung über die Dimensionen der Daten angewendet wird. Im "Gruppen" -Modus berechnet er die technische Überlieferung in der letzten Dimension, während im "All" -Modus die technische über alle Daten über alle Dimensionen hinweg berechnet wird.
Dies wird deutlicher, wenn Sie versuchen, ein "Cumsum" -Techniker über Daten hinweg durchzuführen, die von so etwas wie ["Partner_Name", "Datum"] abgebaut werden. Wenn der "Gruppen" -Modus verwendet wird (in den meisten Fällen die Standardeinstellung), wird in jedem Partner über die Datumsbereiche kumulative Summen durchgeführt. Wenn der "All" -Modus verwendet wird, wird in jeder Datenreihe eine kumulative Summe durchgeführt. Sie können den Modus explizit sein, indem Sie ihn an den technischen Zeichenfolge anhängen: dh "Cumsum: All" oder "Mean (5): Gruppe"
Wenn Sie vermeiden möchten, dass sensible Verbindungsinformationen direkt in Ihre DataSource -Konfigurationen einfügen, können Sie Konfigurationsvariablen nutzen. In Ihrer Zillion YAML -Konfiguration können Sie wie folgt einen Abschnitt DATASOURCE_CONTEXTS angeben:
DATASOURCE_CONTEXTS :
my_ds_name :
user : user123
pass : goodpassword
host : 127.0.0.1
schema : reporting Wenn Ihre DataSource -Konfiguration für die DataSource mit dem Namen "my_ds_name" gelesen wird, kann dieser Kontext Variablen in Ihrer Verbindungs -URL bevölkern:
"datasources" : {
"my_ds_name" : {
"connect" : " mysql+pymysql://{user}:{pass}@{host}/{schema} "
...
}
} Auf Warehouse Init können Sie eine Standard -Prioritätsreihenfolge für DataSources mit Namen angeben. Dies wird ins Spiel kommen, wenn ein Bericht von mehreren Datenquellen erfüllt werden könnte. DataSources früher in der Liste hat eine höhere Priorität. Dies wäre nützlich, wenn Sie eine Reihe schnellerer, aggregierter Tabellen bevorzugen möchten, die in einer DataSource gruppiert sind.
wh = Warehouse ( config = config , ds_priority = [ "aggr_ds" , "raw_ds" , ...]) Das Ziel Zillion's ist es, jede Datenbank -Technologie zu unterstützen, die SQLalchemy unterstützt (siehe Abbildung unten). Das heißt, die Unterstützung und die Prüfstufen in Zillion variieren im Moment. Insbesondere die Fähigkeit, Conversions, Datenbankreflexionen durchzuführen und laufende Abfragen zu töten, erfordern alle einen datenbankspezifischen Code für die Unterstützung. Die folgende Liste fasst bekannte Support -Levels zusammen. Ihre Kilometerleistung kann mit ungetesteten Datenbanktechnologien variieren, die Sqlalchemy unterstützt (es könnte gut funktionieren, wurde einfach noch nicht getestet). Bitte melden Sie Fehler und fügen Sie mehr Unterstützung hinzu!
Sqlalchemy hat Anschlüsse zu vielen beliebten Datenbanken. Die Barriere, um viele davon zu unterstützen, ist aufgrund der einfachen Natur der Zillion -Operationen wahrscheinlich ziemlich niedrig.
Beachten Sie, dass sich das oben genannte von der Datenbankunterstützung für die kombinierte Schichtdatenbank unterscheidet. Derzeit wird dort nur SQLite unterstützt. Dies sollte für die meisten Anwendungsfälle ausreichen, aber es werden weitere Optionen auf der Straße hinzugefügt.
Wenn Sie vorhaben, Zillion in einem Multiprozess -Szenario auszuführen, sei es auf einem einzelnen Knoten oder über mehrere Knoten hinweg, müssen einige Dinge berücksichtigt werden:
Beachten Sie, dass Sie weiterhin das Standard-SQLite-In-Memory-Combined-Layer-DB ohne Probleme verwenden können, da dies mit jeder Berichtsanforderung in der laufenden Fliege vorgenommen wird und keine Koordination/Kommunikation mit anderen Prozessen oder Knoten erfordert.
Zillion Web UI ist eine Demo -UI- und Web -API für Zillionen, die auch ein experimentelles Chatgpt -Plugin enthält. Weitere Informationen zur Installation und Projektstruktur finden Sie im Readme. Bitte beachten Sie, dass der Code leicht auf Tests und Polituren ist, aber in modernen Browsern erwartet wird. Auch Chatgpt -Plugins sind im Moment ziemlich langsam, so dass das derzeit hauptsächlich zum Spaß und nicht so nützlich ist.
Hier finden Sie eine gründlichere Dokumentation. Sie können Ihr Wissen ergänzen, indem Sie das Testverzeichnis oder die API -Referenz durchsuchen.
Weitere Informationen finden Sie im beitragenden Leitfaden. Wenn Sie nach Inspiration suchen, wäre das Hinzufügen von Support und Tests für zusätzliche Datenbanktechnologien eine große Hilfe.
