ステップ構成の表示

パイプラインのオプションに加えて、Cloud Dataflow パイプラインのすべてのステップについても詳しい構成情報を表示できます。たとえば、Source の読み取りパスや Sink の書き込み先、ウィンドウのトランスフォーム(変換)タイプ(FixedWindow、SlidingWindow など)などを参照することが可能です。


次の例では、Window.into() トランスフォームが SlidingWindows を 30 分間適用しており、各ウィンドウの表示時間は 5 秒です。



Read ステップをクリックすると、このパイプラインのソースに関する情報が表示されます。



PubsubIO.Read のソースは Google Cloud Pub/Sub のトピックから要素を読み取ります。この Pub/Sub トピックは現在はサイドバーに表示され、パイプラインのソースがどのように構成されたかを特定したり、それらの要素がどこから読み取られているかを把握したりするのに役立ちます。

複合トランスフォームのグラフ ノードを展開すると、そのステップの構成が表示されます。たとえば、BigQueryIO.Write ステップを展開し、ParDo(StreamingWrite) をクリックすると、シンクの書き込み先となる BigQuery テーブルのスキーマが表示されます。



他のソースやシンクの構成パラメータについても表示が可能です。たとえば、テキストAvro ファイルを読み書きするときは、Google Cloud Storage のファイル パターンが表示されます。


パイプラインのカスタム詳細の表示

display data は、SDK で提供されるトランスフォーム機能に特別に組み込まれているわけではなく、気になる詳細データを表示できる Dataflow Programming Model の一般的な要素です。このモデルでは、アノテーションを使用してトランスフォーム関数に構成パラメータを渡すことで、display data を任意の DoFnCombineFn、もしくは WindowFn に追加できます。

再び AutoComplete を例に見てみましょう。以下の AllPrefixes は、さまざまな長さのプレフィックスを抽出する ParDo です。

private static class AllPrefixes   
    extends DoFn<CompletionCandidate, KV<String, CompletionCandidate>> {  
  private final int minPrefix;  
  private final int maxPrefix;  
  public AllPrefixes(int minPrefix) {    
    this(minPrefix, Integer.MAX_VALUE);  
  }  
  public AllPrefixes(int minPrefix, int maxPrefix) {    
   this.minPrefix = minPrefix;    
   this.maxPrefix = maxPrefix;  
  }  
  @Override    
    public void processElement(ProcessContext c) {    
    String word = c.element().value;    
    for (int i = minPrefix; i <= Math.min(word.length(), maxPrefix); i++) {     
      c.output(KV.of(word.substring(0, i), c.element()));   
    }  
  }
}

この実装にはプレフィックスの最小長と最大長が隠れており、これらは Dataflow Monitoring Interface では表示されません。とはいえ、こうした限界値がわかれば、デバッグにおいて有益です。

populateDisplayData() メソッドで DoFn をオーバーライドすると、最小長と最大長の display data を登録できます。

@Override
public void populateDisplayData(DisplayData.Builder builder) {  
  super.populateDisplayData(builder);  
  builder       
    .add(DisplayData.item("MinimumPrefixLength", minPrefix))     
    .addIfNotDefault(DisplayData.item("MaximumPrefixLength", maxPrefix),           
      Integer.MAX_VALUE);
}
populateDisplayData メソッドは新規の HasDisplayData インターフェースで定義されています。このメソッドは、パイプライン作成時に display data を登録する柔軟な DisplayData.Builder インスタンスを渡します。HasDisplayData は、DoFnCombineFn、さらには PipelineOptionsPTransform のようなユーザー関数タイプに追加されています。

このメソッドの追加後に再びパイプラインを実行すると、Dataflow Monitoring Interface でその display data を見ることができます。



SDK に含まれるトランスフォームは、display data を登録できるように改良されています。そのため、一般的なコンポーネントを使って、目的の詳細データを無料で設定できます。

次の例では、Sliding Windows の構成を登録しています。

