astamuse Lab

astamuse Labとは、アスタミューゼのエンジニアとデザイナーのブログです。アスタミューゼの事業・サービスを支えている知識と舞台裏の今を発信しています。

データエンジニアってなに?

ご挨拶

どうもお久しぶりです、gucciです。
あと3ヶ月ほどで入社して4年が経とうとしています。時の早さに驚きが隠せません。
1年経つのが本当にあっという間ですが、よく過去を振り返る際にスポーツやイベント行事とマッピングして記憶することはありますよね。
今年は、我が東京ヤクルトスワローズがセ・リーグ制覇を成し遂げましたので忘れられない1年となりました。
コロナ禍で声を出しての応援はできませんが、やはりスポーツはいつの時代も熱くなれるとってもいいものですね。

スポーツから話を広げてみますと、
近年スポーツにおいてデータというのがかなり重要なファクターとなってきております。
例えば野球だと、投球を球速だけではなく回転数や回転軸で測り解析したり、
打者の打球方向の傾向から算出した守備シフトを敷いたり、
テレビで見ているとAIキャッチャーが次の球を予測したりといった面白い試みも見られます。
サッカーでも選手がどのぐらいスプリントしているか、パス成功率はどのぐらいかなどがすぐに可視化されるようになりました。

日常においても、スマホやIoT家電から大量のユーザデータが送受信される時代になり、
ビッグデータを分析し企業がデータドリブンで意思決定を行うような場面も増えてきていると思います。
大量のデータをもとに機械学習したAIの活用も増えてきました。

そう、まさに大ビッグデータ時代と言えると思います。
そんな時代においてデータエンジニアというのを生業にしている技術者がいます。
かくいう私もアスタミューゼでデータエンジニアになり3年が経過しようとしています。
そんなデータエンジニアがどういう存在なのかどんなことが求められるのかを今回はご紹介したいと思います。

プログラムや詳細な技術のお話しはでてきません。どちらかといえば非エンジニアの方が対象かなと思いますのでご了承くださいませ。

データエンジニアってなにしてるの?

大規模データ基盤の構築・運用をしている人です。
データ基盤とは、データの取得・保管・加工・分析・提供を担う一連のシステム群のこといいます。
ちょっと何言っているかわからないですよね。

簡単なイラストで例えてみましょう。
食材を調達して、料理として提供するまでをいらすとやさんに助けてもらって表現します。

f:id:astamuse:20211110094212p:plain

とってもシンプルですね。
様々な場所から適切な食材を調達して、適切な形で保管・格納してあげることでシェフが自慢の腕を振るえます。

ではもし、超一流のシェフを集めたのに食材がなかったらどうしましょう。

f:id:astamuse:20211110094744p:plain

こうなりますね。
他にも、食材はあるがどの冷蔵庫に何が入っているかわからない、とっ散らかっていて全く整理整頓されていないといった場合は肝心の料理パフォーマンスが一気に低下すると思います。

これをデータの話に置き換えてみますとこんなことが言えると思います

  • そもそもデータがない。取得・蓄積のノウハウがない。
  • データはあるのに全然整備されていないから活用できない。
  • データサイエンティストがデータ整備の部分に多くの時間を取られモデル作成や分析に注力できない。

データを使える形で整備・提供し、適切に分析ができたらどんなに嬉しいでしょう。
そう、まさにこれがデータ基盤の構築です。
また必要であれば食材の下ごしらえまでやってあげたらシェフは大助かりですね。料理のみに集中し最大限のパフォーマンスを発揮することができます。

様々な用途に応じて多様な形式のデータを活用できるように設計・構築・運用を行なっている人が、データエンジニアというわけです。

データサイエンティスト・データアナリストとの違いは?

よくデータエンジニアはデータサイエンティストやデータアナリストと並べられることがあります。
簡単にそれぞれの特徴を挙げると以下です。

  • データエンジニア
    • データ基盤を構築・運用して、データを活用できる形にする。
  • データアナリスト
    • データを分析し、データに意味を持たせることにより意思決定を可能にする。
  • データサイエンティスト
    • データを用いてアルゴリズム、統計分析、機械学習などを行い、未来予測やAI活用を行う。

