Prestoについての個人的まとめ その１

 

いわゆるビッグデータを解析するときに使うツール(DWH)といえばどんなものがあるだろうか？

私見ではあるが以下のものが使われるのが一般的ではないだろうか。

 

  • BigQuery
  • RedShift
  • Hive
  • Presto

 

今回は上記の中からPrestoについての特徴について個人的なメモを記したい。

Prestoとは

prestodb.io

そもそもPrestoとは何か。

詳細については公式のドキュメントに譲るとして、ざっくりした説明としてはFacebookが開発したHiveよりも高速にクエリを実行してくれるクエリエンジンの事である。ここで注意して頂きたいのは、所謂DWHとは違ってPresto自体はデータを保持しておらず、データを処理する分散クエリエンジンであるという点である。

そのためデータはS3なりCassandraなり別の場所に保存しておく必要がある。逆に言えば、データ自体をPrestoで管理する必要はない。

かわりに後述のConnectorを利用してデータを保存している対象に接続する必要がある。コネクターさえあればどんなデータソースにもクエリを投げることは可能だ。

Prestoの特徴

一般的にDWHはデータの持ち方(列指向)のデータの持ち方をすることでIO処理を減らし、高速化する。対してPrestoは前述の通り、データ自体を保持していない。つまり、一般的なDWHのようなデータの持ち方での処理の高速化はできない。

代わりに中間処理をメモリに保持することで処理の高速化を実現している。

そのためクエリレスポンスがHiveと比較するとかなり良い。

またそのためインタラクティブなデータ分析などに向いている。

(より正確に言うと、Hiveがインタラクティブな処理に向いていないため、インタラクティブな処理を実行するためのクエリエンジンとしてPrestoが開発された。)

逆に言ってしまえばメモリを大量に消費するようなクエリをPrestoで実行すると、メモリ不足により処理が失敗してしまう。歴史的にはHiveを代替するためにPrestoがあるというよりもHiveの苦手な領域を補うためにPrestoが存在すると考えるほうが正しく、両者は補完関係にあると考えるのが良いのではないかと思われる。

 

Prestoのアーキテクチャ

サーバーのタイプとしては以下の2種類が存在する。

  • Coordinator(コーディネーター)
  • Worker(ワーカー)

Coordinatorについての説明は以下のとおりである。

The Presto coordinator is the server that is responsible for parsing statements, planning queries, and managing Presto worker nodes. It is the “brain” of a Presto installation and is also the node to which a client connects to submit statements for execution. Every Presto installation must have a Presto coordinator alongside one or more Presto workers. For development or testing purposes, a single instance of Presto can be configured to perform both roles.

The coordinator keeps track of the activity on each worker and coordinates the execution of a query. The coordinator creates a logical model of a query involving a series of stages which is then translated into a series of connected tasks running on a cluster of Presto workers.

Coordinators communicate with workers and clients using a REST API.

(拙訳)

Prestoのコーディネーターはクエリのパース、実行計画の作成、およびワーカーノードの管理の役割を担う。コーディネーターはPrestoのインストール際の頭脳と呼ぶべきものであり、また同時にクエリを実行したいClientが接続をするノードでもある。1または2台のワーカーノードともにPresoコーディネーターが必ずインストールされる。テストまたは開発用の用途であれば、一つのPrestoインスタンスが両方の役割(コーディネーターとワーカー)を担わせるように設定することが可能だ。

コーディネーターは、各ワーカーの状況をトラックし、またクエリの実行を制御する。コーディネーターは一連のステージを含んだクエリの論理モデルを作成する。またその論理モデルは、ワーカーのクラスター上で実行される一連のタスクにさらに分解される。

コーディネーターはREST APIを通じてワーカーサーバーと通信を行う。

 

ざっくりと言えば、コーディネーターはワーカーのマネージャーのような存在である。

Worker

A Presto worker is a server in a Presto installation which is responsible for executing tasks and processing data. Worker nodes fetch data from connectors and exchange intermediate data with each other. The coordinator is responsible for fetching results from the workers and returning the final results to the client.

When a Presto worker process starts up, it advertises itself to the discovery server in the coordinator, which makes it available to the Presto coordinator for task execution.

Workers communicate with other workers and Presto coordinators using a REST API.

 (拙訳)

Prestoのワーカーはタスクの実行とデータ処理の役割を担っている。ワーカーノードはデータをコネクターから取得し、中間データをワーカー同士で交換している。コーディネーターはワーカーから結果を取得し、クライアントに返す役割を担っている。

Prestoのワーカープロセスが起動すると、自分自身をコーディネーターのディスカバリーサーバーにアドバタイズして、Prestoワーカーからタスク実行の通信が受け取れるようにしている。

ワーカーは自身以外のワーカーやコーディネーターとREST API経由で通信をしている。

 ワーカーは実際のデータ処理部分を担っている。

 

