zillion
v0.12.0
Zillion adalah alat pemodelan data dan analitik yang memungkinkan menggabungkan dan menganalisis data dari beberapa sumber data melalui API sederhana. Ini bertindak sebagai lapisan semantik di atas data Anda, menulis SQL sehingga Anda tidak perlu melakukannya, dan dengan mudah mengikat infrastruktur basis data yang ada melalui inti SQLalchemy. Zillion NLP Extension memiliki dukungan eksperimental untuk kueri bahasa alami bertenaga AI dan konfigurasi gudang.
Dengan Zillion Anda bisa:
PERINGATAN : Proyek ini dalam keadaan alpha dan dapat berubah. Harap uji dengan cermat untuk penggunaan produksi dan laporkan masalah apa pun.
$ pip install zillion
or
$ pip install zillion[nlp] Berikut ini dimaksudkan untuk memberikan gambaran cepat beberapa teori dan nomenklatur yang digunakan dalam pergudangan data dengan Zillion yang akan berguna jika Anda lebih baru di bidang ini. Anda juga dapat melewatkan di bawah ini untuk contoh penggunaan atau gudang/data pembuatan DataSource.
Singkatnya: Zillion menulis SQL untuk Anda dan membuat data dapat diakses melalui API yang sangat sederhana:
result = warehouse . execute (
metrics = [ "revenue" , "leads" ],
dimensions = [ "date" ],
criteria = [
( "date" , ">" , "2020-01-01" ),
( "partner" , "=" , "Partner A" )
]
) Dalam Zillion ada dua jenis Fields utama yang akan digunakan dalam permintaan laporan Anda:
Dimensions : Atribut data yang digunakan untuk pelabelan, pengelompokan, dan pemfilteranMetrics : Fakta dan Langkah -langkah yang dapat dipecah sepanjang dimensi Field merangkum konsep kolom dalam data Anda. Misalnya, Anda mungkin memiliki Field yang disebut "pendapatan". Field itu dapat terjadi di beberapa sumber data atau mungkin dalam beberapa tabel dalam satu sumber data. Zillion memahami bahwa semua kolom itu mewakili konsep yang sama, dan dapat mencoba menggunakan salah satu dari mereka untuk memenuhi laporan yang meminta "pendapatan".
Demikian juga ada dua jenis tabel utama yang digunakan untuk menyusun gudang Anda:
Dimension Tables : Tabel Referensi/Atribut yang hanya berisi dimensi terkaitMetric Tables : Tabel fakta yang mungkin mengandung metrik dan beberapa dimensi/atribut terkaitTabel dimensi seringkali statis atau perlahan tumbuh dalam hal jumlah baris dan berisi atribut yang terkait dengan kunci utama. Beberapa contoh umum adalah daftar kode pos AS atau direktori perusahaan/mitra.
Tabel metrik umumnya lebih transaksional. Beberapa contoh umum adalah catatan untuk permintaan web, penjualan eCommerce, atau riwayat harga pasar saham.
Jika Anda benar-benar ingin melakukan pemodelan dimensi dalam dan teknik permintaan bor Zillion dipekerjakan, saya sarankan membaca buku Ralph Kimball tentang pergudangan data.
Untuk meringkas, pembuatan bor-across memerlukan satu atau lebih pertanyaan untuk memenuhi permintaan laporan untuk metrics yang mungkin ada di beberapa sumber data dan/atau tabel pada biji-bijian dimension tertentu.
Zillion mendukung pengaturan gudang yang fleksibel seperti kepingan salju atau skema bintang, meskipun tidak pilih -pilih tentang hal itu. Anda dapat menentukan hubungan tabel melalui garis keturunan orangtua-anak, dan Zillion juga dapat menyimpulkan gabungan yang dapat diterima berdasarkan adanya tombol primer tabel dimensi. Zillion tidak mendukung banyak hubungan banyak ke banyak saat ini, meskipun sebagian besar skenario yang berfokus pada analitik harus dapat mengatasinya dengan menambahkan pandangan ke model jika diperlukan.
Zillion laporan dapat dianggap berjalan dalam dua lapisan:
DataSource Layer : SQL Queries Against The Warehouse's DataSourcesCombined Layer : Kueri SQL akhir terhadap data gabungan dari lapisan DataSourceLapisan gabungan hanyalah database SQL lain (SQLite dalam memori secara default) yang digunakan untuk mengikat data sumber data bersama-sama dan menerapkan beberapa fitur tambahan seperti rollup, filter baris, batas baris, penyortiran, pivot, dan perhitungan teknis.
Ada beberapa cara untuk dengan cepat menginisialisasi gudang dari file lokal atau jarak jauh:
# 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 ) Miliaran juga menyediakan skrip helper untuk boostrap file konfigurasi DataSource untuk database yang ada. Lihat zillion.scripts.bootstrap_datasource_config.py . Skrip Bootstrap membutuhkan URL koneksi/database dan file output sebagai argumen. Lihat --help Output untuk lebih banyak opsi, termasuk bendera --nlp opsional yang memanfaatkan OpenAi untuk menyimpulkan informasi konfigurasi seperti jenis kolom, jenis tabel, dan hubungan tabel. Fitur NLP memerlukan ekstensi NLP untuk diinstal serta set berikut dalam file konfigurasi Zillion Anda:
Tujuan utama Zillion adalah untuk melaksanakan laporan terhadap Warehouse . Pada level tinggi Anda akan menyusun laporan sebagai berikut:
result = warehouse . execute (
metrics = [ "revenue" , "leads" ],
dimensions = [ "date" ],
criteria = [
( "date" , ">" , "2020-01-01" ),
( "partner" , "=" , "Partner A" )
]
)
print ( result . df ) # Pandas DataFrameSaat membandingkan dengan menulis SQL, akan sangat membantu untuk menganggap dimensi sebagai kolom target grup dengan pernyataan SQL. Pikirkan metrik sebagai kolom yang Anda rencanakan . Pikirkan kriteria sebagai klausa di mana . Kriteria Anda diterapkan dalam kueri SQL Lapisan DataSource.
ReportResult memiliki data pandaframe dengan dimensi sebagai indeks dan metrik sebagai kolom.
Sebuah Report dikatakan memiliki grain , yang mendefinisikan dimensi setiap metrik harus dapat bergabung untuk memenuhi persyaratan Report . grain adalah kombinasi dari semua dimensi, termasuk yang dirujuk dalam kriteria atau dalam rumus metrik. Dalam contoh di atas, grain akan menjadi {date, partner} . Baik "pendapatan" dan "lead" harus dapat bergabung dengan dimensi tersebut agar laporan ini dimungkinkan.
Konsep -konsep ini dapat membutuhkan waktu untuk meresap dan jelas bervariasi dengan spesifik model data Anda, tetapi Anda akan menjadi lebih akrab dengan mereka saat Anda mulai menyusun laporan terhadap gudang data Anda.
Dengan ekstensi NLP, Zillion memiliki dukungan eksperimental untuk permintaan bahasa alami dari gudang data Anda. Misalnya:
result = warehouse . execute_text ( "revenue and leads by date last month" )
print ( result . df ) # Pandas DataFrame Fitur NLP ini memerlukan instance qdrant (database vektor) dan nilai -nilai berikut yang diatur dalam file konfigurasi Zillion Anda:
Embeddings akan diproduksi dan disimpan dalam qdrant dan cache lokal. Basis data vektor akan diinisialisasi saat pertama kali Anda mencoba menggunakan ini dengan menganalisis semua bidang di gudang Anda. Contoh file Docker untuk menjalankan qdrant disediakan di root repo ini.
Anda memiliki kontrol atas bagaimana bidang tertanam. Yaitu dalam konfigurasi untuk bidang apa pun, Anda dapat memilih apakah akan mengecualikan bidang dari embeddings atau menimpa peta embeddings mana ke bidang itu. Semua bidang disertakan secara default. Contoh berikut akan mengecualikan bidang net_revenue dari tertanam dan memetakan permintaan metrik revenue ke bidang 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
}
}
} ,Selain itu, Anda juga dapat mengecualikan bidang melalui pengaturan konfigurasi level gudang berikut:
{
"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"
]
}
} ,
...
} Jika sebuah bidang dinonaktifkan pada salah satu level yang disebutkan di atas, ia akan diabaikan. Jenis kontrol ini menjadi berguna karena model data Anda menjadi lebih kompleks dan Anda ingin memandu logika NLP dalam kasus di mana ia dapat membingungkan bidang yang sama bernama. Setiap kali Anda menyesuaikan bidang mana yang dikecualikan, Anda akan ingin memaksa rekreasi koleksi embeddings Anda menggunakan bendera force_recreate di Warehouse.init_embeddings .
Catatan: Fitur ini masih dalam masa pertumbuhan. Kegunaannya akan tergantung pada kualitas kueri input dan model data Anda (yaitu nama bidang yang baik)!
Selain mengkonfigurasi struktur Warehouse Anda, yang akan dibahas lebih lanjut di bawah ini, Zillion memiliki konfigurasi global untuk mengontrol beberapa pengaturan dasar. Lingkungan ZILLION_CONFIG VAR dapat menunjuk ke file konfigurasi YAML. Lihat examples/sample_config.yaml untuk detail lebih lanjut tentang nilai apa yang dapat diatur. Lingkungan VARS Diawali dengan Zillion_ dapat mengganti pengaturan konfigurasi (yaitu Zillion_DB_URL akan mengganti DB_URL).
Basis data yang digunakan untuk menyimpan spesifikasi laporan Zillion dapat dikonfigurasi dengan mengatur nilai DB_URL di konfigurasi Zillion Anda ke string koneksi database yang valid. Secara default, SQLite DB In /TMP digunakan.
Di bawah ini kami akan berjalan melalui model data penjualan hipotetis sederhana yang menunjukkan konfigurasi DataSource dan Warehouse dasar dan kemudian menunjukkan beberapa laporan sampel. Data adalah database SQLITE sederhana yang merupakan bagian dari kode uji Zillion . Untuk referensi, skema ini adalah sebagai berikut:
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
); Warehouse dapat dibuat dari konfigurasi JSON atau YAML yang mendefinisikan bidang, sumber data, dan tabelnya. Kode di bawah ini menunjukkan bagaimana hal itu dapat dilakukan hanya dalam satu baris kode jika Anda memiliki pointer ke konfigurasi Warehouse JSON/YAML.
from zillion import Warehouse
wh = Warehouse ( config = "https://raw.githubusercontent.com/totalhack/zillion/master/examples/example_wh_config.json" ) Contoh konfigurasi ini menggunakan data_url dalam info connect DataSource -nya yang memberi tahu Zillion untuk mengunduh data itu secara dinamis dan terhubung ke sana sebagai database SQLite. Ini berguna untuk contoh atau analisis cepat, meskipun dalam sebagian besar skenario Anda akan meletakkan string koneksi ke database yang ada seperti yang Anda lihat di sini
Dasar -dasar struktur konfigurasi gudang Zillion's adalah sebagai berikut:
Konfigurasi Warehouse memiliki bagian utama berikut:
metrics : Daftar Konfigurasi Metrik Opsional untuk Metrik Globaldimensions : Daftar Konfigurasi Dimensi Opsional untuk Dimensi Globaldatasources : Pemetaan Nama DataSource ke DataSource Configs atau Config URLS Konfigurasi DataSource memiliki bagian utama berikut:
connect : URL Koneksi Database atau Dikt Params Connectmetrics : Daftar Konfigurasi Metrik Opsional khusus untuk DataSource inidimensions : Daftar Konfigurasi Dimensi Opsional khusus untuk DataSource initables : Pemetaan nama tabel ke tabel konfigurasi atau URL konfigurasiKiat: Konfigurasi DataSource dan Tabel juga dapat diganti dengan URL yang menunjuk ke file konfigurasi lokal atau jarak jauh.
Dalam contoh ini keempat tabel dalam database kami termasuk dalam konfigurasi, dua tabel dimensi dan dua sebagai tabel metrik. Tabel tersebut dikaitkan melalui hubungan orang tua-> anak: mitra kampanye, dan mengarah ke penjualan. Beberapa tabel juga menggunakan bendera create_fields untuk secara otomatis membuat Fields pada sumber data dari definisi kolom. Metrik dan dimensi lain didefinisikan secara eksplisit.
Untuk melihat struktur Warehouse ini setelah init Anda dapat menggunakan metode print_info yang menunjukkan semua metrik, dimensi, tabel, dan kolom yang merupakan bagian dari gudang data Anda:
wh . print_info () # Formatted print of the Warehouse structureUntuk menyelam lebih dalam dari skema konfigurasi, silakan lihat dokumen lengkapnya.
Contoh: Dapatkan penjualan, prospek, dan pendapatan oleh mitra:
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
"""Contoh: Mari kita batasi untuk bermitra dan hancur dengan kampanyenya:
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
"""Contoh: Output di bawah ini menunjukkan rollup di tingkat kampanye dalam setiap mitra, dan juga rollup total di tingkat mitra dan kampanye.
CATATAN: Output berisi karakter khusus untuk menandai baris rollup DataFrame yang ditambahkan ke hasilnya. Objek ReporTresult berisi beberapa atribut pembantu untuk mengakses atau memfilter rollup secara otomatis, serta atribut
df_displayyang mengembalikan hasilnya dengan nilai tampilan yang lebih ramah yang diganti dengan karakter khusus. Karakter khusus di bawahnya ditinggalkan di sini untuk ilustrasi, tetapi mungkin tidak membuat hal yang sama dalam semua skenario.
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
""" Lihat Report dokumen untuk informasi lebih lanjut tentang perilaku rollup yang didukung.
Contoh: Simpan spesifikasi laporan (bukan data):
Pertama, Anda harus memastikan bahwa Anda telah menyimpan Warehouse Anda, karena laporan yang disimpan dicakup ke ID Warehouse tertentu. Untuk menyimpan Warehouse , Anda harus menyediakan URL yang menunjuk ke konfigurasi lengkap.
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" ]
)CATATAN : Jika Anda membangun
WarehouseAnda di Python dari daftarDataSources, atau lulus dalamdictuntuk paramconfigpada init, saat ini tidak ada cara bawaan untuk menghasilkan konfigurasi lengkap ke file untuk referensi saat menyimpan.
Contoh: Muat dan jalankan laporan dari ID spec:
result = wh . execute_id ( spec_id ) Ini mengasumsikan Anda telah menyimpan ID laporan ini sebelumnya dalam database yang ditentukan oleh DB_URL dalam konfigurasi Zillion YAML Anda.
Contoh: biji -bijian yang tidak didukung
Jika Anda mencoba laporan yang mustahil, Anda akan mendapatkan ExportedGrainException UnsupportedGrainException . Laporan di bawah ini tidak mungkin karena mencoba memecah metrik lead oleh dimensi yang hanya ada di tabel anak. Secara umum, tabel anak dapat bergabung kembali dengan orang tua (dan "saudara kandung" orang tua) untuk menemukan dimensi, tetapi tidak sebaliknya.
# Fails with UnsupportedGrainException
result = wh . execute (
metrics = [ "leads" ],
dimensions = [ "sale_id" ]
) Kadang-kadang Anda membutuhkan fungsionalitas seperti subquery untuk memfilter satu laporan ke hasil yang lain (yang mungkin membutuhkan butiran yang berbeda). Million memberikan cara yang sederhana untuk melakukannya dengan menggunakan in report laporan kriteria not in report . Ada dua cara yang didukung untuk menentukan subreport: meloloskan ID spesifikasi laporan atau melewati Dikt Laporan Params.
# 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 = [...]
))
]
) Bidang kriteria yang digunakan dalam in report atau not in report harus berupa dimensi di subreport. Perhatikan bahwa subreportasi dieksekusi pada waktu inisialisasi objek Report alih -alih selama execute - karena itu tidak dapat dibunuh menggunakan Report.kill . Ini dapat berubah di jalan.
Dalam contoh kami di atas konfigurasi kami termasuk metrik berbasis formula yang disebut "RPL", yang hanyalah revenue / leads . FormulaMetric menggabungkan metrik dan/atau dimensi lain untuk menghitung metrik baru pada lapisan gabungan kueri. Sintaks harus cocok dengan database lapisan gabungan Anda, yang merupakan sqlite dalam contoh kami.
{
"name" : " rpl " ,
"aggregation" : " mean " ,
"rounding" : 2 ,
"formula" : " {revenue}/{leads} "
} Sebagai kenyamanan, daripada harus berulang kali mendefinisikan metrik rumus untuk varian laju metrik inti, Anda dapat menentukan konfigurasi metrik pembagi pada metrik non-formula. Sebagai contoh, katakanlah Anda memiliki metrik revenue dan ingin membuat varian untuk revenue_per_lead dan revenue_per_sale . Anda dapat mendefinisikan metrik pendapatan Anda sebagai berikut:
{
"name" : " revenue " ,
"type" : " numeric(10,2) " ,
"aggregation" : " sum " ,
"rounding" : 2 ,
"divisors" : {
"metrics" : [
" leads " ,
" sales "
]
}
} Lihat zillion.configs.DivisorsConfigSchema untuk detail lebih lanjut tentang opsi konfigurasi, seperti templat penamaan utama, templat formula, dan pembulatan.
Fitur kenyamanan kecil lainnya adalah kemampuan untuk secara otomatis menghasilkan varian metrik untuk berbagai jenis agregasi dalam konfigurasi bidang tunggal alih -alih di beberapa bidang dalam file konfigurasi Anda. Sebagai contoh, katakanlah Anda memiliki kolom sales di data Anda dan ingin membuat varian untuk sales_mean dan sales_sum . Anda dapat mendefinisikan metrik Anda sebagai berikut:
{
"name" : " sales " ,
"aggregation" : {
"mean" : {
"type" : " numeric(10,2) " ,
"rounding" : 2
},
"sum" : {
"type" : " integer "
}
}
} Gudang yang dihasilkan tidak akan memiliki metrik sales , tetapi sebaliknya akan memiliki sales_mean dan sales_sum . Perhatikan bahwa Anda dapat lebih lanjut menyesuaikan pengaturan untuk bidang yang dihasilkan, seperti mengatur nama khusus, dengan menentukan bahwa dalam pengaturan bersarang untuk jenis agregasi tersebut. Dalam praktiknya ini bukan keuntungan efisiensi yang besar daripada hanya mendefinisikan metrik secara terpisah, tetapi beberapa mungkin lebih suka pendekatan ini.
Dukungan eksperimental ada untuk bidang FormulaDimension juga. FormulaDimension hanya dapat menggunakan dimensi lain sebagai bagian dari formulanya, dan juga dievaluasi dalam database lapisan gabungan. Sebagai pembatasan tambahan, FormulaDimension tidak dapat digunakan dalam kriteria laporan karena filter tersebut dievaluasi pada lapisan DataSource. Contoh berikut mengasumsikan database lapisan gabungan SQLite:
{
"name" : " partner_is_a " ,
"formula" : " {partner_name} = 'Partner A' "
} Contoh kami juga mencakup "penjualan" metrik yang nilainya dihitung melalui rumus di lapisan DataSource kueri. Perhatikan yang berikut dalam daftar fields untuk param "id" di tabel "Main.sales". Rumus -rumus ini berada dalam sintaks teknologi database DataSource tertentu, yang juga merupakan sqlite dalam contoh kami.
"fields" : [
" sale_id " ,
{ "name" : " sales " , "ds_formula" : " COUNT(DISTINCT sales.id) " }
] Contoh kami juga secara otomatis membuat beberapa dimensi dari kolom "create_at" dari lead dan tabel penjualan. Dukungan untuk konversi tipe otomatis terbatas, tetapi untuk kolom tanggal/datetime dalam teknologi DataSource yang didukung, Anda bisa mendapatkan berbagai dimensi secara gratis dengan cara ini.
Output wh.print_info akan menunjukkan dimensi yang ditambahkan, yang diawali dengan "lead_" atau "Sale_" sebagaimana ditentukan oleh opsional type_conversion_prefix di konfigurasi untuk setiap tabel. Beberapa contoh dimensi yang dihasilkan secara otomatis di gudang contoh kami termasuk Sale_Hour, Sale_day_name, Sale_month, Sale_Year, dll.
Sebagai optimasi di mana klausul kueri laporan yang mendasari, Zillion akan mencoba menerapkan konversi ke nilai kriteria alih -alih kolom. Misalnya, umumnya lebih efisien untuk menanyakan sebagai my_datetime > '2020-01-01' and my_datetime < '2020-01-02' bukan DATE(my_datetime) == '2020-01-01' , karena yang terakhir dapat mencegah penggunaan indeks dalam banyak teknologi basis data. Kemampuan untuk menerapkan konversi ke nilai alih -alih kolom bervariasi berdasarkan bidang dan teknologi DataSource juga.
Untuk mencegah konversi tipe, atur skip_conversion_fields ke true pada konfigurasi DataSource Anda.
Lihat zillion.field.TYPE_ALLOWED_CONVERSIONS dan zillion.field.DIALECT_CONVERSIONS untuk detail lebih lanjut tentang konversi yang saat ini didukung.
Anda juga dapat mendefinisikan metrik "ad hoc" dengan setiap permintaan laporan. Di bawah ini adalah contoh yang menciptakan metrik pendapatan per lead dengan cepat. Ini hanya ada dalam lingkup laporan, dan namanya tidak dapat bertentangan dengan bidang yang ada:
result = wh . execute (
metrics = [
"leads" ,
{ "formula" : "{revenue}/{leads}" , "name" : "my_rpl" }
],
dimensions = [ "partner_name" ]
) Anda juga dapat mendefinisikan dimensi "ad hoc" dengan setiap permintaan laporan. Di bawah ini adalah contoh yang menciptakan dimensi yang partisi pada nilai dimensi tertentu dengan cepat. Dimensi ad hoc adalah subclass dari FormulaDimension S dan karenanya memiliki batasan yang sama, seperti tidak dapat menggunakan metrik sebagai bidang formula. Ini hanya ada dalam lingkup laporan, dan namanya tidak dapat bertentangan dengan bidang yang ada:
result = wh . execute (
metrics = [ "leads" ],
dimensions = [{ "name" : "partner_is_a" , "formula" : "{partner_name} = 'Partner A'" ]
) Zillion juga mendukung pembuatan atau sinkronisasi tabel ad hoc di database Anda selama DataSource atau Warehouse Init. Contoh konfigurasi tabel yang melakukan ini ditampilkan di sini. Ini menggunakan Params data_url dan if_exists Table Config untuk mengontrol sinkronisasi dan/atau pembuatan tabel "main.dma_zip" dari CSV jarak jauh dalam database SQLite. Hal yang sama dapat dilakukan dalam jenis database lain juga.
Kelemahan kinerja potensial terhadap pendekatan semacam itu harus jelas, terutama jika Anda sering menginisialisasi gudang Anda atau jika file data jarak jauhnya besar. Seringkali lebih baik untuk menyinkronkan dan membuat data Anda sebelumnya sehingga Anda memiliki kontrol skema lengkap, tetapi metode ini bisa sangat berguna dalam skenario tertentu.
Peringatan : Berhati -hatilah untuk tidak menimpa tabel yang ada di database Anda!
Ada berbagai perhitungan teknis yang dapat diterapkan pada metrik untuk menghitung statistik rolling, kumulatif, atau peringkat. Misalnya, untuk menghitung rata-rata bergerak 5 poin pada pendapatan, orang dapat mendefinisikan metrik baru sebagai berikut:
{
"name" : " revenue_ma_5 " ,
"type" : " numeric(10,2) " ,
"aggregation" : " sum " ,
"rounding" : 2 ,
"technical" : " mean(5) "
}Perhitungan teknis dihitung pada lapisan gabungan, sedangkan "agregasi" dilakukan pada lapisan sumber data (karenanya perlu menentukan keduanya di atas).
Untuk info lebih lanjut tentang bagaimana string teknis steno diuraikan, lihat kode parse_technical_string. Untuk daftar lengkap jenis teknis yang didukung, lihat zillion.core.TechnicalTypes .
Teknis juga mendukung dua mode: "grup" dan "semua". Mode mengontrol cara menerapkan perhitungan teknis di seluruh dimensi data. Dalam mode "Group", ia menghitung teknis melintasi dimensi terakhir, sedangkan dalam mode "All" dalam menghitung teknis di semua data tanpa memperhatikan dimensi.
Inti dari ini menjadi lebih jelas jika Anda mencoba melakukan teknis "cumsum" di seluruh data yang dipecah oleh sesuatu seperti ["mitra_name", "date"]. Jika mode "grup" digunakan (default dalam banyak kasus) itu akan melakukan jumlah kumulatif dalam setiap mitra selama rentang tanggal. Jika mode "semua" digunakan, itu akan melakukan jumlah kumulatif di setiap baris data. Anda dapat eksplisit tentang mode dengan menambahkannya ke string teknis: yaitu "cumsum: all" atau "mean (5): grup"
Jika Anda ingin menghindari menempatkan informasi koneksi sensitif secara langsung di konfigurasi DataSource Anda, Anda dapat memanfaatkan variabel konfigurasi. Di Zillion YAML Config Anda, Anda dapat menentukan bagian DATASOURCE_CONTEXTS sebagai berikut:
DATASOURCE_CONTEXTS :
my_ds_name :
user : user123
pass : goodpassword
host : 127.0.0.1
schema : reporting Kemudian ketika konfigurasi DataSource Anda untuk sumber data bernama "my_ds_name" dibaca, ia dapat menggunakan konteks ini untuk mengisi variabel dalam url koneksi Anda:
"datasources" : {
"my_ds_name" : {
"connect" : " mysql+pymysql://{user}:{pass}@{host}/{schema} "
...
}
} Di Warehouse Init Anda dapat menentukan urutan prioritas default untuk DataSources dengan nama. Ini akan ikut bermain ketika laporan dapat dipenuhi oleh banyak sumber data. DataSources sebelumnya dalam daftar akan menjadi prioritas yang lebih tinggi. Ini akan berguna jika Anda ingin mendukung satu set tabel agregat yang lebih cepat yang dikelompokkan dalam DataSource .
wh = Warehouse ( config = config , ds_priority = [ "aggr_ds" , "raw_ds" , ...]) Tujuan Zillion's adalah untuk mendukung teknologi basis data apa pun yang didukung Sqlalchemy (gambar di bawah). Yang mengatakan tingkat dukungan dan pengujian di Zillion bervariasi saat ini. Secara khusus, kemampuan untuk melakukan konversi jenis, refleksi basis data, dan membunuh pertanyaan yang berjalan semua memerlukan beberapa kode khusus basis data untuk dukungan. Daftar berikut merangkum tingkat dukungan yang diketahui. Jarak tempuh Anda dapat bervariasi dengan teknologi basis data yang belum teruji yang didukung Sqlalchemy (mungkin berfungsi dengan baik, belum diuji). Harap laporkan bug dan bantu menambahkan lebih banyak dukungan!
Sqlalchemy memiliki konektor ke banyak database populer. Penghalang untuk mendukung banyak dari ini kemungkinan cukup rendah mengingat sifat sederhana dari operasi SQL Zillion penggunaan.
Perhatikan bahwa di atas berbeda dari dukungan basis data untuk database lapisan gabungan. Saat ini hanya SQLite yang didukung di sana; Itu harus cukup untuk sebagian besar kasus penggunaan tetapi lebih banyak opsi akan ditambahkan di jalan.
Jika Anda berencana untuk menjalankan Zillion dalam skenario multiproses, baik pada satu node atau di beberapa node, ada beberapa hal yang perlu dipertimbangkan:
Perhatikan bahwa Anda masih dapat menggunakan DB DB gabungan dalam memori SQLite default tanpa masalah, karena itu dibuat dengan cepat dengan setiap permintaan laporan dan tidak memerlukan koordinasi/komunikasi dengan proses atau node lain.
Zillion Web UI adalah demo UI dan API Web untuk Zillion yang juga mencakup plugin chatgpt eksperimental. Lihat readme di sana untuk info lebih lanjut tentang instalasi dan struktur proyek. Harap dicatat bahwa kode ini ringan pada pengujian dan polesan, tetapi diharapkan bekerja di browser modern. Plugin ChatGPT juga cukup lambat saat ini, jadi saat ini sebagian besar untuk bersenang -senang dan tidak bermanfaat.
Dokumentasi yang lebih menyeluruh dapat ditemukan di sini. Anda dapat melengkapi pengetahuan Anda dengan membaca direktori tes atau referensi API.
Silakan lihat panduan yang berkontribusi untuk informasi lebih lanjut. Jika Anda mencari inspirasi, menambahkan dukungan dan tes untuk teknologi basis data tambahan akan sangat membantu.
