zillion
v0.12.0
Zillionは、複数のデータソースからのデータを簡単なAPIを介して組み合わせて分析できるデータモデリングおよび分析ツールです。データの上にセマンティックレイヤーとして機能し、SQLを書いているため、SQLalchemy Coreを介して既存のデータベースインフラストラクチャに簡単にボルトで固定します。 Zillion NLP拡張は、AIを搭載した自然言語クエリと倉庫の構成を実験的にサポートしています。
Zillionでできます：
警告：このプロジェクトはアルファ状態であり、変更される可能性があります。生産の使用については注意深くテストし、問題を報告してください。
$ pip install zillion
or
$ pip install zillion[nlp]以下は、データウェアハウジングで使用される何らかの理論とZillion法の概要を簡単に説明することを目的としています。使用の例や倉庫/DataSourceの作成クイックスタートオプションについては、以下をスキップすることもできます。
要するに、 ZillionあなたのためにSQLを書き、非常にシンプルなAPIを通じてデータにアクセスできるようにします。
result = warehouse . execute (
metrics = [ "revenue" , "leads" ],
dimensions = [ "date" ],
criteria = [
( "date" , ">" , "2020-01-01" ),
( "partner" , "=" , "Partner A" )
]
)Zillionには、レポートリクエストで使用される2つの主なタイプのFieldsがあります。
Dimensions ：ラベル付け、グループ化、フィルタリングに使用されるデータの属性Metrics ：寸法に沿って分解される可能性のある事実と測定値Field 、データ内の列の概念をカプセル化します。たとえば、「Revenue」と呼ばれるFieldがある場合があります。そのField 、いくつかのデータソースで、または単一のDataSource内の複数のテーブルで発生する場合があります。 Zillion 、これらの列のすべてが同じ概念を表していることを理解しており、「収益」を要求するレポートを満たすためにそれらのいずれかを使用しようとすることができます。
同様に、倉庫を構築するために使用されるテーブルには2つの主要なタイプがあります。
Dimension Tables ：関連する寸法のみを含む参照/属性テーブルMetric Tables ：メトリックといくつかの関連する寸法/属性を含むファクトテーブルディメンションテーブルは、多くの場合、行カウントの点で静的またはゆっくりと成長し、主キーに結び付けられた属性を含んでいます。いくつかの一般的な例は、米国のzipコードまたは会社/パートナーディレクトリのリストです。
メトリックテーブルは、一般に本質的によりトランザクション的です。いくつかの一般的な例は、Webリクエスト、eコマースの販売、または株式市場価格履歴の記録です。
次元モデリングとドリルアクロスクエリのテクニックを本当に深くしたい場合は、 Zillionが採用しています。DataWarehousingに関するRalph Kimballの本を読むことをお勧めします。
要約すると、Drill-Acrossクエリは1つ以上のクエリをフォームにして、特定のdimension粒の複数のデータソースやテーブルに存在するmetricsのレポート要求を満たします。
Zillion 、SnowflakeやStar Schemasなどの柔軟な倉庫のセットアップをサポートしていますが、それについてはうるさいわけではありません。親子の系統を介してテーブルの関係を指定することができ、 Zillion Dimension Tableプライマリキーの存在に基づいて許容可能な結合を推測することもできます。現時点では、 Zillion多くの関係をサポートしていませんが、ほとんどの分析に焦点を当てたシナリオは、必要に応じてモデルにビューを追加することでそれを回避できるはずです。
Zillionレポートは、2つのレイヤーで実行されていると考えることができます。
DataSource Layer ：倉庫のDataSourcesに対するSQLクエリCombined Layer ：DataSourceレイヤーからの結合データに対する最終的なSQLクエリ結合レイヤーは、DataSourceデータを結び付けてロールアップ、行フィルター、行制限、並べ替え、ピボット、技術計算などのいくつかの追加機能を適用するために使用される別のSQLデータベース（デフォルトではインメモリSQLite）です。
ローカルまたはリモートファイルから倉庫をすばやく初期化する方法は複数あります。
# Path/link to a CSV, XLSX, XLS, JSON, HTML, or Google Sheet
# This builds a single-table Warehouse for quick/ad-hoc analysis.
url = "https://raw.githubusercontent.com/totalhack/zillion/master/tests/dma_zip.xlsx"
wh = Warehouse . from_data_file ( url , [ "Zip_Code" ]) # Second arg is primary key
# Path/link to a sqlite database
# This can build a single or multi-table Warehouse
url = "https://github.com/totalhack/zillion/blob/master/tests/testdb1?raw=true"
wh = Warehouse . from_db_file ( url )
# Path/link to a WarehouseConfigSchema (or pass a dict)
# This is the recommended production approach!
config = "https://raw.githubusercontent.com/totalhack/zillion/master/examples/example_wh_config.json"
wh = Warehouse ( config = config ) Zillionはまた、既存のデータベースのデータソース構成ファイルをブートストラップするヘルパースクリプトを提供します。 zillion.scripts.bootstrap_datasource_config.pyを参照してください。ブートストラップスクリプトには、接続/データベースURLと出力ファイルが引数として必要です。 OpenAIを活用して列タイプ、テーブルタイプ、テーブル関係などの構成情報を推測するオプションの--nlpフラグを含む、より多くのオプションについては、 --help出力を参照してください。 NLP機能では、NLP拡張機能をインストールする必要がありZillion 。
Zillionの主な目的は、 Warehouseに対するレポートを実行することです。高いレベルでは、次のようにレポートを作成します。
result = warehouse . execute (
metrics = [ "revenue" , "leads" ],
dimensions = [ "date" ],
criteria = [
( "date" , ">" , "2020-01-01" ),
( "partner" , "=" , "Partner A" )
]
)
print ( result . df ) # Pandas DataFrameSQLの作成と比較する場合、寸法をSQLステートメントによるグループのターゲット列と考えると役立ちます。メトリックを集計している列と考えてください。基準をWhere句と考えてください。あなたの基準は、DataSourceレイヤーSQLクエリに適用されます。
ReportResultは、インデックスとしてディメンションを、メトリックが列としてメトリックを伴うPandasデータフレームがあります。
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（Vectorデータベース）の実行中のインスタンスと、 Zillion構成ファイルで設定された次の値が必要です。
埋め込みは、QDRANTとローカルキャッシュの両方で生成および保存されます。ベクトルデータベースは、倉庫内のすべてのフィールドを分析して、これを使用しようとするときに初めて初期化されます。 qdrantを実行するためのDockerファイルの例は、このレポのルートに提供されています。
フィールドがどのように埋め込まれるかを制御できます。つまり、任意のフィールドの構成では、埋め込みからフィールドを除外するか、そのフィールドにどの埋め込みをマップするかをオーバーライドするかどうかを選択できます。すべてのフィールドはデフォルトで含まれています。次の例では、 net_revenueフィールドが埋め込まれ、 gross_revenueフィールドへのrevenueメトリックリクエストをマップすることを除外します。
{
"name" : "gross_revenue" ,
"type" : "numeric(10,2)" ,
"aggregation" : "sum" ,
"rounding" : 2 ,
"meta" : {
"nlp" : {
// enabled defaults to true
"embedding_text" : "revenue" // str or list of str
}
}
} ,
{
"name" : "net_revenue" ,
"type" : "numeric(10,2)" ,
"aggregation" : "sum" ,
"rounding" : 2 ,
"meta" : {
"nlp" : {
"enabled" : false
}
}
} ,さらに、次のウェアハウスレベルの構成設定を介してフィールドを除外することもできます。
{
"meta" : {
"nlp" : {
"field_disabled_patterns" : [
// list of regex patterns to exclude
"rpl_ma_5"
] ,
"field_disabled_groups" : [
// list of "groups" to exclude, assuming you have
// set group value in the field's meta dict.
"No NLP"
]
}
} ,
...
}前述のレベルのいずれかでフィールドが無効になっている場合、それは無視されます。データモデルがより複雑になり、同様に指定されたフィールドを混乱させる場合にNLPロジックをガイドしたいため、このタイプのコントロールは有用になります。どのフィールドが除外されるかを調整するたびに、 Warehouse.init_embeddingsのforce_recreateフラグを使用して、埋め込みコレクションのレクリエーションを強制したいと思うでしょう。
注：この機能は初期段階にあります。その有用性は、入力クエリとデータモデル（つまり、良いフィールド名）の両方の品質に依存します！
以下でさらに説明するWarehouseの構造の構成に加えて、 Zillionはいくつかの基本的な設定を制御するグローバルな構成があります。 ZILLION_CONFIG Environment VARは、YAML設定ファイルを指すことができます。どの値を設定できるかの詳細については、 examples/sample_config.yamlを参照してください。 Zillion_で付けた環境VARは、構成設定をオーバーライドできます（つまり、Zillion_DB_URLはDB_URLをオーバーライドします）。
Zillionレポート仕様の保存に使用されるデータベースは、 Zillion構成のDB_URL値を有効なデータベース接続文字列に設定することで構成できます。デフォルトでは、 /TMPのSQLite DBが使用されます。
以下では、基本的なDataSourceとWarehouse構成を実証し、いくつかのサンプルレポートを表示する単純な仮想販売データモデルを進めます。データは、 Zillionテストコードの一部である単純なSQLiteデータベースです。参照のために、スキーマは次のとおりです。
CREATE TABLE partners (
id INTEGER PRIMARY KEY ,
name VARCHAR NOT NULL UNIQUE,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE campaigns (
id INTEGER PRIMARY KEY ,
name VARCHAR NOT NULL UNIQUE,
category VARCHAR NOT NULL ,
partner_id INTEGER NOT NULL ,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE leads (
id INTEGER PRIMARY KEY ,
name VARCHAR NOT NULL ,
campaign_id INTEGER NOT NULL ,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE sales (
id INTEGER PRIMARY KEY ,
item VARCHAR NOT NULL ,
quantity INTEGER NOT NULL ,
revenue DECIMAL ( 10 , 2 ),
lead_id INTEGER NOT NULL ,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);Warehouse 、そのフィールド、データソース、およびテーブルを定義するJSONまたはYAML構成から作成できます。以下のコードは、JSON/YAML Warehouse構成へのポインターがある場合、1行のコードでどのように実行できるかを示しています。
from zillion import Warehouse
wh = Warehouse ( config = "https://raw.githubusercontent.com/totalhack/zillion/master/examples/example_wh_config.json" )この例では、 DataSource connect情報のdata_urlを使用して、 Zillionそのデータを動的にダウンロードし、SQLiteデータベースとして接続するように指示します。これは簡単な例や分析に役立ちますが、ほとんどのシナリオでは、ここに表示されるように既存のデータベースに接続文字列を配置します。
Zillion's倉庫構成構造の基本は次のとおりです。
Warehouse構成には、次のメインセクションがあります。
metrics ：グローバルメトリックのメトリック構成のオプションリストdimensions ：グローバルディメンションのディメンション構成のオプションリストdatasources ：DataSource名のデータソース構成または構成URLへのマッピングDataSource構成には、次のメインセクションがあります。
connect ：データベース接続URLまたは接続のdict paramsmetrics ：このデータソースに固有のメトリック構成のオプションリストdimensions ：このDataSourceに固有の寸法構成のオプションリストtables ：テーブル名のマッピングテーブル構成または構成URLヒント：DataSourceおよびテーブル構成は、ローカルまたはリモートの構成ファイルを指すURLに置き換えることもできます。
この例では、データベース内の4つのテーブルはすべて、構成に、2つはディメンションテーブルとして、2つはメトリックテーブルとして含まれています。テーブルは、親と子の関係：キャンペーンとのパートナーを通じてリンクされ、販売につながります。一部のテーブルは、 create_fieldsフラグを使用して、列定義からDataSource上のFieldsを自動的に作成します。他のメトリックと寸法は明示的に定義されます。
INIT後にこのWarehouseの構造を表示するには、データウェアハウスの一部であるすべてのメトリック、寸法、表、および列を表示するprint_infoメソッドを使用できます。
wh . print_info () # Formatted print of the Warehouse structure構成スキーマのより深いダイビングについては、完全なドキュメントをご覧ください。
例：パートナーによる販売、リード、収益を得る：
result = wh . execute (
metrics = [ "sales" , "leads" , "revenue" ],
dimensions = [ "partner_name" ]
)
print ( result . df )
"""
sales leads revenue
partner_name
Partner A 11 4 165.0
Partner B 2 2 19.0
Partner C 5 1 118.5
"""例：パートナーAに制限し、そのキャンペーンに分類しましょう。
result = wh . execute (
metrics = [ "sales" , "leads" , "revenue" ],
dimensions = [ "campaign_name" ],
criteria = [( "partner_name" , "=" , "Partner A" )]
)
print ( result . df )
"""
sales leads revenue
campaign_name
Campaign 1A 5 2 83
Campaign 2A 6 2 82
"""例：以下の出力は、各パートナー内のキャンペーンレベルでのロールアップと、パートナーとキャンペーンレベルでの合計のロールアップを示しています。
注：出力には、結果に追加されたデータフレームロールアップ行をマークする特別な文字が含まれています。 Reportresultオブジェクトには、ロールアップを自動的にアクセスまたはフィルターするためのヘルパー属性と、特殊文字に代わるより親しみやすいディスプレイ値で結果を返す
df_display属性が含まれています。フード下の特別なキャラクターはイラストのためにここに残されていますが、すべてのシナリオで同じようにレンダリングされない場合があります。
from zillion import RollupTypes
result = wh . execute (
metrics = [ "sales" , "leads" , "revenue" ],
dimensions = [ "partner_name" , "campaign_name" ],
rollup = RollupTypes . ALL
)
print ( result . df )
"""
sales leads revenue
partner_name campaign_name
Partner A Campaign 1A 5.0 2.0 83.0
Campaign 2A 6.0 2.0 82.0
� 11.0 4.0 165.0
Partner B Campaign 1B 1.0 1.0 6.0
Campaign 2B 1.0 1.0 13.0
� 2.0 2.0 19.0
Partner C Campaign 1C 5.0 1.0 118.5
� 5.0 1.0 118.5
� � 18.0 7.0 302.5
"""サポートされているロールアップ動作の詳細については、 Reportドキュメントを参照してください。
例：レポート仕様を保存します（データではありません）：
最初に、保存されたレポートが特定のWarehouse IDにスコープされているため、 Warehouseを保存したことを確認する必要があります。 Warehouseを保存するには、完全な構成を指すURLを提供する必要があります。
name = "My Unique Warehouse Name"
config_url = < some url pointing to a complete warehouse config >
wh . save ( name , config_url ) # wh.id is populated after this
spec_id = wh . save_report (
metrics = [ "sales" , "leads" , "revenue" ],
dimensions = [ "partner_name" ]
)注：
DataSourcesのリストからPythonにWarehouseを構築した場合、またはinitのconfigParamのdictで渡された場合、現在、保存時に完全な構成を参照用ファイルに出力する組み込みの方法はありません。
例：仕様IDからレポートをロードして実行します：
result = wh . execute_id ( spec_id )これは、 Zillion YAML構成のDB_URLで指定されたデータベースに以前にこのレポートIDを保存したことを前提としています。
例：サポートされていない穀物
不可能なレポートを試みた場合、 UnsupportedGrainException受容が得られます。以下のレポートは、子供のテーブルにのみ存在する次元によってリードメトリックを分解しようとするため、不可能です。一般的に言えば、子テーブルは親（および親の「兄弟」）に戻って寸法を見つけますが、その逆ではありません。
# Fails with UnsupportedGrainException
result = wh . execute (
metrics = [ "leads" ],
dimensions = [ "sale_id" ]
)1つのレポートを他のレポートの結果にフィルタリングするために、サブクエリのような機能が必要な場合があります（おそらく別の穀物が必要でした）。 Zillionはnot in report in reportを使用するかどうかを使用することにより、それを行うための単純な方法を提供します。サブレポートを指定するには2つのサポートされている方法があります。レポート仕様IDの渡すか、レポートのパラメーションの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場合は、サブレポートの次元でなければなりません。サブレポートは、 execute中ではなくReportオブジェクトの初期化時間で実行さ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を参照してください。これは、命名テンプレート、フォーミュラテンプレート、丸めのオーバーライドなどの構成オプションの詳細をご覧ください。
もう1つのマイナーな便利な機能は、構成ファイルの複数のフィールドではなく、単一のフィールド構成でさまざまな集約タイプのメトリックのバリエーションを自動的に生成できることです。例として、データに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 、その式の一部として他の次元のみを使用することができ、複合層データベースでも評価されます。追加の制限として、これらのフィルターはDataSourceレイヤーで評価されているため、レポート基準ではFormulaDimensionを使用できません。次の例では、sqliteの組み合わせレイヤーデータベースを想定しています。
{
"name" : " partner_is_a " ,
"formula" : " {partner_name} = 'Partner A' "
}私たちの例には、クエリのデータソース層で式を介して値が計算されるメトリック「販売」も含まれています。 「Main.Sales」テーブルの「ID」パラメーションのfieldsリストの以下に注意してください。これらの式は、特定のDataSourceデータベーステクノロジーの構文にあります。これは、たまたまこの例でもsqliteです。
"fields" : [
" sale_id " ,
{ "name" : " sales " , "ds_formula" : " COUNT(DISTINCT sales.id) " }
]また、私たちの例は、リードと販売テーブルの「created_at」列からのいくつかの寸法を自動的に作成しました。自動型変換のサポートは限られていますが、サポートされているDataSourceテクノロジーの日付/データタイム列の場合、この方法でさまざまな次元を無料で入手できます。
wh.print_infoの出力には、各テーブルの構成のオプションのtype_conversion_prefixで指定されているように、「lead_」または「sale_」が付けられた追加の寸法が表示されます。倉庫の例の自動生成寸法の例には、sale_hour、sale_day_name、sale_month、sale_yearなどが含まれます。
基礎となるレポートクエリのWhere句の最適化として、 Zillion列の代わりに基準値に変換を適用しようとします。たとえば、一般に、 DATE(my_datetime) == '2020-01-01'ではなく、 my_datetime > '2020-01-01' and my_datetime < '2020-01-02'としてクエリする方が効率的です。列の代わりに値に変換を適用する機能は、フィールドやDataSourceテクノロジーによっても異なります。
タイプ変換を防ぐために、 skip_conversion_fields DataSource構成でtrueに設定します。
現在サポートされている変換の詳細については、 zillion.field.TYPE_ALLOWED_CONVERSIONS and zillion.field.DIALECT_CONVERSIONS参照してください。
また、各レポートリクエストでメトリック「アドホック」を定義することもできます。以下は、その場でリード1メートルの収益を作成する例です。これらはレポートの範囲内にのみ存在し、名前は既存のフィールドと矛盾することはありません。
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中にデータベース内のアドホックテーブルの作成または同期もサポートしています。これを行うテーブル構成の例をここに示します。 Table Configのdata_urlとif_exists Paramsを使用して、SQLiteデータベースのリモートCSVから「main.dma_zip」テーブルの同期および/または作成を制御します。他のデータベースタイプでも同じことができます。
このようなアプローチに対する潜在的なパフォーマンスの欠点は、特に倉庫を頻繁に初期化する場合、またはリモートデータファイルが大きい場合は明らかです。多くの場合、完全なスキーマ制御ができるように、事前にデータを同期して作成する方が良いですが、この方法は特定のシナリオで非常に役立ちます。
警告：データベース内の既存のテーブルを上書きしないように注意してください！
ローリング、累積、またはランク統計を計算するためにメトリックに適用できるさまざまな技術計算があります。たとえば、収益で5ポイント移動平均を計算するには、次のように新しいメトリックを定義する場合があります。
{
"name" : " revenue_ma_5 " ,
"type" : " numeric(10,2) " ,
"aggregation" : " sum " ,
"rounding" : 2 ,
"technical" : " mean(5) "
}テクニカル計算は複合層で計算されますが、「集約」はデータソースレイヤーで行われます（したがって、上記の両方を定義する必要があります）。
Shorthandの技術文字列の解析方法の詳細については、parse_technical_stringコードを参照してください。サポートされている技術タイプの完全なリストについては、 zillion.core.TechnicalTypes参照してください。
テクニカルは、「グループ」と「すべて」の2つのモードもサポートしています。このモードは、データのディメンション全体に技術計算を適用する方法を制御します。 「グループ」モードでは、最後のディメンション全体でテクニカルを計算しますが、「すべて」モードでは、寸法を考慮せずにすべてのデータにわたってテクニカルを計算します。
このポイントは、["partner_name"、 "date"]のようなものによって分類されたデータ全体で「cumsum」技術を実行しようとすると、より明確になります。 「グループ」モードが使用される場合（ほとんどの場合）、日付の範囲で各パートナー内で累積合計を行います。 「すべて」モードを使用すると、すべてのデータ行で累積合計が行われます。テクニカル文字列に追加することにより、モードを明示することができます。つまり、 "cumsum：all"または 'mean（5）：group "
DataSource構成に敏感な接続情報を直接配置しないようにしたい場合は、構成変数を活用できます。 Zillion YAML構成では、次のようにDATASOURCE_CONTEXTSセクションを指定できます。
DATASOURCE_CONTEXTS :
my_ds_name :
user : user123
pass : goodpassword
host : 127.0.0.1
schema : reporting次に、「my_ds_name」という名前のデータソースのDataSource構成が読み取られると、このコンテキストを使用して、接続URLの変数を入力できます。
"datasources" : {
"my_ds_name" : {
"connect" : " mysql+pymysql://{user}:{pass}@{host}/{schema} "
...
}
}Warehouse initでは、名前でデータソースのデフォルトの優先順位を指定できます。これは、複数のデータソースによってレポートが満たされる可能性がある場合に機能します。リストの前半のDataSources優先度が高くなります。これはDataSourceにグループ化されたより高速な集計テーブルのセットを支持したい場合に役立ちます。
wh = Warehouse ( config = config , ds_priority = [ "aggr_ds" , "raw_ds" , ...])Zillion's目標は、SQLalchemyがサポートするデータベーステクノロジーをサポートすることです（以下の写真）。それは、 Zillionではサポートとテストレベルが異なると述べています。特に、タイプ変換、データベースリフレクション、および実行中のクエリを殺す機能にはすべて、サポートのためにデータベース固有のコードが必要です。次のリストは、既知のサポートレベルをまとめたものです。マイレージは、SQLalchemyがサポートするテストされていないデータベーステクノロジーによって異なる場合があります（それはうまく機能する可能性があり、まだテストされていません）。バグを報告し、サポートを追加するのに役立ちます！
Sqlalchemyには、多くの一般的なデータベースへのコネクタがあります。これらの多くをサポートする障壁は、 Zillion使用するSQL操作の単純な性質を考えると、おそらくかなり低い可能性があります。
上記は、複合レイヤーデータベースのデータベースサポートとは異なることに注意してください。現在、SQLiteのみがそこでサポートされています。ほとんどのユースケースでは十分であるはずですが、より多くのオプションが将来追加されます。
単一のノードでも複数のノードを越えて、マルチプロセスシナリオでZillionを実行する予定がある場合は、考慮すべきことがいくつかあります。
各レポートリクエストでその場で行われ、他のプロセスまたはノードとの調整/通信を必要としないため、問題なくデフォルトのSQLite Inmemory Inmemory Combined Layer DBを使用できることに注意してください。
Zillion Web UIは、ZillionのデモUIおよびWeb APIであり、実験的なChatGPTプラグインも含まれています。インストールとプロジェクト構造の詳細については、Readmeを参照してください。コードはテストとポリッシュに軽いですが、最新のブラウザで動作することが期待されています。また、ChatGptプラグインは現時点では非常に遅いため、現在はほとんどが楽しみであり、それほど便利ではありません。
より徹底的なドキュメントはこちらでご覧いただけます。テストディレクトリまたはAPIリファレンスを熟読することにより、知識を補完できます。
詳細については、寄稿ガイドをご覧ください。インスピレーションを探している場合は、追加のデータベーステクノロジーのサポートとテストを追加することは大きな助けになります。
