データエンジニアの1年のお仕事の振り返り

データエンジニア（？）としてのお仕事の1年の振り返りを上長から執筆の許可をいただいたので今年も記事にしておきます。今年やってみたこと・やってみて良さそうに思えたもの・考えが変わったものなど色々と雑多に触れていきます。

※理想からはまだまだ遥かに遠く、他社さんの方が遥かに先を行っている事例も多いですがあくまで1事例としてお読みください。
※筆者はゲーム業界に所属しているため他業界とは結構ずれているところもあるかもしれませんがご容赦ください。
※あくまで弊社のケースをベースとしています。会社や環境・状況など様々だと思いますので1つの事例程度にお考え下さい。

弊社の場合データ基盤は横断基盤の方が良いのでは？という考えに変わってきた

去年のアドベントカレンダーで書いていた時点では「各プロジェクト横断のデータ基盤にするべきか？」「それとも疎結合にしてサイロ化させるべきか？」というのは判断が出ず迷っていました。

去年の記事 :

迷っていた理由（それぞれの感じていたメリットデメリット）は上記記事にはアウトプットしていた一方で、今年は各社の横断基盤の記事などが多く目に付いたり、データ界隈で著名な方々がTwitterで横断基盤寄りな意見を出されていたり、後は仕事でのAWSサポートの方とのMTGであったりその他AWSの各種イベントでも複数回「サイロ化させるべきではない」という話をお聞きしたりして、気持ち的には今後はなるべく統合基盤の方向に持っていこう・・・という感覚になっています。

※もちろん個人の所感であり、会社やプロジェクトに応じて臨機応変に選択すべきではあります。あくまでうちの会社の場合は横断基盤の方が良さそうだ・・・という感覚になります。以降の節では他社さんの記事の引用や横断基盤のメリットなどについて触れていきます。

各社の横断基盤・横断管理などの事例の一例

今年は色々な横断（統合）基盤や横断管理などの各社の記事が出ましたが一例として2020年年末ごろから今年の記事を中心としてリンクや引用などを貼っておきます。規模の大小は様々ですが（どのくらい横断でやるのかetc）、とても事例が目立つ年となったように思います。

※スライド29ページ目から引用。データ管理やデータ定義（データのメタデータ）関係の集約管理などについて触れられています。

統合のメリットは大きい💪
データプラットフォームの統合にはメリットがいくつもありそうでした。

データプラットフォームは、大雑把な傾向として、取り扱うデータ量とカーディナリティ（種類）が増えるほど便利になります。価値ある関係などを抽出できる可能性が広がるからです。
直感的には驚くべきことですが、事業がかなり違うはずのドワンゴとKADOKAWAで、保有するデータを横断的に分析したいというユースケースが既に出ていました。そういった場合にはプラットフォームが異なるためデータエンジニアがアドホックな対応をするしかなく、作業負荷が高い状態でした。

プラットフォームサイト上で展開する複数プロダクトを横断して、サービス全体の現状を分析したい
...
まずPdM向けのケースでは複数プロダクトのデータを統合しておく必要があります。しかも売上データも同じデータセットで見れた方が都合が良いので、Salesforce などのデータもスコープに入れることになるかもしれません。分析上不要な情報項目は意図的に除外する方が良いでしょう。
...
例えば、サービスを横断したデータを使って、新規プロダクトや施策に活かせるかもしれません。ある程度基盤運用が安定してきたからこそ、こうしたアイデアも現実性のあるものになり始めています。

データ提供元の一元化
「ここを見れば全てのデータがある」という状態に近づける
例えば、複数サービスを利用するオーナーさんのサービス毎の利用状況など、複数データソースにまたがる解析が簡単にできるようにする
操作・分析手法などの共通化
データソースに依存しない共通の方法でデータ操作・可視化できるようにする（具体的には、SQLでの統一的操作への対応やBIツールの共通化）