上のイラストで挙げているシェフの部分がデータアナリストやデータサイエンティストに該当すると思われます。
とはいえこれらは密接に関連しています。
簡単にイラストで表すと以下のようになります。

f:id:astamuse:20211110094811p:plain

明確な境界線というのはなく、なかにはデータ収集・整備から行うデータサイエンティストもいれば、データ活用・分析して意思決定を行うデータエンジニアもいると思います。
このように、データに軸を置いてお仕事している人という意味では仲間であり、
実際にデータ活用することを想定して基盤を作る必要があるのでとても密接に関わっている職種と言えます。

データエンジニアに必要なスキルってなに?

データはどんどん巨大になってきています。
ネットワーク通信が加速度的に成長し、反面ストレージコストはどんどん下がってきています。
これにより大量に多様なデータがじゃぶじゃぶ出てくるので、ビッグデータという言葉が出てくるわけです。
こういったデータをどう捌くかがデータエンジニアの腕の見せ所です。

ではデータエンジニアに必要なスキルはどのようなものがあるでしょうか?
大雑把にいうと以下の要素が重要だと思います。

  • データベースの設計・運用
  • パイプラインの設計
  • 分散処理
  • データの加工

一つ一つみていきましょう。

データベースの設計・運用

「データベースの寿命って実はめちゃめちゃ長いんです」とは弊社のデータベース大臣のお言葉です。これは胸に刺さりました。
蓄積されたデータは非常に価値が高いもので、データを捨てるのは多大な損失となります。

そこで、長年の運用に耐えられるような柔軟なデータベースを設計できると、後から変更が必要になっても最低限の修正で済むためみんなが幸せになれます。
逆に入れ物がひどいと、抽出が困難になりデータ自体を有効活用するのが難しくなってしまいます。
RDB が主流ではありますが NoSQL の方が適している場合もあるでしょう。
近年ではどちらの力も併せ持った NewSQL も登場しています。
データのいわゆる入れ物であるデータベースを、データモデルに適切なアーキテクチャ選定・設計・運用することがとても大事になってきます。

パイプラインの設計

前述のイラストで紹介したように、様々な食材(データ)を簡単に料理(データ分析)できる形にしてあげることがとても重要です。
データを取得しデータを加工しデータを使える形にしてあげる、そうした連続した処理を繋げることでパイプラインというのが構築されます。
そして、このプロセスを全て機械に任せることができれば、データ活用に多くの時間を割くことができますし、また新たなデータへと手を伸ばすこともできます。

データにはそれぞれ性質がありどのようなパイプラインが適しているのかも多種多様です。
リアルタイム性が求められるならストリーミング処理が必要ですし、
日次や週次での定期実行であればバッチ処理で事足ります。
上流から下流へと滞りなくデータを処理して流してあげるパイプラインを設計することが運用という側面で重要になってきます。
人手でのバケツリレーではなく、機械による水道管を引いてあげるようなイメージです。

分散処理

何万件、何億件というデータを処理しようした場合に1つのコンピュータでやっていては何日、何ヶ月経っても終わらない可能性もあります。
大量データを扱うときにはたくさんのコンピュータで処理した方が絶対効率がいいですよね?
そんな処理のことを分散処理といいます。

今の時代はマネージドな分散処理システムも多数存在しているので以前より遥かに分散処理はしやすくなりましたね。
なにより、大量のデータを短時間で処理できたらかっこいいですよね。

データの加工

一番大事なことを忘れてました。
仕入れた食材を加工できないとお話しになりませんね。
世の中には本当に様々なデータが存在します。

  • ファイル形式
    • csv、tsv、xml、excel、json、html ...
  • 文字コード
    • UTF-8、Shift-JIS、EUC ...
  • 同じ文字と思いきや
    • 大文字小文字、全角半角、思わぬ箇所に制御文字が隠れていたり、タイポがあったり ...

多すぎますね。困ったものです。
人間が入力するようなデータには必ずちょっとしたミスも潜んでいます。
たとえ1%しか例外が存在しないという場合でも100万件の場合は1万件、1億件なら100万件にも及びます。