@Override
public void populateDisplayData(DisplayData.Builder builder) {  
  super.populateDisplayData(builder);  
  builder      
    .add(DisplayData.item("size", size)        
      .withLabel("Window Size"))      
    .add(DisplayData.item("period", period)       
      .withLabel("Window Period"))      
    .add(DisplayData.item("offset", offset)        
      .withLabel("Window Start Offset"));
}

ぜひ活用を!

Dataflow ユーザーの皆さんがパイプラインで display data をどのように活用されるのか、それをお聞きすることを私たちは楽しみにしています。ぜひフィードバックをお寄せください。

最後に、display data を利用する方法の大枠をあらためて示します。

  1. Google Dataflow SDK 1.6 を使ってパイプラインを作成します。
  2. Dataflow Monitoring Interface でパイプラインの display data をチェックします。
  3. 関数に display data を追加してみます。詳細は HasDisplayData に関する javadoc を参照してください。



JSON 形式の未加工のレスポンスを見てみることにします。


2. gcloud projects list --format="json"

[
  {
    "createTime": "2016-04-28T22:33:12.274Z",
    "labels": {
      "env": "test",
      "version": "alpha"
    },
    "lifecycleState": "ACTIVE",
    "name": "scesproject1",
    "parent": {
      "id": "297814986428",
      "type": "organization"
    },
    "projectId": "windy-bearing-129522",
    "projectNumber": "222844913538"
  },
  {
    "createTime": "2016-05-11T03:08:13.359Z",
    "labels": {
      "env": "test",
      "version": "beta"
    },
    "lifecycleState": "ACTIVE",
    "name": "scesproject2",
    "parent": {
      "id": "297814986428",
      "type": "organization"
    },
    "projectId": "canvas-syntax-130823",
    "projectNumber": "346904393285"
  }
]


この JSON 形式を基に、興味のある情報を選択して出力を好きなように加工したくなったとします。ここでは createdTime の順序で並べ替え、表示するプロパティを絞り込んで表形式に整形しましょう。


3. gcloud projects list --format="table[box,title='My Project List'](createTime:sort=1,name,projectNumber,projectId:label=ProjectID,parent.id:label=Parent)"


┌────────────────────────────────────────────────────────────────────────────────────────────────┐
│                                        My Project List                                         │
├──────────────────────────┬──────────────┬────────────────┬──────────────────────┬──────────────┤
│       CREATE_TIME        │     NAME     │ PROJECT_NUMBER │      ProjectID       │    Parent    │
├──────────────────────────┼──────────────┼────────────────┼──────────────────────┼──────────────┤
│ 2016-04-28T22:33:12.274Z │ scesproject1 │ 222844913538   │ windy-bearing-129522 │ 297814986428 │
│ 2016-05-11T03:08:13.359Z │ scesproject2 │ 346904393285   │ canvas-syntax-130823 │ 297814986428 │
└──────────────────────────┴──────────────┴────────────────┴──────────────────────┴──────────────┘

ヒント : --format='flattened' フラグを使用すれば、プロパティから JSON Path と値を抽出できます。

ボックスが不要で、日時の部分を年 - 月 - 日の形式でシンプルに表示する罫線なしの表を作りたい場合は、次のようにします。

4. gcloud projects list --format="table(createTime.date('%Y-%m-%d'),name,projectNumber,projectId)"
CREATE_TIME  NAME          PROJECT_NUMBER  PROJECT_ID
2016-05-11   scesproject2  346904393285    canvas-syntax-130823
2016-04-28   scesproject1  222844913538    windy-bearing-129522

もう少し複雑な整形を行ってみましょう。Compute Engine ゾーンのリストを作り、JSON 形式で表示します。


5. gcloud compute zones list --format="json"
{
    "creationTimestamp": "2014-05-30T18:35:16.514-07:00",
    "description": "us-central1-a",
    "id": "2000",
    "kind": "compute#zone",
    "name": "us-central1-a",
    "region": "us-central1",
    "selfLink": "https://www.googleapis.com/compute/v1/projects/windy-bearing-129522/
     zones/us-central1-a",
    "status": "UP"
  },

