Elixir/Phoenix + Neo4j でお手軽!高速!経路探索

はじめに

聖夜に fukuoka.ex Elixir/Phoenix Advent Calendar 2019YAMAP エンジニア Advent Calendar 2019 24日目の記事がやって参りました🎅

🔺YAMAP 分析チームの松本です。元バックエンドエンジニアです。

YAMAP のバックエンドでは、応答速度やスケーラビリティの性能が要求されるケースでの選択肢として、Elixir/Phoenix を活用しています。

また従来より YAMAP では、登山計画時の便利機能として、経路探索システムが熱望されていました。

今回は

  • グラフ構造をもつデータの探索を得意とする GraphDB Neo4j
  • 応答速度に優れる Elixir/Phoenix
  • 特に理由はないけどフロントは Elm

を利用し、お手軽かつ高速な経路探索システムを開発してみようと思います。

Neo4j とは

neo4j.com

実は僕は詳しくなくて、SNS での人間関係の探索などに使われる DB くらいのイメージです。 「A さんは最近サーフィンに興味があるので、友達の友達の範囲内で、サーフィンが趣味の人をサジェストする」等

経路もグラフ構造なので、経路探索にも向いているようです。

Elixir/Phoenix とは

特に説明不要かと思いますが、詳しくはこいつを見てくれ。

すごく

  • 省リソースで
  • 耐障害性が高くて
  • 応答速度が早い

です。

問題設定

今回やることを定義します。 経路探索の舞台は、我らが「宝満山」にします。(福岡県)

f:id:hidetakafm:20191224214045p:plain

↑地図の通り、

  • Neo4j
    • n0 ~ 19 までの node を設定する
    • 実際の登山道に基づき、node 間の relationship を定義する(コースタイムも)
  • Elixir/Phoenix
    • Neo4j へのデータ登録タスク
    • node 一覧を返却する api:GET /nodes
    • 経路探索 api:GET /routes/search?from=<from_id>&to=<to_id>
  • Elm
    • 地図上に node を表示する
    • 2点を選択したら経路探索を実行
    • 結果のルートを表示する

が、今回やることです。

開発結果

f:id:hidetakafm:20191224222010g:plain

始点と終点を選択すると、所要時間が短い順に、3つの経路がサジェストされます。 登山計画が捗る予感がする!🗻

開発詳細

Repository & Setup

Elixir/Phoenix

github.com

$ docker-compose build
$ docker-compose up phoenix

すれば動くはず。

Neo4j

↑の後、localhost:7474 を開くと Neo4j コンソールが見れるので、初期ユーザー / パスワード = neo4j / neo4j でログインできます。 その後パスワードを password に変更します。(Phoenix の設定合わせ)

Elm

github.com

$ elm make src/App.elm --output src/app.js
$ elm reactor --port=8002

すれば動くはず。 ちなみに僕はフロントも Elm も素人なんでクソコード勘弁して下さい😓

mix task で Neo4j にデータ投入

$ docker-compose run --rm phoenix mix import_seed_data

localhost:7474 で Neo4j のデータを確認すると、

f:id:hidetakafm:20191224220152p:plain

宝満山の登山道のグラフ構造が確認できます。良いネ👍

データクリアしたい時は↓も用意してあります。

$ docker-compose run --rm phoenix mix clear_all_data

Neo4j 接続設定

Bolt.Sips を使いました。

github.com

config :bolt_sips, Bolt,
  url: "bolt://neo4j:7687",
  basic_auth: [username: "neo4j", password: "password"],
  pool_size: 10

検索実行

defmodule PhoenixNeo4jExample.Route do
  alias Bolt.Sips, as: Neo
  alias Bolt.Sips.Response
  alias Bolt.Sips.Types.Path
  alias Bolt.Sips.Types.Node

  ...

  def search(from, to) do
    query = cyper_query(:search, from, to)
    routes =
      Neo.conn()
      |> Neo.query!(query)
      |> parse_search_result
    {:ok, routes}
  end

  defp parse_search_result(%Response{records: records}) do
    records
    |> Enum.with_index
    |> Enum.map(fn({[_from, _to, %Path{nodes: nodes}, time], i}) ->
      %{
        node_ids: Enum.map(nodes, fn(%Node{properties: %{"id" => id}}) -> id end),
        total_time: time,
        color: @colors |> Enum.at(i)
      }
    end)
  end

  defp cyper_query(:search, from, to) do
    ~s"""
    MATCH (from:Node {id: '#{from}'}), (to:Node {id: '#{to}'}), path=((from)-[walk:WALK_TO*1..10]->(to))
    RETURN from, to, path,
    REDUCE(totalTime=0, w in walk | totalTime + w.time) as cost
    ORDER BY cost
    LIMIT 3
    """
  end

  ...
