エンビジョンリーディングファイル

エンビジョンで表形式ファイルのリード


ホーム » コマース分析 » このページ

エンビジョンは、Lokadのアカウントに保存されている表形式のファイルをロードして処理します。また、Lokadは一連のサードパーティー提供アプリのネイティブサポートも提供します。アプリがLokadによってサポートされている場合、データをインポートしたり、必要なファイルを作成したりするプロセスは、完全に内部で管理されています。しかし、サポート対象でない場合やLokadがすべての関連データを取得できない場合、手動でLokadにファイルをインポートすることが出来ます。このページでは、これらの表形式ファイルをエンビジョン互換フォーマットにする方法について説明します。これらの表形式のファイルをシステムが読み込む方法に関するエンビジョン構文も以下に記載します。

コネクタ付きファイルストレージ

すべてのLokadアカウントに、個人用のファイルストレージサービスが付属しています。簡単に言えば、フォルダを作成し、フォルダにファイルをアップロードすることが可能です。この点で、ファイル共有機能を除いて、Lokadは、Box やDropboxのような他のファイル•ホスティング•サービスと同様のサービスを提供しています。実際には、Lokadのファイルストレージシステムの目的は、他のファイル共有アプリケーションとは異なり、商取引の分析で、Lokadが使用するすべてのデータにアクセスする為の、完全に明確な手段を提供するものです。Lokadが予測やダッシュボードを生成する際に、ダウンロードしたり、場合によってはLokadから独立して分析したり出来るファイル形式のデータが個人のアカウント内に出来ます。

そもそも、中小企業は膨大なITリソースを持っていないので、全ての社内に関連する履歴データを収集したファイルを生成する事は、非常に骨の折れる作業になりがちです。従い、Lokadは、多くの一般的なコマース向けアプリケーション ― Brightpearl、Linnworks、QuickBooks、TradeGecko、Unleashed、Vend・・・など―に対する 組込みコネクタを提供しています。これらのコネクタは、アプリ、特に一般的にオンラインのAPI(アプリケーション•プログラミング•インタフェース)と上手く接続し、Lokadアカウント内にエンビジョンが処理する上で、最も適したフォーマット形式でデータを生成します。

あなたが使用しているビジネス用アプリがサポートされていない場合は(その場合、迅速に対応するサポートに)。もしLokadのビルトインが関連するデータのサポートを対応していない場合、ウェブを介した手動アップロード機能をサポートしているので、Lokadに直接ファイルをアップロードすることも出来ます。しかし、データを定期的に更新しなければならない場合、データ転送を完全に自動化した方法で行う方がより実用的です。そのため、さらに、Lokadは、すべてのファイル転送を自動化出来るFTPやSFTPなどのプロトコルもサポートしています。

表形式のファイルを幅広くサポート

Lokadは表形式のデータを含めることができる、非常に多様な範囲のファイル形式をサポートしており、ExcelシートまたはCSV(カンマ区切り)ファイルなどの一般的なフォーマットもサポートしています。フラットファイルのインポート/エクスポートの使用経験があれば、プロセスが非常に面倒で、細々とした技術的な設定を無数にしなければならない事を既に知っているかもしれません:

  • ファイルのエンコーディングは、アプリが期待するエンコーディングと異なる場合があります
  • 日付や数字が期待どおりにフォーマットされない場合があります
  • 列区切りや、改行エンコーディングも異なる可能性があります

我々は、エンコーディング、日付と数値の書式、デリミタ・・・などを自動で検出する能力を持つシステムを設計しました。すべてが自動的に行われますが、システムがファイルを読み込む際、Lokad内でかなり大掛かりな処理が行われます。例えば、現在、100以上の異なる日付フォーマットの自動検出をサポートしています。

実際に、表形式のファイル形式のガイドラインは単純です:ファイルの先頭行に列名をリストしなければならないし(この要件は、Excelシートにも適用されます)、CSVやTSVなどのフラットテキストファイルの場合、トークン値とデリミタが重複してはいけません。