selfLink に注目してください。これが、パースしようとしている完全修飾名です。この場合も、gcloud は JSON 値を選択してそれを抽出し、パースする関数を提供して作業を助けてくれます。

selfLink.scope() 関数を使用することで、selfLink の URL セグメントの最後の部分を取り出してみましょう。

6. gcloud compute zones list --format="value(selfLink.scope())"
us-central1-a


この値は、.basename() 関数でも抽出できます。


7. gcloud compute zones list --format="value(selfLink.basename())"
us-central1-a

selfLink の /projects よりも後の部分は、次のようにして抽出します。


8. gcloud compute zones list --format="value(selfLink.scope(projects))"
windy-bearing-129522/zones/us-central1-a

GCP オブジェクトの中には複数の値を持つリソースが含まれていて、それらの値をすべて拾い出して並べなければならないことがよくあります。たとえば、特定の Compute Engine インスタンス向けに有効にされているすべてのスコープのリストを作ってみましょう。


9. gcloud compute instances list --format="json"
"serviceAccounts": [
      {
        "email": "[email protected]",
        "scopes": [
          "https://www.googleapis.com/auth/devstorage.read_only",
          "https://www.googleapis.com/auth/logging.write",
          "https://www.googleapis.com/auth/monitoring.write",
          "https://www.googleapis.com/auth/cloud.useraccounts.readonly"
        ]
      }
    ],


複数の値を持つリソースを 1 つにまとめます。


10. gcloud compute instances list --format="flattened(name,serviceAccounts[].email,serviceAccounts[].scopes[].basename())"

name:                         instance-1
serviceAccounts[0].email:     [email protected]
serviceAccounts[0].scopes[0]: devstorage.read_only
serviceAccounts[0].scopes[1]: logging.write
serviceAccounts[0].scopes[2]: monitoring.write
serviceAccounts[0].scopes[3]: cloud.useraccounts.readonly


複数の値を持つリソースには、値ごとに別々の行を与えるような表示方法もあります。




11. gcloud compute instances list --filter=name:instance-1 --flatten="serviceAccounts[].scopes[]" --format="csv(name,id,serviceAccounts.email,serviceAccounts.scopes.basename())"



name,id,email,scopes
instance-1,763097360168409044,[email protected],
devstorage.read_only
instance-1,763097360168409044,[email protected],
logging.write
instance-1,763097360168409044,[email protected],
monitoring.write
instance-1,763097360168409044,[email protected],
servicecontrol
instance-1,763097360168409044,[email protected],
service.management

同じ情報を読みやすく構造化された形式で表示します。


12. gcloud compute instances list --filter=name:instance-1 --format="table[box,no-heading](name,id,serviceAccounts:format='table[box,no-heading](email,scopes:format=\"table[box,no-heading](.)\")')"

┌────────────┬────────────────────┐
│ instance-1 │ 763097360168409044 │
└────────────┴────────────────────┘
    ┌────────────────────────────────────────────────────┐
    │ [email protected]│
    └────────────────────────────────────────────────────┘
        ┌──────────────────────────────────────────────────────┐
        │ https://www.googleapis.com/auth/devstorage.read_only │
        │ https://www.googleapis.com/auth/logging.write        │
        │ https://www.googleapis.com/auth/monitoring.write     │
        │ https://www.googleapis.com/auth/servicecontrol       │
        │ https://www.googleapis.com/auth/service.management   │
        └──────────────────────────────────────────────────────┘


次は、整形における最後のサンプルです。未加工の状態で表示すると以下のようになる情報において、複数の値を持つリソースをパースし、サービス アカウント キーとサービス アカウントを表示します。