※LINE DEVELOPER DAY 2021、データ関係のセッションをいくつかお聞きしていましたが、LINEやYahooなども横断で扱えるデータプラットフォームやメタデータの一元管理などをされているそうです。

※スライドの67ページ辺りなどに横断基盤等について触れられています。

　新しい統一基盤ではオンラインストレージ「Amazon S3」（Amazon Simple Storage Service）を活用し、各社の購買データなどを集約できる仕組みを整備。集めたデータは、顧客管理やマーケティングなどに関するアプリケーションの開発に活用する方針だ。
セブン＆アイ、AWSをグループ共通のクラウド基盤に　“サイロ化”解消でデータ活用加速

システムの統合によって UI を含む販売面の体験が一休のそれに近づいたことで使いやすくなった･･･というところもありますが、今後の発展性を考えると、Yahoo! トラベルと一休.com のデータウェアハウスが一つ二統合されたということも大きいと思っています。2つの OTA のパフォーマンスを、マスターデータ管理ができた状態で分析ができますし、最近では一休のお家芸にもなったマーケティングオートメーション･･･ 機械学習を利用した、顧客行動に最適化した CRM を Yahoo! トラベルにも展開することができるようになりました。今後が楽しみです。

共通基盤にすることによるメリット

去年の記事でもある程度触れたのですが今年考えが固まって来た点などを踏まえ、感じている共通基盤にすることのメリットについて再度まとめておきます。

他のプロジェクトのデータでの分析や比較などが容易

プロジェクトごとに基盤がサイロ化していると権限や申請なども含めて大変です。データアナリストなどの分析をされる方がその辺の関係各所の調整などで消耗するのは勿体ないと感じます。各プロジェクトでBIツールなどがたくさんばらけている場合ツールの勉強などの負担も増えます。

この辺りのハードルが高いと「〇〇プロジェクトのデータをちょっと分析して役立てたい」となった時に「大変だからやっぱりいいか・・・」となってしまいます。なるべくこの辺りはハードルが下がっていると分析・データ活用面で良いのではという気がしています。

共通のKPIの集計方法を合わせやすい

人によってKPIの定義が微妙にずれていたり集計方法や集計処理の順番が異なったり・・・で各プロジェクトでサイロ化していると数字のずれなどが発生しがちです。この辺のずれはかなり容易に発生しますし厄介です（プロジェクト間の数値比較などで集計方法が合っていないと会社の意思決定などで影響が出かねません）。

統合基盤になっているとデータレイクなどからのETLなどを挟んでテーブル構造やテーブル内容を統一した中間テーブルを設けることもできますし、その後の集計処理は各プロジェクト共通のスクリプトやSQLを通すことも可能になります。

メタデータ管理なども一元管理した方が安心感がある

MonotaROさんのスライドでも触れられていましたがデータのメタデータ（テーブル構造など）もなるべく共通基盤で一元管理し自動化できるところは自動化したりしているとやはり安心感があります。

サイロ化してプロジェクト側が管理している場合、メタデータ資料が保守されなくなったり実際のデータとずれていたりするケースが今まで多く発生しています。

保守されなくなったりする理由としては様々だと思いますが、例えば一例を挙げると

• 資料の管理をエクセルでしていたため保守が大変だった
• エンジニアさんがログの追加や構造変更などをした際に資料の管理をしていたデータアナリストさんへの共有が漏れていた
• 保守担当の方の異動や退職
• 担当の方の役職が変わったことによる保守する時間が無くなってきた

などが考えられます。弊社の場合ゲーム業界なので開発や運用まで含めると1プロジェクトがかなり長期化する都合途中で何らかの要因で保守がされなくなってしまう・・・といったことが過去に結構発生しています。そのためこの辺りはなるべくデータエンジニアとかのデータの仕事の担当者が巻き取って、且つチェックなども含めた自動化などをして出来る限り楽をする・・・と安心できます。

