zillion
v0.12.0
Zillion 은 간단한 API를 통해 여러 데이터 소스의 데이터를 결합하고 분석 할 수있는 데이터 모델링 및 분석 도구입니다. 데이터 상단의 시맨틱 레이어 역할을하고 SQL을 작성하여 SQLALCHEMY CORE를 통해 기존 데이터베이스 인프라에 쉽게 볼트를 볼 필요가 없습니다. Zillion NLP Extension은 AI 구동 자연어 쿼리 및 창고 구성에 대한 실험적 지원을 제공합니다.
Zillion 과 함께 할 수 있습니다.
경고 :이 프로젝트는 알파 상태에 있으며 변경 될 수 있습니다. 생산 사용을주의 깊게 테스트하고 문제를보고하십시오.
$ pip install zillion
or
$ pip install zillion[nlp] 다음은 Zillion 과 함께 데이터웨어 하우징에 사용되는 일부 이론과 명명법에 대한 간단한 개요를 제공하기위한 것이며,이 영역에 새롭다면 유용합니다. 또한 사용법 예제 또는 창고/데이터 소스 작성 QuickStart 옵션을 위해 아래를 건너 뛸 수 있습니다.
요컨대 : Zillion 귀하를 위해 SQL을 작성하고 매우 간단한 API를 통해 데이터에 액세스 할 수 있도록합니다.
result = warehouse . execute (
metrics = [ "revenue" , "leads" ],
dimensions = [ "date" ],
criteria = [
( "date" , ">" , "2020-01-01" ),
( "partner" , "=" , "Partner A" )
]
) Zillion 에는 보고서 요청에 사용될 두 가지 주요 Fields 있습니다.
Dimensions : 라벨링, 그룹화 및 필터링에 사용되는 데이터 속성Metrics : 차원을 따라 분해 될 수있는 사실 및 조치 Field 데이터의 열 개념을 캡슐화합니다. 예를 들어, "수익"이라는 Field 있을 수 있습니다. 해당 Field 여러 데이터 소스 또는 단일 데이터 소스 내의 여러 테이블에서 발생할 수 있습니다. Zillion 이러한 모든 열이 동일한 개념을 나타내는 것을 이해하며 "수익"을 요청하는 보고서를 만족시키기 위해 사용하려고 시도 할 수 있습니다.
마찬가지로 창고를 구조화하는 데 사용되는 두 가지 주요 테이블이 있습니다.
Dimension Tables : 관련 차원 만 포함 된 참조/속성 테이블Metric Tables : 메트릭 및 일부 관련 차원/속성을 포함 할 수있는 사실 테이블치수 테이블은 종종 행 카운트 측면에서 정적이거나 천천히 자라며 기본 키와 관련된 속성을 포함합니다. 몇 가지 일반적인 예는 미국 우편 번호 또는 회사/파트너 디렉토리의 목록입니다.
메트릭 테이블은 일반적으로 더 많은 트랜잭션입니다. 몇 가지 일반적인 예는 웹 요청, 전자 상거래 판매 또는 주식 시장 가격 기록에 대한 기록입니다.
차원 모델링과 Drill-Across Querying Technique Zillion 사용하는 것이 실제로 Data Warehousing에 대한 Ralph Kimball의 책을 읽는 것이 좋습니다.
요약하기 위해, 드릴-아크로스 쿼리는 하나 이상의 쿼리를 형성하여 특정 dimension 곡물에서 여러 데이터 소스 및/또는 테이블에 존재할 수있는 metrics 에 대한 보고서 요청을 충족시킵니다.
Zillion Snowflake 또는 Star Schemas와 같은 유연한 창고 설정을 지원하지만 까다 롭지는 않습니다. 부모-자식 계보를 통해 테이블 관계를 지정할 수 있으며, Zillion 차원 테이블 기본 키의 존재에 따라 허용 가능한 조인을 유추 할 수도 있습니다. Zillion 현재 많은 관계를 지원하지는 않지만 대부분의 분석 중심 시나리오는 필요한 경우 모델에 뷰를 추가하여이를 해결할 수 있어야합니다.
Zillion 보고서는 두 계층으로 실행되는 것으로 생각할 수 있습니다.
DataSource Layer : 창고의 데이터 소스에 대한 SQL 쿼리Combined Layer : DataSource 계층의 결합 된 데이터에 대한 최종 SQL 쿼리결합 된 레이어는 데이터 소스 데이터를 함께 묶고 롤업, 행 필터, 행 제한, 정렬, 피벗 및 기술 계산과 같은 몇 가지 추가 기능을 적용하는 데 사용되는 또 다른 SQL 데이터베이스 (기본적으로 메모리 SQLITE)입니다.
로컬 또는 원격 파일에서 창고를 빠르게 초기화하는 방법에는 여러 가지가 있습니다.
# 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은 또한 기존 데이터베이스에 대한 데이터 소스 구성 파일을 부수하기위한 도우미 스크립트를 제공합니다. zillion.scripts.bootstrap_datasource_config.py 참조하십시오. 부트 스트랩 스크립트에는 연결/데이터베이스 URL 및 출력 파일이 인수로 필요합니다. OpenAI를 활용하여 열 유형, 테이블 유형 및 테이블 관계와 같은 구성 정보를 추론하는 옵션 --nlp 플래그를 포함하여 더 많은 옵션에 대해서는 --help 출력을 참조하십시오. NLP 기능은 NLP 확장 기능을 설치해야하며 Zillion 구성 파일의 다음 세트를 설치해야합니다.
Zillion 의 주요 목적은 Warehouse 에 대한 보고서를 실행하는 것입니다. 높은 수준에서는 다음과 같이 보고서를 제작하게됩니다.
result = warehouse . execute (
metrics = [ "revenue" , "leads" ],
dimensions = [ "date" ],
criteria = [
( "date" , ">" , "2020-01-01" ),
( "partner" , "=" , "Partner A" )
]
)
print ( result . df ) # Pandas DataFrameSQL을 쓰는 것과 비교할 때 크기를 SQL 문 으로 그룹 의 대상 열로 생각하는 것이 도움이됩니다. 메트릭을 집계하는 열로 생각하십시오. 기준을 WHERE 절로 생각하십시오. 귀하의 기준은 DataSource 계층 SQL 쿼리에 적용됩니다.
ReportResult 크기가 인덱스로서 및 메트릭을 열이있는 Pandas Dataframe을 가지고 있습니다.
Report 에는 grain 있는 것으로 알려져 있으며, 이는 Report 요구 사항을 충족시키기 위해 각 메트릭이 참여할 수 있어야하는 차원을 정의합니다. grain 기준 또는 메트릭 공식에서 참조 된 것들을 포함하여 모든 차원의 조합입니다. 위의 예에서 grain {date, partner} 입니다. "수익"과 "리드"는이 보고서가 가능하기 위해 해당 차원에 참여할 수 있어야합니다.
이러한 개념은 데이터 모델의 세부 사항에 따라 가라 앉고 분명히 다를 수 있지만 데이터웨어 하우스에 대한 보고서를 작성하기 시작하면서 더 익숙해 질 수 있습니다.
NLP Extension을 통해 Zillion 데이터웨어 하우스의 자연어 쿼리를 실험적으로 지원합니다. 예를 들어:
result = warehouse . execute_text ( "revenue and leads by date last month" )
print ( result . df ) # Pandas DataFrame 이 NLP 기능은 QDRANT (Vector Database)의 실행중인 인스턴스와 Zillion Config 파일에 설정된 다음 값이 필요합니다.
임베딩은 QDRANT 및 로컬 캐시에 생산 및 저장됩니다. 벡터 데이터베이스는 창고의 모든 필드를 분석하여 처음으로 사용하려고 시도 할 때 초기화됩니다. qdrant를 실행할 예제 Docker 파일 이이 리포지토리의 루트에 제공됩니다.
필드가 어떻게 포함되는지에 대한 제어가 있습니다. 즉, 모든 필드에 대한 구성에서는 임베딩에서 필드를 제외할지 여부를 선택할 수 있습니다. 모든 필드는 기본적으로 포함됩니다. 다음 예제는 net_revenue 필드가 내장되는 것을 제외하고 gross_revenue 필드에 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
}
}
} ,또한 다음 창고 수준 구성 설정을 통해 필드를 제외 할 수도 있습니다.
{
"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"
]
}
} ,
...
} 앞서 언급 한 레벨에서 필드가 비활성화되면 무시됩니다. 이 유형의 제어는 데이터 모델이 더욱 복잡해지고 유사하게 명명 된 필드를 혼동 할 수있는 경우 NLP 로직을 안내하려고합니다. 어떤 필드를 제외 할 때마다, 당신은 Warehouse.init_embeddings 에서 force_recreate 플래그를 사용하여 Embeddings 컬렉션의 레크리에이션을 강제로 만들 것입니다.
참고 : 이 기능은 초기 단계에 있습니다. 유용성은 입력 쿼리와 데이터 모델의 품질 (예 : 좋은 필드 이름)에 달려 있습니다!
Zillion 아래에서 더 자세히 설명 할 Warehouse 구조를 구성하는 것 외에도 일부 기본 설정을 제어하기위한 전역 구성이 있습니다. ZILLION_CONFIG 환경 var는 Yaml 구성 파일을 가리킬 수 있습니다. 설정할 수있는 값에 대한 자세한 내용은 examples/sample_config.yaml 참조하십시오. zillion_로 접두사가있는 환경 대표는 구성 설정을 무시할 수 있습니다 (예 : zillion_db_url은 db_url을 무시합니다).
Zillion 보고서 사양을 저장하는 데 사용되는 데이터베이스는 Zillion 구성에서 DB_URL 값을 유효한 데이터베이스 연결 문자열로 설정하여 구성 할 수 있습니다. 기본적으로 /TMP 인 SQLITE DB가 사용됩니다.
아래에서는 기본 DataSource 및 Warehouse 구성을 보여주는 간단한 가상 판매 데이터 모델을 살펴보고 일부 샘플 보고서를 보여줍니다. 데이터는 Zillion 테스트 코드의 일부인 간단한 SQLITE 데이터베이스입니다. 참고로 스키마는 다음과 같습니다.
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
); 필드, 데이터 소스 및 테이블을 정의하는 JSON 또는 YAML 구성에서 Warehouse 만들 수 있습니다. 아래 코드는 JSON/YAML Warehouse 구성에 대한 포인터가있는 경우 코드 한 줄만큼이나 작은 방법으로 수행 할 수있는 방법을 보여줍니다.
from zillion import Warehouse
wh = Warehouse ( config = "https://raw.githubusercontent.com/totalhack/zillion/master/examples/example_wh_config.json" ) 이 예제 구성은 Zillion 해당 데이터를 동적으로 다운로드하고 SQLITE 데이터베이스로 연결하도록 지시하는 DataSource connect Info의 data_url 사용합니다. 이것은 빠른 예제 또는 분석에 유용하지만 대부분의 시나리오에서는 여기에서 볼 수 있듯이 기존 데이터베이스에 연결 문자열을 넣을 것입니다.
Zillion's 창고 구성 구조의 기본 사항은 다음과 같습니다.
Warehouse 구성에는 다음의 주요 섹션이 있습니다.
metrics : 글로벌 메트릭에 대한 메트릭 구성 목록dimensions : 글로벌 치수에 대한 치수 구성 목록datasources : 데이터 소스 이름을 데이터 소스 구성 또는 구성 URL에 매핑 DataSource 구성에는 다음의 주요 섹션이 있습니다.
connect : 데이터베이스 연결 URL 또는 Connect Params의 DITTmetrics :이 데이터 소스에 맞는 메트릭 구성 목록dimensions :이 데이터 소스에 특정한 치수 구성 목록tables : 테이블 이름을 테이블 구성 또는 구성 URL에 매핑팁 : 데이터 소스 및 테이블 구성은 로컬 또는 원격 구성 파일을 가리키는 URL로 대체 될 수 있습니다.
이 예에서는 데이터베이스의 4 개의 테이블 모두 구성에 포함되어 있으며 2 개는 치수 테이블로, 2 개는 메트릭 테이블로 포함됩니다. 테이블은 부모-> 아동 관계 : 캠페인 파트너를 통해 연결되어 있으며 판매로 이어집니다. 일부 테이블은 또한 create_fields 플래그를 사용하여 열 정의에서 데이터 소스에서 Fields 자동으로 작성합니다. 다른 메트릭과 치수는 명시 적으로 정의됩니다.
Init 이후이 Warehouse 의 구조를 보려면 데이터웨어 하우스의 일부인 모든 메트릭, 치수, 테이블 및 열을 표시하는 print_info 메소드를 사용할 수 있습니다.
wh . print_info () # Formatted print of the Warehouse structure구성 스키마의 더 깊은 다이빙은 전체 문서를 참조하십시오.
예 : 파트너 별 판매, 리드 및 수익을 얻으십시오.
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
"""예 : 파트너 A를 제한하고 캠페인을 통해 분류하겠습니다.
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
"""예 : 아래의 출력은 각 파트너 내의 캠페인 수준에서 롤업과 파트너 및 캠페인 수준의 총 롤업을 보여줍니다.
참고 : 출력에는 결과에 추가 된 데이터 프레임 롤업 행을 표시하는 특수 문자가 포함되어 있습니다. reportresult 객체에는 롤업을 자동으로 액세스하거나 필터링 할 수있는 일부 도우미 속성과
df_display속성이 포함되어있어 특수 문자로 대체 된 더 친숙한 디스플레이 값으로 결과를 반환합니다. 언더 스페셜 캐릭터는 그림을 위해 여기에 남아 있지만 모든 시나리오에서 동일하게 렌더링 할 수는 없습니다.
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
""" 지원되는 롤업 동작에 대한 자세한 내용은 Report 문서를 참조하십시오.
예 : 보고서 사양 저장 (데이터가 아님) :
먼저 저장된 보고서가 특정 Warehouse ID로 범위를두고 있으므로 Warehouse 저장했는지 확인해야합니다. Warehouse 저장하려면 전체 구성을 가리키는 URL을 제공해야합니다.
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" ]
)참고 :
DataSources목록에서 Python에Warehouse제작하거나 Init의configParam에 대한dict에 전달 된 경우 현재 저장시 참조를 위해 파일에 대한 완전한 구성을 출력하는 내장 방법이 없습니다.
예 : 사양 ID에서 보고서를로드하고 실행합니다.
result = wh . execute_id ( spec_id ) 이는 이전에 Zillion Yaml 구성에서 DB_URL이 지정한 데이터베이스에 이전에 저장했다고 가정합니다.
예 : 지원되지 않은 곡물
불가능한 보고서를 시도하면 UnsupportedGrainException 외환을 받게됩니다. 아래 보고서는 어린이 테이블에만 존재하는 차원으로 리드 메트릭을 분해하려고 시도하기 때문에 불가능합니다. 일반적으로, 어린이 테이블은 부모 (및 부모의 "형제 자매")와 다시 가입하여 차원을 찾을 수 있지만 다른 방법은 아닙니다.
# Fails with UnsupportedGrainException
result = wh . execute (
metrics = [ "leads" ],
dimensions = [ "sale_id" ]
) 때로는 하나의 보고서를 다른 곡물의 결과로 필터링하기 위해서는 하위 퀴어와 같은 기능이 필요합니다 (아마도 다른 곡물이 필요할 수 있습니다). Zillion은 not in report in report 를 사용하여이를 수행하는 단순한 방법을 제공합니다. 하위 보고서를 지정하는 두 가지 지원 방법이 있습니다. 보고서 사양 ID를 전달하거나 보고서 매개 변수를 전달합니다.
# 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 = [...]
))
]
) in report 사용 not in report 사용 된 기준 필드는 하위 보고서의 차원이어야합니다. 하위 보고서는 보고서 대상 execute 아닌 Report 초기화 시간에서 실행됩니다. 따라서 Report.kill 사용하여 죽일 수 없습니다. 이것은 길을 바꿀 수 있습니다.
위의 예에서 우리의 구성에는 단순히 revenue / leads 인 "rpl"이라는 공식 기반 메트릭이 포함되었습니다. FormulaMetric 다른 메트릭 및/또는 차원을 결합하여 쿼리의 결합 레이어에서 새로운 메트릭을 계산합니다. 구문은 결합 된 레이어 데이터베이스와 일치해야하며,이 예제에서는 SQLITE입니다.
{
"name" : " rpl " ,
"aggregation" : " mean " ,
"rounding" : 2 ,
"formula" : " {revenue}/{leads} "
} 편의성으로, 코어 메트릭의 속도 변형에 대한 공식 메트릭을 반복적으로 정의하지 않고 비 형식 메트릭에서 Divisor 메트릭 구성을 지정할 수 있습니다. 예를 들어, revenue 메트릭이 있고 revenue_per_lead 및 revenue_per_sale 에 대한 변형을 만들고 싶다고 가정 해 봅시다. 수익 메트릭을 다음과 같이 정의 할 수 있습니다.
{
"name" : " revenue " ,
"type" : " numeric(10,2) " ,
"aggregation" : " sum " ,
"rounding" : 2 ,
"divisors" : {
"metrics" : [
" leads " ,
" sales "
]
}
} 이름 지정 템플릿 재정의 구성 옵션, 공식 템플릿 및 반올림과 같은 구성 옵션에 대한 자세한 내용은 zillion.configs.DivisorsConfigSchema 참조하십시오.
또 다른 사소한 편의 기능은 구성 파일의 여러 필드가 아닌 단일 필드 구성에서 다양한 집계 유형에 대한 메트릭 변형을 자동으로 생성하는 기능입니다. 예를 들어, 데이터에 sales 열이 있고 sales_mean 및 sales_sum 의 변형을 생성하려고합니다. 메트릭을 다음과 같이 정의 할 수 있습니다.
{
"name" : " sales " ,
"aggregation" : {
"mean" : {
"type" : " numeric(10,2) " ,
"rounding" : 2
},
"sum" : {
"type" : " integer "
}
}
} 결과 창고에는 sales 지표가 없지만 대신 sales_mean 및 sales_sum 있습니다. 해당 집계 유형의 중첩 설정에 지정하여 사용자 정의 이름 설정과 같은 생성 된 필드의 설정을 추가로 사용자 정의 할 수 있습니다. 실제로 이것은 메트릭을 개별적으로 정의하는 데 비해 큰 효율성을 얻는 것이 아니지만 일부는이 접근법을 선호 할 수 있습니다.
FormulaDimension 분야에 대해서도 실험적지지가 존재한다. FormulaDimension 다른 차원을 공식의 일부로 만 사용할 수 있으며 결합 된 계층 데이터베이스에서도 평가됩니다. 추가 제한으로서, 이러한 필터가 데이터 소스 계층에서 평가되므로보고 기준에는 FormulaDimension 사용할 수 없습니다. 다음 예는 SQLITE 결합 레이어 데이터베이스를 가정합니다.
{
"name" : " partner_is_a " ,
"formula" : " {partner_name} = 'Partner A' "
} 이 예제에는 쿼리의 데이터 소스 계층에서 공식을 통해 값이 계산되는 메트릭 "판매"도 포함됩니다. "main.sales"테이블의 "ID"매개 변수에 대한 fields 목록에 다음을 참고하십시오. 이러한 공식은 특정 DataSource 데이터베이스 기술의 구문에 있으며,이 예제에서도 SQLITE도 발생합니다.
"fields" : [
" sale_id " ,
{ "name" : " sales " , "ds_formula" : " COUNT(DISTINCT sales.id) " }
] 이 예제는 또한 리드 및 판매 테이블의 "create_at"열에서 몇 차원의 차원을 자동으로 생성했습니다. 자동 유형 변환 지원은 제한적이지만 지원되는 DataSource 기술의 날짜/DateTime 열의 경우 이런 식으로 무료로 다양한 크기를 얻을 수 있습니다.
wh.print_info 의 출력은 각 테이블의 구성에서 선택적 type_conversion_prefix 로 지정된 "lead_"또는 "sale_"로 접두사가 추가 된 추가 치수를 표시합니다. 예제 창고의 자동 생성 치수의 일부 예로는 Sale_hour, Sale_day_name, Sale_month, Sale_year 등이 있습니다.
기본 보고서 쿼리의 WHERE 절의 최적화로 Zillion 열 대신 기준 값으로 변환을 적용하려고합니다. 예를 들어, my_datetime > '2020-01-01' and my_datetime < '2020-01-02' 대신 DATE(my_datetime) == '2020-01-01' 과 같이 쿼리하는 것이 일반적으로 더 효율적입니다. 열 대신 값으로 전환하는 기능은 현장 및 DataSource 기술에 따라 다릅니다.
유형 변환을 방지하려면 DataSource 구성에서 skip_conversion_fields true 로 설정하십시오.
현재 지원되는 전환에 대한 자세한 내용은 zillion.field.TYPE_ALLOWED_CONVERSIONS 및 zillion.field.DIALECT_CONVERSIONS 참조하십시오.
각 보고서 요청과 함께 "Ad Hoc"메트릭을 정의 할 수도 있습니다. 아래는 리드 당 메트릭을 즉시 생성하는 예입니다. 이들은 보고서의 범위 내에만 존재하며 이름은 기존 필드와 충돌 할 수 없습니다.
result = wh . execute (
metrics = [
"leads" ,
{ "formula" : "{revenue}/{leads}" , "name" : "my_rpl" }
],
dimensions = [ "partner_name" ]
) 각 보고서 요청과 함께 "Ad Hoc"치수를 정의 할 수도 있습니다. 아래는 즉시 특정 차원 값으로 분할하는 차원을 생성하는 예입니다. 임시 치수는 FormulaDimension S의 서브 클래스이므로 메트릭을 공식 필드로 사용할 수없는 것과 같은 동일한 제한이 있습니다. 이들은 보고서의 범위 내에만 존재하며 이름은 기존 필드와 충돌 할 수 없습니다.
result = wh . execute (
metrics = [ "leads" ],
dimensions = [{ "name" : "partner_is_a" , "formula" : "{partner_name} = 'Partner A'" ]
) Zillion 또한 DataSource 또는 Warehouse Init 동안 데이터베이스에서 임시 테이블의 생성 또는 동기화를 지원합니다. 이를 수행하는 테이블 구성의 예가 여기에 표시됩니다. 테이블 config의 data_url 및 if_exists 매개 변수를 사용하여 SQLite 데이터베이스의 원격 CSV에서 "main.dma_zip"테이블의 동기화 및/또는 생성을 제어합니다. 다른 데이터베이스 유형에서도 마찬가지입니다.
이러한 접근 방식에 대한 잠재적 성능 단점은 특히 창고를 자주 초기화하는 경우 또는 원격 데이터 파일이 큰 경우 분명해야합니다. 전체 스키마 컨트롤을 확보하여 미리 데이터를 동기화하고 작성하는 것이 좋습니다. 그러나이 방법은 특정 시나리오에서 매우 유용 할 수 있습니다.
경고 : 데이터베이스에서 기존 테이블을 덮어 쓰지 않도록주의하십시오!
롤링, 누적 또는 순위 통계를 계산하기 위해 메트릭에 적용 할 수있는 다양한 기술 계산이 있습니다. 예를 들어, 매출에서 5 점 이동 평균을 계산하려면 다음과 같이 새 메트릭을 정의 할 수 있습니다.
{
"name" : " revenue_ma_5 " ,
"type" : " numeric(10,2) " ,
"aggregation" : " sum " ,
"rounding" : 2 ,
"technical" : " mean(5) "
}기술 계산은 결합 된 계층에서 계산되는 반면, "집계"는 데이터 소스 레이어에서 수행됩니다 (따라서 위의 두 가지를 정의해야 함).
속기 기술 문자열이 어떻게 구문 분석되는지에 대한 자세한 내용은 parse_technical_string 코드를 참조하십시오. 지원되는 기술 유형의 전체 목록은 zillion.core.TechnicalTypes 참조하십시오.
기술은 또한 "그룹"과 "모두"라는 두 가지 모드를 지원합니다. 이 모드는 데이터 차원에서 기술 계산을 적용하는 방법을 제어합니다. "그룹"모드에서는 마지막 차원에서 기술을 계산하는 반면, "모든"모드에서는 차원을 고려하지 않고 모든 데이터에서 기술을 계산합니다.
[ "partner_name", "date"와 같은 데이터에 대한 데이터 전반에 걸쳐 "Cumsum"기술을 수행하려고하면 이것의 요점이 더욱 명확 해집니다. "그룹"모드가 사용되는 경우 (대부분의 경우 기본값) 날짜 범위에서 각 파트너 내에서 누적 합계를 수행합니다. "모든"모드가 사용되면 모든 데이터 행에서 누적 합계를 수행합니다. 기술 문자열에 추가하여 모드를 명시 적으로 명시 할 수 있습니다. 즉 "Cumsum : All"또는 "Mean (5) : Group"
민감한 연결 정보를 DataSource 구성에 직접 넣지 않으려면 구성 변수를 활용할 수 있습니다. Zillion Yaml 구성에서 다음과 같이 DATASOURCE_CONTEXTS 섹션을 지정할 수 있습니다.
DATASOURCE_CONTEXTS :
my_ds_name :
user : user123
pass : goodpassword
host : 127.0.0.1
schema : reporting 그런 다음 "my_ds_name"이라는 데이터 소스에 대한 DataSource 구성이 읽히면이 컨텍스트를 사용하여 연결 URL에서 변수를 채울 수 있습니다.
"datasources" : {
"my_ds_name" : {
"connect" : " mysql+pymysql://{user}:{pass}@{host}/{schema} "
...
}
} Warehouse Init에서는 이름별로 DataSources의 기본 우선 순위 주문을 지정할 수 있습니다. 이것은 여러 데이터 소스에 의해 보고서를 만족시킬 수있을 때이 작업이 진행될 것입니다. 목록의 초기에 DataSources 우선 순위가 높습니다. DataSource 로 그룹화 된 더 빠른 집계 테이블 세트를 선호하려는 경우 유용합니다.
wh = Warehouse ( config = config , ds_priority = [ "aggr_ds" , "raw_ds" , ...]) Zillion's 목표는 Sqlalchemy가 지원하는 모든 데이터베이스 기술을 지원하는 것입니다 (아래 그림). 그것은 현재 Zillion 의 지원 및 테스트 수준이 현재 다양하다고 말했다. 특히, 유형 변환, 데이터베이스 반사 및 킬 런 쿼리를 수행하는 기능에는 모두 지원을위한 일부 데이터베이스 별 코드가 필요합니다. 다음 목록에는 알려진 지원 수준이 요약되어 있습니다. 마일리지는 Sqlalchemy가 지원하는 테스트되지 않은 데이터베이스 기술에 따라 다를 수 있습니다 (아직 잘 작동하고 아직 테스트되지 않았습니다). 버그를보고하고 더 많은 지원을 추가하십시오!
SQLALCHEMY에는 많은 인기있는 데이터베이스에 대한 커넥터가 있습니다. Zillion 사용하는 SQL 운영의 간단한 특성을 감안할 때 이들 중 다수를 지원하기위한 장벽은 상당히 낮을 수 있습니다.
위는 결합 된 계층 데이터베이스의 데이터베이스 지원과 다릅니다. 현재 SQLITE만이 거기에 지원됩니다. 대부분의 사용 사례에는 충분하지만 더 많은 옵션이 도로 아래에 추가됩니다.
단일 노드 나 여러 노드에서 멀티 프로세스 시나리오에서 Zillion 실행할 계획이라면 몇 가지 사항이 있습니다.
각 보고서 요청과 함께 즉시 이루어지며 다른 프로세스 또는 노드와의 조정/통신이 필요하지 않기 때문에 여전히 기본 SQLITE In-Memory 결합 레이어 DB를 사용할 수 있습니다.
Zillion Web UI는 실험적인 Chatgpt 플러그인을 포함하는 Zillion 용 Demo UI 및 Web API입니다. 설치 및 프로젝트 구조에 대한 자세한 내용은 ReadMe를 참조하십시오. 이 코드는 테스트 및 광택에 대해 가볍지 만 최신 브라우저에서 작동 할 것으로 예상됩니다. 또한 Chatgpt 플러그인은 현재 매우 느리기 때문에 현재는 대부분 재미 있고 유용하지 않습니다.
보다 철저한 문서는 여기에서 찾을 수 있습니다. 테스트 디렉토리 또는 API 참조를 지워서 지식을 보충 할 수 있습니다.
자세한 내용은 기고 안내서를 참조하십시오. 영감을 찾고 있다면 추가 데이터베이스 기술에 대한 지원 및 테스트를 추가하는 것이 큰 도움이 될 것입니다.