13. gcloud beta iam service-accounts keys list --iam-account [email protected] --project mineral-minutia-820 --format="json"
[
  {
    "name": "projects/mineral-minutia-820/serviceAccounts/svc-2-429@mineral
-minutia-820.iam.gserviceaccount.com/keys/
04bd2d56d0cc5746b125d17f95d4b0dd654accca",
    "validAfterTime": "2016-03-11T05:30:04.000Z",
    "validBeforeTime": "2026-03-09T05:30:04.000Z"
  },
  {
    "name": "projects/mineral-minutia-820/serviceAccounts/svc-2-
[email protected]/keys/
1deb44e2f54328fc7bb316e5a87315e3314f114f",
    "validAfterTime": "2016-01-02T18:54:26.000Z",
    "validBeforeTime": "2025-12-30T18:54:26.000Z"
  },
....
]


それでは、.scope() を使って serviceAccount の部分だけを取り出し、最初の '/' で区切られた部分を segment(0) で取り出しましょう。


14. gcloud beta iam service-accounts keys list --iam-account [email protected] --project mineral-minutia-820 --format="table(name.scope(serviceAccounts).segment(0):label='service Account',name.scope(keys):label='keyID',validAfterTime)"


(click to enlarge)

フィルタ

次はフィルタです。フィルタを使えば、整形したいリソースだけを選択して処理できます。

たとえば、リソース(プロジェクト、VM など)にラベルが付いており、そのラベルが特定の値になっているプロジェクトだけを表示したいものとします。次の例は、label.env='test' label.version=alpha の場合です。



15. gcloud projects list --format="json" --filter="labels.env=test AND labels.version=alpha"

[
  {
    "createTime": "2016-04-28T22:33:12.274Z",
    "labels": {
      "env": "test",
      "version": "alpha"
    },
    "lifecycleState": "ACTIVE",
    "name": "scesproject1",
    "parent": {
      "id": "297814986428",
      "type": "organization"
    },
    "projectId": "windy-bearing-129522",
    "projectNumber": "222844913538"
  }
]


キーに変換を加えることも可能です。次の例では、createTime キーを日付だけに変換したうえでフィルタを適用しています。

16. gcloud projects list --format="table(projectNumber,projectId,createTime)" --filter="createTime.date('%Y-%m-%d', Z)='2016-05-11'"
PROJECT_NUMBER  PROJECT_ID            CREATE_TIME
346904393285    canvas-syntax-130823  2016-05-11T03:08:13.359Z

上で選択されているフィルタは、実際に JSON 構造(labels.env=test)を参照していることに注意してください。もちろん、フィルタはさまざまに組み合わせて使うことが可能です。

変換

変換を使えば、表示される値を直接操作できます。これまでに挙げたいくつかの例(.scope().basename().segment() など)でも、すでに使用しています。変換で面白いのは、.map() で結合、チェインできることと、複数の値を持つデータに適用できることです。

次の例をご覧ください。parent.id キーがあれば “YES”、なければ “NO” を出力するように条件に基づいて変換しています。このようにすれば、プロジェクトが特定の基準を満たしているかどうか(この場合は、Organization Node の一部かどうか)をすばやく見分けることができます。

17. gcloud projects list --format="table(projectId,parent.id.yesno(yes="YES", no=”NO”):label='Has Parent':sort=2)"
PROJECT_ID                Has Parent
mineral-minutia-820       NO
fabled-ray-104117         YES
rk-test-0506              YES
user2proj1                YES
user2project2             YES

18. gcloud compute instances list --format="flattened(name,serviceAccounts[].email,serviceAccounts[].scopes.map().scope())"
name:                         instance-1
serviceAccounts[0].email:     [email protected]
serviceAccounts[0].scopes[0]: devstorage.read_only
serviceAccounts[0].scopes[1]: logging.write
serviceAccounts[0].scopes[2]: monitoring.write
serviceAccounts[0].scopes[3]: cloud.useraccounts.readonly

スクリプト

最後に、gcloud コマンドを結合し、埋め込まれている情報を簡単に抽出するスクリプトを作ってみましょう。