一元管理がされているとデータを触る社内の方からしても「ここを見ればデータの資料が全て見れる」状態だとやはり楽だと思います（関係各所にヒアリングしたり権限関係の申請をしたりと消耗するよりかは）。

※メタデータの管理については後々の節で別途詳しく触れます。

プロジェクト側の方の負担が減る / プロジェクト側の作業に集中いただける

サイロ化させたプロジェクトの方がサービスやツールなどは縛りが少なくプロジェクト側で選択を結構自由に行うことができます。

一方で社内のサイロ化させた形のプロジェクトを見ていた感じ、普段からデータ関係のお仕事を担当していない方がデータ基盤関係やらデータマネジメントやらをプロジェクト側の方々が担当するのは結構大変そう・・・という印象を受けました。なんだかんだ「こうした方が良い」「こんな感じにしておくと長期的にも無難」といった過去の学びなどを活かしたり地雷を避けたり・・・といったところはやはりデータの専門の担当者に投げていただいた方が無難そうという印象があります。

特にリリース前などでデータ基盤関係の対応をプロジェクト側の方が担当するというのはただでさえ忙しい中での対応となりますし、それであればもっと他のプロダクト自体の価値を高めるタスクにリソースを集中させたりした方が良いケースもあると思います。

また、ゲームというプロジェクトの都合各プロジェクトのリリース回数は少ない（開発期間が長い）のでデータ基盤を整備する機会が各プロジェクトの方側で頻繁に得られにくいというのもあります。

こういった点を踏まえるとEmbulkなりFluentdなりFirehoseなりでログを送るところだけはプロジェクトの方に対応いただく必要がありますが後の作業は横断基盤のチーム側に丸投げしていただく・・・みたいな形がスムーズなのではという印象がしています。プロジェクト側の皆さんも他のタスクにリソースの多くを割くことができますし、共通基盤上で他のプロジェクトでの経験も活かして地雷などを避けられますし、過去の対応のスクリプトなども使いまわしたり（同じものを使って集計を合わせたり）などもすることができます。サイロ化させた時の自由さのメリットよりもプロジェクト側の方々の負担増のデメリットの方が大きいかもという所感です（ただ、この辺は会社やチームなどの状況に結構依存するとは思います。自由さを優先した方が良いケースも勿論世の中にはたくさんあるとは思います）。

ツールが統一され、ツールを学ぶ負担などが減る

エンジニアからすると色々なツール触れるのは楽しいのですが、非エンジニアさんからすると頻繁に使うツールが変わるとか異動する度に別のツールになる・・・というのは、普段から他の業務を忙しく消化されている方々からすると少しマイナスになるかもしれません。

横断基盤・横断BIツールだとその辺のキャッチアップの負担が減りますし、他の部署のデータを使って分析などをする時も楽ですぐに着手することができます。

横断基盤で扱うデータの個人情報について

横断基盤にすると個人情報をどうするのかといった話が出てきます。これに関しては過去のデータエンジニアリングの勉強会（データアーキテクト（データ整備人）を”前向きに”考える会のシリーズのどれかか、Data Engineering Studyのシリーズのどれかだったか・・・）などでも何度か見てきましたが、そもそも横断基盤で扱うデータは個人情報を除いたりもしくはハッシュ化したりして扱っても問題無い形にする方向に新しいプロジェクトからはなっていっています。お問い合わせ対応などで個人情報を含んだデータにアクセスしないといけないケースは横断データ基盤のものとは分けて、個人情報を含んだデータへはごく一部の方しかアクセスできない・・・みたいな形で進んでいます。

以下の記事の「分離パターン戦略」とかに該当します。

分離することで横断基盤はなるべく「色々考えなくても安全に使える」形が理想と感じています。

昔からあるプロジェクトデータの取り込み・整備対応

昔からあるプロジェクトに関してはプロジェクト側のみに置かれているデータが存在したりといったケースがありますがこれらもどんどん統合基盤側に取り込んでいったり加工・再配置などを行って横断BIツール上でAthenaなどで扱えるようにしたりと整備を進めていっています。

