zillion
v0.12.0
Zillion é uma ferramenta de modelagem de dados e análise que permite combinar e analisar dados de vários fontes de dados por meio de uma API simples. Ele atua como uma camada semântica em cima de seus dados, grava SQL para que você não precise e facilmente aparaça na infraestrutura de banco de dados existente via SQLalChemy Core. A extensão Zillion de NLP possui suporte experimental para consulta de linguagem natural a IA e configuração de armazém.
Com Zillion você pode:
AVISO : Este projeto está em um estado alfa e está sujeito a alterações. Teste com cuidado o uso da produção e relate quaisquer problemas.
$ pip install zillion
or
$ pip install zillion[nlp] A seguir, é destinada a fornecer uma rápida visão geral de alguma teoria e nomenclatura usadas no data warehousing com Zillion , o que será útil se você for mais novo nessa área. Você também pode pular abaixo para um exemplo de uso ou opções de criação de armazém/DataSource.
Em resumo: Zillion escreve SQL para você e torna os dados acessíveis através de uma API muito simples:
result = warehouse . execute (
metrics = [ "revenue" , "leads" ],
dimensions = [ "date" ],
criteria = [
( "date" , ">" , "2020-01-01" ),
( "partner" , "=" , "Partner A" )
]
) Em Zillion , existem dois tipos principais de Fields que serão usados em suas solicitações de relatório:
Dimensions : atributos de dados usados para rotulagem, agrupamento e filtragemMetrics : fatos e medidas que podem ser divididos ao longo das dimensões Um Field encapsula o conceito de uma coluna em seus dados. Por exemplo, você pode ter um Field chamado "Receita". Esse Field pode ocorrer em várias fontes de dados ou possivelmente em várias tabelas em uma única fonte de dados. Zillion entende que todas essas colunas representam o mesmo conceito e pode tentar usar qualquer um deles para satisfazer relatórios solicitando "receita".
Da mesma forma, existem dois tipos principais de tabelas usados para estruturar seu armazém:
Dimension Tables : tabelas de referência/atributo contendo apenas dimensões relacionadasMetric Tables : tabelas de fatos que podem conter métricas e algumas dimensões/atributos relacionadosAs tabelas de dimensão geralmente são estáticas ou crescem lentamente em termos de contagem de linhas e contêm atributos vinculados a uma chave primária. Alguns exemplos comuns seriam listas de códigos postais dos EUA ou diretórios da empresa/parceiro.
As tabelas métricas são geralmente de natureza mais transacional. Alguns exemplos comuns seriam registros para solicitações da Web, vendas de comércio eletrônico ou histórico de preços do mercado de ações.
Se você realmente deseja se aprofundar na modelagem dimensional e na técnica de consulta de drill-across, Zillion emprega, recomendo ler o livro de Ralph Kimball sobre Data Warehousing.
Para resumir, a consulta de perfuração de perfuração forma uma ou mais consultas para satisfazer uma solicitação de relatório de metrics que podem existir em várias fontes de dados e/ou tabelas em um grão dimension específico.
Zillion suporta configurações flexíveis de armazém, como floco de neve ou esquemas de estrelas, embora não seja exigente. Você pode especificar relacionamentos de tabela através de uma linhagem pai-filho, e Zillion também pode inferir junções aceitáveis com base na presença de teclas primárias da tabela de dimensões. Zillion não suporta relacionamentos muitos para muitos no momento, embora a maioria dos cenários focados em análises deva ser capaz de contornar isso adicionando visualizações ao modelo, se necessário.
Os relatórios Zillion podem ser considerados em duas camadas:
DataSource Layer : Consultas SQL contra as fontes de dados do armazémCombined Layer : uma consulta final do SQL contra os dados combinados da camada de fonte de dadosA camada combinada é apenas mais um banco de dados SQL (sqlite in-memory por padrão) que é usado para unir os dados da fonte de dados e aplicar alguns recursos adicionais, como rollups, filtros de linha, limites de linha, classificação, pivôs e cálculos técnicos.
Existem várias maneiras de inicializar rapidamente um armazém de um arquivo local ou 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 ) O Zilhão também fornece um script auxiliar para impulsionar um arquivo de configuração do DataSource para um banco de dados existente. Consulte zillion.scripts.bootstrap_datasource_config.py . O script de bootstrap requer um URL de conexão/banco de dados e arquivo de saída como argumentos. Consulte -Saída --help para obter mais opções, incluindo o sinalizador opcional --nlp que aproveita o OpenAI para inferir informações de configuração, como tipos de coluna, tipos de tabela e relacionamentos de tabela. O recurso PNL requer que a extensão da PNL seja instalada, bem como o seguinte definido no seu arquivo de configuração Zillion :
O principal objetivo do Zillion é executar relatórios contra um Warehouse . Em um nível alto, você estará criando relatórios da seguinte forma:
result = warehouse . execute (
metrics = [ "revenue" , "leads" ],
dimensions = [ "date" ],
criteria = [
( "date" , ">" , "2020-01-01" ),
( "partner" , "=" , "Partner A" )
]
)
print ( result . df ) # Pandas DataFrameAo comparar a gravação do SQL, é útil pensar nas dimensões como as colunas de destino de um grupo pela instrução SQL. Pense nas métricas como as colunas que você está agregando . Pense nos critérios como a cláusula onde . Seus critérios são aplicados nas consultas SQL da camada de dados de dados.
O ReportResult possui um quadro de dados de pandas com as dimensões como índice e métricas como colunas.
Diz -se que um Report possui um grain , que define as dimensões que cada métrica deve poder participar para atender aos requisitos Report . O grain é uma combinação de todas as dimensões, incluindo as referenciadas em critérios ou em fórmulas métricas. No exemplo acima, o grain seria {date, partner} . "Receita" e "leads" devem poder participar dessas dimensões para que este relatório seja possível.
Esses conceitos podem levar tempo para afundar e obviamente variar com as especificidades do seu modelo de dados, mas você se familiarizará com eles quando começar a montar relatórios contra seus armazéns de dados.
Com a extensão da PNL, Zillion tem suporte experimental para a consulta de linguagem natural do seu data warehouse. Por exemplo:
result = warehouse . execute_text ( "revenue and leads by date last month" )
print ( result . df ) # Pandas DataFrame Esse recurso de PNL requer uma instância em execução do QDRANT (banco de dados vetorial) e os seguintes valores definidos no seu arquivo de configuração Zillion :
As incorporações serão produzidas e armazenadas no QDrant e em um cache local. O banco de dados Vector será inicializado na primeira vez que você tentar usá -lo analisando todos os campos em seu armazém. Um exemplo de arquivo do docker para executar o QDRANT é fornecido na raiz deste repositório.
Você tem algum controle sobre como os campos são incorporados. Nomeadamente, na configuração de qualquer campo, você pode escolher se deve excluir um campo de incorporação ou substituição que incorpore o mapa para esse campo. Todos os campos são incluídos por padrão. O exemplo a seguir excluiria o campo net_revenue de ser incorporado e mapear solicitações de métricas revenue ao 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
}
}
} ,Além disso, você também pode excluir campos através das seguintes configurações de configuração no nível do armazém:
{
"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"
]
}
} ,
...
} Se um campo estiver desativado em qualquer um dos níveis acima mencionados, ele será ignorado. Esse tipo de controle se torna útil à medida que seu modelo de dados se torna mais complexo e você deseja orientar a lógica do PNL nos casos em que ele pode confundir campos de maneira semelhante. Sempre que você ajusta quais campos são excluídos, você desejará forçar a recreação da sua coleção de incorporação usando o sinalizador force_recreate no Warehouse.init_embeddings .
Nota: esse recurso está em sua infância. Sua utilidade dependerá da qualidade da consulta de entrada e do seu modelo de dados (ou seja, bons nomes de campo)!
Além de configurar a estrutura do seu Warehouse , que será discutida mais adiante, Zillion possui uma configuração global para controlar algumas configurações básicas. O ambiente ZILLION_CONFIG VAR pode apontar para um arquivo de configuração YAML. Consulte examples/sample_config.yaml para obter mais detalhes sobre quais valores podem ser definidos. O Ambiente Vars prefixado com Zillion_ pode substituir as configurações de configuração (ou seja, zilhão_db_url substituirá DB_URL).
O banco de dados usado para armazenar especificações de relatório do Zilhão pode ser configurado definindo o valor DB_URL na sua configuração Zillion em uma string de conexão de banco de dados válida. Por padrão, é usado um sqlite db em /tmp.
Abaixo, passaremos por um modelo simples de dados hipotéticos de vendas que demonstra a configuração básica DataSource e Warehouse e depois mostra alguns relatórios de amostra. Os dados são um banco de dados SQLite simples que faz parte do código de teste Zillion . Para referência, o esquema é o seguinte:
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
); Um Warehouse pode ser criado a partir de uma configuração JSON ou YAML que define seus campos, fontes de dados e tabelas. O código abaixo mostra como pode ser feito em apenas uma linha de código se você tiver um ponteiro para uma configuração Warehouse JSON/YAML.
from zillion import Warehouse
wh = Warehouse ( config = "https://raw.githubusercontent.com/totalhack/zillion/master/examples/example_wh_config.json" ) Este exemplo de configuração usa um data_url em suas informações connect DataSource que informa Zillion para baixar dinamicamente esses dados e conectar -os a ele como um banco de dados SQLite. Isso é útil para exemplos ou análises rápidas, embora na maioria dos cenários você colocasse uma string de conexão em um banco de dados existente como você vê aqui
O básico da estrutura de configuração do armazém Zillion's são os seguintes:
Uma configuração Warehouse tem as seguintes seções principais:
metrics : Lista opcional de configurações métricas para métricas globaisdimensions : lista opcional de configurações de dimensão para dimensões globaisdatasources : Mapeamento de nomes de origem de dados para configurações de fonte de dados ou URLs de configuração Uma configuração DataSource possui as seguintes seções principais:
connect : URL de conexão do banco de dados ou ditado de parâmetros de conexãometrics : Lista opcional de configurações de métricas específicas para esta fonte de dadosdimensions : Lista opcional de configurações de dimensão específicas para esta fonte de dadostables : Mapeamento de nomes de tabela para tabela de configurações ou URLs de configuraçãoDica: as configurações de dados de dados e tabela também podem ser substituídas por um URL que aponta para um arquivo de configuração local ou remoto.
Neste exemplo, todas as quatro tabelas em nosso banco de dados estão incluídas na configuração, duas tabelas de dimensão e duas tabelas como métricas. As tabelas estão vinculadas através de um pai-> relacionamento infantil: parceiros às campanhas e leva a vendas. Algumas tabelas também utilizam o sinalizador create_fields para criar automaticamente Fields na fonte de dados das definições de coluna. Outras métricas e dimensões são definidas explicitamente.
Para visualizar a estrutura deste Warehouse após o init, você pode usar o método print_info que mostra todas as métricas, dimensões, tabelas e colunas que fazem parte do seu data warehouse:
wh . print_info () # Formatted print of the Warehouse structurePara um mergulho mais profundo do esquema de configuração, consulte os documentos completos.
Exemplo: Obtenha vendas, leads e receita por parceiro:
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
"""Exemplo: vamos limitar o parceiro A e quebrar suas campanhas:
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
"""Exemplo: a saída abaixo mostra rollups no nível da campanha em cada parceiro e também um rollup de totais no nível de parceiro e campanha.
NOTA: A saída contém um caractere especial para marcar linhas de rollup do quadro de dados que foram adicionadas ao resultado. O objeto ReportResult contém alguns atributos auxiliares para acessar ou filtrar automaticamente rollups, bem como um atributo
df_displayque retorna o resultado com valores de exibição mais amigáveis substituídos por caracteres especiais. O personagem especial sob a altura é deixado aqui para ilustração, mas pode não renderizar o mesmo em todos os cenários.
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 o Report Docs para obter mais informações sobre o comportamento de rollup suportado.
Exemplo: salve um relatório específico (não os dados):
Primeiro, você deve ter certeza de que salvou seu Warehouse , pois os relatórios salvos estão escovados para um ID Warehouse específico. Para salvar um Warehouse , você deve fornecer um URL que aponte para a configuração 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 : Se você criou seu
Warehouseem Python a partir de uma lista deDataSourcesou passou em umdictpara o param deconfigno init, atualmente não há uma maneira interna de produzir uma configuração completa para um arquivo para referência ao salvar.
Exemplo: carregue e execute um relatório de um ID de especificação:
result = wh . execute_id ( spec_id ) Isso pressupõe que você salvou este ID do relatório anteriormente no banco de dados especificado pelo DB_URL na sua configuração Zillion YAML.
Exemplo: grão não suportado
Se você tentar um relatório impossível, obterá uma UnsupportedGrainException . O relatório abaixo é impossível porque tenta quebrar a métrica de leads por uma dimensão que só existe em uma tabela infantil. De um modo geral, as mesas de crianças podem se juntar aos pais (e "irmãos" dos pais) para encontrar dimensões, mas não o contrário.
# Fails with UnsupportedGrainException
result = wh . execute (
metrics = [ "leads" ],
dimensions = [ "sale_id" ]
) Às vezes, você precisa de funcionalidade semelhante a uma subconeração para filtrar um relatório para os resultados de algum outro (que talvez exigisse um grão diferente). O Zilhão fornece uma maneira simplista de fazer isso usando o in report ou not in report . Existem duas maneiras suportadas de especificar o sub -relatório: Passando um ID de especificação de relatório ou passando um ditado de parâmetros de relatório.
# 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 = [...]
))
]
) O campo de critérios usado in report ou not in report deve ser uma dimensão no sub -relato. Observe que os sub -relatórios são executados no tempo de inicialização do objeto Report , em vez de durante execute - como tal, eles não podem ser mortos usando Report.kill . Isso pode mudar no caminho.
Em nosso exemplo acima, nossa configuração incluiu uma métrica baseada em fórmula chamada "RPL", que é simplesmente revenue / leads . Um FormulaMetric combina outras métricas e/ou dimensões para calcular uma nova métrica na camada combinada de consulta. A sintaxe deve corresponder ao seu banco de dados de camada combinada, que é sqlite em nosso exemplo.
{
"name" : " rpl " ,
"aggregation" : " mean " ,
"rounding" : 2 ,
"formula" : " {revenue}/{leads} "
} Como conveniência, em vez de definir repetidamente as métricas de fórmula para variantes de taxa de uma métrica principal, você pode especificar uma configuração métrica de divisor em uma métrica não-formula. Como exemplo, digamos que você tenha uma métrica revenue e deseja criar variantes para revenue_per_lead e revenue_per_sale . Você pode definir sua métrica de receita da seguinte maneira:
{
"name" : " revenue " ,
"type" : " numeric(10,2) " ,
"aggregation" : " sum " ,
"rounding" : 2 ,
"divisors" : {
"metrics" : [
" leads " ,
" sales "
]
}
} Consulte zillion.configs.DivisorsConfigSchema para obter mais detalhes sobre opções de configuração, como substituir modelos de nomeação, modelos de fórmula e arredondamento.
Outro recurso de conveniência menor é a capacidade de gerar automaticamente variantes de métricas para diferentes tipos de agregação em uma única configuração de campo, em vez de em vários campos em seu arquivo de configuração. Como exemplo, digamos que você tenha uma coluna sales em seus dados e deseja criar variantes para sales_mean e sales_sum . Você pode definir sua métrica da seguinte maneira:
{
"name" : " sales " ,
"aggregation" : {
"mean" : {
"type" : " numeric(10,2) " ,
"rounding" : 2
},
"sum" : {
"type" : " integer "
}
}
} O armazém resultante não teria uma métrica sales , mas teria sales_mean e sales_sum . Observe que você pode personalizar ainda mais as configurações dos campos gerados, como definir um nome personalizado, especificando isso nas configurações aninhadas para esse tipo de agregação. Na prática, esse não é um grande ganho de eficiência sobre definir as métricas separadamente, mas algumas podem preferir essa abordagem.
O suporte experimental também existe para campos FormulaDimension . Uma FormulaDimension só pode usar outras dimensões como parte de sua fórmula e também é avaliada no banco de dados da camada combinada. Como restrição adicional, uma FormulaDimension não pode ser usada nos critérios de relatório, pois esses filtros são avaliados na camada de fonte de dados. O exemplo a seguir assume um banco de dados de camada combinada SQLite:
{
"name" : " partner_is_a " ,
"formula" : " {partner_name} = 'Partner A' "
} Nosso exemplo também inclui uma métrica "vendas" cujo valor é calculado via fórmula na camada de consulta do DataSource. Observe o seguinte na lista fields para o parâmetro "ID" na tabela "main.sales". Essas fórmulas estão na sintaxe da tecnologia de banco de dados DataSource específica, que também é sqlite em nosso exemplo.
"fields" : [
" sale_id " ,
{ "name" : " sales " , "ds_formula" : " COUNT(DISTINCT sales.id) " }
] Nosso exemplo também criou automaticamente um punhado de dimensões das colunas "CREATED_AT" das tabelas de leads e vendas. O suporte para conversões de tipos automáticos é limitado, mas para colunas de data/datetime em tecnologias DataSource suportadas, você pode obter uma variedade de dimensões gratuitamente dessa maneira.
A saída de wh.print_info mostrará as dimensões adicionadas, que são prefixadas com "Lead_" ou "Sale_", conforme especificado pelo tipo opcional type_conversion_prefix na configuração para cada tabela. Alguns exemplos de dimensões geradas automaticamente em nosso exemplo de armazém incluem Sale_hour, Sale_Day_Name, Sale_month, Sale_year, etc.
Como uma otimização na cláusula WHERE of Subjacente às consultas do relatório, Zillion tentará aplicar conversões aos valores dos critérios em vez de colunas. Por exemplo, geralmente é mais eficiente consultar como my_datetime > '2020-01-01' and my_datetime < '2020-01-02' em vez de DATE(my_datetime) == '2020-01-01' , porque o último pode impedir o uso de índices em muitas tecnologias de dados de dados. A capacidade de aplicar conversões a valores em vez de colunas também varia de acordo com a tecnologia de campo e DataSource .
Para evitar conversões de tipo, defina skip_conversion_fields como true na sua configuração DataSource .
Consulte zillion.field.TYPE_ALLOWED_CONVERSIONS e zillion.field.DIALECT_CONVERSIONS para obter mais detalhes sobre conversões atualmente suportadas.
Você também pode definir métricas "ad hoc" com cada solicitação de relatório. Abaixo está um exemplo que cria uma métrica de receita por líder em tempo real. Estes existem apenas dentro do escopo do relatório, e o nome não pode entrar em conflito com nenhum campo existente:
result = wh . execute (
metrics = [
"leads" ,
{ "formula" : "{revenue}/{leads}" , "name" : "my_rpl" }
],
dimensions = [ "partner_name" ]
) Você também pode definir dimensões "ad hoc" com cada solicitação de relatório. Abaixo está um exemplo que cria uma dimensão que particiona em um valor de dimensão específico em tempo real. As dimensões ad hoc são uma subclasse de FormulaDimension S e, portanto, têm as mesmas restrições, como não poder usar uma métrica como campo de fórmula. Estes existem apenas dentro do escopo do relatório, e o nome não pode entrar em conflito com nenhum campo existente:
result = wh . execute (
metrics = [ "leads" ],
dimensions = [{ "name" : "partner_is_a" , "formula" : "{partner_name} = 'Partner A'" ]
) Zillion também suporta a criação ou a sincronização de tabelas ad hoc no seu banco de dados durante DataSource ou Warehouse init. Um exemplo de uma configuração de tabela que faz isso é mostrada aqui. Ele usa os parâmetros data_url e if_exists da tabela Config para controlar a sincronização e/ou a criação da tabela "main.dma_zip" de um CSV remoto em um banco de dados SQLite. O mesmo também pode ser feito em outros tipos de banco de dados.
As desvantagens potenciais de desempenho para essa abordagem devem ser óbvias, principalmente se você estiver inicializando seu armazém com frequência ou se o arquivo de dados remoto for grande. Muitas vezes, é melhor sincronizar e criar seus dados antes do tempo, para que você tenha controle de esquema completo, mas esse método pode ser muito útil em certos cenários.
Aviso : tenha cuidado para não substituir as tabelas existentes em seu banco de dados!
Há uma variedade de cálculos técnicos que podem ser aplicados a métricas para calcular estatísticas rolantes, cumulativas ou classificadas. Por exemplo, para calcular uma média móvel de 5 pontos na receita, pode-se definir uma nova métrica da seguinte maneira:
{
"name" : " revenue_ma_5 " ,
"type" : " numeric(10,2) " ,
"aggregation" : " sum " ,
"rounding" : 2 ,
"technical" : " mean(5) "
}Os cálculos técnicos são calculados na camada combinada, enquanto a "agregação" é feita na camada de fonte de dados (portanto, precisando definir os dois acima).
Para obter mais informações sobre como as cordas técnicas abreviadas são analisadas, consulte o código parse_technical_string. Para uma lista completa de tipos técnicos suportados, consulte zillion.core.TechnicalTypes .
Os técnicos também suportam dois modos: "Grupo" e "All". O modo controla como aplicar a computação técnica nas dimensões dos dados. No modo "Grupo", ele calcula o técnico em toda a última dimensão, enquanto no modo "All" em calcula o técnico em todos os dados sem qualquer consideração pelas dimensões.
O objetivo disso fica mais claro se você tentar fazer um "Cumsum" técnico entre os dados divididos por algo como ["parceiro_name", "date"]. Se o modo "grupo" for usado (o padrão na maioria dos casos), ele fará somas cumulativas dentro de cada parceiro nos intervalos da data. Se o modo "All" for usado, ele fará uma soma cumulativa em todas as linhas de dados. Você pode ser explícito sobre o modo, anexando -o à sequência técnica: ou seja, "Cumsum: All" ou "Mean (5): Group"
Se você deseja evitar colocar informações confidenciais de conexão diretamente em suas configurações DataSource , poderá aproveitar as variáveis de configuração. Na sua configuração de Zillion YAML, você pode especificar uma seção DATASOURCE_CONTEXTS da seguinte maneira:
DATASOURCE_CONTEXTS :
my_ds_name :
user : user123
pass : goodpassword
host : 127.0.0.1
schema : reporting Então, quando sua configuração DataSource para o DataSource denominada "my_ds_name" é lida, ela pode usar esse contexto para preencher variáveis em sua conexão URL:
"datasources" : {
"my_ds_name" : {
"connect" : " mysql+pymysql://{user}:{pass}@{host}/{schema} "
...
}
} No Warehouse Init, você pode especificar uma ordem de prioridade padrão para o DataSources por nome. Isso entrará em jogo quando um relatório puder ser satisfeito por várias fontes de dados. DataSources no início da lista serão uma prioridade mais alta. Isso seria útil se você quisesse favorecer um conjunto de tabelas mais rápidas e agregadas agrupadas em uma DataSource .
wh = Warehouse ( config = config , ds_priority = [ "aggr_ds" , "raw_ds" , ...]) O objetivo Zillion's é suportar qualquer tecnologia de banco de dados que o SQLalChemy suporta (na foto abaixo). Dito isto, os níveis de apoio e teste em Zillion variam no momento. Em particular, a capacidade de fazer conversões, reflexão no banco de dados e consultas em execução, todas exigem algum código específico do banco de dados para suporte. A lista a seguir resume os níveis de suporte conhecidos. Sua milhagem pode variar com as tecnologias de banco de dados não testadas que o SQLalChemy suporta (pode funcionar bem, apenas ainda não foi testado). Por favor, relate bugs e ajude a adicionar mais suporte!
O SQLalChemy possui conectores para muitos bancos de dados populares. A barreira para apoiar muitos deles provavelmente é bastante baixa, dada a natureza simples das operações do SQL Zillion de usos.
Observe que o acima é diferente do suporte ao banco de dados para o banco de dados da camada combinada. Atualmente, apenas o SQLite é suportado lá; Isso deve ser suficiente para a maioria dos casos de uso, mas mais opções serão adicionadas no futuro.
Se você planeja executar Zillion em um cenário de multiprocesso, seja em um único nó ou em vários nós, há algumas coisas a considerar:
Observe que você ainda pode usar o banco de dados de camada combinada SQLITE em memória padrão sem problemas, pois isso é feito em tempo real com cada solicitação de relatório e não requer coordenação/comunicação com outros processos ou nós.
O Zilhão de interface do usuário da web é uma interface do usuário de demonstração e uma API da Web para o Zilhão, que também inclui um plug -in experimental ChatGPT. Veja o ReadMe para obter mais informações sobre a instalação e a estrutura do projeto. Observe que o código é leve sobre testes e polimento, mas espera -se que funcione nos navegadores modernos. Além disso, os plug -ins ChatGPT são bastante lentos no momento, então atualmente é principalmente divertido e não é tão útil.
Documentação mais completa pode ser encontrada aqui. Você pode complementar seu conhecimento lendo o diretório de testes ou a referência da API.
Consulte o guia contribuinte para obter mais informações. Se você estiver procurando inspiração, adicionar suporte e testes para tecnologias adicionais de banco de dados seria uma grande ajuda.
