zillion
v0.12.0
Zillion - это инструмент для моделирования данных и аналитики, который позволяет объединять и анализировать данные из нескольких данных с помощью простого API. Он выступает в качестве семантического слоя поверх ваших данных, пишет SQL, поэтому вам не нужно, и легко зажигается на существующую инфраструктуру базы данных через Sqlalchemy Core. Расширение Zillion NLP обладает экспериментальной поддержкой для запросов на естественный язык натурального языка и конфигурации склада.
С Zillion вы можете:
ПРЕДУПРЕЖДЕНИЕ : Этот проект находится в альфа -штате и может быть изменена. Пожалуйста, тщательно протестируйте использование производства и сообщите о любых вопросах.
$ pip install zillion
or
$ pip install zillion[nlp] Следующее предназначено для того, чтобы дать краткий обзор некоторой теории и номенклатуры, используемой в хранилище данных с Zillion , которая будет полезна, если вы новичнее в этой области. Вы также можете пропустить ниже для примера использования или вариантов быстрого создания склада/создания данных.
Короче говоря: 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 : таблицы фактов, которые могут содержать метрики и некоторые связанные измерения/атрибутыТаблицы измерений часто статичны или медленно растут с точки зрения количества строк и содержат атрибуты, связанные с первичным ключом. Некоторые общие примеры будут списками почтовых индексов США или каталогов компании/партнеров.
Метрические таблицы, как правило, более транзакционны по своей природе. Некоторые общие примеры будут записи для веб -запросов, продаж электронной коммерции или истории цен на фондовый рынок.
Если вы действительно хотите углубиться в моделирование размерных и технику запроса на акросс, которую использует Zillion , я рекомендую прочитать книгу Ральфа Кимбалла о хранилище данных.
Подводя итог, подводя итоги, запросы на то, что образуют одно или несколько запросов, для удовлетворения запроса отчета о metrics , которые могут существовать в нескольких данных и/или таблицах в определенном зерне dimension .
Zillion поддерживает гибкие складские установки, такие как снежинка или звездные схемы, хотя это не разборчиво об этом. Вы можете указать отношения на таблице через линию родительского ребенка, и Zillion также может вывести приемлемые соединения на основе наличия первичных ключей таблицы измерений. Zillion не поддерживает отношения многих ко многим в настоящее время, хотя большинство сценариев, ориентированных на аналитику, должны иметь возможность обойти это, добавляя представления в модель, если это необходимо.
Zillion Reports можно рассматривать как бег в двух слоях:
DataSource Layer : SQL -запросы против данных складаCombined Layer : последний SQL -запрос против комбинированных данных с уровня данных DataSourceКомбинированный уровень-это просто еще одна база данных SQL (по умолчанию в памяти по умолчанию), которая используется для связывания данных данных о данных и применения нескольких дополнительных функций, таких как развертывание, фильтры строк, ограничения строк, сортировка, опорные и технические вычисления.
Есть несколько способов быстро инициализации склада из локального или удаленного файла:
# 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 . Скрипт начальной загрузки требует 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 DataSource.
ReportResult имеет пандас 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 (векторная база данных) и следующие значения, установленные в вашем файле Zillion Config:
Встроения будут производиться и храниться в Qdrant и в локальном кеше. Векторная база данных будет инициализирована в первый раз, когда вы попытаетесь использовать это, анализируя все поля на вашем складе. Пример файла Docker для запуска Qdrant приведен в корне этого репо.
У вас есть некоторый контроль над тем, как поля встроены. А именно в конфигурации для любого поля вы можете выбрать, следует ли исключить поле из Entgeddings или переопределить, что встраивает карту в это поле. Все поля включены по умолчанию. В следующем примере будет исключено поле 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 в случаях, когда она может запутать поля аналогично названные. Каждый раз, когда вы корректируете, какие поля исключаются, вы захотите заставить воссоздать свою коллекцию Entgeddings, используя флаг force_recreate на Warehouse.init_embeddings .
Примечание: эта функция находится в зачаточном состоянии. Его полезность будет зависеть от качества как входного запроса, так и вашей модели данных (т.е. хорошие имена поля)!
В дополнение к настройке структуры вашего Warehouse , которая будет обсуждаться ниже, Zillion имеет глобальную конфигурацию для управления некоторыми основными настройками. Среда ZILLION_CONFIG VAR может указывать на файл конфигурации YAML. См. examples/sample_config.yaml для получения более подробной информации о том, какие значения можно установить. Среда VARS, префиксированная Zillion_ может переопределить настройки конфигурации (то есть Zillion_DB_URL будет переопределять DB_URL).
База данных, используемая для хранения спецификаций отчета о Zillion, можно настроить, установив значение DB_URL в вашей Zillion Config на действительную строку подключения к базе данных. По умолчанию используется 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 : отображение имен данных в конфигурации данных или URL -адреса конфигурации или конфигурации Конфигурация DataSource имеет следующие основные разделы:
connect : URL -адрес подключения базы данных или Dict of Connect Paramsmetrics : необязательный список метрических конфигураций, специфичных для этого данныхdimensions : необязательный список конфигураций измерений, специфичных для этого данныхtables : отображение имен таблиц на конфигурации таблиц или URL -адреса конфигурацииСовет: конфигурации данных и таблицы также могут быть заменены на 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
"""Пример: давайте ограничимся партнером А и разберемся по его кампаниям:
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 содержит некоторые атрибуты Helper для автоматического доступа или фильтрации забросов, а также атрибут
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 DOCS для получения дополнительной информации о поддерживаемом поведении в роты.
Пример: сохранить спецификацию отчета (не данные):
Сначала вы должны убедиться, что вы сохранили свой 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, в настоящее время нет встроенного способа вывода полной конфигурации в файл для справки при сохранении.
Пример: загрузите и запустите отчет с идентификатора Spec:
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 . Существует два поддерживаемых способа указания подрепорта: передача идентификатора спецификации отчета или передача параметров отчета.
# 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} "
} В качестве удобства, вместо того, чтобы неоднократно определять метрики формулы для вариантов скорости базовой метрики, вы можете указать конфигурацию метрики Divisor на метрике без формала. В качестве примера, скажем, у вас есть метрика revenue и revenue_per_sale хотите создать варианты для revenue_per_lead . Вы можете определить свой показатель дохода следующим образом:
{
"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) " }
] Наш пример также автоматически создал несколько измерений из столбцов «censue_at» из таблиц и таблиц продаж. Поддержка автоматических конверсий типа ограничена, но для столбцов даты/DateTime в поддерживаемых технологиях DataSource вы можете получить различные измерения бесплатно таким образом.
Вывод wh.print_info будет отображать добавленные измерения, которые предварительно профиксируют с помощью «head_» или «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" ]
) Вы также можете определить размеры «специальные» с каждым запросом отчета. Ниже приведен пример, который создает измерение, которое разделяет определенное значение измерения на лету. Специальные размеры представляют собой подкласс 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) "
}Технические вычисления вычисляются на комбинированном уровне, тогда как «агрегация» выполняется на уровне данных данных (следовательно, необходимо определить оба выше).
Для получения дополнительной информации о том, как проанализированы сокращенные технические строки, см. Код Parse_technical_string. Полный список поддерживаемых технических типов см. zillion.core.TechnicalTypes .
Техники также поддерживают два режима: «группа» и «все». Режим контролирует, как применить технические вычисления в рамках измерений данных. В режиме «Группа» он вычисляет технические в последнем измерении, тогда как в режиме «все» в вычислении технических по всем данных без какого -либо обращения к измерениям.
Смысл этого становится более ясным, если вы попытаетесь выполнить технические «cumsum» по всем данным, разбитым чем -то вроде [«partner_name», «date»]. Если используется режим «группы» (по умолчанию в большинстве случаев), он будет выполнять кумулятивные суммы в каждом партнере в течение диапазонов дат. Если используется режим «все», он будет выполнять кумулятивную сумму по каждой строке данных. Вы можете быть явным о режиме, добавив его на техническую строку: т.е.
Если вы хотите избежать предоставления конфиденциальной информации о конфиденциальном соединении в конфигурации 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 есть разъемы ко многим популярным базам данных. Барьер для поддержки многих из них, вероятно, довольно низкий, учитывая простую природу использования операций Zillion .
Обратите внимание, что вышеупомянутое отличается от поддержки базы данных для базы данных комбинированных уровней. В настоящее время там поддерживается только SQLite; Этого должно быть достаточно для большинства случаев использования, но в будущем будет добавлено больше вариантов.
Если вы планируете запустить Zillion в многопрофильном сценарии, будь то на одном узле или на нескольких узлах, есть несколько вещей, которые следует рассмотреть:
Обратите внимание, что вы все еще можете использовать SQLite SQLite SQLITE в памяти DB без проблем, так как это сделано на Fly с каждым запросом отчета и не требует координации/связи с другими процессами или узлами.
Zillion Web UI - это демонстрационный пользовательский интерфейс и веб -API для Zillion, который также включает в себя экспериментальный плагин CHATGPT. Смотрите там Readme для получения дополнительной информации об установке и структуре проекта. Обратите внимание, что код является легким на тестировании и полировке, но ожидается, что он будет работать в современных браузерах. Также в данный момент плагины CHATGPT довольно медленные, поэтому в настоящее время это в основном для веселья и не так полезно.
Больше тщательной документации можно найти здесь. Вы можете дополнить свои знания, просматривая каталог тестов или ссылку на API.
Пожалуйста, смотрите Руководство для получения дополнительной информации. Если вы ищете вдохновение, добавление поддержки и тестов для дополнительных технологий базы данных было бы большой помощью.