年数的に数が膨大だったりとしており地味で泥臭い作業でもありますが埋もれていて参照があまりされていないデータがたくさんある・・・というのも勿体ないので整備をして今後じわりじわりと活用が進んだらいいなと考えています。

メタデータ管理について

データのメタデータ（ログテーブルの構造資料などの）管理については各社対応が様々だと思います（dbtを使ったり、クラウドサービスで提供されているものを使ったり、コメント付きDDLを必須として運用してそれをドキュメントとして出力したり等）。

参考 :

ちゃんと保守されるならどんなやり方でも良いと思っていますが、基本的には以下の点は抑えておくと良いかなと思います。

• 実際のテーブルとのズレを自動でチェックしてくれるようにしておく（ログが追加になっているのにメタデータ側の資料へのテーブル追加の反映が漏れるとか、カラムが追加になった時に資料への反映が漏れてしまう等を避ける形にしておく）ようにして、ズレを検知したらチャットなどへ通知されるようにしておく（基本的に毎日ズレが発生していない状態を保持する）。
• データを基盤上で扱える状態にした時点でメタデータ資料にも必ず反映される仕組みにしておく（メタデータの資料を更新するとログデータをBIツール上で扱えるようになる等）。
• なるべく手作業を減らして自動化できるところを増やしていく（エクセルでの手動更新などが多いと保守が止まったり実際のものとずれたりしがちですし扱うテーブルは日々増え続けていくので中々保守が厳しいので楽ができるようになるべく自動化する等）。

弊社での横断基盤でのメタデータ管理の対応方法とORM（モデル）を挟んでいるという点について

弊社の管理方法が結構特殊なやり方をしているので正直あまり参考にならない・・・感じがありますが一例として一応触れておきます（ちゃんと保守されるならdbtでもクラウドサービスのものでもコメント付きDDLでも何でもやり方は良いと思っています）。

また、会社がAWSがメインなためログ置き場（データレイクやらDWH、データマート的な領域等）はS3、ログの操作・分析などはPythonやAthenaなどで処理されている形なのでその辺を踏まえて触れていきます。

まず前提としてデータレイク・DWH・データマート問わず各データテーブルはORMを定義する形にしています。DjangoとかSQLAlchemyのモデルみたいなもののイメージになります(以降モデルと表記します)。Djangoなどに慣れ親しんでいる点、それらが快適に思えている点から似たような形で入れています。

ログテーブルは膨大なので追加やカラムの更新などでそれだとモデルの定義や保守で辛くないか？という感じですが、まずテーブル構造の取得に関してはGlueのクローラー的にログから算出でき、型などを含めたモデル用のコードが出力されるようになっているためそこまで負担ではありません。ただし出力内容には型などのテーブル説明や各カラムの説明は設定されないのでその辺は手動で設定したりする必要があります。

リリース前などで一気にテーブル追加になったりするタイミングは流石に少し負荷は高くなりますが、それ以外の時期は今の所は1人～2人くらいでも社内の各プロジェクトのものは問題ないかな・・・という所感です。

テーブル説明や各カラムの説明はモデルに対して設定が必要となっているため基本的にメタデータが漏れることがありません。

モデルに対してテーブルやカラム説明などを追加したものをデプロイするとマイグレーション的にそのモデルの構造に合わせてテーブルが作成されたり構造が変わっていれば同期が実行されます。

また、モデルを追加するとそのモデル定義に応じてSphinx用のテーブル構造資料が出力・同期されるようになっています。これらの資料はモデルデプロイ時に横断のBIツール環境に反映されるようになっており、そのBIツール上からリンクを張ったりSQL編集中などにアクセスができるようになっています。

---

※補足: Sphinxはドキュメント出力用のライブラリです。docstringなども含めたPythonコードを絡めた静的ドキュメントを出力してくれたりします。Python公式であったり、NumPy、Pandas、Dask、PyTorch、boto3などPythonコミュニティではドキュメント関係で使われるケースがかなり多いように感じます。