次の例では、すべてのプロジェクトに含まれるサービス アカウントのすべてのキーのリストを表示します。そのためには、最初にすべてのプロジェクトを反復処理し、次にプロジェクトごとにすべてのサービス アカウントを取り出し、最後にサービス アカウントごとに作られたすべてのキーのリストを作らなければなりません。これは、基本的には反復処理のためのループをネストした形になります。

bash スクリプトでは次のようになります。



#!/bin/bash
for project in  $(gcloud projects list --format="value(projectId)")
do
  echo "ProjectId:  $project"
  for robot in $(gcloud beta iam service-accounts list --project $project --format="value(email)")
   do
     echo "    -> Robot $robot"
     for key in $(gcloud beta iam service-accounts keys list --iam-account $robot --project $project --format="value(name.basename())")
        do
          echo "        $key" 
     done
   done
done

Windows PowerShell では次のようになります。


foreach ($project in gcloud projects list --format="value(projectId)")
{
  Write-Host "ProjectId: $project"
  foreach ($robot in  gcloud beta iam service-accounts list --project $project --format="value(email)")
  {
      Write-Host "    -> Robot $robot"
      foreach ($key in gcloud beta iam service-accounts keys list --iam-account $robot --project $project --format="value(name.basename())")
      {
        Write-Host "        $key" 
      }
  }
}

レスポンス フィールドをパースして配列にまとめてから処理しなければならないこともよくあります。次の例では、インスタンスのサービス アカウント情報をパースして配列にまとめ、操作しやすくしています。

この例の場合、CSV の serviceAccounts[].scope フィールドは複数の値を持ち、個々の値はセミコロンで句切られている(separator=;)ことに注意してください。つまり、下の gcloud コマンドのレスポンス行は、name,id,email,scope_1;scope_2;scope_3 という形式になっています。このスクリプトは、基本的に例 12 のレスポンスをパースしています。



#!/bin/bash
for scopesInfo in $(
    gcloud compute instances list --filter=name:instance-1 \
        --format="csv[no-heading](name,id,serviceAccounts[].email.list(),
                      serviceAccounts[].scopes[].map().list(separator=;))")
do
      IFS=',' read -r -a scopesInfoArray<<< "$scopesInfo"
      NAME="${scopesInfoArray[0]}"
      ID="${scopesInfoArray[1]}"
      EMAIL="${scopesInfoArray[2]}"
      SCOPES_LIST="${scopesInfoArray[3]}"

      echo "NAME: $NAME, ID: $ID, EMAIL: $EMAIL"
      echo ""
      IFS=';' read -r -a scopeListArray<<< "$SCOPES_LIST"
      for SCOPE in  "${scopeListArray[@]}"
      do
        echo "  SCOPE: $SCOPE"
      done
done


以上で、gcloud コマンドの出力を効果的にフィルタおよび整形する方法がおわかりいただけたと思います。これらのテクニックは、gcloud のすべてのレスポンスに応用できます。未加工のレスポンスを見て、どのように加工したいかを考え、そのように整形するだけです。




■ 写真左から

Founder & CEO 岡田満雄さん
Co-founder & CTO 島田幸輝さん

■ 利用中の Google Cloud Platform サービス





クラウド サービスの一般化などを受け、近年ますます急増しているパスワード リスト攻撃(不正ログイン)。これを受け、多くのサービスがログイン時の CAPTCHA(キャプチャ)認証を採用するようになっていますが、肝心の文字が読みにくすぎるなど、これ自体が大きなストレスになっている面がありました。

ここに目を付けたのが Capy Inc. CEO の岡田満雄さん。5 年前、国内の大学でセキュリティについて研究していた岡田さんは、より使いやすい認証手段を発明することが大きなビジネスチャンスになるのではないかと考えました。

