うちの環境だとambari管理なのでjava heapを増やす場合はAdvanced spark2-envのspark_daemon_memoryを増やせばOKです。ちなみにデフォルトは1GBです。それ以外はSPARK_DAEMON_JAVA_OPTSを設定します。下記のような感じ。ちなみにどっちもいじるとspark history serverでも有効になります。

export SPARK_DAEMON_JAVA_OPTS="$SPARK_DAEMON_JAVA_OPTS -javaagent:/usr/local/lib/jmx_prometheus_javaagent-0.11.0.jar=20015:/usr/local/etc/jmx_exporter_spark.yaml -Xloggc:/var/log/spark2/gc_%p_%t.log -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps"

で、GCログを見ると以下のようになってる。

2019-03-08T12:54:41.265+0900: 89936.447: [GC (Allocation Failure) [PSYoungGen: 1225762K->14514K(1689088K)] 3800753K->2593725K(6508032K), 0.0097586 secs] [Times: user=0.16 sys=0.00, real=0.01 secs]
2019-03-08T12:55:25.468+0900: 89980.650: [GC (Allocation Failure) [PSYoungGen: 1228978K->11218K(1225728K)] 3808189K->2593142K(6044672K), 0.0093735 secs] [Times: user=0.14 sys=0.00, real=0.01 secs]
2019-03-08T12:55:57.112+0900: 90012.294: [GC (System.gc()) [PSYoungGen: 937862K->8066K(1673216K)] 3519786K->2591721K(6492160K), 0.0087363 secs] [Times: user=0.15 sys=0.01, real=0.01 secs]
2019-03-08T12:55:57.121+0900: 90012.303: [Full GC (System.gc()) [PSYoungGen: 8066K->0K(1673216K)] [ParOldGen: 2583655K->1464248K(4818944K)] 2591721K->1464248K(6492160K), [Metaspace: 154960K->154935K(1187840K)], 1.3926389 secs] [Times: user=32.27 sys=0.12, real=1.39 secs]
2019-03-08T12:56:37.166+0900: 90052.347: [GC (Allocation Failure) [PSYoungGen: 1220096K->3678K(1224192K)] 2684344K->1467927K(6043136K), 0.0078803 secs] [Times: user=0.11 sys=0.00, real=0.01 secs]
2019-03-08T12:57:20.567+0900: 90095.748: [GC (Allocation Failure) [PSYoungGen: 1223774K->5886K(1647104K)] 2688023K->1470135K(6466048K), 0.0088429 secs] [Times: user=0.11 sys=0.00, real=0.01 secs]
2019-03-08T13:01:22.166+0900: 90337.347: [GC (Allocation Failure) [PSYoungGen: 1230590K->3231K(1228288K)] 2694839K->1467479K(6047232K), 0.0100951 secs] [Times: user=0.13 sys=0.01, real=0.01 secs]

Full GC (System.gc())ってなんじゃらほいって思ったけど、どうもcontext-cleaner-periodic-gcスレッドでSystem.gc()呼んでる模様 https://github.com/apache/spark/blob/v2.1.1/core/src/main/scala/org/apache/spark/ContextCleaner.scala#L128

なおambari管理だとspark thrift serverが不安定になると二度的に再起動してくれるので便利

2019-03-05

release yanagishima 19.0(support sparksql)

yanagishimaというpresto web uiを作っていて気づけばhive, elasticsearchに続いてsparksqlをサポートしたので今回はその辺をちょっと書いてみようと思います。 https://github.com/yanagishima/yanagishima

sparkではspark thrift serverなるものを起動すればHive JDBC Driverを使ってsqlをsubmitすることができます。 https://spark.apache.org/docs/latest/sql-distributed-sql-engine.html

うちの環境だとsparkをyarn上で動かしています。この場合spark thrift serverを起動すると一つのyarn applicationが立ち上がります。このApplication Masterのリンクをクリックするとsparkのweb uiを見ることができます。 http://sparkthriftserver:4040にアクセスしても同じ。

複数のユーザがこのyarn applicationを共有する感じになります。 containerというかexecutorの数はsparkのdynamic allocationの仕組みで動いていてdefaultだとmaxでも10個のcontainerしか動かないので、うちの環境では増やしてます。 spark.dynamicAllocation.minExecutorsを50にしているので最初は50個のcontainerが動きます。ちなみにspark thrift serverで一つ使うので合計すると51個動きます。

またspark thrift serverはdefaultだと1GBのメモリで動いていてOutOfMemoryに遭遇したので4GBに増やしました。 https://community.hortonworks.com/content/supportkb/233822/sparkthriftserver-crashing-with-java-heap-outofmem.html

うちはHDP環境なのでAmbariでSPARK_DAEMON_MEMORYをいじって設定しました。

なお僕はyanagishimaを作って運用して4年ぐらい経ちますが、この手のビッグデータを扱うsqlフロントエンドツールではジョブをsubmitして結果を表示するだけでは不十分です。

ジョブの進捗状況が見れて、クエリを途中でキャンセル出来ることが重要です。また全ジョブの実行状況が見れることも管理上必要です。

