zillion
v0.12.0
Zillion est un outil de modélisation et d'analyse des données qui permet de combiner et d'analyser les données de plusieurs tours de données via une API simple. Il agit comme une couche sémantique au-dessus de vos données, écrit SQL afin que vous n'ayez pas à le faire et que vous ne bougez pas facilement sur l'infrastructure de base de données existante via SQLALCHEMY CORE. L'extension NLP Zillion a un support expérimental pour les requêtes en langage naturel alimenté par AI et la configuration de l'entrepôt.
Avec Zillion vous pouvez:
AVERTISSEMENT : Ce projet est dans un état alpha et est sujet à changement. Veuillez tester soigneusement l'utilisation de la production et signaler tout problème.
$ pip install zillion
or
$ pip install zillion[nlp] Ce qui suit est destiné à donner un aperçu rapide de certaines théories et nomenclature utilisées dans l'entreposage de données avec Zillion qui sera utile si vous êtes plus récent dans ce domaine. Vous pouvez également sauter ci-dessous pour un exemple d'utilisation ou des options de création de l'entrepôt / de la création de données.
En bref: Zillion écrit SQL pour vous et rend les données accessibles via une API très simple:
result = warehouse . execute (
metrics = [ "revenue" , "leads" ],
dimensions = [ "date" ],
criteria = [
( "date" , ">" , "2020-01-01" ),
( "partner" , "=" , "Partner A" )
]
) En Zillion il existe deux principaux types de Fields qui seront utilisés dans vos demandes de rapport:
Dimensions : Attributs des données utilisées pour l'étiquetage, le regroupement et le filtrageMetrics : faits et mesures qui peuvent être décomposées le long des dimensions Un Field résume le concept d'une colonne dans vos données. Par exemple, vous pouvez avoir un Field appelé "Revenue". Ce Field peut se produire sur plusieurs sources de données ou éventuellement dans plusieurs tables dans une seule source de données. Zillion comprend que toutes ces colonnes représentent le même concept, et il peut essayer d'utiliser l'un d'eux pour satisfaire les rapports demandant des "revenus".
De même, il existe deux principaux types de tables utilisées pour structurer votre entrepôt:
Dimension Tables : tables de référence / attribut contenant uniquement des dimensions connexesMetric Tables : tables de faits qui peuvent contenir des mesures et certaines dimensions / attributs connexesLes tables de dimension sont souvent statiques ou se développent lentement en termes de nombre de lignes et contiennent des attributs liés à une clé primaire. Certains exemples courants seraient des listes de codes postaux ou de répertoires d'entreprise / partenaires.
Les tables métriques sont généralement de nature plus transactionnelle. Certains exemples courants seraient des enregistrements pour les demandes Web, les ventes de commerce électronique ou l'historique des prix du marché boursier.
Si vous voulez vraiment aller en profondeur sur la modélisation dimensionnelle et la technique de requête en acrosserie de forage que Zillion utilise, je recommande de lire le livre de Ralph Kimball sur l'entreposage de données.
Pour résumer, la requête de forage de forage forme une ou plusieurs requêtes pour satisfaire une demande de rapport de metrics qui peuvent exister sur plusieurs sources de données et / ou tables à un grain dimension particulier.
Zillion prend en charge des configurations d'entrepôt flexibles telles que Snowflake ou Star Schemas, bien qu'elle ne soit pas difficile à ce sujet. Vous pouvez spécifier les relations de table à travers une lignée parent-enfant, et Zillion peuvent également déduire les jointures acceptables en fonction de la présence de clés primaires de table de dimension. Zillion ne prend pas en charge les relations plusieurs à plusieurs pour le moment, bien que la plupart des scénarios axés sur l'analyse devraient être en mesure de contourner cela en ajoutant des vues au modèle si nécessaire.
Les rapports Zillion peuvent être considérés comme fonctionnant en deux couches:
DataSource Layer : requêtes SQL contre les données de données de l'entrepôtCombined Layer : une requête SQL finale par rapport aux données combinées de la couche DataSourceLa couche combinée n'est qu'une autre base de données SQL (SQLite en mémoire par défaut) qui est utilisée pour lier les données de l'ourout de données et appliquer quelques fonctionnalités supplémentaires telles que les rollups, les filtres de ligne, les limites de ligne, le tri, les pivots et les calculs techniques.
Il existe plusieurs façons d'initialiser rapidement un entrepôt à partir d'un fichier local ou distant:
# 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 fournit également un script d'assistance pour Boostrap un fichier de configuration de données de données pour une base de données existante. Voir zillion.scripts.bootstrap_datasource_config.py . Le script bootstrap nécessite une URL de connexion / base de données et un fichier de sortie comme arguments. Voir --help Sortie-help pour plus d'options, y compris l'indicateur --nlp NLP facultatif qui exploite OpenAI pour déduire les informations de configuration telles que les types de colonnes, les types de table et les relations de table. La fonction NLP nécessite l'installation de l'extension NLP ainsi que l'ensemble suivant dans votre fichier de configuration Zillion :
Le but principal de Zillion est d'exécuter des rapports contre un Warehouse . À un niveau élevé, vous réalisera des rapports comme suit:
result = warehouse . execute (
metrics = [ "revenue" , "leads" ],
dimensions = [ "date" ],
criteria = [
( "date" , ">" , "2020-01-01" ),
( "partner" , "=" , "Partner A" )
]
)
print ( result . df ) # Pandas DataFrameLorsque vous comparez à l'écriture de SQL, il est utile de considérer les dimensions comme les colonnes cibles d'un groupe Group By SQL. Considérez les mesures comme les colonnes que vous agrégelez . Considérez les critères comme la clause où . Vos critères sont appliqués dans les requêtes SQL de couche DataSource.
Le ReportResult a un Pandas DataFrame avec les dimensions comme index et les métriques comme colonnes.
Un Report aurait un grain , qui définit les dimensions à laquelle chaque mesure doit être en mesure de rejoindre afin de satisfaire aux exigences Report . Le grain est une combinaison de toutes les dimensions, y compris celles référencées en critères ou en formules métriques. Dans l'exemple ci-dessus, le grain serait {date, partner} . Les «revenus» et les «pistes» doivent être en mesure de se joindre à ces dimensions pour que ce rapport soit possible.
Ces concepts peuvent prendre du temps pour s'enfoncer et varier évidemment avec les spécificités de votre modèle de données, mais vous vous familiarisez davantage avec eux lorsque vous commencez à assembler des rapports contre vos entrepôts de données.
Avec l'extension NLP, Zillion a un support expérimental pour la requête en langue naturelle de votre entrepôt de données. Par exemple:
result = warehouse . execute_text ( "revenue and leads by date last month" )
print ( result . df ) # Pandas DataFrame Cette fonction NLP nécessite une instance en cours d'exécution de QDrant (base de données vectorielle) et les valeurs suivantes définies dans votre fichier de configuration Zillion :
Les intégres seront produits et stockés à la fois dans QDRANT et un cache local. La base de données vectorielle sera initialisée la première fois que vous essayez de l'utiliser en analysant tous les champs de votre entrepôt. Un exemple de fichier docker pour exécuter QDRANT est fourni à la racine de ce dépôt.
Vous avez un certain contrôle sur la façon dont les champs sont intégrés. À savoir dans la configuration de tout champ que vous pouvez choisir d'exclure un champ des incorporations ou de remplacer la carte des intégres à ce champ. Tous les champs sont inclus par défaut. L'exemple suivant exclurait le champ net_revenue par intégration et mapperait les demandes de métriques revenue au champ gross_revenue .
{
"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
}
}
} ,De plus, vous pouvez également exclure les champs via les paramètres de configuration au niveau des entrepôts suivants:
{
"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"
]
}
} ,
...
} Si un champ est désactivé à l'un des niveaux susmentionnés, il sera ignoré. Ce type de contrôle devient utile car votre modèle de données devient plus complexe et vous souhaitez guider la logique NLP dans les cas où il pourrait confondre les champs nommés de manière similaire. Chaque fois que vous ajustez les champs exclus, vous voudrez forcer la recréation de votre collection d'intégration en utilisant le drapeau force_recreate sur Warehouse.init_embeddings .
Remarque: cette fonctionnalité en est à ses balbutiements. Son utilité dépendra de la qualité de la requête d'entrée et de votre modèle de données (c'est-à-dire de bons noms de champ)!
En plus de configurer la structure de votre Warehouse , qui sera discutée plus ci-dessous, Zillion a une configuration globale pour contrôler certains paramètres de base. L'environnement ZILLION_CONFIG Var peut pointer vers un fichier de configuration YAML. Voir examples/sample_config.yaml pour plus de détails sur les valeurs qui peuvent être définies. Environnement VARS préfixé avec Zillion_ peut remplacer les paramètres de configuration (c'est-à-dire zillion_db_url remplacera db_url).
La base de données utilisée pour stocker des spécifications de rapport zillion peut être configurée en définissant la valeur DB_URL dans votre configuration Zillion sur une chaîne de connexion de base de données valide. Par défaut, un SQLite DB dans / TMP est utilisé.
Ci-dessous, nous parcourons un modèle de données de vente hypothétique simple qui démontre la configuration de base DataSource et Warehouse , puis affiche quelques exemples de rapports. Les données sont une simple base de données SQLite qui fait partie du code de test Zillion . Pour référence, le schéma est le suivant:
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
); Un Warehouse peut être créé à partir d'une configuration JSON ou YAML qui définit ses champs, ses sources de données et ses tables. Le code ci-dessous montre comment il peut être fait en aussi peu qu'une ligne de code si vous avez un pointeur vers une configuration Warehouse JSON / YAML.
from zillion import Warehouse
wh = Warehouse ( config = "https://raw.githubusercontent.com/totalhack/zillion/master/examples/example_wh_config.json" ) Cet exemple de configuration utilise un data_url dans ses informations connect DataSource qui indiquent Zillion de télécharger dynamiquement ces données et de s'y connecter en tant que base de données SQLite. Ceci est utile pour des exemples ou une analyse rapides, bien que dans la plupart des scénarios, vous mettez une chaîne de connexion à une base de données existante comme vous le voyez ici
Les bases de la structure de configuration de l'entrepôt Zillion's sont les suivantes:
Une configuration Warehouse a les sections principales suivantes:
metrics : liste facultative des configurations métriques pour les mesures globalesdimensions : liste facultative des configurations de dimension pour les dimensions globalesdatasources : mappage des noms de données de données sur les configurations de données ou les URL de configuration Une configuration DataSource a les sections principales suivantes:
connect : URL de connexion de la base de données ou dict des paramètres de connexionmetrics : liste facultative des configurations métriques spécifiques à cette source de donnéesdimensions : Liste facultative des configurations de dimension spécifiques à cette source de donnéestables : mappage des noms de table sur les configurations de table ou les URL de configurationAstuce: les configurations de données de données et de table peuvent également être remplacées par une URL qui pointe vers un fichier de configuration local ou distant.
Dans cet exemple, les quatre tables de notre base de données sont incluses dans la configuration, deux en tant que tables de dimension et deux en tant que tables métriques. Les tableaux sont liés par une relation parent-> enfant: partenaires aux campagnes et conduit à des ventes. Certaines tableaux utilisent également l'indicateur create_fields pour créer automatiquement Fields sur la source de données à partir des définitions de colonnes. D'autres métriques et dimensions sont définies explicitement.
Pour afficher la structure de cet Warehouse après init, vous pouvez utiliser la méthode print_info qui montre toutes les mesures, dimensions, tableaux et colonnes qui font partie de votre entrepôt de données:
wh . print_info () # Formatted print of the Warehouse structurePour une plongée plus profonde du schéma de configuration, veuillez consulter les documents complets.
Exemple: Obtenez des ventes, des prospects et des revenus par partenaire:
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
"""Exemple: limitons le partenariat A et décomposons par ses campagnes:
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
"""Exemple: La sortie ci-dessous montre des rouleaux au niveau de la campagne au sein de chaque partenaire, ainsi que un rouleau de totaux au niveau du partenaire et de la campagne.
Remarque: La sortie contient un caractère spécial pour marquer les lignes de rollup de fraction de données qui ont été ajoutées au résultat. L'objet ReportResult contient des attributs d'assistance pour accéder automatiquement ou filtrer les rouleaux, ainsi qu'un attribut
df_displayqui renvoie le résultat avec des valeurs d'affichage plus conviviales substituées à des caractères spéciaux. Le personnage spécial sous le capot est laissé ici pour l'illustration, mais peut ne pas rendre la même chose dans tous les scénarios.
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
""" Consultez les documents Report pour plus d'informations sur le comportement de Rollup pris en charge.
Exemple: Enregistrez une spécification de rapport (pas les données):
Vous devez d'abord vous assurer que vous avez sauvé votre Warehouse , car les rapports enregistrés sont étendus sur une pièce d'identité Warehouse particulier. Pour enregistrer un Warehouse , vous devez fournir une URL qui pointe vers la configuration complète.
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" ]
)Remarque : Si vous avez construit votre
Warehousedans Python à partir d'une liste deDataSources, ou si vous êtes passé dans undictpour le paramètreconfigsur init, il n'y a actuellement pas de moyen intégré de publier une configuration complète dans un fichier pour référence lors de l'enregistrement.
Exemple: chargez et exécutez un rapport à partir d'un ID de spécification:
result = wh . execute_id ( spec_id ) Cela suppose que vous avez enregistré cet ID de rapport précédemment dans la base de données spécifiée par le DB_URL dans votre configuration Zillion YAML.
Exemple: grain non pris en charge
Si vous essayez un rapport impossible, vous obtiendrez une UnsupportedGrainException . Le rapport ci-dessous est impossible car il tente de décomposer la métrique des leads par une dimension qui n'existe que dans une table d'enfants. D'une manière générale, les tables d'enfants peuvent se réunir aux parents (et aux «frères et sœurs» des parents) pour trouver des dimensions, mais pas l'inverse.
# Fails with UnsupportedGrainException
result = wh . execute (
metrics = [ "leads" ],
dimensions = [ "sale_id" ]
) Parfois, vous avez besoin de fonctionnalités de type sous-requête afin de filtrer un rapport aux résultats de certains autres (qui nécessitaient peut-être un grain différent). Zillion fournit un moyen simpliste de le faire en utilisant le in report ou not in report . Il existe deux moyens pris en charge de spécifier le sous-report: passer un ID de spécification de rapport ou passer un dict de paramètres de rapport.
# 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 = [...]
))
]
) Le champ des critères utilisés dans in report ou not in report doit être une dimension dans le sous-rapport. Notez que les sous-rapports sont exécutés au moment de l'initialisation des objets Report plutôt que pendant execute - en tant que tels, ils ne peuvent pas être tués à l'aide Report.kill . Cela peut changer sur la route.
Dans notre exemple ci-dessus, notre configuration comprenait une métrique basée sur une formule appelée "RPL", qui est simplement revenue / leads . Une FormulaMetric combine d'autres métriques et / ou dimensions pour calculer une nouvelle métrique à la couche combinée de requête. La syntaxe doit correspondre à votre base de données de couche combinée, qui est SQLite dans notre exemple.
{
"name" : " rpl " ,
"aggregation" : " mean " ,
"rounding" : 2 ,
"formula" : " {revenue}/{leads} "
} En tant que commodité, plutôt que de devoir définir à plusieurs reprises les mesures de formule pour les variantes de taux d'une métrique de base, vous pouvez spécifier une configuration de métrique de diviseur sur une métrique non formulaire. Par exemple, disons que vous avez une métrique revenue et que vous souhaitez créer des variantes pour revenue_per_lead et revenue_per_sale . Vous pouvez définir votre métrique de revenus comme suit:
{
"name" : " revenue " ,
"type" : " numeric(10,2) " ,
"aggregation" : " sum " ,
"rounding" : 2 ,
"divisors" : {
"metrics" : [
" leads " ,
" sales "
]
}
} Voir zillion.configs.DivisorsConfigSchema pour plus de détails sur les options de configuration, telles que les modèles de dénomination remplacés, les modèles de formule et l'arrondi.
Une autre fonctionnalité de commodité mineure est la possibilité de générer automatiquement des variantes de mesures pour différents types d'agrégation dans une configuration de champ unique au lieu de plusieurs champs de votre fichier de configuration. Par exemple, disons que vous avez une colonne sales dans vos données et souhaitez créer des variantes pour sales_mean et sales_sum . Vous pouvez définir votre métrique comme suit:
{
"name" : " sales " ,
"aggregation" : {
"mean" : {
"type" : " numeric(10,2) " ,
"rounding" : 2
},
"sum" : {
"type" : " integer "
}
}
} L'entrepôt qui en résulterait n'aurait pas de métrique sales , mais aurait plutôt sales_mean et sales_sum . Notez que vous pouvez personnaliser davantage les paramètres des champs générés, tels que la définition d'un nom personnalisé, en spécifiant cela dans les paramètres imbriqués de ce type d'agrégation. Dans la pratique, ce n'est pas un grand gain d'efficacité sur la simple définition des mesures séparément, mais certains peuvent préférer cette approche.
Un soutien expérimental existe également pour les champs FormulaDimension . Une FormulaDimension ne peut utiliser d'autres dimensions que dans le cadre de sa formule, et elle est également évaluée dans la base de données combinée de couche. En tant que restriction supplémentaire, une FormulaDimension ne peut pas être utilisée dans les critères de rapport car ces filtres sont évalués à la couche de source de données. L'exemple suivant suppose une base de données de couche combinée SQLite:
{
"name" : " partner_is_a " ,
"formula" : " {partner_name} = 'Partner A' "
} Notre exemple comprend également une "vente" métrique dont la valeur est calculée via la formule au niveau de la couche de requête DataSource. Notez ce qui suit dans la liste fields pour le param "ID" dans la table "Main.sales". Ces formules sont dans la syntaxe de la technologie de base de données DataSource particulière, qui se trouve également être SQLite dans notre exemple.
"fields" : [
" sale_id " ,
{ "name" : " sales " , "ds_formula" : " COUNT(DISTINCT sales.id) " }
] Notre exemple a également créé automatiquement une poignée de dimensions à partir des colonnes "Created_at" des prospects et tables de vente. La prise en charge des conversions de type automatique est limitée, mais pour les colonnes date / datetime dans les technologies prises en charge DataSource , vous pouvez obtenir une variété de dimensions gratuitement de cette façon.
La sortie de wh.print_info affichera les dimensions ajoutées, qui sont préfixées avec "Lead_" ou "Sale_" comme spécifié par le type_conversion_prefix facultatif dans la configuration pour chaque table. Quelques exemples de dimensions générées par l'auto dans notre exemple d'entrepôt comprennent la vente_hour, Sale_day_name, Sale_month, Sale_year, etc.
Comme optimisation dans la clause où les requêtes de rapport sous-jacentes, Zillion tentera d'appliquer des conversions aux valeurs de critères au lieu des colonnes. Par exemple, il est généralement plus efficace de s'interroger en tant que my_datetime > '2020-01-01' and my_datetime < '2020-01-02' au lieu de DATE(my_datetime) == '2020-01-01' , car ce dernier peut empêcher l'utilisation d'index dans de nombreuses technologies de base de données. La possibilité d'appliquer des conversions aux valeurs au lieu des colonnes varie également selon le champ et la technologie DataSource .
Pour éviter les conversions de type, définissez skip_conversion_fields sur true sur votre configuration DataSource .
Voir zillion.field.TYPE_ALLOWED_CONVERSIONS et zillion.field.DIALECT_CONVERSIONS pour plus de détails sur les conversions actuellement prises en charge.
Vous pouvez également définir des mesures "ad hoc" avec chaque demande de rapport. Vous trouverez ci-dessous un exemple qui crée une métrique de revenus par lead à la volée. Ceux-ci n'existent que dans le cadre du rapport, et le nom ne peut entrer en conflit avec aucun domaine existant:
result = wh . execute (
metrics = [
"leads" ,
{ "formula" : "{revenue}/{leads}" , "name" : "my_rpl" }
],
dimensions = [ "partner_name" ]
) Vous pouvez également définir les dimensions "ad hoc" avec chaque demande de rapport. Vous trouverez ci-dessous un exemple qui crée une dimension qui partitionne sur une valeur de dimension particulière à la volée. Les dimensions ad hoc sont une sous-classe de FormulaDimension s et ont donc les mêmes restrictions, comme ne pas pouvoir utiliser une métrique comme champ de formule. Ceux-ci n'existent que dans le cadre du rapport, et le nom ne peut entrer en conflit avec aucun domaine existant:
result = wh . execute (
metrics = [ "leads" ],
dimensions = [{ "name" : "partner_is_a" , "formula" : "{partner_name} = 'Partner A'" ]
) Zillion prend également en charge la création ou la synchronisation des tables ad hoc dans votre base de données pendant DataSource ou l'initiation Warehouse . Un exemple de configuration de table qui le fait est montré ici. Il utilise les paramètres de data_url et if_exists du tableau pour contrôler la synchronisation et / ou la création de la table "main.dma_zip" à partir d'un CSV distant dans une base de données SQLite. La même chose peut également être effectuée dans d'autres types de bases de données.
Les inconvénients potentiels de performances à une telle approche doivent être évidents, en particulier si vous initialisez souvent votre entrepôt ou si le fichier de données distant est important. Il est souvent préférable de synchroniser et de créer vos données à l'avance afin que vous ayez un contrôle complet du schéma, mais cette méthode peut être très utile dans certains scénarios.
AVERTISSEMENT : veillez à ne pas écraser les tables existantes dans votre base de données!
Il existe une variété de calculs techniques qui peuvent être appliqués aux mesures pour calculer les statistiques de roulement, de cumulatif ou de classement. Par exemple, pour calculer une moyenne mobile en 5 points sur les revenus, on pourrait définir une nouvelle métrique comme suit:
{
"name" : " revenue_ma_5 " ,
"type" : " numeric(10,2) " ,
"aggregation" : " sum " ,
"rounding" : 2 ,
"technical" : " mean(5) "
}Les calculs techniques sont calculés à la couche combinée, tandis que «l'agrégation» est effectuée à la couche de source de données (il faut donc définir les deux ci-dessus).
Pour plus d'informations sur la façon dont les chaînes techniques raccourcis sont analysées, consultez le code PARSE_TECHNICAL_STRING. Pour une liste complète des types techniques pris en charge, voir zillion.core.TechnicalTypes .
Les techniques prennent également en charge deux modes: "groupe" et "tout". Le mode contrôle comment appliquer le calcul technique à travers les dimensions des données. En mode "groupe", il calcule la technique à travers la dernière dimension, tandis que dans le mode "All" en calcul de la technique sur toutes les données sans aucun égard pour les dimensions.
Le point de cela devient plus clair si vous essayez de faire une technique "cumsum" sur les données décomposées par quelque chose comme ["partenaire_name", "date"]. Si le mode "groupe" est utilisé (la valeur par défaut dans la plupart des cas), elle fera des sommes cumulatives au sein de chaque partenaire sur les plages de date. Si le mode "tout" est utilisé, il fera une somme cumulative sur chaque ligne de données. Vous pouvez être explicite sur le mode en l'appuyant sur la chaîne technique: c'est-à-dire "cumsum: all" ou "Mean (5): groupe"
Si vous souhaitez éviter de mettre des informations de connexion sensibles directement dans vos configurations DataSource , vous pouvez tirer parti des variables de configuration. Dans votre configuration Zillion yaml, vous pouvez spécifier une section DATASOURCE_CONTEXTS comme suit:
DATASOURCE_CONTEXTS :
my_ds_name :
user : user123
pass : goodpassword
host : 127.0.0.1
schema : reporting Ensuite, lorsque votre configuration DataSource pour la source de données nommée "my_ds_name" est lue, elle peut utiliser ce contexte pour remplir les variables dans votre URL de connexion:
"datasources" : {
"my_ds_name" : {
"connect" : " mysql+pymysql://{user}:{pass}@{host}/{schema} "
...
}
} Dans Warehouse Init, vous pouvez spécifier un ordre de priorité par défaut pour les sources de données par nom. Cela entrera en jeu lorsqu'un rapport pourrait être satisfait par plusieurs chônes de données. DataSources plus tôt dans la liste sera une priorité plus élevée. Cela serait utile si vous vouliez favoriser un ensemble de tables agrégées plus rapides qui sont regroupées dans une DataSource .
wh = Warehouse ( config = config , ds_priority = [ "aggr_ds" , "raw_ds" , ...]) L'objectif Zillion's est de prendre en charge toute technologie de base de données que Sqlalchemy prend en charge (photo ci-dessous). Cela dit, les niveaux de soutien et de test en Zillion varient pour le moment. En particulier, la possibilité de faire des conversions de type, de réflexion de la base de données et de tuer les requêtes en cours d'exécution nécessite tous un code spécifique à la base de données pour la prise en charge. La liste suivante résume les niveaux de soutien connus. Votre kilométrage peut varier avec les technologies de base de données non testées que Sqlalchemy supporte (cela pourrait très bien fonctionner, n'a pas encore été testé). Veuillez signaler les bogues et aider à ajouter plus d'assistance!
Sqlalchemy a des connecteurs à de nombreuses bases de données populaires. La barrière à soutenir bon nombre d'entre elles est probablement assez faible étant donné la nature simple des opérations SQL que Zillion utilise.
Notez que ce qui précède est différent de la prise en charge de la base de données pour la base de données de couche combinée. Actuellement, seul SQLite y est pris en charge; Cela devrait être suffisant pour la plupart des cas d'utilisation, mais plus d'options seront ajoutées sur la route.
Si vous prévoyez d'exécuter Zillion dans un scénario multiprocesse, que ce soit sur un seul nœud ou sur plusieurs nœuds, il y a quelques choses à considérer:
Notez que vous pouvez toujours utiliser la couche de couche combinée en mémoire SQLITE par défaut sans problèmes, car cela est fait à la volée avec chaque demande de rapport et ne nécessite aucune coordination / communication avec d'autres processus ou nœuds.
Zillion Web UI est une interface utilisateur de démonstration et une API Web pour Zillion qui comprend également un plugin Experimental Chatgpt. Consultez la lecture là-bas pour plus d'informations sur l'installation et la structure du projet. Veuillez noter que le code est léger sur les tests et le polissage, mais devrait fonctionner dans les navigateurs modernes. Les plugins Chatgpt sont également assez lents pour le moment, donc c'est actuellement pour le plaisir et pas si utile.
Des documents plus approfondis peuvent être trouvés ici. Vous pouvez compléter vos connaissances en parcourant le répertoire des tests ou la référence de l'API.
Veuillez consulter le guide de contribution pour plus d'informations. Si vous recherchez l'inspiration, l'ajout de support et de tests pour des technologies de base de données supplémentaires serait d'une grande aide.
