zillion
v0.12.0
Zillion هي أداة لنمذجة البيانات والتحليلات التي تتيح الجمع بين البيانات وتحليلها من مواد بيانات متعددة من خلال واجهة برمجة تطبيقات بسيطة. إنه بمثابة طبقة دلالية أعلى بياناتك ، ويكتب SQL حتى لا تضطر إلى ذلك ، ويقوم بسهولة بالمسامير على البنية التحتية لقاعدة البيانات الحالية عبر SQLalChemy Core. يتمتع امتداد Zillion NLP بدعم تجريبي للاستعلام عن اللغة الطبيعية التي تعمل بمنظمة العفو الدولية وتكوين المستودعات.
مع Zillion يمكنك:
تحذير : هذا المشروع في ولاية ألفا ويخضع للتغيير. يرجى الاختبار بعناية لاستخدام الإنتاج والإبلاغ عن أي مشاكل.
$ pip install zillion
or
$ pip install zillion[nlp] يهدف ما يلي إلى تقديم نظرة عامة سريعة على بعض النظريات والتسمية المستخدمة في مستودع البيانات مع Zillion والتي ستكون مفيدة إذا كنت أحدث في هذا المجال. يمكنك أيضًا التخطي أدناه للحصول على مثال للاستخدام أو خيارات إنشاء مستودع/مستودع/بيانات.
باختصار: يكتب Zillion SQL لك ويجعل البيانات متاحة من خلال واجهة برمجة تطبيقات بسيطة للغاية:
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 : جداول الحقائق التي قد تحتوي على مقاييس وبعض الأبعاد/السمات ذات الصلةغالبًا ما تكون جداول الأبعاد ثابتة أو تنمو ببطء من حيث عدد الصفوف وتحتوي على سمات مرتبطة بالمفتاح الأساسي. بعض الأمثلة الشائعة هي قوائم الرموز البريدية الأمريكية أو أدلة الشركة/الشريك.
الجداول المتري هي عمومًا أكثر معاملات في الطبيعة. بعض الأمثلة الشائعة هي سجلات لطلبات الويب أو مبيعات التجارة الإلكترونية أو تاريخ سعر سوق الأسهم.
إذا كنت ترغب حقًا في التعمق في النمذجة الأبعاد وتقنية الاستعلام عن الحفر التي يستخدمها Zillion ، أوصي بقراءة كتاب Ralph Kimball حول تخزين البيانات.
لتلخيص ، تشكل الاستعلام عن درجات الحفر استفسارًا واحدًا أو أكثر لتلبية طلب تقرير metrics التي قد توجد عبر عدة بيانات و/أو جداول في حبة dimension معينة.
يدعم Zillion إعدادات المستودعات المرنة مثل Snowflake أو STAR Schemas ، على الرغم من أنها ليست من الصعب إرضاءها. يمكنك تحديد علاقات الجدول من خلال نسب الوالدين والطفل ، ويمكن Zillion أيضًا استنتاج الوصلات المقبولة بناءً على وجود مفاتيح جدول الأبعاد. لا تدعم Zillion العلاقات بين العديد من العدد في هذا الوقت ، على الرغم من أن معظم السيناريوهات التي تركز على التحليلات يجب أن تكون قادرة على التغلب على ذلك عن طريق إضافة طرق عرض إلى النموذج إذا لزم الأمر.
يمكن اعتبار تقارير Zillion على أنها تعمل في طبقتين:
DataSource Layer : استفسارات SQL ضد بيانات بيانات المستودعCombined Layer : استعلام SQL النهائي مقابل البيانات المدمجة من طبقة مصدر البياناتالطبقة المدمجة هي مجرد قاعدة بيانات SQL أخرى (SQLite في الذاكرة بشكل افتراضي) يتم استخدامها لربط بيانات مصدر البيانات معًا وتطبيق بعض الميزات الإضافية مثل Rollups ومرشحات الصفوف وحدود الصفوف والفرز والمحوبين والخابات التقنية.
هناك طرق متعددة لتهيئة المستودع بسرعة من ملف محلي أو بعيد:
# 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 . يتطلب البرنامج النصي BootStrap عنوان URL للاتصال/قاعدة البيانات وملف الإخراج كوسائط. راجع --help لمزيد من الخيارات ، بما في ذلك علامة --nlp الاختيارية التي تستفيد من Openai لاستنتاج معلومات التكوين مثل أنواع الأعمدة وأنواع الجدول وعلاقات الجدول. تتطلب ميزة NLP تثبيت امتداد NLP بالإضافة إلى المجموعة التالية في ملف Zillion Config الخاص بك:
الغرض الرئيسي من 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 SQL DataSource.
يحتوي ReportResult على DataFrame Pandas مع الأبعاد مثل الفهرس والمقاييس كأعمدة.
يقال إن Report يحتوي على grain ، والتي تحدد الأبعاد التي يجب أن يكون كل مقياس قادرًا على الانضمام إليها من أجل تلبية متطلبات Report . grain هي مزيج من جميع الأبعاد ، بما في ذلك تلك المشار إليها في المعايير أو في صيغ مترية. في المثال أعلاه ، ستكون grain {date, partner} . يجب أن يكون كل من "الإيرادات" و "العملاء المتوقعين" قادرين على الانضمام إلى تلك الأبعاد لهذا التقرير.
يمكن أن تستغرق هذه المفاهيم وقتًا للالتفاف ، ومن الواضح أنها تختلف مع تفاصيل نموذج البيانات الخاص بك ، لكنك ستصبح أكثر دراية بها حيث تبدأ في تجميع التقارير مقابل مستودعات البيانات الخاصة بك.
مع امتداد NLP ، يتمتع Zillion بدعم تجريبي للاستعلام عن اللغة الطبيعية لمستودع البيانات الخاص بك. على سبيل المثال:
result = warehouse . execute_text ( "revenue and leads by date last month" )
print ( result . df ) # Pandas DataFrame تتطلب ميزة NLP هذه مثيلًا تشغيلًا لـ QDrant (قاعدة بيانات المتجه) والقيم التالية المحددة في ملف التكوين Zillion الخاص بك:
سيتم إنتاج التضمينات وتخزينها في كل من Qdrant وذاكرة التخزين المؤقت المحلية. سيتم تهيئة قاعدة بيانات المتجه في المرة الأولى التي تحاول فيها استخدام هذا من خلال تحليل جميع الحقول في المستودع الخاص بك. يتم توفير مثال على ملف Docker لتشغيل QDrant في جذر هذا الريبو.
لديك بعض السيطرة على كيفية تضمين الحقول. وهي في التكوين لأي حقل ، يمكنك اختيار ما إذا كنت تريد استبعاد حقل من التضمينات أو تجاوز أي خريطة التضمينات لهذا الحقل. يتم تضمين جميع الحقول بشكل افتراضي. من شأن المثال التالي استبعاد حقل 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 في الحالات التي قد تخلط فيها الحقول المسماة بالمثل. في أي وقت تقوم فيه بالتعديل الذي يتم استبعاد الحقول التي سترغب في إجبارها على الترفيه عن مجموعة التضمين الخاصة بك باستخدام علامة force_recreate على Warehouse.init_embeddings .
ملاحظة: هذه الميزة في مهدها. تعتمد الفائدة على جودة كل من استعلام الإدخال ونموذج البيانات الخاص بك (أي أسماء الحقول الجيدة)!
بالإضافة إلى تكوين بنية Warehouse الخاص بك ، والذي سيتم مناقشته بشكل أكبر أدناه ، لدى Zillion تكوين عالمي للتحكم في بعض الإعدادات الأساسية. يمكن لبيئة ZILLION_CONFIG Var أن تشير إلى ملف تكوين YAML. راجع examples/sample_config.yaml لمزيد من التفاصيل حول القيم التي يمكن تعيينها. يمكن أن تتجاوز البيئة المسبقة مع Zillion_ إعدادات التكوين (أي Zillion_DB_URL ستجاوز DB_URL).
يمكن تكوين قاعدة البيانات المستخدمة لتخزين مواصفات تقرير Zillion عن طريق تعيين قيمة DB_URL في تكوين Zillion الخاص بك إلى سلسلة اتصال قاعدة بيانات صالحة. بشكل افتراضي ، يتم استخدام SQLite DB في /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" ) يستخدم هذا المثال config a data_url في معلومات connect DataSource به التي تخبر Zillion بتنزيل تلك البيانات ديناميكيًا والاتصال بها كقاعدة بيانات SQLite. هذا مفيد للأمثلة السريعة أو التحليل ، على الرغم من أنك في معظم السيناريوهات ، ستضع سلسلة اتصال على قاعدة بيانات موجودة كما ترى هنا
أساسيات بنية تكوين مستودعات Zillion's هي كما يلي:
يحتوي تكوين Warehouse على الأقسام الرئيسية التالية:
metrics : قائمة اختيارية للتكوينات المترية للمقاييس العالميةdimensions : قائمة اختيارية لتكوينات الأبعاد للأبعاد العالميةdatasources : تعيين أسماء مصدر البيانات إلى تكوينات DataSource أو تكوين عناوين URL يحتوي تكوين DataSource على الأقسام الرئيسية التالية:
connect : عنوان URL لاتصال قاعدة البيانات أو قوله من معاملات الاتصالmetrics : قائمة اختيارية للتكوينات المترية الخاصة بمصاعد البيانات هذهdimensions : قائمة اختيارية للبعيد تهيئة خاصة بمصاعد البيانات هذهtables : تعيين أسماء الجدول إلى تكوينات الجدول أو تكوين عناوين URLنصيحة: قد يتم استبدال تكوينات DataSource and Table بعنوان URL الذي يشير إلى ملف التكوين المحلي أو عن بُعد.
في هذا المثال ، يتم تضمين جميع الجداول الأربعة في قاعدة البيانات الخاصة بنا في التكوين ، واثنان من الجداول الأبعاد واثنين من الجداول المتري. يتم ربط الجداول من خلال علاقة الوالدين-> شركاء الحملات ، ويؤدي إلى المبيعات. تستخدم بعض الجداول أيضًا علامة create_fields لإنشاء Fields تلقائيًا على بيانات البيانات من تعريفات الأعمدة. يتم تعريف المقاييس والأبعاد الأخرى بشكل صريح.
لعرض هيكل هذا Warehouse بعد init ، يمكنك استخدام طريقة 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
"""مثال: يوضح الإخراج أدناه Rollups على مستوى الحملة داخل كل شريك ، وأيضًا مجموعة من الإجماليات على مستوى الشريك والحملة.
ملاحظة: يحتوي الإخراج على حرف خاص لوضع علامة على صفوف Rollup 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 لمزيد من المعلومات حول سلوك Rollup المدعوم.
مثال: احفظ مواصفات تقرير (وليس البيانات):
أولاً ، يجب عليك التأكد من حفظ 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لـconfigParam على init ، فلا توجد حاليًا وسيلة مدمجة لإخراج تكوين كامل إلى ملف للرجوع إليه عند حفظه.
مثال: تحميل وتشغيل تقرير من معرف المواصفات:
result = wh . execute_id ( spec_id ) هذا يفترض أنك قمت بحفظ معرف التقرير هذا سابقًا في قاعدة البيانات المحددة بواسطة DB_URL في تكوين Zillion yaml الخاص بك.
مثال: الحبوب غير المدعومة
إذا حاولت تقريرًا مستحيلًا ، فستحصل على UnsupportedGrainException . التقرير أدناه مستحيل لأنه يحاول تحطيم مقياس العملاء المتوقعين ببعد موجود فقط في طاولة الطفل. بشكل عام ، يمكن لجداول الأطفال الانضمام إلى الآباء (و "الأشقاء" من الآباء) لإيجاد أبعاد ، ولكن ليس العكس.
# Fails with UnsupportedGrainException
result = wh . execute (
metrics = [ "leads" ],
dimensions = [ "sale_id" ]
) في بعض الأحيان ، تحتاج إلى وظائف تشبه الإسماع الفرعي من أجل تصفية تقرير واحد إلى نتائج البعض الآخر (ربما يتطلب حبة مختلفة). يوفر Zillion طريقة مبسطة للقيام بذلك باستخدام in report not in report . هناك طريقتان مدعومتان لتحديد الإجراء الفرعي: تمرير معرف SPEC التقرير أو تمرير قولات التقرير.
# 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" param في جدول "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 . مثال على تكوين الجدول الذي يقوم بذلك يظهر هنا. يستخدم معاملات 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) "
}يتم حساب الحسابات الفنية في الطبقة المدمجة ، في حين يتم "التجميع" في طبقة مصدر البيانات (وبالتالي تحتاج إلى تحديد كلاهما أعلاه).
لمزيد من المعلومات حول كيفية تحليل السلاسل التقنية المختصرة ، راجع رمز parse_technical_string. للحصول على قائمة كاملة بالأنواع التقنية المدعومة ، انظر zillion.core.TechnicalTypes .
تدعم التقنيات أيضًا وضعين: "المجموعة" و "الكل". يتحكم الوضع في كيفية تطبيق الحساب الفني عبر أبعاد البيانات. في وضع "Group" ، يحسب التقنية عبر البعد الأخير ، بينما في وضع "All" في حساب التقنية عبر جميع البيانات دون أي احترام للأبعاد.
يصبح الهدف من هذا أكثر وضوحًا إذا حاولت القيام بتقنية "Cumsum" عبر البيانات التي تم تقسيمها بواسطة شيء مثل ["Partner_Name" ، "Date"]. إذا تم استخدام وضع "المجموعة" (الافتراضي في معظم الحالات) ، فسوف يقوم بمبالغ تراكمية داخل كل شريك خلال نطاقات التاريخ. إذا تم استخدام وضع "All" ، فسوف يقوم بمجموع تراكمي عبر كل صف بيانات. يمكنك أن تكون صريحًا حول الوضع عن طريق إلحاقه بالسلسلة الفنية: أي "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 ثم عندما يتم قراءة تكوين DataSource الخاص بك للمعلومات المسمى "my_ds_name" ، يمكنه استخدام هذا السياق لملء المتغيرات في عنوان 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 لديه موصلات للعديد من قواعد البيانات الشائعة. من المحتمل أن يكون حاجز دعم العديد من هذه الأشياء منخفضًا للغاية نظرًا للطبيعة البسيطة لعمليات SQL التي تستخدمها Zillion .
لاحظ أن ما سبق يختلف عن دعم قاعدة البيانات لقاعدة بيانات الطبقة المدمجة. حاليا فقط sqlite مدعوم هناك ؛ يجب أن يكون ذلك كافيًا لمعظم حالات الاستخدام ولكن سيتم إضافة المزيد من الخيارات على الطريق.
إذا كنت تخطط لتشغيل Zillion في سيناريو متعدد المعالجة ، سواء في عقدة واحدة أو عبر عقد متعددة ، فهناك بعض الأشياء التي يجب مراعاتها:
لاحظ أنه لا يزال بإمكانك استخدام SQLITE SQLITE في الذاكرة مجتمعة DB دون مشاكل ، حيث يتم تقديمها أثناء الطيران مع كل طلب تقرير ولا يتطلب أي تنسيق/اتصال مع العمليات أو العقد الأخرى.
Zillion Web UI عبارة عن واجهة مستخدم ويب ويب لـ Zillion والتي تتضمن أيضًا مكونًا إضافيًا تجريبيًا ChatGpt. شاهد ReadMe هناك لمزيد من المعلومات حول التثبيت وهيكل المشروع. يرجى ملاحظة أن الرمز خفيف على الاختبار والتلميع ، ولكن من المتوقع أن يعمل في المتصفحات الحديثة. كما أن مكونات chatgpt بطيئة جدًا في الوقت الحالي ، لذلك في الوقت الحالي مفيدًا في الغالب وليس مفيدًا.
يمكن العثور على توثيق أكثر شمولاً هنا. يمكنك استكمال معرفتك من خلال الاطلاع على دليل الاختبارات أو مرجع API.
يرجى الاطلاع على دليل المساهمة لمزيد من المعلومات. إذا كنت تبحث عن الإلهام ، فإن إضافة الدعم واختبارات تقنيات قاعدة البيانات الإضافية سيكون مساعدة كبيرة.
