1

背景としては、Google BigQuery を BI 系ツールのバックエンド プラットフォームとして利用することを研究してきました。私はまだ BigQuery を使用していないことを指摘しておきたいので、私の質問はドキュメントで見たことに関するものです。

大まかな計画は、おそらく、Tableau 上に構築されたダッシュボードの「ライブ」ソースとして Big Query を使用することでした。

どうやらデータをロードする最良の方法は、JSON (ネストをサポートする) を使用した非正規化構造を使用することです。

JSON が次のようになっていることがわかります。

{
    FirstName: 'John',
    LastName: 'Doe',
    Orders: {
        orderNo: 12345, 
        orderDate: '2013-01-01'
        orderlines: {
          lineNo: 1,
          qty: 1,
          price: 12,
          productId: 1234
          productName: 'Learning System',
         productSubsystem: 'SUB'
       }
    },
    LeadScores: {
       {
        scoreName: 'Learning Tech',
        scoreValue: 123,
        scoreDate: '2013-01-01'
       },
       {
       scoreName: 'ScoreB',
       scoreValue: 15,
       scoreDate: '2013-01-01'
       }
    },
    Activities {
     ** email opens, email clicks, page view, etc. (all here) **
      {
        activityType: 'email',
        activityAction: 'open',
        activityDescription 'message-1234'
      }
    }

}

今私の質問：

「内部」コレクションにレコードを追加できますか (毎日より多くのアクティビティを追加したい場合など)? それとも、別のエンティティである必要がありますか? (穴のように JSON は単一のエンティティです)

この構造は理にかなっていますか、それとも「3」程度のエンティティ (アクティビティ、注文、人口統計、スコア) を持ち、JOIN を使用する方がよいでしょうか? BigQuery は JOIN を使用しないことを好むと読みました。

潜在的な構造は

スコアの場合:

 {  
   date: '2013-01-01',
   scoreName: 'Score A',
   scoreValue: '1234',
   customerId: '123456'
 }

アクティビティの場合:

 {  
   date: '2013-01-01',
   activityType: 'email',
   activityAction: 'open',
   extra: '',
   customerId: '123456'
 }

人口統計の場合

  {
       customerId: '123456',
       firstName: 'A',
       lastName: 'B', etc..

  }

どちらのアプローチがより理にかなっていますか?

ありがとうございました！

4

1 に答える 1

1

質問 a) は単純です。行と列を追加できますが、既存の行を変更することはできません。既存の行のネストされた構造にデータを追加すると、その行を変更することになるため、不可能です。

質問 b) は設計上の質問です。基本は理解できましたが、クエリ パターンを知らなければ、最適化は困難です。BigQuery は柔軟性があり、どちらの方法でも機能しますが、最適化にはより多くのデータが必要になります。

従うべき良い経験則は、ストレージが安価であるということです: 正規化されたデータと非正規化されたデータを保持し、クエリに応じて選択することができます。使用するのに最適なパターンは、この方法ですばやく表示されます!

于 2013-11-03T23:51:14.903 に答える