dbt on Treasure Data with dbt-trino の動作確認をした

サマリー

  • dbt-trino アダプターを使って dbt を TD で使えるか試したら動いた。
  • これで dbt のエコシステムを使っていろいろ出来そう

背景

以前 dbt の presto アダプターである dbt-presto を試したが、コードに修正をしないと動かないことが分かった。

satoshihirose.hateblo.jp

その後は特に何もしてなかったが、久しぶりに dbt 周りのコードを眺めていたときに dbt-presto がアーカイブされていることを発見し、と同時にその代替の trino アダプターである dbt-trino だと動きそうなことが分かったので試してみた。

動作確認

インストール

以前の記事と一緒、と思ったら ImportError: cannot import name 'soft_unicode' from 'markupsafe' というエラーが出たので、とりあえず今のところは markupsafe を 2.1.0 から 2.0.1 に戻して先に進む。

$ python3 -m venv venv
$ source venv/bin/activate
$ pip install dbt-trino
$ pip install MarkupSafe==2.0.1
$ dbt --version
installed version: 1.0.1
   latest version: 1.0.3

Your version of dbt is out of date! You can find instructions for upgrading here:
https://docs.getdbt.com/docs/installation

Plugins:
  - trino: 1.0.1

~/.dbt/profiles.yml を修正する。ほぼ以前の記事通りだが、dbt-trino では http_schemeプロトコル指定できるのでそこで https を指定する。

td:
  target: dev
  outputs:
    dev:
      type: trino
      method: none  # optional, one of {none | ldap | kerberos}
      user: <your td api key>
      password: dummy
      database: td-presto
      host: api-presto.treasuredata.com
      port: 443
      schema: satoshihirose
      threads: 1
      http_scheme: https

プロジェクトの作成

$ dbt init sample
12:28:39  Running with dbt=1.0.1
Which database would you like to use?
[1] trino