さらに、フラットファイルのサイズが大きい場合、Lokadにアップロードする前に、圧縮するのが一般的です。 Lokadは、Gzip(WinZIPではなく)で圧縮された、ファイル名の末尾に.gzという拡張子を持つフラットテキストファイルのみをサポートしています。たとえば、「Lokad_Items.tsv.gz」はgzipで圧縮されたTSVファイルとして認識されます。 Excelシートは、すでに圧縮されているので、非常に大きくなる場合でも、圧縮する必要はありません。

ファイルとカラムの命名ガイドライン

Lokadは、殆どの任意のファイル名と任意の列名を受け入れる事ができますが、一定のガイドラインに従っていると、結果として得られるエンビジョンスクリプトがよりシンプルになります。 サンプルデータセット はこれらのガイドラインに従ったファイルセットの良い例です。まだ今まで、このデータセットを見る機会がなかったなら、今ここでチェックされる事をお勧めします。

ファイルは、このパターン:Lokad_TableName.xyz に従って命名されることが期待されており、TableName はテーブルの名前に、 xyz は実際のファイル拡張子に置き換えられ、例えば、ExcelシートはXLSXになります。テーブル名にスペースを含めることはできませんし、数字で始まってもいけません。これらのファイルの命名規則に従うことで、エンビジョンは、余分な労力をかけずに、ロードすべき関連テーブルの自動検出を可能にしています。

具体的には、 アイテムテーブル は特殊なケースであり、すべてのエンビジョンスクリプトは1テーブル項目がシステムにロードされることを想定しています。 Lokad_Items.xyzファイル名は、何らかの形でLokad に提供される事を期待されています。厳密には必須ではありませんが、アプリは、Lokad_Orders.xyz(販売履歴)や Lokad_PurchaseOrders.xyz (サプライヤー購入履歴)も、ファイル名に指定する事を期待します。

個々のファイルが大きすぎるために、表が複数のファイルに分割された場合など、その後エンビジョンで、全てのこれらのファイルを一つのテーブルに統合することができます。この為には、すべてのファイルにLokad_TableName_Suffix.xyz名を付け、ファイル別にSuffixを付ける必要があります。例えば、販売データ抽出の為に毎日データ抽出が行われている場合、毎日の売上高データ抽出の1つをLokad_Orders_2015-03-16.tsvと命名しなければなりません。Suffix は、ファイルを個別に維持する為だけに必要なので、何でもかまいません。当然のことながら、エンビジョンは、それらのサフィックスを手掛かりにして、異なるサフィックスを持つ全てのファイルから同じ列を見つけようとしますが、同じ列が見つからない場合、エンビジョンは追加の指示なしに、これらのファイルを一つのテーブルに統合することはできません。

エンビジョンの視点からすると、カラム名に少しばかりの予測を持ちます。しかし、オリジナルの Lokad_Items.xyzファイルから検出された 、外部キーとして機能する「ID」という名前の列は、ほとんどすべてのファイルで見つけることが予想されます。これにはいくつかの例外がありますが、この点については、以降でより詳細に説明します。そして、様々なタイプの履歴データを含む全てのファイルに対して、「日付」列を見出す事を予想します。スペースを含まない、数字で始まらなければ、ほとんどの列名は使用可能です。

実際には、上記のガイドラインに準拠していない場合でも、- 例えばスペースがテーブル名や列名に発見された場合 など― 、エンビジョンは、そのような状況にも対処するための構文を提供しています。しかし、よい結果を取得する上で、エンビジョン内で必要となるオーバヘッドを減らす意味で、可能な限りガイドラインに準拠することをお勧めします。

ファイル読取り構文

エンビジョンは、ガイドラインに従って命名されたファイルをフルに活用する場合に使用する、非常に簡潔な構文をサポートしていますが、さらに、ファイルが正しく命名されていない、および/または内部ファイルに変更できないなどの状況の対処に必要となる豊富な構文もサポートしています。

