uokadaの見逃し三振は嫌いです

ここで述べられていることは私の個人的な意見に基づくものであり､私が所属する組織には一切の関係はありません｡

メモ書き, Mavenでno dependency information availableエラーが出来た時の対処法

Java 
% ./mvnw clean compile package
/path/to/presto-sample-udf
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building presto-sample-udf 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[WARNING] The POM for org.eclipse.jetty:jetty-alpn-java-client:jar:9.4.6.v20170531 is missing, no dependency information available
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.108 s
[INFO] Finished at: 2018-02-11T14:14:08+09:00
[INFO] Final Memory: 15M/50M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project presto-sample-udf: Could not resolve dependencies for project io.github.yuokada:presto-sample-udf:jar:1.0-SNAPSHOT: The following artifacts could not be resolved: com.sun:tools:jar:1.8, org.eclipse.jetty:jetty-alpn-java-client:jar:9.4.6.v20170531: Could not find artifact com.sun:tools:jar:1.8 at specified path /Library/Java/JavaVirtualMachines/jdk-9.0.1.jdk/Contents/Home/../lib/tools.jar -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException

JDK9でビルドでしていたのが原因でエラーになっていたみたい。 Macだとこんな感じでJDK8を使うように環境変数を設定してやると上手くうごくようになる。

export JAVA_HOME=`/System/Library/Frameworks/JavaVM.framework/Versions/A/Commands/java_home -v "1.8"`

Java8-mavenを使ったユニットテストでTimezoneを指定する

Java Presto

手元のMacbook Proで通っていたユニットテストがTravis-CI上で実行したら失敗したので原因を探っていたところ、 Travis-CI上だとタイムゾーンの設定が違っていることが分かった。

stackoverflowでmave-surefire-pluginを使って指定する方法があったのでそれを試してみた。

Maven Surefire Plugin – Introduction

maven-surefire-pluginを下のような形でsystemPropertyVariables -> user.timezone をセットする。
たった、これだけでTimezoneを上書き出来る。

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.20.1</version>
                <configuration>
                    <systemPropertyVariables>
                        <user.timezone>Asia/Tokyo</user.timezone>
                    </systemPropertyVariables>
                </configuration>
            </plugin>

仕事で作ったPrestoのプラグインで試してみたらZoneId.systemDefault()の戻り値が指定した値に上書きされてユニットテストが通るようになった。

Change GregorianCalendar to ZonedDateTime by yuokada · Pull Request #3 · yahoojapan/presto-audit

ただ、stackoveerflowの記事をよく読むとうまくいかない的なことが書いてあるんだがうまく動いた理由はなんでだろう？

疑問は残りつつも一旦これで対応完了としたい。

ランダム秒スリープしてからサーバーを再起動する

development

＊ bashとzshで動作確認済み。

$ sleep $(($RANDOM % 180)) && sudo shutdown -r +2

このコマンドを実行すると0~179秒スリープした後にそこからさらに2分待ってマシンを再起動させます。

$RANDOMとはどんなものかman bashの中にある説明を見てみましょう。

       RANDOM Each  time  this parameter is referenced, a random integer between 0 and 32767 is generated.  The sequence of random numbers may
              be initialized by assigning a value to RANDOM.  If RANDOM is unset, it loses its special properties, even if it is  subsequently
              reset.

変数 RANDOM は実行するたびに0~32767までのランダムな整数が返ってきます。 こんな感じですね。

$ for i in $(seq 1 10); do echo $RANDOM; done
17967
28058
9675
28765
5299
4990
29659
25088
3179
24945

これをさらに計算するために $((計算式)) って形でくくってやれば上のコマンドの完成です。

qiita.com

PrestoをアップデートしたらHivemetastoreを落としてしまった

うちで運用しているPresto + HivemetastoreのシステムでPrestoを0.174以上に上げてトラブったのでメモ書き。

うちで運用しているシステムっていうのはこれ => https://www.slideshare.net/techblogyahoo/teradata-prestodb

2020/02/16 追記

v330のドキュメントからはHive metastoreのCache周りの設定について記述が追加されました。

github.com

TL; DR

Presto 0.174でHivemetastoreに対するキャッシュがデフォルトで無効化されており PrestoのバージョンアップによりHivemetastoreへのリクエストが増えてしまいHivemetastoreを落としてしまった。

github.com

バージョンアップ前でも結構ギリギリだったやつがリクエスト増えたせいでHiveサーバーのキャパシティを超えてしまった。