(Don't see the one you want? https://docs.getdbt.com/docs/available-adapters)

Enter a number: 1
12:28:41
Your new dbt project "sample" was created!

For more information on how to configure the profiles.yml file,
please consult the dbt documentation here:

  https://docs.getdbt.com/docs/configure-your-profile

One more thing:

Need help? Don't hesitate to reach out to us via GitHub issues or on Slack:

  https://community.getdbt.com/

Happy modeling!

接続テスト

$ dbt debug --profile td
12:29:42  Running with dbt=1.0.1
dbt version: 1.0.1
python version: 3.9.6
python path: /Users/satoshi.hirose/work/dbt-trino-test/venv/bin/python3.9
os info: macOS-11.2.3-x86_64-i386-64bit
Using profiles.yml file at /Users/satoshi.hirose/.dbt/profiles.yml
Using dbt_project.yml file at /Users/satoshi.hirose/work/dbt-trino-test/dbt_project.yml

Configuration:
  profiles.yml file [OK found and valid]
  dbt_project.yml file [ERROR not found]

Required dependencies:
 - git [OK found]

Connection:
  host: api-presto.treasuredata.com
  port: 443
  user: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  database: td-presto
  schema: satoshihirose
  cert: None
  Connection test: [OK connection ok]

0 checks failed:

dbt run の実行

作成したプロジェクトに作られた dbt_project.yml の中で、 view と指定されている箇所を table に変更してから、dbt run の実行をする。

models:
  sample:
    # Config indicated by + and applies to all files under models/example/
    example:
      +materialized: table
$ cd sample
$ dbt run --profile td
12:35:08  Running with dbt=1.0.1
12:35:08  Unable to do partial parsing because a project config has changed
12:35:08  Found 2 models, 4 tests, 0 snapshots, 0 analyses, 167 macros, 0 operations, 0 seed files, 0 sources, 0 exposures, 0 metrics
12:35:08
12:35:13  Concurrency: 1 threads (target='dev')
12:35:13
12:35:13  1 of 2 START table model satoshihirose.my_first_dbt_model....................... [RUN]
12:35:19  1 of 2 OK created table model satoshihirose.my_first_dbt_model.................. [SUCCESS in 6.57s]
12:35:19  2 of 2 START table model satoshihirose.my_second_dbt_model...................... [RUN]
12:35:26  2 of 2 OK created table model satoshihirose.my_second_dbt_model................. [SUCCESS in 6.18s]
12:35:26
12:35:26  Finished running 2 table models in 17.31s.
12:35:26
12:35:26  Completed successfully
12:35:26
12:35:26  Done. PASS=2 WARN=0 ERROR=0 SKIP=0 TOTAL=2

実行に成功した。UI からサンプルテーブルが作成されていることを確認できた。

f:id:wonderthinkanswer:20220226213559p:plain

Customer Reliability Engineering in Action

What's this?

Customer Reliability Engineering の方法論について考えたことをまとめる。

CREing

Google の提唱した CRE 職の新規性は、SRE の発想を自社プラットフォームのみならずその上で動く顧客アプリケーションにも適用したことにある。 基本的にはその発想に従えば良い。

SRE の方法論は、ざっくり言うと、SLA やエラーバジェットなるもので信頼性を定量的に定義しそれをモニタリングしながら改善可能性を探っていく、みたいなものだ。 それを顧客アプリケーションにも適用するのが CRE だと思えば良いだろう。

つまり、例えば現職の Treasure Data のプラットフォームには、それを取り巻く様々な顧客アプリケーションが存在する(Scheduled Query, Workflow, Source などなど)が、それらコンポーネントについて、顧客ごとまたは全体のエラー率、もしくはそれに準ずるメトリクスを計算して、それらをモニタリングしながら、改善可能性を追求していけば良い。特定の顧客の Scheduled Query のエラー率が極端に高かったら、その原因を調査し、エラーの解消に導く。原因が判明したなかで、プラットフォーム側で対応が不能な場合は、みずから顧客とコミュニケーションをとるか、カスタマーサクセスやサポートチームに協力を仰ぎ、それを解決していく。結果として、顧客側はサービスキャパシティの消費量を減らしたり気づいていない問題を発見したりアプリケーションを正常化することができ、プラットフォーム側は無駄に消費されるリソースコストを削減でき、みなハッピーというわけだ。

基本的には、適切な KPI を決めてそれを改善するという一般的な所作を顧客アプリケーションのエラー率に対してやっていきましょう、という話である。

何を改善していくか

上で述べた CRE の活動がどう実を結ぶかは、選んだメトリクスに大きく依存する。例えば、特定の顧客アプリケーションのエラーが極端に高いことを発見し、それを長時間かけて調査し人々のリソースを使って解消しようとしても、それは顧客にとってエラーが起こっていても問題ない何ら重要ではないアプリケーションかもしれない。つまりそのようなケースでは、エラー率の改善度合いは顧客へのインパクトの大きさと相関しない。

また、SRE 的な発想にこだわると改善対象のメトリックはエラー率かもしれないが、そこは所属するチームの職責やオーナーシップを持つシステム、組織のステージなどに応じて変わってくるだろう。ドキュメントシステムを改善しているなら結果 0 件リターン率がそのメトリックでも良いかもしれないし、会社 OKR が profit margin の改善なら顧客ごとの profit margin がそのメトリックでも良いかもしれない。そして、そのメトリックは一つである必要もない。対象のメトリックに何を選び、何を改善していくかを決定するかは、チームや会社の目標を元に、合意を経て決めるのが良いだろう。

具体例

以下は、現職であった事例である。

Treasure Data のサービスは、顧客のアプリケーションから Treasure Data が用意したエンドポイントに送信されたデータを、プラットフォームに蓄積する。エンドポイントはリージョンごとに存在しており、顧客アカウントは特定のリージョンに属する。

あるとき、たまたまログデータを確認していた同僚が、ある顧客が自身のアカウントの属するリージョンのエンドポイントではなく、異なるリージョンのエンドポイントに対して大量にデータを送信しているのを見つけた。 そのようなリクエストで送信されたデータは破棄されてしまい、結果としてデータは顧客アカウント上に残らない。 一日に数千万レコードが継続的に送信されつづけており、顧客アプリケーションにおいて本来蓄積されるべきそれだけの量のデータが破棄されているのも無視できなかろうということで、対策を講じようという話になった(プラットフォームにとっても意味のないリソースを消費していることになる)。

調べてみると、その他の顧客アカウントでも同様に異なるリージョンのエンドポイントにリクエストを送信していることも分かった。 はじめに、そのようなレコードがどのアカウント、リージョン、ユーザーから送信されているかを可視化してモニタリングできるダッシュボードを作成した。 そして、そのダッシュボードをカスタマーサクセスチームにシェアし、顧客とのコミュニケーション方法について相談した。 そのようなリクエストを送信している特定のユーザーに通知を送る方法も検討したが、最終的に、そのようなリクエストを送信しているアカウントのカスタマーサクセスマネージャー宛に定期的に Slack でリクエスト数などのステータスを通知し、その担当が顧客とコミュニケーションを取り削減に努めるというフローになった。 通知はリクエスト数に適当に閾値を設け自動化することで、今後にそのようなリクエストを送信するユーザーが発生したら担当メンバーまで通知が飛び、詳細をダッシュボードで確認することで顧客とコミュニケーションを取れるフローが構築できた。

以上は、スポット対応によるオペレーションフローの構築の例であり、継続的にメトリック改善施策を行っている例ではないが、ストーリーは同様なものになる思う。 この例の改善対象メトリックとは、アカウントの属するリージョンと異なるリージョンへのリクエスト数(率)だ。 メトリックが改善することで、顧客アプリケーションの瑕疵もなくなり、プラットフォームも無駄なリソース消費がなくなる。

まとめ

以上では、CRE の方法論についてまとめた。

何をしたら顧客のためになるかを考え、計測し、ひとつずつ解決していきましょう。

Superset で TD に接続できるか動作確認をした

サマリー

  • Superset から TD に接続する方法として pyhive、trino-python-client、sqlalchemy-trino を試したがどれも現時点までの実装だと対応が難しそう。
  • pyhive にパッチを当てることで接続でき、クエリが実行できることを確認した。
  • [2022-02-08 追記] 最新の trino-python-client をインストールすることでクエリが実行できることを確認した。

Superset を localhost で動かす

こんな感じの Dockerfile を用意して、

FROM apache/superset:1.4.0
USER root
RUN superset db upgrade && \
superset init && \
superset fab create-admin \
            --username superset-admin \
            --password superset-admin \
            --firstname Superset \
            --lastname Admin \
            --email admin@superset.com

build して run する。

docker build . -t superset-td-example
docker run -d -p 8088:8088 superset-td-example

http://localhost:8088/ にアクセスして、Dockerfile で指定したユーザー名とパスワードを入力し、ログインできることを確認。

f:id:wonderthinkanswer:20220206162707p:plain

TD への接続確認

PyHive で動作確認

PyHivePython から Hive/Presto に接続する際に使われる一番ポピュラーなライブラリであり、sqlalchemy の Hive/Presto dialect である。 上記の Superset の用意した docker image にもすで含まれており、デフォルトでは Hive/Presto への接続ではこれが使われる。

Superset のコンソール上から database を作成し、接続テストする。 設定はこんな感じ。<<TD_API_KEY>> は実際の API key に置換する。

# SQLALCHEMY URI
presto://api-presto.treasuredata.com/td-presto/sample_datasets
# ADVANCED > Others > ENGINE PARAMETERS
{
  "connect_args": {
    "username": "<<TD_API_KEY>>",
    "port": 443,
    "protocol": "https"
  }
}

f:id:wonderthinkanswer:20220206165551p:plain

f:id:wonderthinkanswer:20220206165600p:plain

Test Connection を実行すると、Connection looks good! と表示され成功するが、 Connect を実行すると An error occurred while creating databases: Fatal error と表示され失敗する。docker のエラーログを確認すると Missing X-Presto-User header が原因であることが分かる。

sqlalchemy.exc.OperationalError: (pyhive.exc.OperationalError) Unexpected status code 401
b'{"id":"20220206_075652_49433_c4j75","infoUri":"http://not_accessible","stats":{"state":"FAILED","queued":false,"scheduled":false,"nodes":0,"totalSplits":0,"queuedSplits":0,"runningSplits":0,"completedSplits":0,"cpuTimeMillis":0,"wallTimeMillis":0,"queuedTimeMillis":0,"elapsedTimeMillis":0,"processedRows":0,"processedBytes":0,"peakMemoryBytes":0,"spilledBytes":0},"error":{"message":"Missing X-Presto-User header","sqlState":"FAILED","errorCode":4,"errorName":"PERMISSION_DENIED","errorType":"USER_ERROR","errorLocation":{"lineNumber":1,"columnNumber":1},"failureInfo":{"type":"com.treasuredata.prestobase.core.PrestobaseException","message":"[InvalidArgument] Missing X-Presto-User header","suppressed":[],

同様の Issue は PyHive に報告されており、当該 PR は close はされているが問題は解消していないようだ。

Fix get/delete requests in Presto to accept headers by toru-takahashi · Pull Request #200 · dropbox/PyHive · GitHub

更に、今年 2022年 に入り、PyHive は unsupported であるというという明記がされてしまったため修正が取り入れられることはなさそうだ。

Mention that project is unsupported

Update README.rst by bkyryliuk · Pull Request #423 · dropbox/PyHive · GitHub

PyHive では trino の dialect もサポートしていたようだがベースは presto のものであり問題は解消されない。

trino-python-client で動作確認

trino-python-client では trino の sqlalchemy の dialect をサポートしている。 と言うことで、上記の Dockerfile に

pip uninstall -y pyhive && \
pip install trino

を追加して build & run する。 再度、Superset のコンソール上から database を作成し、接続テストする。

# SQLALCHEMY URI
trino://api-presto.treasuredata.com/td-presto/sample_datasets
# ADVANCED > Others > ENGINE PARAMETERS
{
  "connect_args": {
    "user": "<<TD_API_KEY>>",
    "port": 443,
    "http_scheme": "https"
  }
}

Test Connection を実行すると ERROR: line 1:8: Function 'version' not registered が表示され失敗する。

元の実装であった sqlalchemy-trino の issue を確認すると、どうやら当該 trino の dialect でサポートしている trino のバージョンは 352 以降らしい。エラーの元となっている select version(); がどこかの時点でライブラリで使用されるようになり、それをサポートしている trino が 352 以降ということのようだ。

Update Readme Instruction to clear supported trino version · Issue #7 · dungdm93/sqlalchemy-trino · GitHub

TD のサポートする trino のバージョンは 350 が最新であり、アップグレードによる問題の解消はできない。

[2022-02-08 追記]

twitter でつぶやいたところ、ebyhr さんに補足され、trino-python-client の修正パッチを書いていただいた!

server_version_info: Optional[Tuple[Any, ...]]
"""a tuple containing a version number for the DB backend in use.
This value is only available for supporting dialects, and is
typically populated during the initial connection to the database.
"""

[https://github.com/sqlalchemy/sqlalchemy/blob/main/lib/sqlalchemy/engine/interfaces.py#L518-L522:title]

どうやら server_version_info は dialect の実装補助のための情報で、trino-python-client では使っていなく、必須ではないようだ。 ということで、

pip uninstall -y pyhive && \
pip install trino==0.310.0

みたいな感じで最新のものを使うとクエリを実行できることを確認した。Happy!

[追記ここまで]

sqlalchemy-trino で動作確認

それではと、上記の select version(); の導入前の sqlalchemy-trino を使うことで問題が解消されるか確認する。

Dockerfile の pip 実行部を trino から sqlalchemy-trino に修正して、改めて build & run する。

pip uninstall -y pyhive && \
pip install git+https://github.com/dungdm93/sqlalchemy-trino.git@d343c46b79475b577c8a1fa166dfec30112c10e3

再度 Database を作成し、Test Connection を実行すると ERROR: Access Denied: Cannot select from table runtime.nodes が表示され失敗する。

これは、TD が runtime.nodesというシステム用テーブルへのアクセスを許可していないことに起因するため、こちらも解消は厳しそうだ。

誰も心当たりのないPrestoクエリについて - PLAZMA by Treasure Data

PyHive にパッチを当てて動作確認

pyhive、trino-python-client、sqlalchemy-trino の現時点までの実装だと対応が難しそうなので、パッチを当てることで接続できるか確認する。 pyhive を fork して下記 Toru-san の PR の修正をそのまま pyhive に適用し、適当に push する。

Fix get/delete requests in Presto to accept headers by toru-takahashi · Pull Request #200 · dropbox/PyHive · GitHub

Dockerfile の pip 実行部を下記のように修正して、再度 build & run。

pip uninstall -y pyhive && \ 
pip install git+https://github.com/satoshihirose/pyhive.git@develop

Superset にログインし、上記 pyhive のセクションの設定のまま Database を作成すると、成功した。

f:id:wonderthinkanswer:20220206183551p:plain

クエリエディターから実際にクエリを実行できることを確認した。

f:id:wonderthinkanswer:20220206183840p:plain

30年後読んでも面白いであろう海外SF小説10選

これはなに

ここ3-4年、散発的にSF小説を読むにつれSF小説好きとしての自認が徐々に強くなってきた。そこで、大した冊数もない自分の既読本の中から、特に面白いと思ったものを挙げて自分の考えをまとめる。

このリストの中で一番古い作品は1949年の一九八四年で、一番新しい作品は2019年の息吹だ。基本的には SF は新しいものが良い。科学技術の発展とともに生活様式や社会が変わり、想像力の土台となる常識が更新されていくからだ。一方で、それと同時に普遍的なテーマを取り扱った SF は古びれない。70年以上前に書かれた一九八四年やファウンデーションは今読んでも傑作である。特に銀河を旅するような遠未来を描くハードSFは、舞台が現代社会から時空間共に離れているため普遍的なテーマを選ばざるを得ず、その傑作は30年後読んでも今と変わらず面白いだろう。自分がハードSFを好んで読む理由と今回のリストにハードSFが多く含まれている理由がそれだ。

30年後読んでも面白いであろう海外SF小説10選

息吹 (テッド・チャン

あなたの人生の物語」を映画化した「メッセージ」で、世界的にブレイクしたテッド・チャン。第一短篇集『あなたの人生の物語』から17年ぶりの刊行となる最新作品集。人間がひとりも出てこない世界、その世界の秘密を探求する科学者の、驚異の物語を描く表題作「息吹」(ヒューゴー賞ローカス賞、英国SF協会賞、SFマガジン読者賞受賞)、『千夜一夜物語』の枠組みを使い、科学的にあり得るタイムトラベルを描いた「商人と錬金術師の門」(ヒューゴー賞ネビュラ賞星雲賞受賞)、「ソフトウェア・オブジェクトのライフサイクル」(ヒューゴー賞ローカス賞星雲賞受賞)をはじめ、タイムトラベル、AIの未来、量子論、自由意志、創造説など、科学・思想・文学の最新の知見を取り入れた珠玉の9篇を収録。

https://www.amazon.co.jp/dp/4152098996/

あなたの人生の物語テッド・チャン

地球を訪れたエイリアンとのコンタクトを担当した言語学者ルイーズは、まったく異なる言語を理解するにつれ、驚くべき運命にまきこまれていく…ネビュラ賞を受賞した感動の表題作はじめ、天使の降臨とともにもたらされる災厄と奇跡を描くヒューゴー賞受賞作「地獄とは神の不在なり」、天まで届く塔を建設する驚天動地の物語―ネビュラ賞を受賞したデビュー作「バビロンの塔」ほか、本邦初訳を含む八篇を収録する傑作集。

https://www.amazon.co.jp/dp/4150114587/

三体(劉 慈欣)

物理学者の父を文化大革命で惨殺され、人類に絶望した中国人エリート女性科学者・葉文潔(イエ・ウェンジエ)。失意の日々を過ごす彼女は、ある日、巨大パラボラアンテナを備える謎めいた軍事基地にスカウトされる。そこでは、人類の運命を左右するかもしれないプロジェクトが、極秘裏に進行していた。 数十年後。ナノテク素材の研究者・汪淼(ワン・ミャオ)は、ある会議に招集され、世界的な科学者が次々に自殺している事実を告げられる。その陰に見え隠れする学術団体〈科学フロンティア〉への潜入を引き受けた彼を、科学的にありえない怪現象〈ゴースト・カウントダウン〉が襲う。そして汪淼が入り込む、三つの太陽を持つ異星を舞台にしたVRゲーム『三体』の驚くべき真実とは?

https://www.amazon.co.jp/dp/B08KWLBML3

ファウンデーションアイザック・アシモフ

銀河系宇宙を支配する大銀河帝国に、徐々に没落の影がきざしていた。ひとたび銀河帝国が崩壊すれば、各太陽系は小王国に分裂し、人類はふたたび原始の暗黒時代に逆行する運命にあった。このとき現われた天才的な歴史心理学者ハリ・セルダンの予言は? 巨匠の最高傑作たる未来叙事詩三部作。ヒューゴー賞受賞作。新訳決定版。

https://www.amazon.co.jp/dp/4488604110/

ハイペリオンダン・シモンズ

28世紀、宇宙に進出した人類を統べる連邦政府を震撼させる事態が発生した!時を超越する殺戮者シュライクを封じこめた謎の遺跡―古来より辺境の惑星ハイペリオンに存在し、人々の畏怖と信仰を集める“時間の墓標”が開きはじめたというのだ。時を同じくして、宇宙の蛮族アウスターがハイペリオンへ大挙侵攻を開始。連邦は敵よりも早く“時間の墓標”の謎を解明すべく、七人の男女をハイペリオンへと送りだしたが…。ヒューゴー賞ローカス賞星雲賞受賞作。

https://www.amazon.co.jp/gp/product/B00EQ0Q78O

エンダーのゲーム(オースン・スコット・カード

地球は恐るべきバガーの二度にわたる侵攻をかろうじて撃退した。容赦なく人々を殺戮し、地球人の呼びかけにまったく答えようとしない昆虫型異星人バガー。その第三次攻撃に備え、優秀な艦隊指揮官を育成すべく、バトル・スクールは設立された。そこで、コンピュータ・ゲームから無重力訓練エリアでの模擬戦闘まで、あらゆる訓練で最高の成績をおさめた天才少年エンダーの成長を描いた、ヒューゴー賞/ネビュラ賞受賞作!

https://www.amazon.co.jp/dp/4150119279/

竜の卵(ロバート L.フォワード)

ほんの数日間のファーストコンタクトの様子を書きながら、同じ時間に進んでいく、外宇宙文明の歴史小説でもある奇妙なSF。 それを実現させるために、人類の100万倍の速度で生きる「チーラ」とよばれる中性子星人が登場。 彼らの一生が人類の15分であるため、直接のコンタクトはほぼ不可能であるが、それでも互いを理解するために行われる通信。 そして、ついに10秒間の物理的なファーストコンタクトが実現する・・・。 ロバート L.フォワード 竜の卵 - かせいさんとこ

https://www.amazon.co.jp/dp/4150104689/

ブラインド・サイト(ピーター ワッツ)

突如地球を包囲した65536個の流星の正体は、異星からの探査機だった。調査のため出発した宇宙船に乗り組むのは、吸血鬼、四重人格言語学者、感覚器官を機械化した生物学者、平和主義者の軍人、そして脳の半分を失った男。彼らは人類の最終局面を目撃する―。ヒューゴー賞・キャンベル記念賞・ローカス賞など5賞の候補となった、現代ハードSFの鬼才が放つ黙示録的傑作!

https://www.amazon.co.jp/dp/4488746012/

星を継ぐもの(ジェイムズ P.ホーガン)

月面調査隊が真紅の宇宙服をまとった死体を発見した。すぐさま地球の研究室で綿密な調査が行なわれた結果、驚くべき事実が明らかになった。死体はどの月面基地の所属でもなく、世界のいかなる人間でもない。ほとんど現代人と同じ生物であるにもかかわらず、5万年以上も前に死んでいたのだ。謎は謎を呼び、一つの疑問が解決すると、何倍もの疑問が生まれてくる。やがて木星の衛星ガニメデで地球のものではない宇宙船の残骸が発見されたが……。

https://www.amazon.co.jp/dp/448866301X/

一九八四年(ジョージ・オーウェル

“ビッグ・ブラザー”率いる党が支配する全体主義的近未来。ウィンストン・スミスは真理省記録局に勤務する党員で、歴史の改竄が仕事だった。彼は、完璧な屈従を強いる体制に以前より不満を抱いていた。ある時、奔放な美女ジュリアと恋に落ちたことを契機に、彼は伝説的な裏切り者が組織したと噂される反政府地下活動に惹かれるようになるが…。二十世紀世界文学の最高傑作が新訳版で登場。

https://www.amazon.co.jp/dp/B009DEMC8W/

雑記: 読む本の選び方

今昔含めて世界で出版されたSF小説は膨大な数ある。人生は有限で、面白い本、自分に合った本を優先的に読みたい。そのためこんな感じで自分が読むSF小説をフィルタすることで、ある程度クオリティを担保している。

  • 翻訳物: 翻訳されたものは当地で売れた、翻訳者と編集者のお眼鏡にかなったなど、一定のクオリティが期待できる。大森望さん訳の本は特に信頼できる
  • 受賞歴: ヒューゴー賞ネビュラ賞ローカス賞などのSF関連の賞を複数取得していると基本的にクオリティが高い
  • その他: 人がブログ記事や書籍中で紹介しているもの、何らかのランキングに載っているもの

上記の条件下にあるような本を手に取り、あらすじを見て気になるものを選んでいる。 もちろん日本のSFも読むし例外はあるので、結局は自分の直感に従う。

おわりに

この中で普段SFを読まない人、時間がない人に一冊だけ勧めるとしたらテッド・チャンの息吹を勧める。一番好きな作家を一人挙げろと言われたらテッド・チャンを挙げるだろう。この中で順位を着けるなら、上位三つは息吹、ハイペリオンファウンデーションだ。

ファウンデーションはAppleTV+でドラマ化されたのを見たが、小説とは別物になっていた(映像は良かったが、脚本が微妙な出来だった)。砂の惑星デューンの映画化は小説に割と忠実に作られていたが、それでも映像作品は派手な動きと音楽、見たことのない画を楽しむもので、小説とは楽しみかたが違うなと感じた。長大なストーリーと緻密な設定や世界観を楽しむには小説の方が向いており、上記リストにはそんな感じの作品が多い。

SF小説を読むことは、想像力は豊かにし、柔軟な思考を育んでくれる。その他の文学と同様に社会の一面を切り取り啓蒙したりもする。近年ではSFに注目したビジネス書も出版されるなどその効用に注目されていたりもする。

しかし、個人的には、SF小説にはそんなビジネスの道具として効能を求めるようなつまらない期待はせずに、好奇心を刺激し、自分の常識を揺さぶってくれるような強烈なエンタメとしてのSF小説との出会いを今後も楽しみにしていきたいと思う。

Modern Data Stack / モダンデータスタックというトレンドについて

はじめに

Modern Data Stack というワードを最近よく目にするようになった。あまり日本語の情報も多くなさそうなのでその周辺情報をまとめてみる。

Modern Data Stack ?

f:id:wonderthinkanswer:20211120160456j:plain The modern data stack in 2021

Modern Data Stack とは、10-20年くらい前からあるデータ処理関連のサービスやソフトウェアと比べて、現代の環境に相応しい設計やコンセプトを提案するような新しいサービス・ソフトウェア群自体、またそれに伴いデータをよりよく取り扱うための方法論や今後の行く末について議論が活発になっているというトレンドを表すバズワードである。 基本的にはツールとしてはクラウド化や周辺技術の進化により、スケーラビリティが高くなったり、特定用途に特化し技術的知識があまり要らなく簡単な設定のみで動く、低コストで要望を実現できるなど、利便性が向上しているという特徴がある。

2020 年からは Modern Data Stack Conference が fivetran 主催で行われていたりするので、アップデートにはその辺を参照すると良い。

Modern Data Stack の特徴やメリット、関連するトレンド

下記の Preset 社のブログ記事が情報量も多く面白かったので、以下ではこちらの記事をもとに、あわせて他の記事も参照して自分の感想も加えながらそのトレンドをまとめていく。ちなみにこの記事は、Airflow、Superset のクリエーターの Max Beauchemin 氏のものである。さすが。

preset.io

データインフラのクラウドサービス化 / Data infrastructure as a service

Snowflake, BigQuery, Firebolt, その他 Managed Airflow サービスの登場など、各種データインフラはマネージドサービスとして提供されるようになっている。それにより、エンジニアがデータインフラを構築する場面は確実に減っている。 代わって、データエンジニアリングチームは、ツールの選択、統合、およびコストの抑制に今後ますます関与していく必要がある。

  • 調達 / procurement
    • 技術やベンダーの調査、コンプラインアンスや各種ポリシーや導入コスト対効果の評価
  • インテグレーション / integration
    • 異なるツール間のインテグレーションは大変
  • コストコトロール / cost-control
    • 従量課金制で青天井なサービスなんかを使う時は、実際に払っただけ価値が出ているかを考えないといけない

関連ツールがさまざま出てきている昨今、トレンドをキャッチアップして正しく技術選定することで結果には大きな差が生まれるだろう。組織に合わないツールを導入することでオペレーションコストや実費には何倍、何十倍もの差が生まれる。

データ連携サービスの発展

昔は各種 SaaS 上のデータを連携するためにコードを書いていたが、データ連携のための Fivetran などのサービスや Meltano や Airbyte みたいな OSS の登場によってそのような問題は解決された。現代でゼロからそのような連携の仕組みを自社開発する必要はない、という話。

ELT! ELT! ELT!

DWH の進化で分散処理が手軽になるにつれて、データのあるところで変換処理をするべきだという話。

ETL よりも ELT をしろってのは最近のトレンドではないが、ますます一般的になるはずってのはまあその通りだと思う。Spark において SparkSQL の重要性が増しているように、同じコンポーネントでデータの変換と分析という本来は異なるワークロードができることが当たり前になっていき、ますます ETL システムがデータベースみたいに振る舞うことが多くなっていく。ストレージとコンピュートの分離も進んでいるので、Spark とか Presto とかをみるとそうだよねという感じ。まだまだ、任意の処理を実行するって感じではないけど、UDF とか独自関数の発展をみると良くはなっている。このトレンドが dbt による ELT の管理というニーズとつながっている。

Reverse ETL

Reverse ETL については下記の記事で紹介したので割愛する。

satoshihirose.hateblo.jp

Max Beauchemin は Reverse ETL をかつての Master Data Management (MDM) のサブセットであるみたいな紹介をしており、EAI とか EII とか勉強しても面白いかもよって言っている。

テンプレート化された SQL and YAML などによるデータの管理

ELT の一般化によって、データの管理はテンプレート化された SQLYAML によって行われるようになってきている。 SQL はすでに標準化され成熟したインターフェイスであり、テンプレート化も容易で柔軟性も与えられるし、コード管理できCI/CDも適用可能であるためである。 この辺は k8s によりリソースの宣言的な管理が進むインフラ周りと同じ方向に進んでいる。 Connor’s McArthur’s 2018 talk “KISS: Keep it SQL, Stupid” がおすすめ。

そのようなトレンドがある一方で Max Beauchemin は、PHP + HTML が古びれていったように、SQL のテンプレート化による手法も表現の多様化には対応できなくなる可能性があると指摘している。例えば SQL のテンプレート化の問題点の一つとして、異なる SQL 方言間で reusable でないということを挙げている。ここにはまだ適切なプログラミングモデルが登場する余地がある。

セマンティックレイヤーの凋落と Headless BI

DWH 上のデータはスタースキーマスノーフレークスキーマなど物理的な実体として存在する。そのまま利用するには各テーブル間の関係性などの知識が必要とされるために利用しにくい。そこで、DWH 上の物理的なデータをビジネスドメインの概念モデルに近づけ利用しやすくすることがセマンティックレイヤーの基本的な目的である(ざっくり)。

BIやDWHやETLツールなどのレイヤーがそのためソリューションを提供している(LookerのLookML、MicrosftのOLAP、TableuのLogical Layerなど)。複数の理由から(複雑すぎる、機能が製品をまたぐことができない、コード管理できないなど)それらの機能は決定的なものにならず、最近ではセマンティックレイヤーは非正規化され実体をもったデータとして(データマートとして)構築されることが多い。つまり、今日ではセマンティックレイヤーの実体はトランスフォームレイヤーに吸収されている。その結果、dbt などのツールが ELT の実行管理だけではなく、Data Lineanage など含めセマンティック管理の機能も搭載され、勢力が拡大している。

一方で、最近は Headless BI という概念も登場しており、セマンティックレイヤーの再興を促す動きもある。

f:id:wonderthinkanswer:20211119221928p:plain

headless bi | base case capital

ちょうど今月リリースされた Supergrain は Headless BI を謳っており、コードによるセマンティックの管理と複数のインターフェイスによるデータをサーブする機能を提供する。

計算フレームワーク (Computation Frameworks)

上記で紹介した Supergrain のような Headless BI ツールにも関連するが、トランスフォームレイヤーに集約されたセマンティックの再利用性を高めることで、なんらかのドメインに特化したデータ変換フレームワークが登場してきている。

まだ、そこまでツール群が成熟している様子はないが、確かにメトリックの管理などはどの会社のデータ管理の中でも不可欠なものだし、それに特化した管理ソフトウェアが欲しいなと日々感じている(dbt にもメトリクス管理機能が実装されたっぽい)。

個人的にもこのレイヤーの発展は気になっているが、Max Beauchemin はこの概念を “data middleware”, “parametric pipelining” or “computation framework” と呼んでおり、また後で記事書くとのことで楽しみにしている。

分析プロセスの民主化、データガバナンスとデータメッシュの試み

Modern Data Stack は分析プロセスを民主化し、その結果、データを扱う仕事が遍く増える。ガバナンスの重要性が高くなるのは言うまでもない。この分野の製品は古くから存在するが(Collibra, Alation etc...)、エンタープライズに特化しており普遍的に使い勝手が良いものではなかった。そのため、スタートアップ各社は自社でそれ用のソフトウェアを作り運用するような状況が生まれていた。

要件に差はあるが需要があることは間違いないため、DataHub や Amundsen はスピンアウトし、マネージドサービスとして提供がなされはじめた(それぞれ Acryl Data, Stemma

組織が大きくなるにつれ中央集権型のデータ管理は問題や労力が大きくなってくる。その結果、最近ではデータメッシュなどのキーワードも提起され、データの各エンドユーザーからなるそれぞれのドメインエキスパートがデータの品質・SLA に責任を持ち、組織全体にデータを提供する非中央集権型データガバナンスが模索されている。そのような組織では、データエンジニアリングチームは、組織の他のメンバーにベストプラクティスを指導、教育、および権限を与える上でその役割を果たすことになる。一方で、データがどのチームに所属するかなど自明でないことも多く、必ずしも簡単に導入できるものではないことに注意する必要がある。

プロダクト組み込み用データサービス

何らかの製品があったとき、ユーザーはその製品上のデータを利用することは必須である。それは REST API 経由かもしれないし、管理画面のダッシュボード経由かもしれない。一方で、基本的で一般的なニーズであるにもかかわらず、製品にそのようなデータ機能を組み込むための開発をする労力はとても大きい。この問題は単一の機能を持った製品が解決する問題というよりは、マネージド BI の Superset による組み込みダッシュボードの外部化、Supergrain のような Headless BI レイヤーによるデータと結びついたインターフェイスの提供など、各種アプリケーションの発展によるものになるのかもしれない。

リアルタイム

データをリアルタイムに活用できるようにするという夢は昔から語られている。製品内部で行うユーザーへのレポートをリアルタイムにできれば嬉しい、自社内のデータを簡単にイベントドリブンで利用、オペレーションに活用できたら嬉しい。ほぼリアルタイムのマテリアライズドビューをサポートしたPostgres互換のデータストアである Materialize 、CDC ベースのリアルタイムデータパイプライン構築サービス meroxa (マネージドDebezium?)など出てきているが、果たして今回は成功するのか。

Analytics Engineer の登場

これまでデータエンジニアはデータ基盤を管理し組織横断でデータ活用の面倒を見てきたが、今後はその需要の高まりに応じて、水平な役割を持つデータエンジニアのほかに特定のプロダクトやチームに紐づく Analytics Engineer として垂直の役割をする新しいロールが活躍できるだろうという話。その役割は、dbt Labs のブログ記事中によくまとまっている。

f:id:wonderthinkanswer:20211119185424p:plain What is Analytics Engineering?

Web 開発において、フロント、バックエンド、フルスタックみたいな役割の違いがあるように、組織の中でのカバーする領域が異なるのは自然に思う。データ関連の職種はさまざま生まれつつある( “Data ops”, “data observability”, “analytics engineering”, “data product manager”, “data science infrastructure” etc...)。

各社ファウンダーが考える Modern Data Stack

最後に Modern Data Stack とは?という質問に対する各社ファウンダーの回答をまとめた記事を紹介する。 興味深いので是非読んでみて欲しい。

www.rilldata.com

個人的には Census CEO の「データはプロダクト化される。そのためにデータチームをプロダクトチームのように“software-ification”するためのものがModern Data Stack」って見方が面白かった。

Data itself is turning into a product that serves all these various use cases, specifically because it is horizontal. So now the only way for a team to reach all the various stakeholders, if it's going to be horizontal, is to think and deliver like a product team. So to me, the Modern Data Stack is the “software-ification” of data organizations, turning what they do into an agile, business-like operational model.

Software Engineering の手法が進化していった後をついてデータ管理・活用の方法がこれから洗練されていくのだろう。

さいごに

ということで、Modern Data Stack についてまとめてみようと思ったら、思ったより長くなってしまったし細かいところで雑になってしまった。各論それぞれ掘り下げがいがあるのでまた記事にでもしたい。

Further Readings

CREを一年やってみたサマリー

転職して一年経過した

CREとしてTDに転職して、一年経過したので今の所感とどんなことやったのかをまとめる。

一人目ロールのCRE

前々職ではAWSインフラに詳しくなって、前職でデータ基盤の開発・運用をした。データ基盤の開発運用は基本的には保守的な活動である。次の職では、会社のKPI改善をより直接サポートできるような領域をやっていきたいと思い、これまでの知見を生かしてデータ基盤の上のレイヤーの活用領域を出来れば良いなと思っていた。TDで募集していたCRE職は、サポートチーム内の一人目ロールで自由度が高く、期待されることも希望に近かったためちょうど良かった。Pre IPOのグローバルSaaS企業の求人はそんなに多くはない。

とりあえずの基本方針として、ICであり特に指示できるメンバーもいないため、各チームのニーズを受けて自分の動ける範囲で手を動かし、まずは短期的に結果が出るタスクに注力した。徐々に触れる領域を増やしていきながら、その中で成果が出て引き合いが強いものに集中的に時間を使い、目に見える成果を積んで信頼を稼いだ。

多分にもれず、TDのCREはGoogleが当初提唱したカスタマーフェイシングなSREっぽいロールとはちょっと違う。直接的・間接的にカスタマーのためになることなら何でもやるプロダクト開発はしないエンジニアロール的な感じである。Data Engineer みたいにデータ基盤の開発・運用に軸足があるでもなく、Analytics Engineer みたいに分析業務に特化しているわけでもなく、データとシステム化でさまざまなオペレーションをエンハンスしたりするような雑多な仕事をしているので、ラベルはCREよりただのSysDEや素直にSoftware Engineerでも良いのかもしれない。きっと企業規模が大きくなると各チームに専属のSoftware Engineerがアサインされるんだけど、今はそこまで大きくないから色々面倒を見ているだけかもしれない。

所属しているのはカスタマーサポートチームだけれど、雑多に色々なチームと一緒に仕事をしている。やってきたことは、具体的には以下の通りである。

やったこと

カスタマーサクセス領域

  • カスタマーヘルスダッシュボードの構築
    • カスタマーサクセスチーム向けに任意のカスタマーの状況やその推移を一覧できるダッシュボードを構築している。CSOpsやっているカスタマーサクセスマネージャー(CSM)が主に要件をまとめ、自分がそれを元にデータを集め、データマートを作って提供した。既存データの把握やワークフローの引き継ぎ、項目追加のパイプラインの改善など、諸々スピーディに対応した。
    • ツールとしてはTDをそのまま利用していて、Digdagでワークフローを書いて、PrestoでTransformしている。
    • TDには独立したデータチームが存在しており社内データを整備してくれていたため、自分は簡単なデータマートを用意するだけでスムーズに導入できた。
  • カスタマー向けメール通知の実装
    • Mailchimpを使っていくつかの種類のカスタマー向けメール通知パイプラインを実装した(例えば現在のプラットフォームの利用量がコントラクトの量を超過しそうになったら通知するなど)。
    • カスタマーとCSMのコミュニケーションが生まれ、複数Upsellに繋がっている事例を確認しておりコスパの良い施策だった。
  • インターナル向けSlack通知の実装
    • 担当カスタマーの利用状況になんらかの変化があったときに Slack でメンションされるようなもので、必要なデータを揃えながらひとつひとつ実装を進めている。アクションに繋がる通知を用意するのはなかなか簡単ではない。
  • 将来のカスタマー利用量予測
    • CSMがカスタマーとコミュニケーションをする際に利用することを想定した予測値を計算した。上記のインターナル向けの通知やダッシュボードでの表示に利用することを想定しており、そこまで複雑なモデルで高い精度を目指すものでないので、簡単に線形回帰で PoC してみてぱっと見で使えそうなところだけ導入することにした。

カスタマーサポート領域

  • 地道なデータ整備
    • サポートに利用する必要があるけど開発者しか確認できないような状況にあるようなデータを、サポートでも利用できるように整備する日々の活動もデータチームと協力しながら行っている。
  • Hive バージョンマイグレーション状況確認用のダッシュボード
    • カスタマーのマイグレーション状況を確認するためのもの。サポートチームメンバーでも全然対応できるんだけど、データ追加が必要で全般的に把握している自分が対応するみたいに分業できるとまあ効率が良いでしょう。
  • サポートチーム向けの社内ツールを開発するサイドプロジェクト的なもの
    • データパイプラインを作ったり、Retool を使って UI を作ってみたりした。
    • Retool は気に入ったので、Mandrill 用に通知プレビュー機能を作るなどもした。
    • 自社開発されているTDと連携したAPIレイヤーが既に存在しており、ETLを書くだけでエンドポイントが自動で生えてくるため、Retoolと組み合わせると素早くデータクライアントアプリケーションが開発できる。開発者体験がとても良い。

プロダクト領域

  • PM向けダッシュボード
    • ProductOps メンバー主導で、プロダクト開発サイクルで使われるメトリックのためのパイプラインを用意した。さまざまなメトリックとダッシュボードを作成したが、実際のところ現時点で有効活用されておらず、これは用途に目を向けない要件定義が原因だったと反省している。次回からは要件定義段階から深く食い込めないものにはコミットしないくらいでも良いかもしれない。
  • 簡単なプラットフォーム活用状況分析
    • feature flag の有効化数の推移から、ファネル分析や、有効化されていない機能や特定機能がどれだけ稼いでいるかを可視化した。プロダクト開発の優先順位決定に利用できるものかと思っている。
  • カスタマーとデータ共有をするためのソリューション開発
    • UX の改善にはプロダクトの改善や開発へのコミットが近道である。現在所属するサポートチームはカスタマーフェイシングな機能開発ノウハウがあまりないため、試行錯誤、紆余曲折ありながら苦労して進めている。

その他オペレーション領域

  • bot 開発
    • 各種社内メンバーのオペレーションを改善するため、bot を開発していくつか機能を実装した。
    • TDにはクエリの実行結果を簡単に可視化する機能がないため、Job ID を渡すとクエリ結果を使ってグラフを描いてくれる機能を用意した。
    • その他、Box上のファイルが更新されたら通知する機能やTableauのチャートをSlackに通知する機能など(この同様の機能は後にTableauによってサポートされた)。

できなかったこと・今後やっていきたいこと

  • Cost・Performance 観点での利用方法の最適化やフィードバック
    • 実行されている無駄な処理を見つけてそれを無くすことができればカスタマーもプラットフォームもハッピーである。この辺できてないなーって言ったら、同僚がアイディアを出してくれて早速今月から動き始めることができたので、二年目はその辺もっとやっていきたい。
  • プロダクト改善活動
    • 自分はプロダクトを開発するエンジニアではないけれど、やっぱりCXを改善するにはプロダクトが良くなることが一番なので、その辺にうまく貢献するやり方を見つけられれば良いな。必要な労力もそれだけ大きいため片手間ではできないという実感はある。

まとめ

一通り自分が覚えている範囲でこの一年に試みたことを挙げてみた。上手くいったものと上手くいかなかったものがある。CREとして一人目ロールであり、ニーズベースでさまざま雑多な取り組みに関わっていったが、もうちょっと反省点やCREロールのあり方を整理をして、次の一年間に活かしていきたい。

[PR] 求人

最後は、求人の宣伝になります。今はタイミングが良いのでお話し聞くだけでもお気軽にどうぞ〜。現時点では CRE とか Data Engineer みたいなポジションは空いてないかもしれないですがそのうち空くかもしれません。チーム間の異動やロケーションの異動も割と目にするので、フレキシブルにキャリア考えている人にとってもいい環境なんじゃないかなと思います。

行ってみたいリゾートホテル3選、2021年夏

新婚旅行でバリに滞在したときの体験が良かったので、人生で財布に余裕ができたらまたリゾートホテルに滞在したいなと思っていたが、コロナ禍で目処が立たなくなってしまった。時間もあり Apple TV 4K も少し前に購入したので、滞在するとしたらどこが良いかなーと YouTube をザッピングしていたりしている。実現性はともかくこのリゾートホテルに行きたいなと思ったところを紹介する。

Maldive | Soneva Fushi

モルディブの海は一度見てみたい。モルディブには死ぬほどホテルがあるが、その中でも独特の哲学を表現している Soneva リゾートが気に入った。

About Soneva | Discover Soneva's SLOW LIFE philosophy

ホテルとは関係ないが、上記動画元の YouTuber の他の映像もクオリティが高くて良い。

Lucas T. Jahn - YouTube

Saint Lucia | Jade Mountain Resort

カリブ海の島国、セントルシアにあるリゾートホテル。山と海を同時に臨むダイナミックな情景が良い。上記動画中のオープンエアーの壁がない部屋に泊まってひたすら景色を眺めたい。

Bali | THE APURVA KEMPINSKI BALI

バリ島のヌサドゥアエリアに 2019 年にオープンしたホテル。とても背の高いロビーとそこからの眺め、水槽に囲まれたレストランがとても印象的。やっぱりスケールの巨大な建築は良い。

感想

上記でわかるように、青い海、白い砂浜みたいな典型的なビーチリゾートが好きなようだ。高原とか雪山、みたいなリゾートも世の中にはあるが、やはりリゾートは水平線を臨む南の島が良い。