「セキュリティって、見るからに面白くなさそうな分野じゃないですか(笑)。ここで何か面白いことをやってやろうと試行錯誤していく中で、画像を使ったバーチャル エンクリプションを思い付いたんです。当初は 2 つのノイズ画像を組み合わせると意味のある文字列に変換されるというものだったのですが、これをパズル形式とすることで UI 的にも分かりやすいものにすることができました」(岡田さん)


するとこれが CES2012 selected by IEEE や、SFNewTech 2012 ベストデモ賞など、国内外で高い評価を獲得。エンジェル投資家からの助力が得られたこともあり、2012 年夏、大学の後輩である島田幸輝さんと共に Capy Inc. を立ち上げることになりました。そして翌年には、Capy Inc. 初のプロダクトとして「Capy パズルキャプチャ」をローンチ。以降も多くの賞を獲得するなど快進撃が続きます。



(Capy パズルキャプチャのサンプル。人にやさしく、ボットに厳しい認証に。)



こうして、徐々にセキュリティ業界内での存在感を高めていった Capy ですが、クライアントが増えるにつれ、費用面の問題が無視できない規模になってきました。同社ではそれまで業界最大手のクラウド プラットフォームを利用していたのですが、その料金設定がCapy の利用形態とかみ合わず、サービス規模の拡大に合わせてトータルコストが大きく跳ね上がってしまうことが分かってきたのです。

「そこで昨年夏頃、懇意にしていた方のアドバイスもあって、Google Cloud Platform への移行を決意しました。結論から言うと、それだけで約 2 割のコスト削減に成功。システムをプラットフォームに依らない設計にしていたこともあり、およそ 2、3 か月で引っ越しすることができました」(島田さん)

「具体的には現時点で毎月およそ数十万円のコスト減となっています。我々のようなスタートアップにとって、これは本当にうれしい。コスト面だけでなく、スケーラビリティ、そして安定性の面で、Google Cloud Platform に勝る選択肢はないのではないかと思っています」(岡田さん)

ちなみにこのシステム移行作業時、従来プラットフォームとの仕組みの違い(未公開の仕様)に起因するトラブルが発生したそうですが、これについても問い合わせへの対応が丁寧だったとお褒めいただいています。「Google さんって、もっと投げっぱなしなのかなと勝手に思っていたのですが誤解でした。すみません(笑)」(島田さん)

そしてその上で、島田さんたちが Google Cloud Platform への移行を決心したのにはもう 1 つ別の理由があるのだと島田さんは言います。

「実は『Capy パズルキャプチャ』とは別に、お客様からの依頼で不正アクセスにまつわるログ分析を行なっているのですが、それに Google BigQuery を使いたかったのです。もちろん、従来プラットフォームにもデータベース機能はありました。しかし、BigQuery なら、あらかじめインデックスを設定しておかなくてもとりあえずデータを突っ込んでおいて……という使い方が可能です。お客様からどのようなアクセス ログが提供されるか分からない業務のため、これが非常に魅力的だと感じていました」


2012 年夏の創業から順調に事業規模を拡大している Capy Inc.、「Capy パズルキャプチャ」をいろいろな場所で見かけるようになっているからも分かるよう、既に多くの企業で採用されるようになっています。特に重宝されているのが、重大な情報を扱うが、ユーザー側の IT リテラシーが必ずしも高くない金融や通信などの分野。誰もが知っているような大手クライアントでの導入実績も増えているそうです。

Capy Inc. では 1 年ごとに 1 製品という目安で新製品を開発中。先日も、人間にしか分からないような仕掛けで不正ログイン対策を行なう『Capy アバターキャプチャ』という新製品をリリースしたばかり。

「現在、研究しているのが、ユーザーの動作から本人性を確認するというもの。キーボードのタイピング速度や、マウスの動かし方のクセなどから誰が画面の前に座っているのかを把握するというものです。そう考えた時に役立ってくれそうなのが、昨年末に公開された TensorFlow。機械学習技術を上手に利用することで、よりユーザーにとって負担の少ないログイン処理を実現してみたいですね」(島田さん)

