[Solr] Heliumパッケージを使って zeppelin-solr の可視化手段を増やす

Zeppelinには始めからいくつかの可視化の手法が用意されていますが、Helium パッケージを使って後から追加することもできます。飛行船に追加するものだからヘリウムなんですね。

そのためには、Zeppelin の設定ファイルを変更して Helium パッケージリポジトリを有効にする必要があります。conf/zeppelin-site.xml.template をコピーして conf/zeppelin-site.xml を作り、以下のコメントアウトされている箇所を有効にします。

$ diff -u conf/zeppelin-site.xml.template conf/zeppelin-site.xml
--- conf/zeppelin-site.xml.template     2022-02-24 12:56:08.000000000 +0900
+++ conf/zeppelin-site.xml      2022-07-24 23:50:42.829396848 +0900
@@ -410,13 +410,11 @@
   <description>Remote Yarn package installer url for Helium dependency loader</description>
 </property>

-<!--
 <property>
   <name>zeppelin.helium.registry</name>
   <value>helium,https://s3.amazonaws.com/helium-package/helium.json</value>
   <description>Location of external Helium Registry</description>
 </property>
--->

 <property>
   <name>zeppelin.interpreter.group.default</name>

設定ファイルの準備ができたら zeppelin を再起動します。

$ bin/zeppelin-daemon.sh restart

Helium パッケージリポジトリを有効にしたら Zeppelin のページにアクセスしてメニューから Helium を開き、追加するパッケージを選んで “Enable” ボタンを押します。

パッケージを最初に追加するときにはかなり時間が掛かる場合もありますが、しばらく待てば利用できる状態になります。今回は ultimate-heatmap-chart を追加しました。

以下は、大阪市のどの区にどの施設が沢山あるかを示すヒートマップチャートです。

SQSのFIFOキューと標準キューの大まかな違い

前に勘違いして使っていたことがあったので書きます。結論だけ先に書いてあとは蛇足になります。

直列と並列

・FIFOキューは直列、標準キューは並列といったイメージ
気を付けておくこととして
・FIFOキューはメッセージ毎の遅延が利用できない
・標準キューは2回以上配信される可能性がある
大半は標準キューを利用してどうしても1つずつ実行される必要があるようなものはFIFOを使うといったぐらいの認識でいい気がします。

以下は蛇足分になります。

気づいたのは処理が多くなってきたので実行数を増やしたが実行ログを見る限りだと完全に終わってから実行されているような・・・といったことからわかりました。増やす必要ができたもの以外は1回だけ配信されて欲しい内容が大半で基本的にFIFOのままで問題なかったのですが、増やそうとしている処理は複数実行されていかないと処理しきれないので将来的にキューが溜まり続ける未来が容易に予想でき、また標準キューにしていなかった理由も内部では実行時のチェックはやっているので1回だけの必要があるというわけではなく単純に他が全部FIFOだったからそのままFIFOでやってしまったというだけだったので原因がわかればそう難しいことではなかったのですがイメージ的に順番が保証されてるかされていないかと一回切りか複数回の可能性があるかぐらいの認識だったのでそこの部分を誤認識していたという話です。

しっかり準備しよう

※ 書き初めで「前田敦子」とボケることの継続はきっぱりやめました。理由として誰もツッコんでくれなかったためとなります。(涙)

卯年なので『飛躍』などと書きたいところですが、今年はまだまだ「準備」の時期と位置づけて取り組んでいきたいと考えています。

今期スプラウトは第9期となります。
10期に向けて、8期が始まった頃くらいから新しい事業体制を模索してきました。

徐々に輪郭が固まってきたので今期も継続してしっかりと「準備」を進めていきたいと考えます。
メンバーのみんな、お世話になっている方々、本当に感謝しかありません。
ありがとうございます。

「準備」というコトバが自分の中であらためて大事なことと気づいたきっかけは、中田英寿さんがサッカー日本代表の時期にインタビューで「準備をしっかりする」ということをよく答えられていたことにあります。

結果のためには十分な準備をすることが大事。
当たり前かもしれませんが、とても難しいことだと思います。

