zillion
v0.12.0
Zillion es una herramienta de modelado de datos y análisis que permite combinar y analizar datos de múltiples fuente de datos a través de una API simple. Actúa como una capa semántica en la parte superior de sus datos, escribe SQL para que no tenga que hacerlo, y se ataques fácilmente a la infraestructura de base de datos existente a través de SQLalchemy Core. La extensión de Zillion NLP tiene soporte experimental para consultas de lenguaje natural con IA y configuración de almacén.
Con Zillion puedes:
ADVERTENCIA : Este proyecto está en un estado alfa y está sujeto a cambios. Pruebe cuidadosamente para el uso de la producción e informe cualquier problema.
$ pip install zillion
or
$ pip install zillion[nlp] Lo siguiente está destinado a dar una visión general rápida de alguna teoría y nomenclatura utilizada en el almacenamiento de datos con Zillion que serán útiles si es más nuevo en esta área. También puede omitir a continuación para obtener un ejemplo de uso o opciones de aceleración de creación de almacén/almacenamiento de datos.
En resumen: Zillion escribe SQL para usted y hace que los datos sean accesibles a través de una API muy simple:
result = warehouse . execute (
metrics = [ "revenue" , "leads" ],
dimensions = [ "date" ],
criteria = [
( "date" , ">" , "2020-01-01" ),
( "partner" , "=" , "Partner A" )
]
) En Zillion hay dos tipos principales de Fields que se utilizarán en sus solicitudes de informe:
Dimensions : Atributos de los datos utilizados para etiquetar, agrupar y filtrarMetrics : hechos y medidas que pueden descomponerse a lo largo de las dimensiones Un Field encapsula el concepto de una columna en sus datos. Por ejemplo, puede tener un Field llamado "ingresos". Ese Field puede ocurrir en varios platos de datos o posiblemente en múltiples tablas dentro de una sola fuente de datos. Zillion entiende que todas esas columnas representan el mismo concepto, y puede intentar usar cualquiera de ellas para satisfacer los informes que solicitan "ingresos".
Del mismo modo, hay dos tipos principales de tablas utilizadas para estructurar su almacén:
Dimension Tables : tablas de referencia/atributo que contienen solo dimensiones relacionadasMetric Tables : tablas de datos que pueden contener métricas y algunas dimensiones/atributos relacionadosLas tablas de dimensión a menudo están estáticas o crecen lentamente en términos de recuento de filas y contienen atributos vinculados a una clave primaria. Algunos ejemplos comunes serían listas de códigos postales de EE. UU. O directorios de empresa/socios.
Las tablas métricas son generalmente de naturaleza más transaccional. Algunos ejemplos comunes serían registros de solicitudes web, ventas de comercio electrónico o historial de precios de mercado de valores.
Si realmente desea profundizar en el modelado dimensional y la técnica de consulta de ejercicios de perforación que emplea, Zillion , le recomiendo leer el libro de Ralph Kimball sobre almacenamiento de datos.
Para resumir, la consulta de achicamiento de perforación forma una o más consultas para satisfacer una solicitud de informe de metrics que pueden existir en múltiples platos y/o tablas en un grano dimension particular.
Zillion admite configuraciones de almacén flexibles como copos de nieve o esquemas de estrellas, aunque no es exigente al respecto. Puede especificar las relaciones de tabla a través de un linaje para padres e hijos, y Zillion también puede inferir uniones aceptables basadas en la presencia de claves primarias de la tabla de dimensiones. Zillion no es compatible con las relaciones de muchos a muchos en este momento, aunque la mayoría de los escenarios centrados en el análisis deberían poder trabajar en torno a eso agregando puntos de vista al modelo si es necesario.
Se pueden considerar que Zillion de informes se están ejecutando en dos capas:
DataSource Layer : SQL Consultas contra los platos de datos del almacénCombined Layer : una consulta SQL final contra los datos combinados de la capa de fuente de datosLa capa combinada es solo otra base de datos SQL (SQLite en memoria de forma predeterminada) que se utiliza para unir los datos de la fuente de datos y aplicar algunas características adicionales, como rollups, filtros de filas, límites de fila, clasificación, pivotes y cálculos técnicos.
Hay varias formas de inicializar rápidamente un almacén desde un archivo local o remoto:
# 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 también proporciona un script auxiliar para impulsar un archivo de configuración de la fuente de datos para una base de datos existente. Ver zillion.scripts.bootstrap_datasource_config.py . El script Bootstrap requiere una URL de conexión/base de datos y un archivo de salida como argumentos. Consulte: salida --help para obtener más opciones, incluido el indicador opcional --nlp que aprovecha a OpenAI para inferir información de configuración, como tipos de columnas, tipos de tabla y relaciones de tabla. La función NLP requiere que se instale la extensión NLP, así como el siguiente conjunto en su archivo de configuración Zillion :
El objetivo principal de Zillion es ejecutar informes contra un Warehouse . En un alto nivel, elaborará informes de la siguiente manera:
result = warehouse . execute (
metrics = [ "revenue" , "leads" ],
dimensions = [ "date" ],
criteria = [
( "date" , ">" , "2020-01-01" ),
( "partner" , "=" , "Partner A" )
]
)
print ( result . df ) # Pandas DataFrameAl comparar con la escritura de SQL, es útil pensar en las dimensiones como las columnas objetivo de un grupo por declaración SQL. Piense en las métricas como las columnas que está agregando . Piense en los criterios como la cláusula WHERE . Sus criterios se aplican en las consultas SQL de la capa de datos de datos.
El ReportResult tiene un marco de datos PANDAS con las dimensiones como índice y las métricas como columnas.
Se dice que un Report tiene un grain , que define las dimensiones que cada métrica debe poder unirse para satisfacer los requisitos Report . El grain es una combinación de todas las dimensiones, incluidas las referenciadas en criterios o en fórmulas métricas. En el ejemplo anterior, el grain sería {date, partner} . Tanto los "ingresos" como los "clientes potenciales" deben poder unirse a esas dimensiones para que este informe sea posible.
Estos conceptos pueden tomar tiempo para hundirse y obviamente variar con los detalles de su modelo de datos, pero se familiarizará con ellos a medida que comience a armar informes contra sus almacenes de datos.
Con la extensión NLP, Zillion tiene apoyo experimental para la consulta de lenguaje natural de su almacén de datos. Por ejemplo:
result = warehouse . execute_text ( "revenue and leads by date last month" )
print ( result . df ) # Pandas DataFrame Esta característica NLP requiere una instancia en ejecución de QDRANT (Base de datos vectorial) y los siguientes valores establecidos en su archivo de configuración Zillion :
Los incrustaciones se producirán y almacenarán tanto en Qdrant como en un caché local. La base de datos Vector se inicializará la primera vez que intente usar esto analizando todos los campos en su almacén. Se proporciona un archivo de Docker de ejemplo para ejecutar Qdrant en la raíz de este repositorio.
Tienes cierto control sobre cómo se integran los campos. A saber, en la configuración para cualquier campo, puede elegir si excluir un campo de los incrustaciones o anular qué incrustaciones se asignan a ese campo. Todos los campos se incluyen de forma predeterminada. El siguiente ejemplo excluiría el campo net_revenue de ser incrustado y mapear las solicitudes de la métrica de revenue al campo 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
}
}
} ,Además, también puede excluir los campos a través de la siguiente configuración de configuración de nivel de almacén:
{
"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 campo está deshabilitado en cualquiera de los niveles mencionados, se ignorará. Este tipo de control se vuelve útil a medida que su modelo de datos se vuelve más complejo y desea guiar la lógica de NLP en los casos en que pueda confundir campos con nombre de manera similar. Cada vez que ajuste qué campos se excluyen, querrá forzar la recreación de su colección de incrustaciones utilizando el indicador force_recreate en Warehouse.init_embeddings .
Nota: Esta característica está en su infancia. ¡Su utilidad dependerá de la calidad de la consulta de entrada y su modelo de datos (es decir, buenos nombres de campo)!
Además de configurar la estructura de su Warehouse , que se discutirá más adelante, Zillion tiene una configuración global para controlar algunas configuraciones básicas. El VAR de entorno ZILLION_CONFIG puede apuntar a un archivo de configuración YAML. Consulte examples/sample_config.yaml para obtener más detalles sobre qué valores se pueden establecer. El entorno Vars prefijo con Zillion_ puede anular la configuración de configuración (es decir, zillion_db_url anulará db_url).
La base de datos utilizada para almacenar las especificaciones del informe Zillion se puede configurar configurando el valor DB_URL en su Zillion Config en una cadena de conexión de base de datos válida. Por defecto, se utiliza un DB SQLite DB IN /TMP.
A continuación, caminaremos a través de un modelo de datos de ventas hipotéticos simples que demuestra la configuración básica DataSource y Warehouse y luego muestra algunos informes de muestra. Los datos son una base de datos SQLite simple que forma parte del código de prueba Zillion . Como referencia, el esquema es el siguiente:
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
); Se puede crear un Warehouse a partir de una configuración JSON o YAML que define sus campos, platos de datos y tablas. El siguiente código muestra cómo se puede hacer en tan solo una línea de código si tiene un puntero a una configuración Warehouse JSON/YAML.
from zillion import Warehouse
wh = Warehouse ( config = "https://raw.githubusercontent.com/totalhack/zillion/master/examples/example_wh_config.json" ) Esta configuración de ejemplo utiliza un data_url en su información connect DataSource que le dice Zillion que descargue dinámicamente esos datos y se conecten a él como una base de datos SQLite. Esto es útil para ejemplos o análisis rápidos, aunque en la mayoría de los escenarios pondría una cadena de conexión en una base de datos existente como ves aquí.
Los conceptos básicos de la estructura de configuración del almacén Zillion's son los siguientes:
Una configuración Warehouse tiene las siguientes secciones principales:
metrics : lista opcional de configuraciones métricas para métricas globalesdimensions : lista opcional de configuraciones de dimensiones para dimensiones globalesdatasources : mapeo de nombres de plato de datos en configuraciones de fuente de datos o URL de configuración Una configuración DataSource tiene las siguientes secciones principales:
connect : URL de conexión de base de datos o dict de parámetros de conexiónmetrics : Lista opcional de configuraciones métricas específicas para esta fuente de datosdimensions : Lista opcional de configuraciones de dimensiones específicas para esta fuente de datostables : asignación de nombres de tabla en configuraciones de tabla o URL de configuraciónConsejo: las configuraciones de datos de datos y tabla también se pueden reemplazar con una URL que apunta a un archivo de configuración local o remoto.
En este ejemplo, las cuatro tablas en nuestra base de datos se incluyen en la configuración, dos como tablas de dimensión y dos como tablas métricas. Las tablas están vinculadas a través de una relación de padres: socios a campañas y conduce a ventas. Algunas tablas también utilizan el indicador create_fields para crear automáticamente Fields en el DataSource desde las definiciones de columna. Otras métricas y dimensiones se definen explícitamente.
Para ver la estructura de este Warehouse después de init, puede usar el método print_info que muestra todas las métricas, dimensiones, tablas y columnas que forman parte de su almacén de datos:
wh . print_info () # Formatted print of the Warehouse structurePara una inmersión más profunda del esquema de configuración, consulte los documentos completos.
Ejemplo: Obtener ventas, clientes potenciales e ingresos por socio:
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
"""Ejemplo: Limitemos al socio A y desglose por sus campañas:
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
"""Ejemplo: el siguiente resultado muestra rollups a nivel de campaña dentro de cada socio, y también un rollup de totales a nivel de socio y campaña.
NOTA: La salida contiene un carácter especial para marcar las filas de rollup de DataFrame que se agregaron al resultado. El objeto REPORTRESULT contiene algunos atributos de ayuda para acceder o filtrar automáticamente, así como un atributo
df_displayque devuelve el resultado con valores de visualización más amigables sustituidos por caracteres especiales. El personaje especial bajo el capado se deja aquí para ilustración, pero puede no hacer lo mismo en todos los escenarios.
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
""" Consulte los documentos Report para obtener más información sobre el comportamiento acumulativo admitido.
Ejemplo: guarde una especificación de informe (no los datos):
Primero, debe asegurarse de haber guardado su Warehouse , ya que los informes guardados están alcanzados a una identificación Warehouse particular. Para guardar un Warehouse , debe proporcionar una URL que apunte a la configuración completa.
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" ]
)Nota : Si construyó su
Warehouseen Python a partir de una lista deDataSources, o se pasa en undictpara laconfigparam en init, actualmente no hay una forma incorporada de generar una configuración completa a un archivo como referencia al guardar.
Ejemplo: Cargue y ejecute un informe desde una ID de especificación:
result = wh . execute_id ( spec_id ) Esto supone que ha guardado este ID de informe previamente en la base de datos especificada por el DB_URL en su configuración Zillion YAML.
Ejemplo: grano no compatible
Si intenta un informe imposible, obtendrá una UnsupportedGrainException . El siguiente informe es imposible porque intenta desglosar la métrica de cables por una dimensión que solo existe en una mesa infantil. En términos generales, las mesas infantiles pueden unirse a los padres (y los "hermanos" de los padres) para encontrar dimensiones, pero no al revés.
# Fails with UnsupportedGrainException
result = wh . execute (
metrics = [ "leads" ],
dimensions = [ "sale_id" ]
) A veces necesita una funcionalidad similar a la subconsulta para filtrar un informe a los resultados de algún otro (que tal vez requirió un grano diferente). Zillion proporciona una forma simplista de hacerlo mediante el uso in report o not in report . Hay dos formas compatibles de especificar el subregistro: aprobar una identificación de especificación de informe o pasar un dict de parámetros de informe.
# 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 = [...]
))
]
) El campo de criterios utilizado en in report o not in report debe ser una dimensión en el subregistro. Tenga en cuenta que los subreglas se ejecutan en el tiempo de inicialización del objeto Report en lugar de durante execute , como tal, no pueden ser asesinados utilizando Report.kill . Esto puede cambiar el camino.
En nuestro ejemplo anterior, nuestra configuración incluía una métrica basada en fórmula llamada "RPL", que es simplemente revenue / leads . Una FormulaMetric combina otras métricas y/o dimensiones para calcular una nueva métrica en la capa combinada de consulta. La sintaxis debe coincidir con su base de datos de capa combinada, que es SQLite en nuestro ejemplo.
{
"name" : " rpl " ,
"aggregation" : " mean " ,
"rounding" : 2 ,
"formula" : " {revenue}/{leads} "
} Como conveniencia, en lugar de tener que definir repetidamente las métricas de fórmula para las variantes de velocidad de una métrica central, puede especificar una configuración métrica divisor en una métrica sin formula. Como ejemplo, digamos que tiene una métrica revenue y desea crear variantes para revenue_per_lead y revenue_per_sale . Puede definir su métrica de ingresos de la siguiente manera:
{
"name" : " revenue " ,
"type" : " numeric(10,2) " ,
"aggregation" : " sum " ,
"rounding" : 2 ,
"divisors" : {
"metrics" : [
" leads " ,
" sales "
]
}
} Consulte zillion.configs.DivisorsConfigSchema para obtener más detalles sobre las opciones de configuración, como anular las plantillas de nombres, las plantillas de fórmula y el redondeo.
Otra característica de conveniencia menor es la capacidad de generar automáticamente variantes de métricas para diferentes tipos de agregación en una única configuración de campo en lugar de en múltiples campos en su archivo de configuración. Como ejemplo, digamos que tiene una columna sales en sus datos y desea crear variantes para sales_mean y sales_sum . Puede definir su métrica de la siguiente manera:
{
"name" : " sales " ,
"aggregation" : {
"mean" : {
"type" : " numeric(10,2) " ,
"rounding" : 2
},
"sum" : {
"type" : " integer "
}
}
} El almacén resultante no tendría una métrica sales , sino que tendría sales_mean y sales_sum . Tenga en cuenta que puede personalizar aún más la configuración para los campos generados, como establecer un nombre personalizado, especificando eso en la configuración anidada para ese tipo de agregación. En la práctica, esta no es una gran ganancia de eficiencia solo para definir las métricas por separado, pero algunos pueden preferir este enfoque.
El apoyo experimental también existe para los campos FormulaDimension . Una FormulaDimension solo puede usar otras dimensiones como parte de su fórmula, y también se evalúa en la base de datos de capa combinada. Como restricción adicional, una FormulaDimension no se puede utilizar en los criterios de informes, ya que esos filtros se evalúan en la capa de fuente de datos. El siguiente ejemplo supone una base de datos de capa combinada SQLite:
{
"name" : " partner_is_a " ,
"formula" : " {partner_name} = 'Partner A' "
} Nuestro ejemplo también incluye una métrica "ventas" cuyo valor se calcula a través de la fórmula en la capa de consulta de la fuente de datos. Tenga en cuenta lo siguiente en la lista de fields para el parámetro "ID" en la tabla "Main.Sales". Estas fórmulas están en la sintaxis de la tecnología de base de datos de datos DataSource particular, que también es sqlite en nuestro ejemplo.
"fields" : [
" sale_id " ,
{ "name" : " sales " , "ds_formula" : " COUNT(DISTINCT sales.id) " }
] Nuestro ejemplo también creó automáticamente un puñado de dimensiones de las columnas "Create_AT" de los leads y las tablas de ventas. El soporte para conversiones de tipo automática es limitado, pero para columnas de fecha/fecha de fecha en tecnologías DataSource compatibles, puede obtener una variedad de dimensiones de forma gratuita de esta manera.
La salida de wh.print_info mostrará las dimensiones adicionales, que están prefijadas con "Lead_" o "Sale_" como se especifica por el type_conversion_prefix opcional en la configuración para cada tabla. Algunos ejemplos de dimensiones generadas automáticamente en nuestro almacén de ejemplo incluyen Sale_Hour, Sale_Day_Name, Sale_Month, Sale_Year, etc.
Como optimización en la cláusula WHERE de consultas de informes subyacentes, Zillion intentará aplicar conversiones a valores de criterios en lugar de columnas. Por ejemplo, generalmente es más eficiente consultar como my_datetime > '2020-01-01' and my_datetime < '2020-01-02' en lugar de DATE(my_datetime) == '2020-01-01' , porque este último puede evitar el uso del índice en muchas tecnologías de bases de datos. La capacidad de aplicar conversiones a valores en lugar de columnas también varía según el campo y la tecnología DataSource .
Para evitar conversiones de tipo, establezca skip_conversion_fields en true en su configuración DataSource .
Consulte zillion.field.TYPE_ALLOWED_CONVERSIONS y zillion.field.DIALECT_CONVERSIONS para obtener más detalles sobre las conversiones compatibles actualmente.
También puede definir las métricas "ad hoc" con cada solicitud de informe. A continuación se muestra un ejemplo que crea una métrica de ingresos por favor sobre la marcha. Estos solo existen dentro del alcance del informe, y el nombre no puede entrar en conflicto con ningún campo existente:
result = wh . execute (
metrics = [
"leads" ,
{ "formula" : "{revenue}/{leads}" , "name" : "my_rpl" }
],
dimensions = [ "partner_name" ]
) También puede definir las dimensiones "ad hoc" con cada solicitud de informe. A continuación se muestra un ejemplo que crea una dimensión que se divide en un valor de dimensión particular en la mosca. Las dimensiones ad hoc son una subclase de FormulaDimension s y, por lo tanto, tienen las mismas restricciones, como no poder usar una métrica como campo de fórmula. Estos solo existen dentro del alcance del informe, y el nombre no puede entrar en conflicto con ningún campo existente:
result = wh . execute (
metrics = [ "leads" ],
dimensions = [{ "name" : "partner_is_a" , "formula" : "{partner_name} = 'Partner A'" ]
) Zillion también admite la creación o sincronización de tablas ad hoc en su base de datos durante DataSource o el inicio Warehouse . Un ejemplo de una configuración de tabla que hace esto se muestra aquí. Utiliza los parámetros data_url e if_exists de la tabla para controlar la sincronización y/o creación de la tabla "main.dma_zip" desde un CSV remoto en una base de datos SQLite. Lo mismo se puede hacer en otros tipos de bases de datos también.
Los posibles inconvenientes de rendimiento para este enfoque deben ser obvios, particularmente si está inicializando su almacén con frecuencia o si el archivo de datos remoto es grande. A menudo es mejor sincronizar y crear sus datos con anticipación para que tenga un control de esquema completo, pero este método puede ser muy útil en ciertos escenarios.
ADVERTENCIA : ¡Tenga cuidado de no sobrescribir las tablas existentes en su base de datos!
Hay una variedad de cálculos técnicos que se pueden aplicar a las métricas para calcular estadísticas de laminación, acumulativa o rango. Por ejemplo, para calcular un promedio móvil de 5 puntos en los ingresos, uno podría definir una nueva métrica de la siguiente manera:
{
"name" : " revenue_ma_5 " ,
"type" : " numeric(10,2) " ,
"aggregation" : " sum " ,
"rounding" : 2 ,
"technical" : " mean(5) "
}Los cálculos técnicos se calculan en la capa combinada, mientras que la "agregación" se realiza en la capa de fuente de datos (por lo tanto, necesita definir ambos arriba).
Para obtener más información sobre cómo se analizan las cadenas técnicas, consulte el código parse_technical_string. Para una lista completa de tipos técnicos compatibles, consulte zillion.core.TechnicalTypes .
Los técnicos también admiten dos modos: "Grupo" y "Todos". El modo controla cómo aplicar el cálculo técnico a través de las dimensiones de los datos. En el modo "Grupo", calcula la técnica en la última dimensión, mientras que en el modo "All" en el modo técnico calcula la técnica en todos los datos sin tener en cuenta las dimensiones.
El punto de esto se vuelve más claro si intenta hacer una técnica de "corro" en todos los datos desglosados por algo como ["socio_name", "fecha"]. Si se usa el modo "Grupo" (el valor predeterminado en la mayoría de los casos) hará sumas acumulativas dentro de cada socio durante los rangos de fecha. Si se usa el modo "todo", hará una suma acumulativa en cada fila de datos. Puede ser explícito sobre el modo agregándolo a la cadena técnica: es decir, "Cumsum: All" o "media (5): grupo"
Si desea evitar poner información de conexión confidencial directamente en sus configuraciones DataSource , puede aprovechar las variables de configuración. En su configuración Zillion Yaml, puede especificar una sección DATASOURCE_CONTEXTS de la siguiente manera:
DATASOURCE_CONTEXTS :
my_ds_name :
user : user123
pass : goodpassword
host : 127.0.0.1
schema : reporting Luego, cuando se lee su configuración de Cource DataSource para el DataSource llamado "My_DS_Name", puede usar este contexto para completar las variables en su URL de conexión:
"datasources" : {
"my_ds_name" : {
"connect" : " mysql+pymysql://{user}:{pass}@{host}/{schema} "
...
}
} En Warehouse Init, puede especificar un orden de prioridad predeterminado para DataSources por nombre. Esto entrará en juego cuando un informe pueda ser satisfecho con múltiples platos de datos. DataSources anteriormente en la lista será de mayor prioridad. Esto sería útil si quisiera favorecer un conjunto de tablas más rápidas y agregadas que se agrupan en una DataSource .
wh = Warehouse ( config = config , ds_priority = [ "aggr_ds" , "raw_ds" , ...]) El objetivo Zillion's es admitir cualquier tecnología de base de datos que SQLalchemy admita (en la foto a continuación). Dicho esto, los niveles de soporte y prueba en Zillion varían en este momento. En particular, la capacidad de hacer conversiones de tipo, reflexión de la base de datos y consultas de ejecución de la ejecución requieren algún código específico de base de datos para soporte. La siguiente lista resume los niveles de soporte conocidos. Su kilometraje puede variar con las tecnologías de bases de datos no probadas que Sqlalchemy admite (podría funcionar bien, simplemente no se ha probado todavía). ¡Informe a los errores y ayude a agregar más soporte!
Sqlalchemy tiene conectores a muchas bases de datos populares. La barrera para respaldar muchos de estos es probablemente bastante baja dada la naturaleza simple de las operaciones SQL que usa Zillion .
Tenga en cuenta que lo anterior es diferente al soporte de la base de datos para la base de datos de capa combinada. Actualmente, solo SQLite es compatible allí; Eso debería ser suficiente para la mayoría de los casos de uso, pero se agregarán más opciones en el futuro.
Si planea ejecutar Zillion en un escenario multiproceso, ya sea en un solo nodo o en múltiples nodos, hay un par de cosas a considerar:
Tenga en cuenta que aún puede usar la capa combinada de capa combinada en memoria de SQLite predeterminada sin problemas, ya que se hace en la marcha con cada solicitud de informe y no requiere coordinación/comunicación con otros procesos o nodos.
Zillion Web UI es una UI de demostración y una API web para Zillion que también incluye un complemento ChatGPT experimental. Consulte el ReadMe allí para obtener más información sobre la instalación y la estructura del proyecto. Tenga en cuenta que el código es ligero en las pruebas y es pulir, pero se espera que funcione en los navegadores modernos. Además, los complementos ChatGPT son bastante lentos en este momento, por lo que actualmente eso es principalmente para divertirse y no tan útiles.
Se puede encontrar una documentación más exhaustiva aquí. Puede complementar su conocimiento examinando el directorio de pruebas o la referencia de API.
Consulte la guía de contribución para obtener más información. Si está buscando inspiración, agregar soporte y pruebas para tecnologías de base de datos adicionales sería de gran ayuda.