まとめ

  • PrestoはDWHではなくクエリエンジン
  • コネクターを使って、データソースに接続する
  • インメモリ処理のためHiveに比べてレスポンスが早い
  • コーディネーターがクエリのパース、実行計画の作成ワーカーノードの管理を行う
  • ワーカーがタスクの実行とデータ処理を行う。

Embulkの使い方について

はじめに

目的

現在の会社ではEmbulk関連の問い合わせを受けることが多い。この記事は自身の備忘録を兼ねて書いている。

Embulkって何？

EmbulkはFluentdやMessage Packで有名な古橋さんが開発した、バルク処理用のOSS。Fluetdだと細かくデータを転送するのには向いているが（いわゆるストリーミング処理）、データベースのテーブルまるごとや巨大なログ・ファイルの転送には向いておらず、Embulkはその課題を解決するためのもの。(バルク処理)

Embulkを使うメリット

  • 自動的にInput fileの形式を推測してくれる機能（あくまで推測する機能）
  • ビックデータを並行処理・分散処理してくれる
  • トランザクション処理があり、中途半端にデータが投入されている危険性をなくしてくれる。(All-or-Nothing)

  • 途中から再開できる。

Embulkの使い方について

  • 前提条件 : java8の環境が必要。

細かい動作検証はしていないが、java8であればはopenjdkでもoracle jdkでも基本的には

問題ない。

1. embulkをインスールする。

このページをみて各自の環境に合わせてバイナリーをインスールしてください。

github.com

 

2. seed.ymlを作る。

まず基礎となるseed.ymlを作る。まずは気軽に以下のようなイメージで作ってもらえば問題ない。

 

in:
  type: file
  path_prefix: ./mydata/csv/
out:
  type: elasticsearch
  index: embulk
  index_type: embulk
  nodes:
    - host: localhost

 

Embulkのファイルには項目が以下の4つ存在する。

  • in : input plugin optionsについてのconfを記載する箇所。
  • out : output plugin optionについて記載する箇所
  • filters : filter plugin optionについて記載する箇所。

上記のseed.ymlに関していえば、inはlocalのファイルを指定しており、outではoutput先のelasticsearchのpluginを指定している。

type以降の書き方に関しては各pluginに依存しているため、それぞれのpluginのドキュメントを参照しながら必要な情報について記載をする必要がある。

 

基本はinとoutがわかっていれば問題なのだが、実際の運用ではfilterは非常に重要となる。例えば、Treasure Dataの仕様としてHeaderが大文字のcsvやテーブルの取り込みは推奨されていない。これを行うと、同じカラム名のはずなのに別カラムとして判断されて、小文字のheader名_xなどのカラムができてしまう。そういった場合にはぜひfilter pluginを使用してほしい。

 

in:
  type: file
  path_prefix: ./mydata/csv/
out:
  type: elasticsearch
  index: embulk
  index_type: embulk
  nodes:
    - host: localhost
filters:
- type: rename
  rules:
  - rule: upper_to_lower
  - rule: character_types
    pass_types: [ "a-z", "0-9" ]
    pass_characters: "_"
    replace: "_"
3. load.ymlを作る。
seedができたらload.ymlを作ろう。

embulk guess ./mydata/seed.yml -o config.yml

このコマンドを実行するとconfig.ymlが自動生成される。こんな感じである。
in:
  type: file
  path_prefix: ./mydata/csv/
  decoders:
  - {type: gzip}
  parser:
    charset: UTF-8
    newline: CRLF
    type: csv
    delimiter: ','
    quote: '"'
    escape: ''
    null_string: 'NULL'
    skip_header_lines: 1
    columns:
    - {name: id, type: long}
    - {name: account, type: long}
    - {name: time, type: timestamp, format: '%Y-%m-%d %H:%M:%S'}
    - {name: purchase, type: timestamp, format: '%Y%m%d'}
    - {name: comment, type: string}
out:
  type: elasticsearch
  index: embulk
  index_type: embulk
  nodes:
  - {host: localhost}

4. Previewする。(option)
dry runとして以下のコマンドを実行すると、どんなデータが取り込まれるのかがわかる。

embulk preview config.yml 

5. embulkを実行する。
embulk run config.yml -c diff.yml

-c diff.ymlって何かというと、これは増分バルクインポート用のファイルであり、一回だけのインポートであればこのオプションは不要である。
ではdiff.ymlになにが入るかというと、

in: {last_path: mydata/csv/sample_01.csv.gz} out: {}
という内容が記録される。

重要なのはlast_pathに入っている値である。このlast_pathは前回取り込み時のファイル名を記録している。次回実行時にはこのlast_pathより新しいファイルが取り込まれるようになる。ぜひ役立ててほしい。



最後に

これらの内容はembulkのドキュメントからも確認できるので、困ったことがあったらそっちを確認してほしい。

 

www.embulk.org

 

 

 

GDC参加の感想

 

GDCについて

GDCとは世界最大のゲーム開発者の祭典の事である。