プライベートで趣味で書いているPythonライブラリでもお世話になっています。

---

基本的に各プロジェクト側からテーブル追加や構造の変更時の連絡をいただいたりはしていますが、加えて追加されているモデルとログを参照して「モデルの追加が漏れているログが存在しないか」「カラム構造がずれているテーブルが存在しないか」といったことは日々自動でチェックされるようになっています。チェックに引っかかったら通知が来るため、モデルの更新などを行うことでテーブル構造・メタデータが同期されます。

モデルのオプションとして特定の共通の種別値定義の箇所へリンクを付けたりする機能もあります。例えばアイテム種別のenumのような定義が存在し、複数のログテーブルでその種別値のカラムが存在する・・・といった場合に、種別値の定義は1か所のみで行って各テーブルからはその種別値へのリンク設定用の定数を加えることで種別値定義は1か所のみでDRY原則的に定義が出来て且つそれらの種別値定義や各テーブルからの種別値などのリンクがSphinxで出力されるようになっています。

まとめると、ログなどから判定してモデル用のコードが出力されるようになっている（Glueクローラー的に楽ができる） → モデルにテーブル説明やカラム説明の設定はデプロイ前に必須になっているのでメタデータ設定が漏れない → デプロイしたらテーブル構造などが同期され、PythonやAthena、BIツール上などで扱えるようになる → モデル内容に応じたドキュメントも自動同期されるので結果的にメタデータ資料とテーブル構造などがずれない といった感じになります。

テーブル構造の同期・メタデータ資料・チェック処理など一通りの処理がモデルを起点としているため諸々がずれにくく、且つできるだけ自動化して長期的な保守が楽になるように・・・という方向で進めています（ゲーム業界で1タイトル開発3年・運用5年とかのタイトルも珍しく無くなってきた点、横断基盤で複数プロジェクト扱うので余計に基盤のプロジェクトは寿命が長期化するのでなるべく楽ができるようにと考えています）。

各プロジェクトで共通の構造を持つテーブルの定義の統一の管理

基本的な指標などで共通の構造を持つテーブルが必要になるケースが結構あります。データレイク部分のデータからETLなどしてテーブル構造などを合わせたテーブルを設け、さらにそこから（各プロジェクトでずれないように）共通の集計スクリプトなどを通した集計結果を保存するテーブル・・・といったように各プロジェクトごとにETLでの中間テーブルと集計結果の2テーブル必要になるケースが弊社では結構あります。

基本的な指標に関しては各プロジェクトでダッシュボードの仕組みも共通のものを利用しているため、そこで参照するテーブル構造は各プロジェクトで一致させておく必要があります。

こういったケースではモデルを挟んでデータを扱うことで、テーブル構造を定義した基底クラスを設けて各プロジェクトごとにその基底クラスを継承したモデルを使う・・・ということをしています。サブクラス側のモデルでは構造は定義しませんし、修正が必要になった場合には基底クラスを1か所修正すればOKなのでDRY原則にも準じることができます。基底クラスが更新されれば各プロジェクト側のテーブル構造も同期され、Sphinxのドキュメントも同期されます。

また、データを扱う際にもダッシュボードのページに応じて基底クラスのモデル + 対象のプロジェクトのIDを指定することでその基底クラスを持つ対象プロジェクトのモデルを取得する・・・という使い方が出来るようになっているためプロジェクト間で構成が一緒のダッシュボードなどは参照するテーブルが異なっていても同じコードで対応ができるようになっています。

この辺りのコードなどが共通化されることによって、（新規プロジェクト対応時に楽ができたり集計処理がプロジェクト間でなるべくずれないように）共通化すべきところは共通化する・・・ということが出来ています。

モデルを挟むことによる型やデータチェック

dbtなどでもデータに対するテストなどが段々と広がっていると思います。