ファイルと列が正しくガイドラインに従って命名された場合、ロードされる全てのファイルは1つのフォルダに格納されていると仮定され、全てのファイルを1ステートメントでロードすることができます。

read "/sample1" all

この例では、 /sample1 は、これまでにサンプルデータセットで使用してきたフォルダ名です。 all オプションを指定すると、エンビジョンは、名前Lokad_で始まるすべてのファイルを識別することから始め、それに対応したテーブル名を推定します。適応される全てのファイルを識別すると、エンビジョンは、デフォルトでは、 Items テーブルを探し、他のテーブルのリストを加えます(他のテーブルがない場合、厳密には、 Items テーブルのみ必要とされている場合以外)。 read all オプションは簡潔であり、サンプルデータセットの場合に動作しますが、read ステートメントは、多様なシナリオに対処するための、より複雑で強力な構文を提供します。一般的な構文は以下の通りです。
read "/foo/bar*.xyz" as MyTable with "Foo1" as Id, "Foo2" as Date, "Foo 3" as Foo3
/foo/bar*.xyz パスは、ワイルドカード(*)を含める事ができ、このワイルドカードは任意の文字列に置き換えることができます。ワイルドカードの使用はオプションですが、使用された場合、ワイルドカードを使って、一度に複数のファイルをキャプチャする事が可能です。このパターンは、コマンドラインからファイルを一覧表示させる、シェルの構文に似ています。

パスの右後にある、 最初の as キーワードは テーブルの名前を示しています。テーブルにMyTable名が付けられている場合、エンビジョンスクリプトは例えばこのテーブルが{MyTable.Id}}で書かれていると仮定します。 ロードされるテーブルが、テーブル項目そのものである場合には、as MyTable のように省略することができます。

とともに キーワードの後に続く指定は、列名の変更指示として動作します。上記の例では、 Foo1 列は、Id に、Foo2 列は Dateに名前変更されます。これら2列の名前変更の変更に伴い、テーブル MyTableは、 IdDate列が正しく定義され、過去のデータを含む正当なエンビジョンテーブルになります。

3番目の名前の変更操作Foo 3 (元の列名は空白であること)は、Foo3に名前が変更されます。これは、間違った列名を正しく変換する方法を示しています。さらに、ベクトル変数名が空白であってはならないという重要な注意も示唆しています。簡潔にするために、それ以上の名前の変更例を挙げていませんが、実際には、名前変更のペアリングがカンマで区切られていれば、単一ファイル内の名前変更操作の数に制限はありません。実際には、列名を変更するスクリプトをより読みやすくするために有益ですが、整合性のない列名を含んだ複数のファイルを、一つのテーブルに統合する必要がある場合など、必要な調整を行うために使用する事もできます。

たとえば、注文履歴が二つのファイルに分割されていると仮定しましょう。まず、Lokad_Orders_Old.tsv に2014年12月31日までの全てのデータが含まれているとします。このファイルは、 ItemIdOrderDateQuantityの3列を持っています。このファイルの列は、エンビジョンの列名のガイドラインに従っていません。第2に、Lokad_Orders.tsvは、2015年1月1日から始まるすべての履歴を含む最新のファイルです。このファイルは、IdDateQuantityの3列が含まれており、列名はエンビジョンガイドラインのデフォルトに適合しています。スクリプトは、以下の2つのファイルを一つの Orders テーブルに統合させる方法を示しています。
read "/foo/Lokad_Orders_Old.tsv" as Orders with "ItemId" as "Id", "OrderDate" as Date
read "/foo/Lokad_Orders.tsv" as Orders
当然、沢山のread文を定義して、すべてのファイルとすべてのテーブルを網羅する事は出来ます。エンビジョンは、スクリプト内にこれらの文の正確な位置を強制していないので、技術的には、スクリプトの一番下であろうが、どこにでも配置することができます。しかし、プログラミング言語に精通している人々は、スクリプトの先頭に記述されていることを期待していますので、先頭に置く事お勧めします。