対策

Hive metadataのキャッシュを再度有効化するにはhive.metastore-cache-ttl と hive.metastore-refresh-intervalのパラメータを有効にする必要がある。 ただし、これらのパラメータはドキュメントには記載されていない。

presto/HiveClientConfig.java at ba8627aa260c96fefdc9e5f6069f4b86d0b3d45b · prestodb/presto

今回トラブったおかげでこのパラメータのデフォルト値が書かれているクラスのコードを読んだが、 他にもドキュメントに記載されてないパラメータがいくつかあったので改めてコードを読み直したい。

とりあえず、今回のトラブル関わったであろうパラメータ2つについては、ドキュメントに記載して欲しかったのでPRを送っておいた。

Add documentation for Hivemetastore settings by yuokada · Pull Request #9836 · prestodb/presto

Atomパッケージ language-auroraを作った

development

最近、Apache Mesos とその上で動くフレームワーク Apache Auroraを触ったり調査したりしています。

そこで、Auroraの設定ファイルを読み書きしているんですがsyntax highlightがされなくて読みづらく また書いてはtypoに気づけてなくて無駄な時間を過ごすことがあったのでatomのパッケージを作ってこの問題を解決することにしました。

Atomのパッケージの作り方を調べてみたら参考に出来るものは十二分に情報が得られたので思い立ってからほんの数時間で、 最低限のものを作ることが出来ました。 まだ、アルファ版ぐらいの扱いですが公開してありますのでapm installでインストール出来る状態になっています。

language-aurora

atom.io

Auroraの設定ファイルは拡張子が.auroraなだけで中身は一種のpyhtonスクリプトなのでlanguage-auroraもpythonのsyntax highlightを継承してそこにいくつかのキーワードを追加しただけの簡単なものになります。

twitter社などが公開しているリポジトリの.auroraファイルを拾ってきてハイライトを目視確認ぐらいしかしてませんがそれなりに視認性が高まったかなというのが今のステータスです。

今後の展望としては、sunippets周りの拡充が出来たらベータ版にできるかなというのが現在のステータスです。 年内にはその辺を完了させる心づもりです。

そういえば、明日はNPBのドラフトですね。

Mesos実践ガイド (impress top gear)

Mesos実践ガイド (impress top gear)

embulk-output-orcを作った

development ruby embulk

techplay.jp
togetter.com

6月に開催されたPresto meetupで登壇したときに夏休みに作るわ〜と言ってしまったので宣言通り作ってみた。

embulk-output-orc | RubyGems.org | your community gem host

現状、マルチスレッドでちゃんと動かないバグを回避するために一時的な実装を入れています。

https://github.com/yuokada/embulk-output-orc/blob/0.2.2/src/main/java/org/embulk/output/orc/OrcOutputPlugin.java
github.com

diff --git a/src/main/java/org/embulk/output/orc/OrcOutputPlugin.java b/src/main/java/org/embulk/output/orc/OrcOutputPlugin.java
index c0ef4d8..d9352d9 100644
--- a/src/main/java/org/embulk/output/orc/OrcOutputPlugin.java
+++ b/src/main/java/org/embulk/output/orc/OrcOutputPlugin.java
@@ -34,6 +34,7 @@ import org.embulk.util.aws.credentials.AwsCredentialsTask;
 import org.joda.time.DateTimeZone;
 
 import java.io.IOException;
+import java.util.ArrayList;
 import java.util.List;
 import java.util.Map;
 
@@ -265,6 +266,7 @@ public class OrcOutputPlugin
     {
         private final PageReader reader;
         private final Writer writer;
+        private final ArrayList<VectorizedRowBatch> rowBatches = new ArrayList<>();
 
         public OrcTransactionalPageOutput(PageReader reader, Writer writer, PluginTask task)
         {
@@ -288,11 +290,8 @@ public class OrcOutputPlugin
                 );
                 i++;
             }
-            try {
-                writer.addRowBatch(batch);
-            }
-            catch (IOException e) {
-                Throwables.propagate(e);
+            synchronized (this) {
+                rowBatches.add(batch);
             }
         }
 