参考 :

長期プロジェクトで単体テスト・自動テストなどが整備されていないとじわりじわりときつくなってきたり保守に時間がかかったりリードタイムが長くなってくるのと同様、データ基盤に関してもこの手のデータチェックやテストなどがしっかりしていないと、日々ログが増え続けたりテーブルが増え続けていくので段々きつくなってきます。

弊社の場合ログの配置先がS3となり、それをAthenaやPythonなどで利用していく形となっているため、極端な話直接S3を操作してテーブル構造に合っていないデータを配置することが出来てしまいます（BigQueryのようにログの配置箇所とDBが統合されておらず、S3とAthenaなどで分離されている形になります）。

分離されていることでこれはこれで便利なことはあります（テーブル再生成などが一瞬で終わったりログが圧縮ファイルで置けたり等）が、一方で変なデータが紛れ込んだりそれによってAthenaでSQLが流せられない・・・といったケースが発生しうる形となります。

Djangoのモデルなどでもデータ操作時には型チェックやテーブル構造に合わせたチェック・変換などが自動でされるようになっていますが、同様にデータ基盤でもモデルを挟むことでデータの操作を行う場合の型のチェックやデータチェック、日次の自動テストなどがされるようになっています。

分析SQL（Athena）環境のブラッシュアップ

多くの会社でBIツール上でSQLを書いたり（Redashなどの場合はPythonなども使ったり）して計算をしたり可視化したりされているのと同様、弊社でも同様にSQLでユーザーが色々できるようになっています。

ただしSQLでの分析などの作業は中々ハードルが高い（普段のアプリ関係での作業とは結構異なる範囲までSQLを学ぶ必要がある）ため、その辺の利用率（分析などによるデータ活用率）を上げたい・・・ため社内でも段々と分析SQLの勉強や社内資料の整備・評価制度・SQLを身に付けていただくためのSQL試験・・・などとじわりじわりと整備が進んでいっています。

評価制度などは私はノータッチで役員の方々や別の方々が進めていらっしゃるようですが、ワークマンさんの分析本にあるようなものを参考にされているようです。評価制度などがリンクしてくると分析のSQLやデータ活用なども進んでいきそう・・・と考えているためその辺りはどんな効果が出るかなどは来年に期待です（評価制度などとリンクしていないと普段皆さん通常業務に追われていてデータを見たり活用・分析したりなどが中々進まないかなと）。

別途BIツール上のSQL実行環境もなるべく社内の方々が楽ができるようにするためのブラッシュアップを入れていってみています。以降の節ではそれらの工夫について触れていきます。

※前述の通り今の所会社がほぼAWSで統一されているため今の所SQL実行環境はAthenaです。Redshiftなどは将来もしかしたら追加するかもしれません。

SQLのエラーで日本語の分かりやすいエラーメッセージを表示するようにした

まずエラーメッセージですが、Athena（Presto）のエラーメッセージがエンジニアの私からしても初見の時分かりづらい・・・というケースがぼちぼちあります（エラーが英語な点、エラー内容の解決方法が推測しづらかったりするケース、もしくは検索してもあまり引っかからなかったりする等）。

そのため、正規表現のパターンをたくさん追加する形でBIツール上で英語のエラーと併記する形で日本語の分かりやすいエラーメッセージ（どういったミスなのか、どうすればエラーを直せるのかなど）を表示するようにしました。

この辺のパターンによるマッピングは自前でやったので漏れは勿論日々出てきますが、マッピング設定がない場合には元々の英語のメッセージのみを表示し且つ足りていないものを検知したら通知が来るようになっており、通知を受け取り次第都度マッピング用のパターン設定を追加する・・・としています（たくさん利用されたり日を追うごとに定義しているマッピングパターンが増えていっています）。

また、定義されているマッピングやエラーが発生するSQL例などはマッピング設定と同期される形でこちらもエラーリファレンスとしてSphinxで自動出力されるようになっています。

