astamuse Lab

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

Kaggle Days Championshipに参加しました

こんにちは、中塚と申します。

今回の記事では、私が先日参加したKaggle Days x Z by HP World Championship (以降、Kaggle Days Championship) について紹介します。ただし、どれくらいCompetitionの内容に触れていいのかが不明なので、今回はタスクや解法の詳細には触れませんのでご理解願います。

私はチームで参加しましたが、チームメンバに恵まれたこともあり、上海開催ではPublic (暫定順位) 11位 / Private (最終順位) 14位、ニューデリー開催ではPublic 4位 / Private 3位でした!各開催のいずれかで3位以内に入ると、バルセロナのオフラインでの最終開催への参加権を得ることができるので、私はスペインへ行くことができそうです。

Kaggle Days Championshipとは?

Kaggle Days Championshipは、KaggleとLogic AIが主催のMeetupイベントで、オンラインで12開催した後、最終イベントがバルセロナでオフライン開催される予定です。本記事執筆時点 (2021/12) では、2開催はすでに終了しています。参加費用は無料で、各MeetupではKaggle Grandmaster (GM) のプレゼンテーションの後、Competitionが開催されます。上述した通り、各オンラインの開催のいずれかで3位以内に入ると、バルセロナのオフラインでの最終開催への参加権を得ることができます。

各開催のタイムテーブルとしては、大体以下の通りです。

  • Opening・GMのプレゼンテーション: 計1-1.5時間程度
  • Competition: 4時間
  • Closing: 0.5時間程度

以上の通り、Meetupは計6時間近く掛かります。また、仮に3位以内に入賞した場合、その後2時間以内にソリューションの提出が求められます。

下に、公式の告知ビデオのリンクを貼っておきます。

youtu.be

Competitionについて

CompetitionはKaggleのInclass competitionとして開催されます。タスクは開始の10分前くらいに公開されます。チームは最大4人までで、チームを組むデメリットは私が知る限りはないので、できるだけチームを組んで参加することをお薦めします。ソロで参加している場合でも、公式のSlack内でチームメンバを募集できます。

タスクの詳細は開始時間の直前に公開されます。そのため、様々なタスクについてのコードの準備を予めしておかないと、あっという間にCompetitionの時間が終わってしまいます。第1回の上海開催は画像の分類、第2回のニューデリー開催では匿名化されたテーブルデータの回帰がタスクでした。なお、第1回の開催は直前のGMのプレゼンが画像タスクにおけるアプローチに関するもので、実際のCompetitionも画像に関するタスクでしたが、第2回は自然言語処理に関するプレゼンの後、テーブルデータを使ったタスクが行われました。私はプレゼンを聞きながら、大量の事前学習モデルをひたすらダウンロードしていましたが、それらを全く使うことはありませんでした・・・。

いずれの開催でもCompetitionの時間内で試行錯誤ができるようにデータは比較的軽量にはなっているものの、特に画像や自然言語処理では大きなモデルを使って精度が上がることが多いので、計算リソースがある方が有利になるのは否めないと思います。とはいえ、Kaggle NotebookやGoogle Colabで参加しているユーザもいます。いずれにせよ、効率よく実験を行うことが求められているでしょう。

また、ここまでの2開催に参加した限りは、DiscussionやNotebookの公開が盛んな訳ではないので、勉強目的でCompetitionに参加するより、腕試しや楽しむことを目的にして参加することを個人的にはお薦めします。もちろん、GMのプレゼンテーション目的に参加するのも良いと思います。

今後の開催について

本記事執筆時点では、残り10開催あります。既に終了した開催も含めて、下表に日本のタイムゾーンでの開催日時をまとめました。時差は私が調べたものですので、誤りを含む可能性があります。参加を検討する場合はご自身で確認してください。

Location 開催日 (UTC+9) 開始時間 (UTC+9)
Shanghai 2021/11/18 (木) 17:00
New Delhi 2021/12/09 (木) 19:30
Moscow 2022/01/13 (木) 22:00
San Francisco 2022/02/18 (金) 9:00
Mumbai 2022/03/10 (木) 19:30
Beijing 2022/03/31 (木) 17:00
Tokyo 2022/04/21 (木) 16:00
New York 2022/05/13 (金) 6:00
Dubai 2022/06/02 (木) 21:00
Berlin 2022/06/23 (木) 24:00
London 2022/07/15 (金) 1:00
Paris 2022/08/04 (木) 24:00

いずれも木曜日の現地時間16時開始なので、翌日も仕事や学校がある場合、日本在住の人が常識的な時間に参加できそうなのはものはそこまで多くないのかもしれません。

参加したい場合は、公式ホームページから参加登録を予めしておく必要があります。開催日の3週間前に登録が開始されますが、こちらのページからSubscribeしておくと登録が開始されたときにメールで通知されるので、登録忘れせずに済みそうです。

まとめ

短期間のCompetitionは難しいですが、ハッカソンのような楽しさがあるので、興味が湧けば是非参加してみてください。公式のホームページを見ると、「WORLD CHAMPIONになろう」的なことが書いてあり、開催時間的には少しハードなものが多いですが、なんとなく参加したくなりますよね。

最後に、弊社ではアプリエンジニア、デザイナー、プロダクトマネージャー、データエンジニア、機械学習エンジニアなど募集中です。もしご興味があれば下記のリンクからご応募いただけると幸いです。

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

ご挨拶

どうもお久しぶりです、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を消しつつ共有して活用していけたらかなと思います。

それではー。

Copyright © astamuse company, ltd. all rights reserved.