end

Bolt.Sips は Cyper query の DSL は用意せず、生クエリを書いて query! 関数で実行するスタイルでした。 僕は DSL 好きじゃないので良いと思いました。

また Bolt.Sips.Response はかなりネストが深い構造でしたが、Elixir のパターンマッチで、割とスッキリ処理できました。 実は久しぶりに Elixir を書いたのですが、やっぱり書き味が素晴らしいです😊

まとめ

Elixir/Phoenix + Neo4j で、お手軽かつ高速な経路探索システムを開発しました。 実際どれくらいの応答速度になるのかは、データを大量に入れて検証していきたいと思います。

Elixir はパターンマッチが強力で、データ処理言語としても有用であることは、fukuoka.ex の @piacere さんも言われている 通りだと思います。

僕はバックエンド出身の分析エンジニアとして、分析処理した結果を api でユーザーに配信して〜といったシステムを作りたくなる時もあるのですが、Elixir/Phoenix は一つの良い選択肢だと考えています。 耐障害性に優れる点も、スタートアップ企業のような開発リソースが潤沢ではない局面で、とても助かるんですよね。

ということで、久しぶりに Elixir に触れて楽しいクリスマスイブでした! 達郎聴いて寝よ🎅🎸

Looker ノススメ

はじめに

Looker Advent Calendar 2019YAMAP エンジニア Advent Calendar 2019 1日目の記事です。 (元々 Qiita に書いていたもの を、こちらに引っ越しました)

こんばんは、🔺YAMAP 分析チームの松本です。好きな山は赤岳(八ヶ岳)です。 YAMAP は 2019-11 から、次世代 BI ツール Looker を導入しました。

この記事では、YAMAP で導入前に感じていた課題とその解決方法を中心に、Looker の素晴らしさを紹介したいと思います。

参考までに、YAMAP の概況

Looker をはじめ、 BI ツール導入を検討している方の参考になればと思い、会社の規模などを共有してみます。

  • 社員数: 50 くらい(開発メンバーは半分くらい)
  • 分析チーム: 2019-01 に発足、現在 2 人
  • 主な事業: 有料会員 , 登山保険 , EC , 観光・アウトドア周辺の営業

Looker 導入前の課題と、どう解決するか

私達は、おおよそ以下のような課題を感じていました。

f:id:hidetakafm:20191205225905j:plain
before looker

それがこうなります、Looker 凄い 🎉

f:id:hidetakafm:20191205230031j:plain
after looker

以下でそれぞれ説明したいと思います。 なお LookML については、分かりやすくまとめて頂いている記事 等ありますので、そちらをご参照下さい 👀

a. データ基盤をみんなに使ってもらうには敷居が高い

私達は BigQuery にデータ基盤を構築し、2019-06 から運用を始めました。 (構築に当たっては 私の考えた最強のログ&モニタリング設計 - 下町柚子黄昏記 by @yuzutas0 がとても参考になりました。この場を借りてお礼を 🙏 )

ですがデータが1箇所に集まったのは良いものの、

  • 何がどこにあるのか難易度が高く、分析者以外が使うのに敷居が高い

という課題がありました。

どう解決するか?

これは 「分析者が LookML を定義すれば、それを元に Looker が UI が提供してくれるので、利用者はポチポチでグラフが作れる」 という特徴により、解決できます。

b. Redash でクエリが乱立、メンテが大変

私達はもともと Redash を使っていました。 Redash は無料ですし、とても素晴らしかったのですが、運用を重ねるにつれ、

  • 似たようなクエリが増殖
  • どれが使われているのか分からない
  • スキーマに変更があった際、参照しているクエリを修正して回るのが辛い

という課題が出てきました。

どう解決するか?