例年、サンフランシスコのmoscone centerで開催される。

詳細については、公式サイトを参照してください。

 

www.gdconf.com 

 

ちなみに参加費用は非常に高額。

すべてのSession,Conferenceに参加するために必要な金額は$2,499。

展示会に参加するだけでも$399もする。

単なる展示会やナレッジ共有の場ではなくて、リクルーティングの場でもあるようで各社がこぞって人材募集をかけていた。

 

参加セッションの概要

 

セッションに参加したのは、3月18日から3月21日の4日間。

 

AWSによるクラウドの使い方のセッション

機械学習／AIのセッション

オンラインマルチプレイの実装方法についてのセッション

 

 

現在のゲーム開発トレンド

これだけみると一般的なシステム開発とトレンドは正直変わらない。

 

感想

ゲーム開発もシステム開発と同じノリでトレンドが取り入れられている。ただし、Web系に比べると開発期間が長くなりやすので、世間一般よりも技術トレンドを取り入れるのにやや時間がかかるのではないだろうか。

 

 

VPC内のEC2のDNSを変更する方法

まず基本的にVPC内のEC2インスタンスはAWSのDNSが設定されている。

 

VPNやDirectConnectでつないでいるAWSの環境のサーバーがオンプレミスのDNSサーバーを使いたいときがある。

 

今回はそういったときに必要な手順についての説明

 

2. VPCのDNS設定について

公式ページより確認

docs.aws.amazon.com

上記ページより抜粋

Amazon が提供するプライベート (内部) DNS ホスト名はインスタンスのプライベート IPv4 アドレスに解決され、ip-private-ipv4-address.ec2.internal の書式が us-east-1 リージョンに使用され、ip-private-ipv4-address.region.compute.internal の書式が (private-ipv4-address が逆引きルックアップ IP アドレスとなっている) 他のリージョンに使用されます。プライベート DNS ホスト名は、同じネットワーク内のインスタンス間の通信に使用できます。ただし、インスタンスが含まれるネットワークの外部の DNS ホスト名を解決することはできません。

 

このDNSの設定が何で行われているかといえば、DHCPである。

そのため、DHCPの設定を変更すればデフォルトのDNS設定が変更できるようになる。

 

3. 設定方法

変更に必要な作業はこれだけ。

　　1. DHCPオプションセットの作成

aws ec2 create-dhcp-options --dhcp-configuration "Key=domain-name-servers,Values=10.2.5.1,10.2.5.2"

　　2. VPCのDHCP設定の変更

associate-dhcp-options
--dhcp-options-id <value>
--vpc-id <value>

 

たったこれだけでいけます。

 

 

 

 

 

Terraformを社内の人に使ってもらえるように準備している話

社内でInfrastructure as Codeの推進活動をしており、TerraformなどのOSSを社内に浸透させたいと思っている。

 

それにあたって課題になっているのがProxyの問題だ。

 

Terraformを社内の開発環境にインストールして利用することを考えていたが、途中で問題にぶち当たった。

 

ProxyやFWである。

Terraformは便利なツールだがそれ単体ではクラウドのリソースを構築することはできない。providerというpluginを入れる必要があるのだ。

 

よくある話だが、弊社ではProxyによってアクセスできるサイトは制限されているし、FWでSSHはできないようになっている。

 

特に今回問題になったのが、SSH！

Terraformはリソースを作成するときにどうやら自動的にproviderをダウンロードしてくれるらしい。が、社内NWの都合によって通信が遮断される。

ダウンロードが失敗するのだ。

 

これはまずい。非常にまずい。

 

社内ツールを提供するにあたって、気にしなければいけないことは使いやすさである。使いにくいツールは即座に使われなくなり、意味をなさなくなる。

 

最初はどうにか突破をしようとしたが、解決方法がなく断念。。。

 

代わりに採用したのが、CI環境での実行である。

 

CI環境だと使い捨てだから、環境情報を共有できないのでは？とおもったが、実は問題ない。TerraformにはBackendという機能がある。

 

www.terraform.io

 

Terraformはtfstateというファイルで、作成しようとしているリソースの状況を管理している。

複数人でTerraformを利用する場合に問題となるのは、tfstateファイルの管理だ。

 

というのもtfstateファイルは、変化するスピードが早いものだ。これをGitなどのVCSなどで管理すれば目も当てられない悲劇が多発するのは想像にかたくない。

 

話をもどすが、Terraformの実行環境をSaaSのCI環境に移した。

この場合は特に社内NWを意識する必要もないし、実行環境を統一することができる。

 

つまり、社内の人が環境準備をせずにいきなりTerraformにふれることができるようになったのだ。

 

もし、Terraformを利用しようとしたときに同じような悩みを抱えている人がいれば、CI環境での実行を考えてみてほしい。

多分うまくいく。

 

あ、ちなみにお金のある人はTerraform Enterpriseを契約してください。

 

www.publickey1.jp