このような多様なデータを加工して共通のフォーマットに落とし込み特定の箱に格納してあげる必要があるわけです。 こうした、データ加工・変換・格納のプロセスをまとめて ETL という言葉でよく表現します。

  • Extract(抽出)
  • Transform(変換)
  • Load(格納)

データの処理自体が ETL ですし、広義な意味ではパイプラインも ETL と言えますね。
ぜひ ETL の名前だけでも覚えて帰ってください。

データエンジニアってなにが楽しいの?

『データ量や要件に応じてアーキテクチャを選定し、データベースを設計し、ETLを実装してパイプラインを構築する(ドヤァ』

・・・こういうとカッコいいですが、実際は結構泥臭い側面も多いです。
実際に生のデータを見るのが非常に重要ですので、
抽出前のデータ、変換後のデータ、想定しない例外のデータ、などなどデータ自体と向き合う時間は必ず要るものでそこがとても大事な時間です。
「最近全然コード書いてないよ!」ということもままあります。
データモデルが把握できていない段階では「なんだよこのデータ、全然知らんよ!わからん!」となると思います。

マイナス面を先に言ってしまいましたが、
自分の集めたデータのことを「このデータめっちゃお客さんに刺さります」と営業の方に言ってもらえたり、
データアナリストが素晴らしい分析をした物凄いレポートを見せてもらったり、
データサイエンティストがどんでもないアルゴリズムでデータ活用をしている姿を見ていると、
「あぁ、データ、役に立ってるんだな・・・」と実感できます。

裏方のような役割で花形とは違うかもしれませんが、そのデータから様々な価値が生まれていると考えると、裏方も悪くないかもしれませんね。

さいごに

いかがだったでしょうか。
かなり抽象度の高い内容だったので、結局なにしているか全然わからなかったという方もいるかもしれません。
「データエンジニアっていうのが存在するんだな」と認識してもらえればもうバッチリです。
また、エンジニアの方は「データエンジニア、ちょっと面白そうやん」と思っていただけたら幸いです。

これからもっともっとデータが重要な時代になってくると思います。
よりリアルタイムなデータが活用されていくでしょう。
あと数年〜数十年は、データ整備には人間の手がまだ必要だと思います。
データエンジニア、やってみましょう。
そして、弊社で共にデータ基盤を作りましょう。

最後に、アスタミューゼではアプリエンジニア、デザイナー、プロダクトマネージャー、データエンジニア、機械学習エンジニアなどなど絶賛大募集中です。
どしどしご応募ください。お待ちしております。

最後までお読みいただき、ありがとうございました。

SpectralでOpenAPI Specをlintしたい!

季節の変わり目に心まで震えてます。chotaroです。

ICPチームでは日々、OpenAPI V3に即してAPIの設計を行なっています。gitlabでは、GUIでSpecを閲覧することができるため、大変便利です。

ですが、この閲覧機能lintまではやってくれないため、気づいたらエラー出るようになってるじゃん!ということであったり、細かい部分の表記揺れはどうしても出てきます。typeはstringで記載されているのに、exampleは数字じゃん!ということもままあります。

致命的な問題には今の所なっていないのですが、後から検知して直すというのも面倒だし、何か起きたら嫌なのでlintするツールないのかな?というのが今回の動機です。

Spectralを使ってみよう

spactralは、JSONやymlファイルをlintすることに特化したツールです。

与えられたルールをもとに、各ファイルの文法や記法をチェックすることができる作りになっており、汎用性高く設計されています。

ルールはrulesetsという形式で定まっていて、デフォルトで利用できるRulesetsにOpenAPI V2, V3用のものも含まれているため、すぐにICPのSpecをlintするために利用することができます。

インストール

コマンドとしてのinstallはnpmで一発です。

npm install -g @stoplight/spectral-cli

もしくはnpxで実行することも可能

npx @stoplight/spectral-cli lint target.yml

OpenAPIのlint設定

先述のようにOpenAPI用のルールセットはデフォルトで用意されているので、それを使う設定をlint対象と同じdirに作成する

echo '{\n\t"extends": ["spectral:oas"]\n}' > .spectral.json

ルールの詳細はこちらのページに記載されているのに加えて、手動でカスタマイズすることもできる。(今回の私のように表記方法を統一したい、くらいのモチベーションであればデフォルトのルールで十分な印象があります。デフォルトの時点でとても細かい。)

lintの実行

/repos/api-docs/v1: spectral --version
6.1.0
/repos/api-docs/v1: spectral lint openapi.yml

/repos/api-docs/v1/openapi.yml
 2:6  warning  info-contact  Info object must have "contact" object.  info
 ...[省略]...
 
 ✖ 91 problems (34 errors, 57 warnings, 0 infos, 0 hints)
 

😱

ログは丁寧に出ているし、確認すると確かに矛盾している部分とかもあったので、間違いが内在しているのは事実なようなので歯を噛み締めて対応したいところですね、、、

Spectralの良いところと困ること

ICPのSpecは $refを利用して、機能ごとに分割されています。

Spectralでは、デフォルトのrulesetsでもこのrefを深掘りして不適切ながないかをチェックしてくれます。えらい。

f:id:astamuse:20211027105522p:plain
refsの中身まで見てくれる

反面で困りごとでもあります。深掘りをするのはいいんですが、深掘りした先まではネストして行数を表示してくれないため、該当箇所の参照元まで行って、どの要素で怒られてるのかを調べる必要があります。仕方ない。。。

メリットの裏返しですが、特に導入時点ですこし手間がかかってしまうかも。

活用方法などの応用編

gitlab-ciに入れ込んでみる

npmが使えるimageを利用すれば、簡単にnpxで実行することもできるので、Circle CI向けの設定を参考に

lint-openapi:
    image: node:16.12-alpine
    stage: test
    script:
        - cd ${CI_PROJECT_DIR}/api-docs/v1
        - npx @stoplight/spectral-cli lint openapi.yml

これでよし。

spectral-cliのinstall含めても20秒ほどで完了しているため、CIとして実行する分には良さそうです。

vscode plugin

2021/10/27時点でPreviewですが、vscodeのプラグインも用意されています。

ローカルではこれで確認しつつ、CIでもチェックする、が良さそう。

lint結果の制御

defaultだとerror以上でexit codeが1になります。

  -F, --fail-severity            results of this level or above will trigger a failure exit code
                                                              [string] [choices: "error", "warn", "info", "hint"] [default: "error"]

Optionで閾値を制御可能。Errorが出てても成功にする、というのはなさそうなので上述のErrorくん達はどうしても対応しなきゃいけない。

そういえばrulesetsってどんなのがあるの?

先述したように、Spectralのlintのルールはrulesetと呼ばれるものによって定義されます。

ルールさえあれば、どんなjsonもymlもlintできるはず。

公式提供はOpenAPIとAsyncAPIの二種類 が用意されています。そのほかに有志のユーザーが作ったものがあればそれも利用してチェックできると。

OpenAPI以外で公開されているルールは・・・?

https://github.com/search?q=spectral+rulesets

f:id:astamuse:20211027105647p:plain
あくまでrepository数だけど6つしかない

githubだとほぼないですね。。。

実質ほぼ公式提供のOpenAPI向けに使われているのが現状なのかな?

終わりに

ここまで見てきて、

導入時点でError取り切る -> ローカルではvscodeでlintチェック -> CIでもlintして警告出してくれるようにする

がいい気がしています。初期導入時には直しきらないといけないので大変ですが、一度通したらあとは常に警告を気にするようになるので、フォーマット面での迷いはなくなりそう。

カスタマイズするかどうかは難しいとこですが、内容が一見して細かすぎるのでひとまずはデフォルトで利用しつつ、窮屈さを感じてきたら検討かなと。とりあえずこれ書いてる現時点ではまだチーム共有してないので、上記のたくさんのErrorを消しつつ共有して活用していけたらかなと思います。

それではー。

昭和二十年のデータ・サイエンティスト

大変ご無沙汰しております。じんと申します。テック・ブログの担当と相成りまして、今回は技術の裏側の思想について考えてみたいと思います。

今回の主人公は堀栄三という人です。詳しくはウィキペディアを参照していただければと思いますが、戦中から戦後にかけて優れた情報分析者として足跡を残しました。彼の著書に『情報なき国家の悲劇 大本営参謀の情報戦記』というものがあります。これはデータに関わる技術者の必読書としてもいいのではないか、とも思われるもので、昔からの愛読書の一つです。

本書は一読するたびに大きな学びがあり、その感想は到底ここで書き尽くせるものではありませんが、今回取り上げてみたい問いは以下のようになります。それは「どうすれば堀栄三のような優れた分析者が生じうるのか?」というものです。これは自分自身が彼のような精密な分析能力をどのようにすれば得られるのか、と考える面もありますし、彼のような分析者をどのように育成できるのか、と考える面もあります。

様々な要素があり、天賦の才というものもあるでしょうし、彼の父が陸軍の幹部であったことも大きな要素として働いているように思えます。一方、彼自身が言及しているように、彼自身が異なる分析姿勢を横断的に経験している点が非常に重要な要素として抽出できるのではないか、と考えるようになり、しばらくそれを整理していました。本書では、大きく3カ国の対する諜報が俎上に上げられています。米国、ソ連、そして当時の同盟国であるドイツです。

大前提として、堀は「情報の究極は権力の中枢から出てくる」と断言しています。権力とはすなわち意思決定の主体ですから、その意思がすなわち情報に他ならず、彼のこの考えは正鵠を射たものと言えましょう。

さて、まずドイツですが、当然、同盟国ですので、情報は比較的入手しやすいものです。ドイツの場合、当時の駐独大使などが、政権内部の要人に対して直接的に聞き取りを行うことができます。すなわち「人」を経由して情報が入ってきます。詳細な情報を得やすい一方、当該情報は同盟国ということもあり、なんらかのバイアスが含まれる危険性があります。一言でいいますと、「盛ってある」可能性が大きいわけです。また、同盟国であるため、どうしてもドイツから提供される情報を心情的に信用しやすくなってしまいます。

次にソ連です。当時は日ソ中立条約下にありますが、ソ連は日本の同盟国ドイツと死闘を繰り広げているなかでもあり、ソ連への諜報はとても難しいものでした。到底要人への聞き取りなど不可能です。したがって、新聞記事、雑誌をはじめとした報道、シベリア鉄道の貨物輸送量、要人の発言内容の過去と現在の違いなど、入手可能な情報を細かく積み上げ、それを多面的に分析していきます。また、当時の陸軍の仮想敵国はそもそもソ連でしたから、ソ連課のアプローチは、相手を端から信用していません。常に情報を疑っています。そのため、精度の高い情報を得るために、様々なデータの収集に余念がありません。ソ連の場合、「データ」を経由して情報を入手していたと言えるでしょう。

最後に米国です。米国に対しては既に開戦していましたから、ソ連と同様に、ドイツのように要人に直接聞き取りを行うことなどはできませんし、ソ連以上に情報収集は難しくなります。さらに状況が悪いことに、当時の陸軍は対ソ戦を重視していましたから、米国に対する分析は不十分なものでした。そこで、当時の堀の上司であった米国担当の杉田大佐は、米国担当を命じられた彼にさっそく現地の様子を見てくるように命じます。彼は驚愕しつつも、ニューギニアのウェワクに出張し、そこで現地司令官の寺本中将から現地の様子を詳しく聞き取ります。ウェワクに到着したまさにその日に彼は早速空襲に晒されます。これはまさに「現場」経由で情報を入手していると言えるでしょう。

まとめると以下のようになるかと思います。

f:id:astamuse:20211008173708p:plain
ドイツ型・ソ連型・米国型のまとめ

堀自身は上司を「親方」、自分を「職人」と書いています。優れた複数の親方から、様々な分析手法を吸い上げ、それを実践、それどころか実戦で磨き上げたことが冒頭の問いへの一つの回答となるでしょう。おそらくこのなかの一つでも欠いたら情報参謀・堀栄三は完成しなかったでしょう。「人」と「データ」だけでは生々しい「現場」はわからず、「人」と「現場」だけでは俯瞰的な「データ」はわからず、「データ」と「現場」だけでは枢要な「人」はわかりません。

東京に戻った堀は様々な情報源から収集した情報を多角的に分析していきます。収集した情報を基に対米戦における基本的な戦術を確立させ、南方戦線に抽出される関東軍部隊に対して対応方針を教授します。この米軍の上陸作戦に対する対応方針は驚嘆すべきもので、データに基づく上陸前の空襲の分類、実際的な数字に基づく彼我戦力の比較など、何やら学術論文を読むような思いがあります。何よりも、彼は『敵軍戦法早わかり』という冊子によって対応方針、すなわち結論を導き出しています。彼は単なる分析者ではなく、体系的な方針を組み立てることができたのでした。

フィリピンでの決戦が近づくなか、堀はフィリピンの山下将軍の情報参謀としてマニラに向かいます。その間、台湾沖航空戦での誤った戦果発表を指摘したものの、それに伴う戦略の誤った変更を止めることはできませんでした。後世から見れば失敗を繰り返していく軍のなかで、堀は山下将軍を補佐し、最善を尽くします。レイテ島で敗北を喫したのち、ルソン島の山下将軍に殉じる覚悟であった堀は、東京に送り返され、本土決戦に向けた諜報に粉骨砕身します。その結果は後世の我々には明らかですが、彼の努力には感銘を受けざるを得ません。

とまれ、データ・サイエンスというものを、一定の規模のデータから何らかの価値、究極的には意思決定をもたらすものであるとすると、常に、そのデータは信用できるのか、意思決定に必要なデータを集め切れているのか、という懸念が生じます。私自身も十分なデータを集め切れているのか、と懸念を感じることが多々あります。これに対して堀は明快に回答しています。

コンピューターが出来て、もうそんな事態はあり得ないと思う人もいるだろうが、今度はインプットするデーターが百パーセント揃っている保証がない。〇・〇一パーセントでも誤差があれば、株式相場のブラックマンデーは必ず起ることになる。

ーー堀栄三. 情報なき国家の悲劇 大本営参謀の情報戦記. 文春文庫, 1996年.

戦後、警察予備隊が陸上自衛隊に改組されて間もない1956年、スエズ動乱が発生します。陸上自衛隊に参画していた堀は、冷戦下にあった米ソの全面衝突の可能性について上司から見解を求められます。堀の判断は「衝突には至らない」というものでした。この判断は堀の上司が上司自身の見解として提出しなければなりません。顧問会議などを作り、その責任の所在を曖昧にしたい、とこぼす上司に堀は冷然と言い放ちます。

「顧問を作っても同じですよ、情報の判断には、百パーセントのデーターが集まることは不可能です。三十パーセントでも、四十パーセントでも白紙の部分は常にあります。この空白の霧の部分を、専門的な勘と、責任の感とで乗り切る以外にありません」

ーー堀栄三. 情報なき国家の悲劇 大本営参謀の情報戦記. 文春文庫, 1996年.

何らかの判断のために情報を収集し、見解を提示する仕事をここしばらく多く行っています。誤った判断は組織に惨禍をもたらし、その可能性を考えるとこれは必ずしも気安い作業ではありません。そんなとき、常に彼のことを考えています。最後にまた冒頭の問いに戻ります。幽明相隔てた彼に直接尋ねることはできませんが、熱心に本書を読み返し、彼の思考を辿り、現代の「データ・サイエンス」を踏まえて、彼に「どうすればあなたのようになれますか?」と尋ねてみます。彼は冷然と一言、言い放つのではないか、と想像しています。「顧問」を「ビッグ・データとAI」と置き換えて。

しかし、0.01%の誤差まで努力した結果は無駄ではない、専門家としての矜恃と責任感を持つ限り、と彼は付け加えます。その時の彼は、私の覚悟を問うように、冷厳に私の眼を見据えています。

データの収集と解析、分析は重要です!アスタミューゼ株式会社ではエンジニアを募集しています!ひりつくようなデータエンジニアリングやデータサイエンスに対して、我こそは、という方からのご連絡をお待ちしております。

Copyright © astamuse company, ltd. all rights reserved.