「“セキュリティは高価で複雑なものほど良い”というイメージを破壊していくのが Capy Inc.の目的。リーズナブルで分かりやすいセキュリティを提供し、それを使っていただくことで世の中を変えていきたいと考えています」(岡田さん)

$ gcloud beta debug logpoints create MarkovServlet.java:114 "Hello seed {seed}"



Stackdriver Debugger は、稼働中の全インスタンスにログポイントを適用し、コマンドで指定されたコード パスが次に実行されると、ログ メッセージを出力します。


ログポイントは、24 時間後に手動で削除されていなかった場合、自動的に解除されます。ログポイントのパフォーマンス オーバーヘッドは、コードに記述されたログ ステートメントと同じです。また、デバッグ コマンドはアプリケーションの稼働中のインスタンス数がいくつであっても機能します。

ログポイントは Stackdriver Debugger が有効なときに、稼働中のJava、Python、Node.js アプリケーションで利用できます。

上述したように、gcloud beta debug コマンドでは、ログポイントの作成に加えて、スナップショットの作成、一覧表示、削除が可能です。これにより、稼働中のアプリケーションのスタック トレースと変数が得られます。サポートされているすべてのデバッグ コマンドの一覧については、Cloud SDK Documentation をご覧ください。

ぜひログポイントをお試しください。そして、お気に召したらお知らせください。Stackdriver Debugger についてさらに詳しく知りたい方は Debugger ページをご覧ください。



Source : Wikimedia Commons


また、通常は時間がかかる動作を高速化することも、私たちの得意とするところです。クラウド ベースのコールド ストレージはその一例で、これはデータ バックアップのような、使用頻度の低いデータを安価に保存する優れた方法として登場しました。

Data Center Knowledge が先ごろ発表したレポートでは、Google Cloud Storage Nearline を含む、主要プロバイダー 3 社のコールド ストレージを比較しています

このレポートにおける重要な指摘として、「アクセス頻度の低いデータだからといって、必要なときに高速にアクセスしたくないわけではない」という点が挙げられます。Cloud Storage Nearline の場合、データの取り出しが開始されるまでの待ち時間はわずか 1 秒に過ぎません。

Google Cloud Platform(GCP)が皆さんのもとでどのように役立っているのか、それを知ることも私たちにとってはうれしい限りです。Dane Tidwell 氏は、新サイトの立ち上げを目前に控えた土壇場で、予定していた電子商取引エンジンに見切りをつけ、GCP で従来から利用していた WordPress とともに WooCommerce を運用することを決断したと述べています
「それでもサイトは無事始動し、万々歳です」(Tidwell 氏)


Share on Twitter Share on Facebook

下記のコードは SparkSession の使い方の一例です。SQLContext.read() を使わずに、Google Cloud Storage からデータフレームにデータを読み込んでいます。

val csvData = spark.read.csv("gs://my-bucket/project-data/csv")

Cloud Storage に格納されているデータに対して毎日実行する一連の Spark SQL クエリがあるとしましょう。Spark 2.0 プレビュー イメージを使って単純に新しいクラスタを作成すれば、プレビュー イメージ上で簡単にスクリプトをテストできます。約 90 秒のうちに、既存のユーザーやパイプラインに影響を与えることなく、テスト用のクラスタにアクセスできるようになるのです。

テストが終わったら、単純にクラスタを削除してください。このようにしてテストを行うと、動かなくなる部分に関する有用な情報を入手したり、パフォーマンスの違いを理解したりしながら、Spark 2.0 プレビューの新機能にアクセスできます。

Google Developers ConsoleGoogle Cloud SDKCloud Dataproc API のいずれかでクラスタを作成するときは、これからは “preview” イメージ バージョンを使うことをお勧めします。そうすれば、Cloud Dataproc 上で Spark 2.0 プレビューを使用できます。

Cloud Dataproc のバージョン選択の詳細については、Cloud Dataproc のドキュメントを参照してください。


Share on Twitter Share on Facebook