- やっているのは NodeScheduler のcomputeAssignments のようだ。
- locationAwareScheduling と isRemotelyAccessible() によって処理は分岐する、と考えておいて良い
- ここでしばしば紹介される minCandidates パラメータが登場する。コードを読む限り、これ、「Split を処理する Node の候補をいくつ選ぶか」というだけであるっぽい。
- 少なくとも minCandidates の数だけ Node を選び、その中から現在持っているタスクが少ない Node を選んでいるのである。
- だから、 minCandidates は別に並列度とは関係ないわけで、結果的にパフォーマンスに寄与するかどうかは微妙な感じもある。
- "max number of workers to run a stage in parallel (default: 10) " という説明は誤りなのではないか、という話。
- この minCandidates が node-scheduler.min-candidates であることも確認済みである。
- 指摘もあったが誰も反応していない https://groups.google.com/forum/#!msg/presto-users/Ft71bkwElkQ/v85ROXC82hIJ
- これが Hive Connector を使うときの肝で、このパラメータを HDFS のレプリカ数にしておけば、「できる限りローカルからデータを取る」ということができる。
Last active
August 13, 2017 01:50
-
-
Save descico/ee7a52732cee2e1dbd15 to your computer and use it in GitHub Desktop.
Presto の話。ただし最近ほとんど触っていなかったので情報は古いので注意せよ。
- 上に書いたとおりで、 Prestogres 経由で Presto にアクセス。使えることは確認済み。
- Hue のチューニング次第か。
- https://github.com/tagomoris/shib
- 直接確認したが、あくまで、クエリの実行と結果の取得のためで、 Presto クラスタの状況のモニタリングとかのためではない。
- 開発言語・実行環境は JavaScript + Node.js
- https://github.com/airbnb/airpal
- 開発言語等は Java + DropWizard + Apache Shiro
- DropWizard はウェブアプリケーションフレームワークである。個人的にとても興味があるが、まだ使ったことがない。
- Apache Shiro は authentication/authorization のフレームワークである。LDAP も使えるようだ。
- ただしこれも、クエリの実行と結果の取得のためであり、 Presto クラスタのモニタリングとかはできないようだ。
- https://github.com/sanjuusan/presto-console
- 俺が書いた。
- こんなものすごいオフィシャルっぽい名前はやめたいけど、いい名前が考えられない。
- どうせクエリの実行と結果の取得は Hue などがあるわけだし、ということで、そういう機能はない。
- サーバとクエリの一覧を出すだけである。クエリの中止もできる。
name | URL | クエリ実行 | クエリキャンセル | クエリ状況確認 | ノード状況確認 | 結果ダウンロード | その他情報 | 認証機構 | 認可機構 |
---|---|---|---|---|---|---|---|---|---|
純正ツール | https://github.com/facebook/presto/tree/master/presto-main/src/main/resources/webapp | × | ◯ | ◯ | ◯ | × | REST API と同じポートで / にアクセスすれば良い | × | ? |
Airpal | https://github.com/airbnb/airpal | ◯ | ? | ◯ | ? | △ | CSV での結果ダウンロードに S3 を使うらしい | Apache Shiro | ? |
Shib | https://github.com/tagomoris/shib | ◯ | ◯ | ◯ | × | ◯ | TSV, CSV でダウンロードできる。 | ◯(※1) | ◯(※2) |
yanagishima | https://github.com/wyukawa/yanagishima | ◯ | ? | ? | ? | ? | see also http://d.hatena.ne.jp/wyukawa/20150427/1430133743 | なし | × |
- | https://github.com/sanjuusan/presto-console | × | ◯ | ◯ | ◯ | × | 自作 | × | × |
Hue | ◯ | × | × | × | × | Prestogres 経由で使う | ◯ | × |
- ※1 ... https://github.com/tagomoris/shib/wiki/Authentication にあるとおり、mod_authnz_ldap を使えば LDAP も使える、という話になるようだ
- ※2 ... 独自実装で(とはいえ、どのみち独自実装になるだろうが)、データベース単位での指定、というような感じのようだ。
- 0.104 までは 0.13 だったが、 0.105 以降は 0.14 になっている。
- このバージョンが Hive のバージョンと対応しているのか知らないが、恐らく、対応しているのであろう。
- これが関係しているかはわからないが、 Hive 0.13 を使っている環境で Presto 0.115 を動かしたところ、 Hive テーブルと対応づいている SymlinkText の中身のパスが hdfs ではなく file で解釈され、結果、クエリが失敗した。
- LzoCodec が見つからない、と言われる話もある prestodb/presto#856
- ということで plugins/hive-hadoop2 の下に hadoop-lzo の jar をコピーするなどしたらとりあえずこれは解決した
- が、 select の結果で値が全部 NULL で表示されている、という問題が出ている
- ↑これ、単に create table の仕方が悪かっただけだった。デフォルトは列デリミタがない、という話。
- いろいろ原因はあるのかもしれないが、今のところ明確にわかっているのは、対象のファイルが bzip2 だと HIVE_CURSOR_ERROR と言われる。
- ごくまれにクエリが成功しているっぽいケースもあるが、基本的には失敗する。
- bzip2 について、ここでは "Inconsistent restults" になる、という話があがっている。 https://groups.google.com/forum/#!searchin/presto-users/bz2/presto-users/GVdMQwVEgCM/3oG0ImQYZ4YJ
- Sundstorm さんは "We don't actively support bz2 since it is not a very good compression algorithm" とも言っている。
- Presto で bzip2 が動かないことの言い訳というわけではないが、 Presto が CPU がボトルネックになるということを考えると CPU をとてもたくさん使う bzip2 は Presto 向きではない、と言っている。
- "You are trading off a small amount of disk space for 5-10x increase in CPU usage. Since Presto is typically CPU bound, this is a particularly poor choice for presto."
- "That said, there is no reason Presto shouldn't work with BZ2 compression."
- と思ったが、また別のやりとりでは... https://groups.google.com/forum/#!searchin/presto-users/bz2/presto-users/dXqfDIkrWbY/zMfO6kESTEcJ
- サンドストームさんが "Quick note on BZ2. Presto doesn't support bz2." と言っている。
- これは Hive そのものでもいろいろ制約があるはずなので、仕方なさそう。
- https://groups.google.com/forum/#!searchin/presto-users/hive$20insert/presto-users/gCIK_RavqFc/JHcCApTsM7QJ
- CREATE TABLE AS は使えるらしいので、それで済む要件ならば、良い...と思ったが、 CREATE TABLE 自体、 HiveConnector でできないのでは。
- Hive の CREATE TABLE は標準的な SQL とは違うので、それこそ無理な気はするが...
- と思ったが、実際に試したり、コードを見てみた感じ、 CREATE TABLE AS はできるっぽい。どういうことなんだこれは。。。
- 結局
HiveSplitManager#getPartitionSplits
をどうにかすればいいっぽい。 - で、あとは、クエリを投げたユーザーが誰なのか、というのを取り出せれば良い。が、取り出せそうな気配がない。
- issue これ prestodb/presto#2957 対応される気配がない。
- なお、基本的には worker を動かしているユーザーで HDFS にアクセスに行くようだ。 HDFS 側で group の制御をうまくできている場合、「とにかくアクセスできるようにする」ならば、 worker を動かすユーザーを適宜グループに属させるなどでコントロールすることもできよう。
- https://groups.google.com/forum/#!msg/presto-users/7aJ68pn0_oI/mzntBKvNeL4J
- "The default number of threads per box will be 4x the number of cores on your machine, but this is configurable with the option "task.shard.max-threads"." とのこと
- http://d.hatena.ne.jp/wyukawa/20140719/1405775230 にも同様の記述がある
- 確かにソースコードに "private int maxShardProcessorThreads = Runtime.getRuntime().availableProcessors() * 4;" という記述がある
- https://github.com/facebook/presto/blob/master/presto-main/src/main/java/com/facebook/presto/execution/TaskManagerConfig.java
- これ、性質的には「より性能を引き出すための設定」というよりは「性能を抑えるための設定」なのではないだろうか。特に DataNode や NodeManager と共存させようとなった場合には、これで抑えてやらないとすぐに負荷が上がり過ぎてしまいそうである。
- このパラメータである程度抑えるか、あるいは、 cgroups で CPU Affinity を指定するか、という話だろう。というか、 CPU Affinity を設定している場合、実際、どうでもよいような気もする。
- 結局のところ、たくさんジョブを並走させたとき、このパラメータが大きければ結果としてスループットも下がるだろうと考えられる。つまり、このパラメータとマシンパワーと実行速度のバランスをよく考えろ、という話になるのだろう。
- もう少し書くと、マシンのパワーあるいは cgroups による制限がハードリミットであり、次のこのパラメータでの絞り込みになる、という話だろうと。
- https://groups.google.com/forum/#!searchin/presto-users/task.max-memory|sort:relevance/presto-users/Hmb7L56vY6M/qC_0fPomZPsJ
- " Currently, Presto does distributed hash aggregations across a fixed number of nodes (configured via query.initial-hash-partitions which defaults to 8)." とある
- これは全体のノード数に応じて増やした方がよいのだろうか。
- https://prestodb.io/docs/current/release/release-0.55.html
- "If the value is larger than the number of machines available during query scheduling, Presto will use all available machines." とのこと。まあ、増やすに越したことはないのだろう。
- これを設定しておくと、 Presto を起動した際に、このディレクトリに以下をつくる
- Presto のインストールディレクトリの etc への symlink
- Presto のインストールディレクトリの plugin への symlink
- var ディレクトリ。そのなかに log, run がある。
- 設定していない場合、これはつくらずインストールディレクトリのを利用するようだ。
- ログが書き出される場所になるので、それをわけたければ便利だろうが、 etc, plugin への symlink は本当に必要なのだろうか?
- この値が JOIN できるテーブルの大きさの閾値になるような感覚の値である。
- なお、 -Xmx < task.max-memory の場合は、単にジョブが失敗するようだ。
- てっきり、 coordinator で保存するクエリの履歴の数かと思ったら、そうでもないっぽい
- あるいは query.max-age との兼ね合いなのかもしれない。詳しくは見ていない。
- こういうのはコード読んだほうが早そう...
- CLI のヒストリの数でもないようだ
- 文字通りっぽい
- これを 1 に設定し、何かクエリを走らせ、完了する前にもうひとつ実行すると、待たされる。最初のクエリが完了すると、2つめが動き出す。
- 待たされている時の state は QUEUED である。
- なおこれは、 airlift の AsyncSemaphore のパラメータとして使っており、つまり、並列数制御は Presto 側ではなくあくまで airlift に任せているようだ。
- 1 以上にしないとダメっぽい。0 にするとそもそも worker が起動しない。
- この値を 1 にして、1つクエリを実行し、終わるまでにもう1つ実行しようとすると
Too many queued queries!
と言われる。
- 末尾に / (スラッシュ)がつくとダメのようだ。
- see https://gist.github.com/electrum/7710544
- クエリを投げるのは例えば以下のように。クエリの最後に ; (セミコロン)をつけるとダメのようだ。
curl -H "X-Presto-Schema:default" -H "X-Presto-Catalog:hive" -H "X-Presto-User:bob" -d "select count(*) from users" http://presto-coordinator:8080/v1/statement
- 以下の手順で使うことになる
- クエリを /v1/statement に POST する
- レスポンスの nextUri を見る。終わっていればここに結果が入る。
- 2.のレスポンスの nextUri を見る。これをやると 1. の nextUri は見れなくなる。
- http://www.slideshare.net/taroleo/presto-as-a-service-at-treasure-data これの 13 ページあたりにも書いてある。
- どのような API があるか、は、ソースコードを "@Path" で grep すればわかる
name | method | 内容 |
---|---|---|
/v1/execute | POST | クエリの実行 |
/v1/node | GET | ノード一覧 |
/v1/node/failed | GET | コケてるノード一覧? |
/v1/query-execution/{queryId} | GET | クエリの実行状況 |
/ui/query-execution?{queryId} | GET | これはブラウザで見る用のクエリ実行状況。緑ノードが実行中、青ノードが完了。かっこいいけど微妙かもしれぬ。 |
/v1/query | GET | 実行したクエリの一覧。何件まで出してるかわからん。 |
/v1/query/{queryId} | GET | クエリの情報取得 |
/v1/query | POST | クエリの実行 |
/v1/query/{queryId} | DELETE | クエリのキャンセル |
/v1/query/stage/{stageId} | DELETE | ステージのキャンセル。ステージは1つ以上のタスクを持つ。また、ステージは0個以上のステージを持つ。ステージの親玉は outputStage であり、これはクエリと 1:1 対応である。 |
/v1/stage/{stageId} | DELETE | ステージのキャンセル |
/v1/statement | POST | クエリの実行 |
/v1/statement/{queryId}/{token} | GET | クエリの実行状況 |
/v1/statement/{queryId}/{token} | DELETE | クエリのキャンセル |
/v1/task | GET | 全タスク情報取得。タスクとは、実際に各 worker が処理する単位である。 |
/v1/task/{taskId} | POST | タスク生成? |
/v1/task/{taskId} | GET | タスク情報取得 |
/v1/task/{taskId} | DELETE | タスクのキャンセル |
/v1/task/{taskId}/results/{outputId}/{token} | GET | タスクの結果確認? |
/v1/task/{taskId}/results/{outputId} | DELETE | タスクの削除?中断? |
/v1/thread | GET | 動いているスレッドの状況。 |
/ui/thread | GET | 動いているスレッドの状況を可視化したもの |
/v1/jmx/mbean | GET | JMX の MBean の値全部。よって、かなりでかいレスポンス。これは Presto そのものではなく、 airlift で実装しているもの(jmx-http/src/main/java/io/airlift/jmx/MBeanResource.java) |
/v1/service/presto | GET | ノード情報。/v1/node よりわかりやすい |
- クエリ失敗時に自動的にリトライするように手が入っている
- ストレージが S3 上の MPC(MessagePack Columnar)である。MPCは高速化の一因となっている。
- 高速化については、まじめなパフォーマンスチューニングをやっている。以下に例を示す。
- YourKit https://www.yourkit.com/ でまじめにプロファイリングはしている。もちろん前提知識も多いだろうが。
- sun.misc.Unsafe パッケージを使い、 TypeProfile を生成しないように reflection でなんとかする、みたいなことをやっている。
- ルックアップテーブルを static イニシャライザでつくって、というようなこともやっている。
- GC は G1GC を使っている。これやらないと、ヒープ使用量がギザギザで、ピークのときに重いのがくるとヤバイ、とのこと。
- Presto の設定自体は、わりとふつうにやっている。もちろん min-candidates や initial-hash-partitions などは調整しているが。
- ASM http://asm.ow2.org/ を使って、バイトコードを操作して、というようなこともやっている。
- 実行速度が担保できるようなチューニングをしているようだ。
- coordinator はやはり SPOF であるが、彼らの場合、ストレージクラスタと処理クラスタが別であり、処理クラスタをクラスタごと切り替える、という運用方針なので、 coordinator もそれに従っている。つまり、 coordinator 自体が冗長構成を取れるように手を加えていたりはしない。
- http://prestodb.io/overview.html ここを読めという感じである。
- とにかくお手軽に使えそうな感じがある
- "Presto compiles queries to bytecode at runtime and thus produces many classes, so we enable class unloading." とのこと
- 0.87 から Java8 必須である。
- http://prestodb.io/docs/current/release/release-0.87.html
- Presto が使う java はどうやら環境変数 PATH 上にある java を使うようだ。 JAVA_HOME は関係ないっぽい。
- prestodb/presto#882
- https://groups.google.com/forum/#!topic/presto-users/jS3QLYx6j08 "Presto does not use JAVA_HOME." とのこと
- "Presto supports reading Hive data from the following versions of Hadoop:" とあるぐらいで Hadoop がらみは Hive が前提らしい。
- ファイルフォーマットとしては、 "The following file formats are supported: Text, SequenceFile, RCFile, ORC" とのこと。
- ここで ORC が出てくるのである。Parquet はでてこないのか。
- Hive の場合 Hive Metastore を使うとのこと。HMS を使わないという手はないようだ。
- Hive コネクタの場合は insert できないとのこと
- http://stackoverflow.com/questions/27291013/prestodb-insert-fails-with-null-error-message
- テーブルも作れない、とオフィシャルには書いてあるが、できてるっぽい事案がある。
- https://groups.google.com/forum/#!searchin/presto-users/permission/presto-users/nzaDMXP7AxA/Aq8vrb-kJoMJ
- HDFS 読み込みについて short circuit read には対応していないらしい。
- が、一方で、 short circuit read も良し悪しっぽいので、まあいいか、とも思うが、 Presto の場合、悪しの面が出るかどうか謎い
- 悪し、というのは、 DataNode を経由しないことで、かえって柔軟性が落ちるケースがある、という話である。ディスク故障のときとか。
- HiveConnector による HDFS へのアクセスはあくまで、 worker の起動に利用したユーザーが使われるようだ。なので、仮に worker を bob で起動し、 client を alice で起動していたとしても、 HDFS へのアクセスは bob によるものなので、 bob が見られるファイルにしかアクセスできない。
- Cassandra もストレージとして利用できるようだ。
- 調べたところ、 2015-01-15 現在(つまり、 0.89 時点)、クエリキャッシュもリザルトキャッシュもない
- もちろん HDFS 側で OS のキャッシュに乗る、とかはあるのだろうが。
- そもそも、 Presto が処理するデータのボリュームと、用途を考えると、クエリキャッシュはいいとしてもリザルトキャッシュは不要だろうし、クエリキャッシュも、ひょっとしたら「全体から見たら微々たるもの」かもしれない。
- そういう話題はあった https://groups.google.com/forum/#!topic/presto-users/CzB1kv_3dR8
- 2015-08 ごろに確認した情報では、クエリキャッシュはあるらしい。
- やっぱり coordinator は SPOF
- FULL OUTER JOIN は version 0.89 現在、サポートされていない
- worker を graceful に落とす方法がいまのところないっぽい
- パッチは書かれている https://groups.google.com/forum/#!searchin/presto-users/presto$20permission/presto-users/cmhx6HzJwFU/P-h7t0Mb9kcJ
- Non-equi joins not supported である。
- GROUP BY している場合、 select にあるキーは GROUP BY にもないとダメっぽい。
- つまり select foo, bar, count(*) のとき group by には foo, bar いずれも存在しないとダメっぽい。
- 全般的に、型のチェックは Hive に比べれば厳密のようである。
- どうやら Hive の場合は、型推論をしているようなところがある。シングルクォートで囲んだ数値を bigint として扱っているケースがある。
- 0.100 現在、まだ、 Hive テーブルでの decimal 型は使えない
- https://groups.google.com/forum/#!msg/presto-users/ROnD-M-7sNU/diewbOIYDlsJ
- 当然かも知れないが、 Presto の worker による CPU の使い方は、平均的に使っているときもあるが、 1 の CPU だけ 100% 使っている、という時間がある。
- データのローカリティは考慮している
- http://stackoverflow.com/questions/19924862/presto-hdfs-local-reads-and-preaggregation
- 回答者が Presto の開発者である。
- http://www.slideshare.net/frsyuki/prestogres-internals
- JDBC ドライバの話はやや触れられている http://togetter.com/li/590571
- この感じだと JDBC ドライバあるの知ってるけど作った、という感じっぽいな
- https://github.com/treasure-data/prestogres/blob/master/prestogres/ChangeLog これを見ると、 system catalog queries 限定でクエリキャッシュがあるらしい。
- テーブルの作成やパーティションの追加は Hive 側でやらないといけないが、どうも反映までには少し時間がかかるようである。
- Hive のメタデータの取得自体が数分に1回とかなのだろうか。強制的に更新できると良いのだが。
- というか、 JDBC ドライバは"the current JDBC driver is just a thin wrapper around the Presto REST interface"とのこと。
- http://stackoverflow.com/questions/20476965/prestodb-api-options-other-than-jdbc
- ただし2013年12月の情報。今は違うかもしれない。しかしこのことが Prestogres の開発の動機になっているのではないか。
- ソースコードを確認したが、 2015年2月現在も同様であった。
- https://github.com/treasure-data/prestogres
- デフォルトの設定だと Postgres は 127.0.0.1:5432 で起動する。
- やり方は https://medium.com/@ilkkaturunen/integrating-presto-with-hue-61702b244839 のとおり
- Hue と Prestgres を動かすサーバが異なる場合は、 "prestogres_hba.conf" に適切に設定を追加する必要がある。
- そもそも Hue から PostgreSQL にアクセスできる状態にしておく必要があり、それは "hue postgresql" などで検索してひっかかった情報を見ればよい。
- 例えば http://www.cloudera.com/content/cloudera/en/documentation/cloudera-manager/v4-latest/Cloudera-Manager-Installation-Guide/cmig_external_db_for_hue.html
- それ以外は特に注意点はなさそうである。
- オフィシャルドキュメント http://prestodb.io/docs/current/installation/deployment.html に従うだけで良い。
- 唯一の注意点は上にも書いているが Java8 の bin を環境変数 PATH に入れること、というぐらい。
- あとは、 Hadoop にも言えることだが、 ulimit -n の値つまり open files の値を増やしておけ、というぐらいであろうか。
- https://groups.google.com/forum/#!topic/presto-users/DDomQMbuJ98
- prestodb/presto#894
- prestodb/presto#1770
- hive.force-local-scheduling=true にして、全ノード(coordinator も worker も)再起動すれば良い
- ひょっとしたら coordinator だけでよかったかもしれない。少なくとも worker だけ再起動した場合は反映されなかった。
- ただし、このパラメータ、本当に "force" のようで、 worker が動いているノードにブロックが存在しない場合は、 "No nodes available to run query" になるようだ。
- ソースコードを追っていくと、 forcelocalscheduling という文字列でなく、 remotelyaccessible という文字列で検索することになる。読めばわかる。
- NodeScheduler#computeAssignments や selectCandidateNodes で見ている
- remotelyAccessible の否定は、確かに forceLocalScheduling であるな。そういうこともあるから、 forceLocalScheduling でないときでも、なるべくローカルを優先させる、という実装にしたいのだが、現在は、そういうケースでも selectRandomNodes を呼び出している
- cgroups を使えば良い。
- ネットワークの帯域制限のためには、これに加えて tc を使うことになる。
- see also https://gist.github.com/sanjuusan/6791c7c3045ad5848552
- cgroups の適用に際しては、 launcher のプロセスIDだけを tasks に書き出すだけではダメである。実際には大量のスレッドが生成されており、 Linux だとそれもまたプロセスIDが振られているためである。
- ps コマンドで -T オプションをつけて実行してみるとわかる。
- 正確には、 launcher を起動し、そこからスレッドが生成される前に tasks に追加していれば、そのスレッドは自動的に tasks に登録されるはずである。
- この事象を回避するのは簡単で、 libcgroup パッケージをインストールし、それに含まれる cgexec を利用して launcher を起動すれば良い、というだけである。
- libcgroup 自体は cgroups を利用する上で必須ではないが、上記のようなケースがあると、実質的には必須と言える。
- ただし、ネットワークに関しては、 Hive Connector では、結局、 DataNode からの pull によるネットワーク利用がメインになるため、 tc は意味はない(tc は送るときの帯域を絞るだけ)。この問題は、帯域を絞るという話ではなく、ローカリティの考慮で解決すればよい。ただし、これをやる場合、すべての DataNode のサーバで worker も動かす必要があるだろう。
- 他にリソースの制限方法として worker のスレッド数を "task.shard.max-threads" で絞るというのもあるのだろうが、 cgroups が使えるなら、それに越したことはないだろう。
- http://sssslide.com/www.slideshare.net/Ogibayashi/20140120-presto-meetup
- http://qiita.com/y-ken/items/400b7c70c324ac67af02
- http://www.slideshare.net/frsyuki/presto-hadoop-conference-japan-2014
- http://togetter.com/li/712461
- http://www.slideshare.net/frsyuki/hadoop-source-code-reading-15-in-japan-presto
- http://www.slideshare.net/frsyuki/understanding-presto-presto-meetup-tokyo-1
- http://www.slideshare.net/treasure-data/2014-1113prestodbtechshowcase
- HiveMetaStore を動かす。
- libcgroup を入れる。cgexec を使って launcher を起動するため。
- chkconfig cgconfig on しておく
- /etc/cgconfig.conf に presto 用の設定を追加しばらまき、 service cgconfig restart する。
- iperf を入れる。worker の実行自体には関係はないが、 cgroups net_cls + tc による帯域制限を確認するために
- tc による設定を各サーバで実行する
- 念のため iperf で設定のとおりの帯域制限ができているか確認する
- Presto の公式サイトにあるセットアップ手順をこなす。設定ファイルも用意する。
- hadoop-lzo の jar を plugin/hive-hadoop2 にコピーする
- 展開した presto のディレクトリを worker を動かすサーバにばらまく
- なお、 node.properties と config.properties はそれぞれノードごと・役割毎に異なるだろうから、 symlink で対処するのがよいだろう。
- deploy 用のスクリプトで symlink を適切につくれば良い。
- worker を動かすサーバで node.data_dir に指定したディレクトリをつくる
- もちろん Hadoop 関係のファイルもばらまいておく。というか、 DataNode が動いている場合は不要のはずではある。
- /etc/security/limits.d/presto.conf をつくる。実際はファイル名は任意。nofile, nproc をデカくする設定を仕込んでおく。そしてばらまく。
- PATH に Java8 の bin を通してから launcher を cgexec で起動する
- 上に書いてあるが、 Presto は JAVA_HOME は見ない。PATH しか見ない。
- ソースコードを "@Config(" で grep すれば良い
Error: Constraint violation with property prefix '': environment is malformed (for class io.airlift.node.NodeConfig)
- http://stackoverflow.com/questions/19915439/com-facebook-presto-server-prestoserverguice-creation-errors
- [a-z0-9][_a-z0-9]* でないとダメなのか
- /etc/security/limits.conf や limits.d 以下のファイルで設定するアレである。
- Presto もそれなりに使うようであり、また Presto を動かすノードでは DataNode も動かしていることを考えると、結局、 presto ユーザーでもつくり、それに対して設定するのが良さそうである。
function | 違い |
---|---|
from_unixtime | Presto では返り値は timestamp であり、直接 substr にかけられない。Hive では string を返す。 |
datediff/date_diff | Hive の datediff は「日」の差を取るだけ。 Presto の date_diff は差をとる単位を第一引数で指定できる。 |
substring/substr | Presto には substring はない。 substr はあるし、使い方も同じ。 |
= など各種比較演算子 | Presto は Hive と違って比較の際に型が不一致だととにかくエラーにするので、 cast する必要がある。 |
(調べている)
- https://groups.google.com/forum/#!topic/presto-users/hvWjpHrebPE
- 結局これ、独自の SerDe をつくっている場合、その jar を Presto coordinator の Connector の lib のディレクトリ(plugin/hive-hadoop2 ディレクトリとか)におけばよい。
- Java なので JMX でとるが、ぱっと見たところでは、生の JMX でのアクセスするためのポート番号などがわからない。
- しかし Presto の場合 JMX Connector があり、それを使えば SQL で JMX の情報を取り出すことができる。
- これはつまり Presto によって Presto の JMX を取り出すような話である。
- もちろん、 REST API でも JMX Connector を指定すれば、取り出すことができる。
- それ以外に https://github.com/xerial/presto-metrics このようなツールもある。
- これのコードを少し読む限り、ストレートに REST API で JMX にアクセスできるっぽい https://github.com/xerial/presto-metrics/blob/master/lib/presto/metrics/client.rb
presto:default> show tables from sys;
Table
---------
catalog
node
query
task
(4 rows)
- 以下のような構成の Presto クラスタで、以下のような特徴のファイルを、非圧縮、gzip、ORC(zlib)の3種用意し、あるキーで group by して count したときについて記す。
- worker 数は約 100 。それぞれのスペックは明かさないが、最近のサーバで使うようなスペックを想像してもらえば良い。
- ファイルは10列程度のタブ区切り(いわゆるTSV)
- 全体で1300万行ぐらい、group by のキーのカーディナリティは4万ぐらい
- 非圧縮でファイルサイズは6GB程度。gzip, ORC(zlib)はそれぞれ500MB程度、400MB程度、であった。
- ORC は default で内部を zlib (gzip と同等だろう)で圧縮している
- ORC は非圧縮の元々のブロック数の数だけファイル自体が分割されている。結果として、1ファイルあたり 10MB 程度であった。
- クエリの実行時間は、非圧縮、 gzip はそれぞれ10秒程度だったが、 ORC については概ね1秒未満であった。
- ということで、 Presto に限った話ではないだろうが、 ORC にするとより高速な集計が望めるケースは多いだろう。
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment