Zillion เป็นเครื่องมือสร้างแบบจำลองข้อมูลและการวิเคราะห์ที่อนุญาตให้รวมและวิเคราะห์ข้อมูลจากแหล่งข้อมูลหลายตัวผ่าน API อย่างง่าย มันทำหน้าที่เป็นเลเยอร์ความหมายที่อยู่ด้านบนของข้อมูลของคุณเขียน SQL เพื่อให้คุณไม่จำเป็นต้องและสลักเกลียวลงบนโครงสร้างพื้นฐานฐานข้อมูลที่มีอยู่ได้อย่างง่ายดายผ่าน Sqlalchemy Core ส่วนขยาย Zillion NLP มีการสนับสนุนการทดลองสำหรับการสอบถามภาษาธรรมชาติที่ขับเคลื่อนด้วย 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 : ตารางข้อเท็จจริงที่อาจมีตัวชี้วัดและมิติ/แอตทริบิวต์ที่เกี่ยวข้องตารางมิติมักจะคงที่หรือเพิ่มขึ้นอย่างช้าๆในแง่ของการนับแถวและมีคุณลักษณะที่เชื่อมโยงกับคีย์หลัก ตัวอย่างทั่วไปบางอย่างคือรายการรหัสไปรษณีย์ของสหรัฐอเมริกาหรือไดเรกทอรี บริษัท/พันธมิตร
โดยทั่วไปตารางตัวชี้วัดมักจะทำธุรกรรมในธรรมชาติมากขึ้น ตัวอย่างทั่วไปบางอย่างจะเป็นบันทึกสำหรับคำขอเว็บการขายอีคอมเมิร์ซหรือประวัติราคาในตลาดหุ้น
หากคุณต้องการลึกลงไปในการสร้างแบบจำลองมิติและเทคนิคการสืบค้น Across ของ Zillion ฉันขอแนะนำให้อ่านหนังสือของ Ralph Kimball เกี่ยวกับคลังข้อมูล
เพื่อสรุปการค้นหาแบบสืบค้นการเจาะแบบฟอร์มหนึ่งหรือมากกว่าหนึ่งคำสอบถามเพื่อตอบสนองการร้องขอรายงานสำหรับ metrics ที่อาจมีอยู่ในแหล่งข้อมูลและ/หรือตารางหลายรายการที่ธัญพืช dimension เฉพาะ
Zillion รองรับการตั้งค่าคลังสินค้าที่ยืดหยุ่นเช่น Snowflake หรือ Star Schemas แม้ว่ามันจะไม่จู้จี้จุกจิก คุณสามารถระบุความสัมพันธ์ของตารางผ่านเชื้อสายแม่ลูกและ Zillion ยังสามารถอนุมานการเข้าร่วมที่ยอมรับได้ตามการมีอยู่ของคีย์หลักของตารางมิติ Zillion ไม่สนับสนุนความสัมพันธ์แบบหลายต่อหลายครั้งในเวลานี้แม้ว่าสถานการณ์ที่เน้นการวิเคราะห์ส่วนใหญ่ควรจะสามารถแก้ไขได้โดยการเพิ่มมุมมองลงในแบบจำลองหากจำเป็น
รายงาน Zillion สามารถคิดได้ว่าทำงานในสองชั้น:
DataSource Layer : SQL Queries เทียบกับแหล่งข้อมูลของคลังสินค้าCombined Layer : คิวรี 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 ยังมีสคริปต์ผู้ช่วยในการ boostrap ไฟล์กำหนดค่าแหล่งข้อมูลสำหรับฐานข้อมูลที่มีอยู่ ดู zillion.scripts.bootstrap_datasource_config.py สคริปต์ bootstrap ต้องใช้ URL การเชื่อมต่อ/ฐานข้อมูลและไฟล์เอาต์พุตเป็นอาร์กิวเมนต์ ดู --help ท์พุทสำหรับตัวเลือกเพิ่มเติมรวมถึงการตั้งค่าสถานะทางเลือก --nlp ที่ใช้ประโยชน์จาก OpenAI เพื่ออนุมานข้อมูลการกำหนดค่าเช่นประเภทคอลัมน์ประเภทตารางและความสัมพันธ์ของตาราง คุณสมบัติ 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 DataFrameเมื่อเปรียบเทียบกับการเขียน SQL จะมีประโยชน์ในการคิดว่ามิติเป็นคอลัมน์เป้าหมายของ กลุ่มโดย คำสั่ง SQL คิดว่าตัวชี้วัดเป็นคอลัมน์ที่คุณ รวบรวม คิดว่าเกณฑ์เป็น ประโยคที่ เกณฑ์ของคุณถูกนำไปใช้ในการสืบค้น SQL เลเยอร์ DataSource
ReportResult มี dataframe pandas ที่มีขนาดเป็นดัชนีและตัวชี้วัดเป็นคอลัมน์
มี 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 (ฐานข้อมูลเวกเตอร์) และค่าต่อไปนี้ที่ตั้งไว้ในไฟล์กำหนด Zillion ของคุณ:
EMBEDDINGS จะถูกผลิตและเก็บไว้ทั้งใน QDRANT และแคชท้องถิ่น ฐานข้อมูลเวกเตอร์จะเริ่มต้นในครั้งแรกที่คุณพยายามใช้สิ่งนี้โดยการวิเคราะห์ฟิลด์ทั้งหมดในคลังสินค้าของคุณ ตัวอย่างไฟล์ Docker ที่จะเรียกใช้ Qdrant มีให้ในรูทของ repo นี้
คุณมีการควบคุมวิธีการฝังฟิลด์ กล่าวคือในการกำหนดค่าสำหรับฟิลด์ใด ๆ ที่คุณสามารถเลือกได้ว่าจะยกเว้นฟิลด์จาก Embeddings หรือแทนที่ที่ฝังแผนที่ไปยังฟิลด์นั้นหรือไม่ ฟิลด์ทั้งหมดรวมอยู่ในค่าเริ่มต้น ตัวอย่างต่อไปนี้จะไม่รวมฟิลด์ net_revenue จากการถูกฝังและการร้องขอตัวชี้ revenue ของแผนที่ไปยังฟิลด์ 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
}
}
} ,นอกจากนี้คุณยังสามารถยกเว้นฟิลด์ผ่านการตั้งค่าการกำหนดค่าระดับคลังสินค้าต่อไปนี้:
{
"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 ในกรณีที่มันอาจทำให้ฟิลด์ที่มีชื่ออยู่ในทำนองเดียวกัน เมื่อใดก็ตามที่คุณปรับฟิลด์ที่ไม่รวมอยู่ในฟิลด์คุณจะต้องบังคับให้มีการพักผ่อนหย่อนใจของคอลเลกชัน Embeddings ของคุณโดยใช้ force_recreate Flag บน Warehouse.init_embeddings
หมายเหตุ: คุณสมบัตินี้อยู่ในช่วงเริ่มต้น มันมีประโยชน์จะขึ้นอยู่กับคุณภาพของทั้งแบบสอบถามอินพุตและรูปแบบข้อมูลของคุณ (เช่นชื่อฟิลด์ที่ดี)!
นอกเหนือจากการกำหนดค่าโครงสร้างของ Warehouse ของคุณซึ่งจะกล่าวถึงเพิ่มเติมด้านล่าง Zillion มีการกำหนดค่าทั่วโลกเพื่อควบคุมการตั้งค่าพื้นฐานบางอย่าง สภาพแวดล้อม ZILLION_CONFIG var สามารถชี้ไปที่ไฟล์กำหนดค่า YAML ดู examples/sample_config.yaml สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับค่าใดที่สามารถตั้งค่าได้ สภาพแวดล้อม vars นำหน้าด้วย zillion_ สามารถแทนที่การตั้งค่าการกำหนดค่า (เช่น zillion_db_url จะแทนที่ db_url)
ฐานข้อมูลที่ใช้ในการจัดเก็บข้อมูลจำเพาะรายงาน Zillion สามารถกำหนดค่าได้โดยการตั้งค่า DB_URL ในการกำหนดค่า Zillion ของคุณเป็นสตริงการเชื่อมต่อฐานข้อมูลที่ถูกต้อง โดยค่าเริ่มต้นจะใช้ SQLite db in /tmp
ด้านล่างเราจะเดินผ่านรูปแบบข้อมูลการขายสมมุติฐานที่แสดงให้เห็นถึงการกำหนด DataSource พื้นฐานและการกำหนด Warehouse จากนั้นแสดงรายงานตัวอย่างบางอย่าง ข้อมูลเป็นฐานข้อมูล SQLite อย่างง่ายซึ่งเป็นส่วนหนึ่งของรหัสทดสอบ Zillion สำหรับการอ้างอิงสคีมามีดังนี้:
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 อาจถูกสร้างขึ้นจากการกำหนดค่า JSON หรือ YAML ที่กำหนดเขตข้อมูลข้อมูลและตาราง รหัสด้านล่างแสดงให้เห็นว่ามันสามารถทำได้ในรหัสเพียงบรรทัดเดียวหากคุณมีตัวชี้ไปยังการกำหนด Warehouse JSON/YAML
from zillion import Warehouse
wh = Warehouse ( config = "https://raw.githubusercontent.com/totalhack/zillion/master/examples/example_wh_config.json" ) ตัวอย่างการกำหนดค่านี้ใช้ data_url ใน DataSource connect แหล่งข้อมูลที่บอกให้ Zillion ดาวน์โหลดข้อมูลนั้นแบบไดนามิกและเชื่อมต่อกับมันเป็นฐานข้อมูล SQLite สิ่งนี้มีประโยชน์สำหรับตัวอย่างหรือการวิเคราะห์อย่างรวดเร็วแม้ว่าในสถานการณ์ส่วนใหญ่คุณจะใส่สตริงการเชื่อมต่อลงในฐานข้อมูลที่มีอยู่อย่างที่คุณเห็นที่นี่
พื้นฐานของโครงสร้างการกำหนดค่าคลังสินค้า Zillion's มีดังนี้:
การกำหนดค่า Warehouse มีส่วนหลักต่อไปนี้:
metrics : รายการเสริมของการกำหนดค่าตัวชี้วัดสำหรับตัวชี้วัดทั่วโลกdimensions : รายการเสริมของการกำหนดค่ามิติสำหรับขนาดทั่วโลกdatasources : การแม็พของชื่อแหล่งข้อมูลไปยัง DataSource Configs หรือ URL config การกำหนดค่า DataSource มีส่วนหลักต่อไปนี้:
connect : URL การเชื่อมต่อฐานข้อมูลหรือ DICT ของการเชื่อมต่อพารามิเตอร์metrics : รายการเสริมของตัวชี้วัดการกำหนดค่าเฉพาะสำหรับแหล่งข้อมูลนี้dimensions : รายการเสริมของมิติกำหนดค่าเฉพาะสำหรับแหล่งข้อมูลนี้tables : การแม็พของชื่อตารางไปยังตารางการกำหนดค่าหรือ URL configเคล็ดลับ: DataSource และ Table Configs อาจถูกแทนที่ด้วย URL ที่ชี้ไปที่ไฟล์การกำหนดค่าท้องถิ่นหรือระยะไกล
ในตัวอย่างนี้ทั้งสี่ตารางในฐานข้อมูลของเรารวมอยู่ในการกำหนดค่าสองตารางเป็นตารางมิติและสองตารางเป็นตารางเมตริก ตารางมีการเชื่อมโยงผ่านความสัมพันธ์ระหว่างผู้ปกครอง-> เด็ก: พันธมิตรกับแคมเปญและนำไปสู่การขาย บางตารางยังใช้การตั้งค่าสถานะ create_fields เพื่อสร้าง Fields โดยอัตโนมัติบนแหล่งข้อมูลจากคำจำกัดความของคอลัมน์ ตัวชี้วัดและมิติอื่น ๆ มีการกำหนดอย่างชัดเจน
ในการดูโครงสร้างของ Warehouse นี้หลังจาก init คุณสามารถใช้วิธี print_info ซึ่งแสดงตัวชี้วัดขนาดตารางและคอลัมน์ทั้งหมดที่เป็นส่วนหนึ่งของคลังข้อมูลของคุณ:
wh . print_info () # Formatted print of the Warehouse structureสำหรับการดำน้ำที่ลึกซึ้งยิ่งขึ้นของ Schema config โปรดดูเอกสารฉบับเต็ม
ตัวอย่าง: รับยอดขายลูกค้าเป้าหมายและรายได้จากพันธมิตร:
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
"""ตัวอย่าง: เอาต์พุตด้านล่างแสดงโรลอัพในระดับแคมเปญภายในแต่ละพันธมิตรและยังรวมถึงผลรวมที่ระดับพันธมิตรและแคมเปญ
หมายเหตุ: เอาต์พุตมีอักขระพิเศษเพื่อทำเครื่องหมายแถวการหมุนของ DataFrame ที่เพิ่มเข้ามาในผลลัพธ์ วัตถุ 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 ของคุณไว้เนื่องจากรายงานที่บันทึกไว้จะถูกกำหนดขอบเขตของ 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" ]
)หมายเหตุ : หากคุณสร้าง
Warehouseของคุณใน Python จากรายการDataSourcesหรือส่งผ่านในdictสำหรับพารามิเตอร์configบน Init ขณะนี้ไม่มีวิธีในตัวในการส่งออกการกำหนดค่าที่สมบูรณ์ไปยังไฟล์สำหรับการอ้างอิงเมื่อบันทึก
ตัวอย่าง: โหลดและเรียกใช้รายงานจาก ID ข้อมูลจำเพาะ:
result = wh . execute_id ( spec_id ) สิ่งนี้จะถือว่าคุณได้บันทึก ID รายงานนี้ไว้ก่อนหน้านี้ในฐานข้อมูลที่ระบุโดย DB_URL ในการกำหนดค่า Zillion YAML ของคุณ
ตัวอย่าง: ข้าวที่ไม่รองรับ
หากคุณพยายามรายงานที่เป็นไปไม่ได้คุณจะได้รับ UnsupportedGrainException รายงานด้านล่างเป็นไปไม่ได้เพราะมันพยายามที่จะทำลายตัวชี้วัดโอกาสในการขายโดยมิติที่มีอยู่ในตารางเด็กเท่านั้น โดยทั่วไปแล้วโต๊ะเด็กสามารถเข้าร่วมกับผู้ปกครอง (และ "พี่น้อง" ของผู้ปกครอง) เพื่อค้นหามิติ แต่ไม่ใช่วิธีอื่น ๆ
# Fails with UnsupportedGrainException
result = wh . execute (
metrics = [ "leads" ],
dimensions = [ "sale_id" ]
) บางครั้งคุณต้องการฟังก์ชั่นเหมือนคำถามย่อยเพื่อกรองรายงานหนึ่งรายงานไปยังผลลัพธ์ของอื่น ๆ (ซึ่งอาจต้องใช้ธัญพืชที่แตกต่างกัน) Zillion เป็นวิธีที่ง่ายในการทำเช่นนั้นโดยใช้ in report หรือ not in report มีสองวิธีที่ได้รับการสนับสนุนในการระบุรายงานย่อย: ผ่านรหัสข้อมูลจำเพาะของรายงานหรือผ่าน DICT ของรายงานรายงาน
# 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 จะต้องเป็นมิติในรายงานย่อย โปรดทราบว่ารายงานย่อยจะดำเนินการตามเวลาเริ่มต้นวัตถุ Report แทนในระหว่าง execute - เช่นนั้นพวกเขาไม่สามารถฆ่าได้โดยใช้ Report.kill สิ่งนี้อาจเปลี่ยนไปตามถนน
ในตัวอย่างของเราด้านบนการกำหนดค่าของเรารวมถึงตัวชี้วัดที่ใช้สูตรที่เรียกว่า "RPL" ซึ่งเป็นเพียง revenue / leads FormulaMetric รวมตัวชี้วัดและ/หรือมิติอื่น ๆ เพื่อคำนวณตัวชี้วัดใหม่ที่ชั้นรวมของการสืบค้น ไวยากรณ์จะต้องตรงกับฐานข้อมูลเลเยอร์รวมของคุณซึ่งเป็น sqlite ในตัวอย่างของเรา
{
"name" : " rpl " ,
"aggregation" : " mean " ,
"rounding" : 2 ,
"formula" : " {revenue}/{leads} "
} เพื่อความสะดวกแทนที่จะต้องกำหนดตัวชี้วัดสูตรซ้ำ ๆ สำหรับตัวแปรอัตราของตัวชี้วัดหลักซ้ำ ๆ คุณสามารถระบุการกำหนดค่าการวัดตัวหารบนตัวชี้วัดที่ไม่ใช่สูตร ตัวอย่างเช่นบอกว่าคุณมีตัวชี้วัด 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' "
} ตัวอย่างของเรายังรวมถึง "ยอดขาย" ของตัวชี้วัดที่มีการคำนวณค่าผ่านสูตรที่เลเยอร์แหล่งข้อมูลของการสืบค้น หมายเหตุดังต่อไปนี้ในรายการ fields สำหรับพารามิเตอร์ "ID" ในตาราง "Main.sales" สูตรเหล่านี้อยู่ในไวยากรณ์ของเทคโนโลยีฐานข้อมูลฐาน DataSource เฉพาะซึ่งเกิดขึ้นเป็น SQLite ในตัวอย่างของเรา
"fields" : [
" sale_id " ,
{ "name" : " sales " , "ds_formula" : " COUNT(DISTINCT sales.id) " }
] ตัวอย่างของเรายังสร้างมิติจำนวนหนึ่งจากคอลัมน์ "created_at" โดยอัตโนมัติของโอกาสในการขายและตารางการขาย การสนับสนุนสำหรับการแปลงประเภทอัตโนมัติมี จำกัด แต่สำหรับคอลัมน์วันที่/dateTime ในเทคโนโลยี DataSource ที่รองรับคุณจะได้รับความหลากหลายของมิติฟรีด้วยวิธีนี้
ผลลัพธ์ของ wh.print_info จะแสดงขนาดที่เพิ่มขึ้นซึ่งนำหน้าด้วย "lead_" หรือ "sale_" ตามที่ระบุโดย type_conversion_prefix ที่เป็นตัวเลือกในการกำหนดค่าสำหรับแต่ละตาราง ตัวอย่างบางส่วนของมิติที่สร้างขึ้นอัตโนมัติในตัวอย่างคลังสินค้าของเรารวมถึง sale_hour, sale_day_name, sale_month, sale_year ฯลฯ
เพื่อเป็นการเพิ่มประสิทธิภาพในประโยคที่มีการสืบค้นรายงานพื้นฐาน Zillion จะพยายามใช้การแปลงกับค่าเกณฑ์แทนคอลัมน์ ตัวอย่างเช่นโดยทั่วไปจะมีประสิทธิภาพมากกว่าในการสอบถามเป็น my_datetime > '2020-01-01' and my_datetime < '2020-01-02' แทนที่จะเป็น DATE(my_datetime) == '2020-01-01' ความสามารถในการใช้การแปลงกับค่าแทนคอลัมน์จะแตกต่างกันไปตามเทคโนโลยีฟิลด์และ DataSource เช่นกัน
เพื่อป้องกันการแปลงประเภทให้ตั้งค่า skip_conversion_fields เป็น true ในการกำหนดค่า DataSource ของคุณ
ดู 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 ตัวอย่างของการกำหนดค่าตารางที่ทำสิ่งนี้แสดงที่นี่ มันใช้พารามิเตอร์ data_url และ if_exists ของตารางการกำหนดค่าเพื่อควบคุมการซิงค์และ/หรือการสร้างตาราง "main.dma_zip" จากตาราง CSV ระยะไกลในฐานข้อมูล SQLite สามารถทำได้ในประเภทฐานข้อมูลอื่น ๆ ด้วย
ข้อเสียประสิทธิภาพที่อาจเกิดขึ้นกับวิธีการดังกล่าวควรชัดเจนโดยเฉพาะอย่างยิ่งหากคุณเริ่มต้นคลังสินค้าของคุณบ่อยครั้งหรือหากไฟล์ข้อมูลระยะไกลมีขนาดใหญ่ บ่อยครั้งที่การซิงค์และสร้างข้อมูลของคุณก่อนเวลาดังนั้นคุณจึงมีการควบคุมสคีมาที่สมบูรณ์ แต่วิธีนี้อาจมีประโยชน์มากในบางสถานการณ์
คำเตือน : ระวังอย่าเขียนทับตารางที่มีอยู่ในฐานข้อมูลของคุณ!
มีการคำนวณทางเทคนิคที่หลากหลายที่สามารถนำไปใช้กับตัวชี้วัดเพื่อคำนวณการกลิ้งการสะสมหรือสถิติอันดับ ตัวอย่างเช่นในการคำนวณค่าเฉลี่ยเคลื่อนที่ 5 จุดบนรายได้หนึ่งอาจกำหนดตัวชี้วัดใหม่ดังนี้:
{
"name" : " revenue_ma_5 " ,
"type" : " numeric(10,2) " ,
"aggregation" : " sum " ,
"rounding" : 2 ,
"technical" : " mean(5) "
}การคำนวณทางเทคนิคจะถูกคำนวณที่เลเยอร์รวมในขณะที่ "การรวม" จะทำที่เลเยอร์แหล่งข้อมูล (ดังนั้นจึงจำเป็นต้องกำหนดทั้งสองด้านบน)
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีการแยกกลุ่มทางเทคนิค Shorthand ดูรหัส PARSE_TECHNICAL_STRING สำหรับรายการประเภททางเทคนิคที่รองรับทั้งหมดโปรดดู zillion.core.TechnicalTypes
เทคนิคยังรองรับสองโหมด: "กลุ่ม" และ "ทั้งหมด" โหมดควบคุมวิธีการใช้การคำนวณทางเทคนิคในมิติของข้อมูล ในโหมด "กลุ่ม" มันคำนวณทางเทคนิคในมิติสุดท้ายในขณะที่ในโหมด "ทั้งหมด" ในการคำนวณทางเทคนิคในข้อมูลทั้งหมดโดยไม่คำนึงถึงมิติใด ๆ
ประเด็นนี้จะชัดเจนยิ่งขึ้นหากคุณพยายามทำทางเทคนิค "Cumsum" ข้ามข้อมูลที่แยกย่อยโดยบางอย่างเช่น ["Partner_name", "วันที่"] หากใช้โหมด "กลุ่ม" (ค่าเริ่มต้นในกรณีส่วนใหญ่) มันจะทำเงินรวมสะสม ภายใน แต่ละพันธมิตรในช่วงวันที่ หากใช้โหมด "ทั้งหมด" มันจะทำผลรวมสะสมในทุก ๆ แถวข้อมูล คุณสามารถชัดเจนเกี่ยวกับโหมดโดยผนวกกับสตริงทางเทคนิค: เช่น "Cumsum: ทั้งหมด" หรือ "หมายถึง (5): กลุ่ม"
หากคุณต้องการหลีกเลี่ยงการใส่ข้อมูลการเชื่อมต่อที่ละเอียดอ่อนโดยตรงในการกำหนดค่า DataSource ของคุณคุณสามารถใช้ประโยชน์จากตัวแปรการกำหนดค่า ในการกำหนดค่า Zillion yaml ของคุณคุณสามารถระบุส่วน DATASOURCE_CONTEXTS ดังต่อไปนี้:
DATASOURCE_CONTEXTS :
my_ds_name :
user : user123
pass : goodpassword
host : 127.0.0.1
schema : reporting จากนั้นเมื่อการกำหนดค่า DataSource ของคุณสำหรับแหล่งข้อมูลชื่อ "my_ds_name" ถูกอ่านมันสามารถใช้บริบทนี้เพื่อเติมตัวแปรใน URL การเชื่อมต่อของคุณ:
"datasources" : {
"my_ds_name" : {
"connect" : " mysql+pymysql://{user}:{pass}@{host}/{schema} "
...
}
} บน Warehouse เริ่มต้นคุณสามารถระบุลำดับความสำคัญเริ่มต้นสำหรับแหล่งข้อมูลตามชื่อ สิ่งนี้จะเข้ามาเล่นเมื่อรายงานจะได้รับความพึงพอใจจากแหล่งข้อมูลหลายแห่ง DataSources ก่อนหน้านี้ในรายการจะมีความสำคัญสูงกว่า สิ่งนี้จะมีประโยชน์หากคุณต้องการให้ชุดของตารางรวมที่เร็วขึ้นและรวมที่จัดกลุ่มใน DataSource
wh = Warehouse ( config = config , ds_priority = [ "aggr_ds" , "raw_ds" , ...]) เป้าหมาย Zillion's คือการสนับสนุนเทคโนโลยีฐานข้อมูลใด ๆ ที่ Sqlalchemy รองรับ (ในภาพด้านล่าง) ที่กล่าวว่าระดับการสนับสนุนและการทดสอบใน Zillion นั้นแตกต่างกันไปในขณะนี้ โดยเฉพาะอย่างยิ่งความสามารถในการแปลงการแปลงฐานข้อมูลการสะท้อนฐานข้อมูลและฆ่าคิวรีที่เรียกใช้ทั้งหมดต้องการรหัสเฉพาะฐานข้อมูลสำหรับการสนับสนุน รายการต่อไปนี้สรุประดับการสนับสนุนที่รู้จัก ไมล์สะสมของคุณอาจแตกต่างกันไปตามเทคโนโลยีฐานข้อมูลที่ยังไม่ผ่านการทดสอบที่ Sqlalchemy รองรับ (อาจใช้งานได้ดีเพียงแค่ยังไม่ได้ทดสอบ) โปรดรายงานข้อบกพร่องและความช่วยเหลือเพิ่มการสนับสนุนเพิ่มเติม!
Sqlalchemy มีตัวเชื่อมต่อไปยังฐานข้อมูลยอดนิยมมากมาย อุปสรรคในการสนับสนุนสิ่งเหล่านี้จำนวนมากน่าจะค่อนข้างต่ำเนื่องจากลักษณะที่เรียบง่ายของการดำเนินงาน SQL Zillion ใช้

โปรดทราบว่าด้านบนนั้นแตกต่างจากการสนับสนุนฐานข้อมูลสำหรับฐานข้อมูลเลเยอร์รวม ปัจจุบันมีเพียง SQLite เท่านั้นที่ได้รับการสนับสนุนที่นั่น นั่นควรจะเพียงพอสำหรับกรณีการใช้งานส่วนใหญ่ แต่จะเพิ่มตัวเลือกเพิ่มเติมลงบนถนน
หากคุณวางแผนที่จะเรียกใช้ Zillion ในสถานการณ์หลายกระบวนการไม่ว่าจะในโหนดเดียวหรือในหลายโหนดมีสองสิ่งที่ควรพิจารณา:
โปรดทราบว่าคุณยังสามารถใช้ SQLite ในหน่วยความจำเริ่มต้น DB แบบรวมโดยไม่มีปัญหาเนื่องจากมีการร้องขอรายงานแต่ละครั้งและไม่จำเป็นต้องมีการประสานงาน/การสื่อสารกับกระบวนการหรือโหนดอื่น ๆ
Zillion Web UI เป็น Demo UI และ Web API สำหรับ Zillion ซึ่งรวมถึงปลั๊กอิน chatgpt ทดลอง ดู ReadMe ที่นั่นสำหรับข้อมูลเพิ่มเติมเกี่ยวกับการติดตั้งและโครงสร้างโครงการ โปรดทราบว่ารหัสมีน้ำหนักเบาในการทดสอบและขัด แต่คาดว่าจะทำงานในเบราว์เซอร์ที่ทันสมัย ปลั๊กอิน CHATGPT นั้นค่อนข้างช้าในขณะนี้ดังนั้นในขณะนี้ส่วนใหญ่เพื่อความสนุกสนานและไม่เป็นประโยชน์
สามารถพบเอกสารที่ละเอียดยิ่งขึ้นได้ที่นี่ คุณสามารถเสริมความรู้ของคุณได้โดยการอ่านไดเรกทอรีการทดสอบหรือการอ้างอิง API
โปรดดูคู่มือการสนับสนุนสำหรับข้อมูลเพิ่มเติม หากคุณกำลังมองหาแรงบันดาลใจการเพิ่มการสนับสนุนและการทดสอบสำหรับเทคโนโลยีฐานข้อมูลเพิ่มเติมจะเป็นความช่วยเหลือที่ดี