細かく入力補完が効くようにした

VS Codeみたいな（PylanceやTabnineなどの）補完が好きなのですが、web上のBIツール上でもSQLに対して細かく補完が効くようにしました。補完の動作もCtrl + SpaceキーなどよりもVS Codeみたく通常の入力だけしていれば補完される形が好みなので近い形になるように調整しています。

補完対象に関しては通常の各SQLキーワードに加えて関数なども補完が効くようにしています。関数の引数情報なども私はしょっちゅう忘れるのでその辺も補完されるようにしています（VS Code上などでプログラミングなどしていても引数情報や補完の表示が無いと結構きついので近い形で補完されるように）。

DB名やテーブル名、カラム名なども補完が効くようにしています。単体の各名称の補完に加えてDB名やテーブル名にドットを繋いだ場合などに候補を対象のものに絞りこんだりといった制御も加えています。例えばany_dbというDBがあったとしてany_db.と入力すればそのDB内に存在するテーブルが補完候補に表示され、any_tableというテーブルがあればany_table.とドットまでを入力すればそのテーブル内にあるカラムが補完候補に出てくる・・・といった具合にプログラムエディタのように楽ができるようにしてあります。

この辺りは前述のモデル定義から自動で設定が出力・同期されるようになっています（この辺もモデルを起点として自動で同期されずれないようにしてあります）。

SQL編集中にリアルタイムに参照しているテーブルの構造資料のリンクが表示されるようにした

SQL編集中にリアルタイムに参照しているテーブルの概要やSphinxで出力された該当テーブルの構造などのメタデータの資料へのリンクがBIツール上に表示されるようにしました。

なるべくメタデータの資料にすぐにアクセスできる状態・・・が好ましいですし利用ログやメタデータの資料へのアクセスログなどを見ている感じ、結構使われているようなのでUX向上的にぼちぼち影響しているのではという印象を受けています。

UI上で任意のSQLキーワードや関数などのヒントが表示されるようにした

VS Code上で関数などの要素にマウスオーバーするとそのインターフェイスなどのドキュメントが表示されたりしますが、それに近い感じの機能をSQLエディタに入れています（説明や使い方例などが表示されるようにしています）。

AthenaだとPrestoのドキュメントを読んだりが必要になるケースが結構多くなりますが基本的にそれらは英語となりますし、日本語でSQLエディタのUIに近いところで表示されるというのは中々良いのではと思っています。ただし定義を全体的に追加するのは結構大変でした・・・（一方で、私の方はPresto関係のドキュメントを全体的にしっかり目を通したりQiita記事にしたりしたので大分勉強にはなりましたが・・・）。

また、社内の複数の方から「MySQL（or Oracleなど）では〇〇が使えたけどAthenaでは使えないみたいでその辺の差異の把握が大変」「全体的に使えるものを把握・検索などできる資料が欲しい」といった意見をいただいたためこの辺の定義もSphinxで自動で出力されるようにしています。対応後にポジティブな意見をいただいたりしているため今後も役立ってくれそうに思います。

Athenaで一時テーブル関係やスキャンサイズのある程度の事前の確認ができるようにした

AthenaだとCTASはできるものの、BigQueryにあるような期限付きの一時テーブル作成のようなことは今の所はできません（将来アップデートでできるようになるかもしれませんが・・・）。地味に一時テーブルなどを作って中間テーブルを挟んだ方がWITH句などでやるよりも快適なケースがぼちぼちあります。

そのためこの辺りは自前で拡張する形で、安全に使えて且つ半年などの経過で自動で掃除される仕組みなどは追加したりしています。

また、BigQueryにはあるdry runによる事前のスキャンサイズの計算なども欲しかったのでS3上に置かれているファイル各日のファイルサイズを事前に保存しておいてSQL編集中にその辺りの目安値が計算・表示されるようにしています。

