遅れてしまいましたが、この記事は、 MicroAd Advent Calendar 2019 及び Distributed computing (Apache Spark, Hadoop, Kafka, ...) Advent Calendar 2019 - Qiita の20日目の記事です。
Apache Hadoop Ozone[^1] で対応したCSIをつかってKubernetesでPVCをお試しようと思ったんですが、準備が間に合わなかった… S3を喋れるので、今回は、aws CLI使って、ファイル操作をしてみた。
続きを読むVBAってExcelブックにコードが埋まっちゃうので、読みにくい、、、
そこで、変更したらマクロだけをexportして、GitなりSvnなりにコミットしておけば、共有も出来るしレビューも出来るし、良いことづくめ。 終わったら、元のExcelブックにimportするだけ。超簡単。
そんな素敵ツールがこちら。
使い方はコマンドプロンプトからvbacを呼び出すだけ。
コマンドの詳細はこちら。
詳細は https://github.com/vbaidiot/ariawase/blob/master/vbac.wsf を見ると分かります。
これを build.bat から呼び出してるだけなので、これを参考に、importとexportのバッチを作成したらOK。
他にもvbacに色々書いているのでこれがREADMEだと思って読むと良いかと。
そして、サンプルで入っている src/Ariawase.xlsm のVBAスクリプトはスクリプトとして参考になるのでオススメ。
とはいえ、VBAを開発するなら、どうせ要件膨らむので素直にOfficeアドオン使って、開発する方がデバッグも楽だし良いと思います。
MacとかWindowsとかでminikube動かすよりも、Linuxでmicrok8s動かすほうが100倍快適だと思うのでk8sいじり倒したい人は普段使いのLaptopをLinuxにするべき https://t.co/I3PG8ukd9s
— junichi yoshise (@jyoshise) April 23, 2019
って @jyoshise さんがつぶやいてたので、ほんまかねぇと思って、snapだし良いかってくらいのノリで入れてみた。
続きを読む
分析用のクラスタでの運用の話。
クラスタへのデータ投入やETLなどのジョブと分析用のジョブを共存共栄したいという要望がある。 基本的に分析系のジョブは重たくなりやすいので、他に影響与えないように隔離したい。
beelineを使う場合は、以下のようにすると、リソースプールを例えば root.analysts として実行出来るのだけれど、、、
beeline -u jdbc:hive2://hiveserver2:10000/ -n analysts -f test.sql --hiveconf mapred.job.queue.name=root.analysts
ちなみに、impalaの場合は以下の感じ。
impala-shell -i hostname:portnum -B -q "set REQUEST_POOL=root.analysts; select * from hoge;"
ただし、リソースプールの指定には、下図のように動的リソースプールの設定も必要で、そこに指定したものだけが指定出来た。
※↑超適当です
本題。
今回は、Hueから実行した場合にも同様にリソースプールを別にしたい。
社内ブログがあるのでそっちには毎日書いてるんだけど、せっかくなんでこっちにも書いてみることにした。 もともとメモなんだし、もっと雑に描いてもいいかなぁと。
Cloudera Manager API Client というのがあるなぁってのは分かってたんですが、どうせライセンスがーとかと思ってたら、どうやら認識違いしてた。 エンタープライズライセンス無くても使えるよね？
試しに、Cloudera Manager（以下、CM）のAPIのVersionを調べる
$ curl -X GET -u "CMアカウント名:パスワード" -i http://CMドメイン:7180/api/version HTTP/1.1 200 OK Expires: Thu, 01-Jan-1970 00:00:00 GMT ； v19
おお。使える。
/api/version を /api/v19/clusters にすると管理クラスタ一覧とれたり出来た。
もちょっと見るとQiitaにこんな記事が。
Cloudera Manager API を使ったクラスタ構築 - Qiita
CMのアカウントがいるので、管理アカウントを晒せないけど、機能制限したユーザ（作れるのかな？）を用意できれば、生きてるNameNodeを取得とか出来そうなので、DistCpでリモート側のNNがどこか調べられるなぁと。
ただ、その場合、CMをメンテのために止めたりなどが出来なくなるので手間が増える。
Qiitaの記事にあるような、管理系の利用を考慮するだけの方が良いかもしれない。
なかなか三方良しってのは難しい、、、
Ambari使って自動化って話は、ちょろちょろ聞くのだけど、Cloudera Manager使って自動化がどうのって話はほぼ聞かないけどどうなんでしょね。
Ambariとの比較はまたこんど（ぁ
活動拠点は京都なのですが、大阪のコアメンバ不在もあって、神戸方面のメンバと一緒になって大阪で開催しました。
一緒にやってくれる人募集してます。
最初は、 去年のアドカレネタを膨らまして発表する予定だったんですが、どうしても気になってしまって結局、直前で変更。
発表スライドは以下です。
www.slideshare.net
ホントは動かしたりもしたかったのですが、調査するのに時間がかかって、掘っても掘っても色々出てくる。。。
ただ、自分の仕事もそうだけど、興味のある分野もあってどんどん調べていくのでまとまらないこと。。。
データエンジニア方面からのCloudNative方面へのフォローの何かの足しになれば良いかなぁ思います。
後、同じ境遇の人とつながって色々話がしたい！
他の方はこちら。
www.slideshare.net speakerdeck.com
京都もやるのでお楽しみ？に。
2019/01/07時点で Hive または Impala において、ネストしたカラムに対するpushdownは対応が済んでいない。
CDH5.14にて、Hiveのクエリが激遅いって事で、実行計画見て、これpushdown出来てないんじゃね？って事で調べる事にした。
複雑型に対するSELECT句（projection）のpushdownはまだ未対応ですね（なのでまるととってパースしてる）https://t.co/tUGEJpdwY7
— あさぬー (@hayanige) December 13, 2018
WHERE句（predicate）のpushdownは最近できるようになったかも・・・？https://t.co/FHMgBZby9H
っと、ありがたい事に回答頂いていたのですが、この辺きっかけで自分でも調べてみた。
HDFS上からSQLライクにデータを取り出すには、HiveやImpalaを使うのですが（他にも PrestoとかDrillとかもあるけど）、
でかいテーブルでフルスキャンするとデータ量が半端なくなるので、特定のカラムだけとか、特定の行だけと、フィルタして取り出します。
その辺りのフィルタの事をPushdownと言います。
Pushdownについては、以下のスライド及びBlogが参考になります。
また、Hive及びImpalaには、1カラムに複数の値を保持できる Complex型と呼ばれる型が存在します。
そして、Complex型には、Array、Struct、Mapがあります。
cf. Hive - Complex Types
cf. Impala - Complex Types
今回は、PostgreSQLやMySQLで言うところのJSON型の様に扱える Struct型に絞った話。 Struct型を使うことで、アプリログなど後から要素の数を柔軟に増減出来るようになります。さらに、Struct型のカラムにさらにStruct型を入れ込む事も出来きます。
Struct型のメリットとしては、「複数のテーブルを結合してまとめておいて、それをStruct型のカラムとしておくことで、結合コストを減らす事が出来る」という事。
ただし、その場合、pushdownに対応していないと、不要なカラムまでStrcut型に含めるのでデータが冗長になる、つまり、データサイズが増えてパースする時間が生じる（結合しなくても良いカラムまで含むので）。
なので、クエリ内で使える事とpushdown出来るかは別の話。 select句やWhere句・Group by句で、Struct型の要素を指定してクエリを書いた場合、その要素だけを取り出せている(pushdown出来ている)と期待しますが、実は違います。
クエリの実行計画は大事。必ず見て欲しいです。
クエリの頭に EXPLAIN または EXPLAIN EXTENDED を付けると確認出来ます。
Projection Pushdown または Predicate Pushdown に未対応な場合、select句(Projection) または where句(Predicate)にて、ネストしたカラムを1個、2個と要素を増やしても取得するデータサイズが変わっていない事が分かります。
それでは前置き長くなったので本題。
以下、前提として、2019/01/07時点のCDHにおけるHiveまたはImpalaを調査した結果に基づいています。
前提： Hiveで対応している 列指向なデータフォーマット ORCかParquet を対象にしています
結論： ネストしたカラム Complex型に対する pushdownはまだ未対応（なのでまるととってパースしてる）
実際にはこの事は、HiveのJIRAにも以下の様に ORCは HIVE-19103 、 Parquetは HIVE-14826 から現状の状況が確認出来ます。
[HIVE-19103] Nested structure Projection Push Down in Hive with ORC - ASF JIRA
[HIVE-14826] Support vectorization for Parquet - ASF JIRA
ただし、Where句（predicate）なら、今後、新しいVer.ので行けるようになるかも。
[ORC-323] Predicate push down for nested fields - ASF JIRA
前提： Impalaで対応している 列指向なデータフォーマット ORCかParquet を対象にしています
結論： ネストしたカラム Complex型に対する pushdownはまだ未対応（なのでまるととってパースしてる）
Impalaの公式ドキュメントには、Complex型に対する記載が以下のようにあります。
Complex Types (Impala 2.3 or higher only)
Impalaについては、基本的にParquetによる対応は進んでいますが、ORCについてはまだまだな状況です。
IMPALA-5717 にて対応はしたように見えますが、同Issueのコメントを見ると以下のようにまだまだ課題が残っています。
[IMPALA-5717] Support for ORC format files - ASF JIRA
更に、以下の IMPALA-6503 の通り、 Complex型への対応がまだ残っているようです。
[IMPALA-6503] Support reading complex types from ORC format files - ASF JIRA
CDHの場合、パッチが適用されるので実際の本家のバージョンと対応状況が異なるかもです。
最新のCDH6系でHive及びImpalaで実行計画を試してみた訳ではないので、「いやいや対応してるよ」というものがあれば教えてください。
以上です。