そしてつくづく分かったのはprestoはapiというかアーキテクチャからして上記の要件を実装しやすいが、他はそれが簡単ではないということです。 prestoの場合はJDBCではなくpresto-clientを使えばジョブをsubmitしてすぐにquery idを取得できます。そしてこのquery idを使ってapiをたたけば途中の進捗状況も取れますし、クエリのキャンセルも可能です。ジョブの一覧を見るのも容易です。

一方、Hive JDBC Driverを使うとStatement#cancelを使えばクエリのキャンセルこそできますが、進捗状況や全ジョブ一覧を知るには一工夫必要です。 Hive on MapReduceであればyarn rest apiを使えば割といろいろできますが、自分が投げたジョブがどのジョブかを判断するのは簡単ではありません。

yanagishima hiveではshibを真似してmapreduce.job.nameをいじってyanagishima-hive-wyukawa-20190305_060438_9235eaae6f11cd0ff3de907771b28914みたいなユニークなidを採番して設定してトラッキングします。このidは自前で採番します。prestoとはここが違います。

Hive on Tezだと同じことができないので進捗状況を知ることができません。

sparksqlの場合はどうするかというとすごく泥臭いことをしました。

sparkもapiはありますが、十分ではありません。 https://spark.apache.org/docs/latest/monitoring.html https://medium.com/@an_chee/how-to-get-spark-metrics-as-json-using-spark-rest-api-in-yarn-cluster-mode-52a88002c826

sparkのjob idがわかればnumCompletedTasks / numTasksで進捗状況がわかります。問題はどうやって知るかです。

http//[resourcemanager]:8088/proxy/[spark application id]/api/v1/applications/[spark application id]/jobs をたたけばジョブ一覧が取れます。

以下は一つのジョブの例です。

  "jobId" : 15,
  "name" : "run at AccessController.java:0",
  "submissionTime" : "2019-02-21T02:23:54.513GMT",
  "stageIds" : [ 21 ],
  "jobGroup" : "b46b9cee-bb9d-4d10-8b44-5f7328ce5748",
  "status" : "RUNNING",
  "numTasks" : 1093,
  "numActiveTasks" : 1,
  "numCompletedTasks" : 488,
  "numSkippedTasks" : 0,
  "numFailedTasks" : 0,
  "numActiveStages" : 1,
  "numCompletedStages" : 0,
  "numSkippedStages" : 0,
  "numFailedStages" : 0

これだけだと誰がどんなクエリ投げたのかわからないですが、http://sparkthriftserver:4040/sqlserver のSQL StatisticsのところにUser, JobID, GroupID, Start Time, Finish Time, Duration, Statement, State, Detail があって、ここのJobIDと上記のjobGroupを紐づければ誰がどんなクエリを投げたかわかります。やったね。だがしかしapiが無いようなので仕方なくhtml parseしました。。。

ともあれ、そんな感じで作りました。

sparkも今後rest apiが充実するといいなあというか、そういう状況だからApache Livyが存在しているという気もする。遠い昔まだhadoop 1の時代にrest apiがなかったのでHuahin Managerがあったように。

2018-12-30

ベジタブルマラソン走ってきた

記録はネットタイムが1時間51分35秒。ちなみに2017年が1時間47分39秒、2016年が1時間49分33秒。2015年が1時間44分17秒、2014年が1時間42分7秒です。

練習不足なのでこんなもんですかね。走っている時はエイドのキュウリ、ミニトマト、パイナップル、オレンジ、レモン、グレープフルーツ、チョコ、梅干しを少々、走り終わった後は豚汁、熊谷駅で満州の餃子とチャーハンを食べて帰ってきました。餃子は王将の方がうまいな。

この大会は12時スタートで人数もそんなに多くなく気軽に参加できる良い大会です。
5年連続で参加してますが、毎回良い天気ですが若干風があって寒かった。。

今日が走り納めです。runtasticによると今年は1285km走ったらしい。2017年は1471km、2016年は1476km、2015年は1633kmです。

今年はあんまり走れてなかったけど、来年はもうちょっと走ろうかな。

2018-12-03

那覇マラソン走ってきた

記録は5時間6分57秒で、ワーストなのはある程度事前に予想できたけど5時間オーバーなのは想定外。

理由は練習不足以外にも、思ったより暑く最高気温が27度を超えたらしい。元々完走率が低い大会で今回も60%ほど。地味にアップダウンもあってコース的にもタフ。

後半はしばしば歩いてしまったし、20回以上フルマラソン走ったけどこんなにきつかったのは、初マラソンで膝やった時以来だな。

びっくりしたのはエイドでゴミ箱がほぼなくて道路にすてる前提になっていることと、立ち小便が多かった事。あとランナーが多過ぎてちょっと走りづらいかな。

エイドに関しては公式のものは少なくてほぼ私設エイドに頼っているのが実態で、僕もお世話になったけど、私設エイドが無かったら完走は難しかったと思う。

私設エイドはもちろんありがたいんだけど、参加費上げてランナー減らしてもっとクオリティ上げた方が良いのではと思ってしまった。まあずっと続いてるし評価の高い大会なのでそういうもんだと思った方がいいんでしょうけど、他の大会と雰囲気違ったんでちょっとびっくりしました