勿論Parquetなどの列指向のフォーマットを使って且つ列を絞りこんだ場合やLIMIT句などを使った場合には正確には計算できず実際のスキャンサイズが小さくなりますが、SQL実行前にパーティション指定が漏れていてスキャンサイズが膨大になる・・・みたいなことを減らすのが目的なので目安値として使えれば良いか・・・と判断しています。

※Athenaの設定で一度のSQLでの上限スキャンサイズは設定しているので大きく事故るといったことは発生しないようにも別途しています。

AthenaでのETLやELT

ETLやELT処理に関してはAWSで言えばGlueだったりMWAA（Managed Workflows for Apache Airflow）だったりLambdaやFargateなどでPython等で処理したり、Batchだったりもしくはインスタンス上でPythonで扱ったり、もしくはビジュアルスクリプティング的にノーコード（ローコード）で処理できるサービスを使ったりなどと様々だと思いますが、比較的最近追加されたAthenaのUNLOADの機能でも使ってみたらETLがしやすくなっていったので少し触れておきます。

つまり、Athenaのようなサーバレスな仕組みを用いてSQLのみでELT (Extract、Load、Transform)ができるようになりました。今回のアップデートを利用することで、素早くコスト効率の良いAthenaでデータ加工ができるようになります。

今まではAthenaでのETLなどの対応はAWSのイベントでの中の方々でも意見が割れていた（AthenaのETLは便利とおっしゃる方も結構いらっしゃれば、AthenaはETLに向いていないという意見もイベントで聞いたり等）感じがありましたが、UNLOADのものは大分使いやすいなとは感じたのでETLなどに積極的に使ってもいいのではという印象を受けています。なにより、Athenaではスキャンサイズが圧縮後のサイズで計算されるので自動処理で並列でたくさんSQLを流しても非常に安価です（こんなに安くていいの・・・？といったレベルで安価です）。

参考 :

速度もBigQueryなどと比べると結構遅くはなりますが業務時間外などの時間帯に並列でたくさん動かしたりしている感じでは必要十分に感じています。

BIツール上へのSQL試験機能の組み込み

この辺は全社展開はまだで、社内の10人弱くらいの方々に使っていただいたりテストしてみていただいたりしてフィードバックをいただいている・・・といった段階なので結果は来年という感じですが、BIツール上にSQL試験機能が入りました（SQLでのデータ活用を推進されていらっしゃる方の依頼を受けて作成）。

社内の分析のSQL力を底上げしたり評価面で活用したりといった目的になっています。

外部のSQL試験のサービスなどを利用した方が良いのでは？といったような意見も社内で複数ありその辺の議論が結構あったのですが、最終的に自前で追加する形になっています（まあでも最初にいただいた要件を組み終わるまでは8人日くらいでさくっと組めたので内製でも別にいいか・・・という所感を受けました）。

今の所UXなども含め色々いただいているフィードバックはポジティブなものが多く評価制度の整備などと同様にデータ活用の推進で来年全社展開されていったらプラスになると良いな・・・と思っています（まああまり効果が無くてもそこまで膨大な工数をかけているわけではないので、軌道修正してデータ活用推進のための別の施策を試してみるとかで良いとは思いますが・・・）。

自前で既存の横断BIツール上にこの機能を追加してみて良さそう・・・と思った点を最後にまとめておきます。

• UIが既存のBIツールと共通なので普段あまりBIツールに触っていない方にもUIに慣れていただけそう
• 横断基盤のAthenaをそのままSQL試験機能で使う形となるため、DBごとの関数の（UDF的な）方言などで戸惑いにくい（MySQLやPostgreSQLで使えたものが使えないといったケースや、試験がMySQLだけど実務での分析はAthenaといったズレが生じない）
• 試験で使われるデータは既存の実際のプロジェクトのログやマスタデータのスナップショットがベースとなっている（実務に近いログが試験で使われる）
• 実際に社内で分析などをされていらっしゃる方が試験問題の作成を担当された（試験と実務が乖離していない）