これも LookML が分析用 Object-relational mapping の如く、グラフとテーブルの間に入ってくれるので、テーブルに変更があったときは LookML を修正すれば、それを利用しているグラフを一括修正できる ということで解決できます。

また Looker には Look(グラフ) ごとのアクセス数を可視化する機能が備わっており、使われていない Look を整理するのにとても便利そうでした。

c. 人によってクエリの書き方が異なり、信頼性を担保しにくい

YAMAP では実際

  • SQL を書く人の技量により、間違った集計を行ってしまう
  • 技量が高くても分析対象のテーブルの細かい仕様までは把握しきれておらず、間違った集計を行ってしまう

といったケースが有りました。 (例えば、論理削除フラグや、契約履歴テーブルに "契約解除" でもレコードが挿入されるなどの仕様の把握漏れで、集計が水増しされてしまう. etc.)

こういう事が重なると、誰かがグラフを書いた時に「そもそも集計合ってるんだっけ?」といった確認作業が大変になるのも残念です。

どう解決するか?

これまた テーブル定義に精通した分析者が LookML を定義し、利用者はそれを使ってグラフを書く といった明確な分担ができることで、集計の信頼性が格段に担保しやすくなります。

d. 細かい集計依頼が多く、骨太な分析に時間を使えない

先に紹介したように、YAMAP は有料会員、登山保険、EC、営業と事業が多く、各チームから分析チームへ細かい集計依頼もコンスタントに来ています。

そして、YAMAP 分析チームは↓2つのミッションを掲げています。

  1. データ分析で事業の意思決定にコミットする
  2. ユーザーが投稿するデータを価値に変え、ユーザーに還元する

しかし先述したように現状分析チームは2人だけなので、各チームからの集計依頼が多くなると、2 に時間を使えなくなるという危機意識がありました。 (僕たちは 2 を "骨太な分析" と呼んでいます)

どう解決するか?

今まで書いたことでお分かり頂けると思うのですが、Looker は データの民主化 という視点で、とても強力です。 "LookML の定義に分析者が責任を持ち、利用者はそれを使ってグラフを書く" という切り分けができることで、データガバナンスとデータ民主化を両立できる 訳です。 今まで Looker を使ってみて、このバランス感は本当に素晴らしいと感じます 💜

ということで、Looker を各チームに浸透させ、簡単な集計や分析はチーム内で完結できるように持っていくことで、"骨太な分析" の時間も確保していく方針です。

加えて LookML はとても優秀で、クエリをかなり動的に生成してくれます。 故にお決まりの集計やデータ抽出業務は、グラフ(Look)の FILTERS パラメータを良い感じに用意してあげると、仕組み化しやすいです。 (Redash にもパラメータ機能はありますが、Looker はパラメータの選択状況に応じて JOIN 文レベルで切り替わってくれるので、柔軟に仕組み化できます)

まとめ

YAMAP での BI の課題と、それをどう解決できるのかを中心に、Looker をご紹介しました。

使えば使うほどに素晴らしいツールだと驚くのですが、特に

  • "LookML の定義に分析者が責任を持ち、利用者はそれを使ってグラフを書く" という切り分けができることで、データガバナンスとデータ民主化を両立できる

点がミソなのかなと感じています。

しっかり使いこなして、みんなの登山をより安全にしていきたいと思います。 🗻 明日の Looker Advent Calendar 2019, YAMAP エンジニア Advent Calendar 2019 もお楽しみに!

うぐいすオルゴール (Nightingale Music Box)

www.uguisumb.app

App

デモソング (Demo song)

  • アプリをインストール後に↓リンクをクリック (Click the bellow link after you install the App.)
  • canon

 操作方法 (How to)

  • 音符を作る/消す (Create/delete a note.)
    • テーブル上をタップ (Tap on the table.)
  • オクターブを上げる/下げる (Up/down the octave.)
    • テーブル上で左/右にスワイプ (Swipe on the table.)
  • 曲の出来具合を確認する (Check the song you making.)
    • テーブルを上/下にドラッグし、音を鳴らす (Play sounds by dragging the table.)
  • 曲が完成したので再生する (Play your song.)
    • 再生ボタンを押す (Tap the play button.)

f:id:hidetakafm:20150205001056j:plain