@@ -300,6 +299,9 @@ public class OrcOutputPlugin
         public void finish()
         {
             try {
+                for (VectorizedRowBatch batch : rowBatches) {
+                    writer.addRowBatch(batch);
+                }
                 writer.close();
             }
             catch (IOException e) {

Javaをこれまで全く書いてこなかったのでマルチスレッド周りのバグ対応の知見がなくこんなパッチになっています。
そして、この実装を取り入れた副作用として大量のレコード(自分の環境だとデフォルトの設定にでだいたい2~300万レコード以上)を処理するときに、java.lang.OutOfMemoryError: GC Overhead limit exceeded が発生して処理が落ちます。

自分の用途だと今のところ検証目的で100万程度までの処理が多いのでこの実装で間に合っていますし、 v0.2.0の実装でシングルスレッドで使えばレコードが増えても問題なく動くので今のところこれに落ち着きました。

ただ、ちゃんとバグ修正はしたいなと思っているので年内にでもちゃんと時間取って対応して1千万レコードでも1億レコードでも問題なく処理できるようにしたいとなと考えてます。

orcのなかでスレッドセーフじゃないクラスがいくつかあり、#addRowBatchからこれらを呼んでいるからかなというステータスでその先は調査中です。

orcフォーマットを軽く試す分には問題なく使えるレベルにはなっているので是非使って見てください。

clocとlocを試してみた。

clocとは?

Perl製のコードの行数を計測するツールです。
GitHub - AlDanial/cloc: cloc counts blank lines, comment lines, and physical lines of source code in many programming languages.

locとは?

clocにインスパイアされた(?)Rust製のコードの行数を計測するツールです。
GitHub - cgag/loc: Count lines of code quickly.

clocのインストール

早速、clocを試してみましょう。 今回はbrweからインストールしてみます。

% brew install cloc

今回はdjangoのリポジトリを使ってパフォーマンスなどを見ていきます。

% git clone https://github.com/django/django.git
Cloning into 'django'...
remote: Counting objects: 398103, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 398103 (delta 0), reused 0 (delta 0), pack-reused 398101
Receiving objects: 100% (398103/398103), 163.06 MiB | 2.83 MiB/s, done.
Resolving deltas: 100% (289580/289580), done.
Checking out files: 100% (5766/5766), done.

% cloc django
   4005 text files.
   3902 unique files.
   1149 files ignored.

github.com/AlDanial/cloc v 1.74  T=41.37 s (81.9 files/s, 15448.0 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Python                        1883          50083          48320         216702
PO File                       1136          70500           9752         213272
JavaScript                      45           2938           3450          13531
HTML                           234            521             19           4414
CSS                             30            656            115           2755
JSON                            43              3              0           1415
XML                             14              0              2            207
DOS Batch                        1             23              1            165
make                             2             30              7            134
INI                              1              7              0             59
Bourne Shell                     1              4              7             17
-------------------------------------------------------------------------------
SUM:                          3390         124765          61673         452671
-------------------------------------------------------------------------------
>>> elapsed time 41s

コマンドの完了までに41秒かかってしまいました。 3300ファイルもあるとなかなか時間がかかりますね。

locのインストール

次に、locを実行してみましょう。今回はwgetでgithubから取得してきます。

% wget https://github.com/cgag/loc/releases/download/v0.3.4/loc-v0.3.4-x86_64-apple-darwin.tar.gz
% tar zxvf loc-v0.3.4-x86_64-apple-darwin.tar.gz

% ./loc django
--------------------------------------------------------------------------------
Language             Files        Lines        Blank      Comment         Code
--------------------------------------------------------------------------------
Python                2419       315559        50191        19358       246010
Plain Text             436       127392        34876            0        92516
JavaScript              45        19919         2938         3451        13530
HTML                   302         5029          523           19         4487
CSS                     31         3526          656          115         2755
JSON                    44         1427            3            0         1424
XML                     15          220            0            2          218
Batch                    1          189           23            1          165
Makefile                 2          171           30            7          134
INI                      1           66            7            0           59
reStructuredText         3           85           26            0           59
Autoconf                 1           17            0            0           17
Bourne Shell             1           28            4            8           16
ASP.NET                  2            2            0            0            2
--------------------------------------------------------------------------------
Total                 3303       473630        89277        22961       361392
--------------------------------------------------------------------------------

locの方は実行時間1秒程度で完了しました。

ただ、clocの結果とかなり違うのでどっちが正確な結果なのか判断するのは難しいです。。。
実績でclocの方の結果が正確だろうというのが自分の予想です。

正確性のclocと早さのlocといった認識で使い分けをするのが良いのかなというところです。

Link