エクスぺクテーション・タイプの定義

「アイテム」テーブルを除き、 前のセクションで説明したように、特に指定しない限り、エンビジョンは、関連する列の名前を、IdDate 列に名前変更します。しかし、時には、テーブルが正確にこれらの期待どおりになっていない場合もあり、エンビジョン構文は、テーブルに関連する全ての期待を明確にするために使用することができます。同様に、列の型は、通常、エンビジョンスクリプト自体から推測されますが、時には、タイプ推論だけでは不十分です。繰り返しますが、エンビジョン構文は、必要に応じて任意の列の型を指定出来ます。

エンビジョンは、テーブルの主キーを定義出来る expectキーワードを提供しています。 AB、・・・・、 Fという名前のテーブルの場合、6つの主キーの組み合わせがあります。
expect A(Id)
expect B(Id, *)
expect C(Date)
expect D(Date,*)
expect E(Id, Date)
expect F(Id, Date,*)
A(Id) の場合、1項目毎に1行あるテーブルを定義します。たとえば、 在庫設定 は、このカテゴリに分類されます。

B(Id,*) の場合、項目毎に複数行を持つテーブルを定義します。たとえば、クォンタイルグリッドは、このカテゴリ(高度予測の特殊タイプ)に分類されます。

C(Date) の場合、特定した日に、単一のスカラー値を含むテーブルを定義します。例えば、このような表は、特定の地理的位置に適用される祝日をリストするために使用できます。

D(Date,*) の場合、特定した日に、任意の数のスカラー値を含むテーブルを定義します。前のケースの拡張版で、指定された日に、複数の要因を関連付けることができます。

E(Id, Date) の場合、それぞれ (Id, Date) ペアにした値を最大で1つ含むテーブルを定義します。例えば、このような表は、過去の在庫切れの発生をリストするために使用することができます。

F(Id,Date,*) の場合、 expect 文を指定せずに得られる デフォルトの動作をします。実際、ほとんどの履歴データは、例えば販売注文履歴など、このケースに該当します。

さて、エンビジョンは、ストロングタイプの言語です。すべてのベクトルがエンビジョンで使用可能なタイプのいずれかに関連していることを意味しています。エンビジョンには、4種類のタイプがあります:テキスト、数値、日付、ブール値で、これらのタイプは、一般的にスクリプト自体から直接推測されます。例として、以前に書いたサンプルデータセットに戻ります:
read "/sample1" all // will be omitted in the following
Quantity = sum(Orders.Quantity)
Orders.Quantityベクトルは、数字のみ合計の対象となるので、暗黙的に数値として扱われます。その結果、エンビジョンがLokad_Orders.tsvファイルを解析する際、数字として正常に解析する為にQuantity 列にトークンが含まれている事を期待します。記述は:
Nonsense = sum(Orders.Client)

この場合、エンビジョンは数字付きLokad_Orders.tsv ファイルのClient列を解析しようとして、クライアント識別子を含む列が数字ではないので、処理は失敗します。 タイプ推論メカニズムに加え、エンビジョンは、すべてのテーブルの列ごとに期待されるタイプを指定する明示的な構文も提供しています。例えば、サンプルのデータセットは、明示的に次の文のように入力する事ができます。
expect Supplier : text
expect Orders.NetAmount : number
expect PurchaseOrders.ArrivalDate : date
構文は、単純にexpect MyTable.MyColumn : typetextnumberdatebooleanの一つを指定します。 最も広く使用されるアサーション型は、算術演算とタイプ推論に基づいているので、{{date 型ですが、この列が日付であると期待されるような正確な推測が常に可能なわけではありません。

FORMATTER ERROR (Transcluded inexistent page or this same page)