スプラウトは、本年もひとつひとつしっかりと準備し、「ITサービスで日常を少し豊かにする」というビジョン実現に邁進してまいります!

<追記>
余談ですが、中田英寿さんは尊敬する方のひとりであり、僕と同じ誕生日で勝手にご縁を感じております。
1月22日はカレーの日。※ 僕の好きな食べものはカレーです。

SolrとZeppelinによる可視化

Zeppelinを使えばクエリの結果を簡単に可視化できるので、色々試してみます。
サンプルデータとしていつもの通り大阪市の施設情報を利用します。こんな感じのデータです。

$ curl 'http://localhost:8983/solr/test1/select?omitHeader=true&fl=name_str%2Ctype_str%2Carea_str%2Caddress_str%2Caddress_p&indent=true&rows=3&q=*%3A*'
{
  "response":{"numFound":9238,"start":0,"numFoundExact":true,"docs":[
      {
        "address_p":"34.6164938333333,135.438210722222",
        "name_str":["軽自動車検査協会大阪主管事務所"],
        "type_str":["官公庁"],
        "area_str":["住之江区"],
        "address_str":["住之江区南港東3-4-62"]},
      {
        "address_p":"34.6190439722222,135.442191833333",
        "name_str":["大阪陸運支局なにわ自動車検査登録事務所"],
        "type_str":["官公庁"],
        "area_str":["住之江区"],
        "address_str":["住之江区南港東3-1-14"]},
      {
        "address_p":"34.6109641111111,135.491388722222",
        "name_str":["住吉税務署"],
        "type_str":["官公庁"],
        "area_str":["住吉区"],
        "address_str":["住吉区住吉2丁目17番37号"]}]
  }}

まずは表形式の出力。
search() の構文では、最初の引数がコレクション名、それ以降に solr のクエリパラメータを書けます。

search() の代わりに random() にすると、同じクエリでランダムサンプリングになります。

facet() を使って区別の施設数を円グラフで。

同じことを SQL でも書けます。

施設種別毎の施設数を各区で比較した図。

ヒートマップによる区毎の比較。

Navigator.userAgentDataを使いたい

現在、検討が進められているUA-CHですが、導入にあまり乗り気では無いFirefoxが、
先日(6月)、Navigator.userAgentData実装のトラッキングステータスを “UNCONFIRMED” から “New” へ移行させました。

1750143 – Implement Navigator.userAgentData
https://bugzilla.mozilla.org/show_bug.cgi?id=1750143

これにより、少なくともuserAgentDataのプロトタイプが実装される可能性が少し高まったのではないかと考えています。実際の製品版への実装時期は未定。優先度も高くないため、
完全に取り下げられる場合もあり得る状況ですが、standards-positionsの議論を見ている限りでは、ユーザーエージェントの情報を構造化することについては肯定的なところもあるように見えます。

Navigator.userAgentDataが使えると何が嬉しいのか。

User-Agentの解析というと、これまでは以下のような文字列を解析していました。

Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.85 Mobile Safari/537.36 EdgA/90.0.818.46

構造化されたuserAgentDataであれば、スマートフォンやタブレットの判定がこれで済みます。

const isMobile = navigator.userAgentData.mobile;

他にも、以下のような構造でデータが取得できます。

{
  "brands": [
    {
      "brand": "Chromium",
      "version":"91"
    },
    {
      "brand": "Microsoft Edge",
      "version":"91"
    },
    {
      "brand": "GREASE",
      "version":"99"
    }
  ],
  "mobile": false 
}

// https://docs.microsoft.com/ja-jp/microsoft-edge/web-platform/user-agent-guidance#user-agent-client-hints-javascript-api

特定の端末やブラウザの判定、対応がこれまで以上にやり易くなりそうです。
UA-CH自体とは無関係に実装して欲しい機能であることだなぁというところです。

ところで、炎暑酷暑のみぎりではありますが、Safari様におかれましてはご健勝でしょうか。userAgentの文字列は凍結するのかどうかどっちなんでしょうか。パワーでしょうか。
Push APIは、来年ようやく対応されるとのこと。おめでとうございますありがとうございます。

暑熱耐え難き時節、皆様夏風邪など召されませぬようご自愛ください。