社内の現状を聞いていくとデータ基盤をそろそろ作った方がはかどりそうだ。TechBlog株式会社ホワイトプラスのエンジニアによる開発ブログです。2019-12-01社内の現状を聞いていくとデータ基盤をそろそろ作った方がはかどりそうだ。2019の1日目の記事です。はじめに先日、データレイクが期間にして1ヶ月、実稼働にすると正味7営業日程度で整いました。構成の選定理由、最終的にはどんなデータ基盤イメージを持っているのか。具体的には、利用者をあえて限定せず将来的に発生しうる利用者のニーズに応えうるデータの提供元。とでも呼ぶものを「データ基盤」として以降、話を進めます。今回の記事はデータエンジニアリング領域が中心となります。ちなみに「データ基盤」の概念整理をする上で、この記事が大変参考になりました。yuzutas0.hatenablog.com最終的に動いている構成は以下のとおりで、データレイクをBigQueryとし、パイプラインの構築はEmbulkベースのフルマネージドサービスであるtroccoを利用してかなりシンプルなものとなりました。代表の「データの見える化を進めたいんだけど」という発言を機に、良いタイミングと捉え動き出したのがはじまりでした。そこからは、あえて問題設定を狭めずに、結局なにが出来るとはかどるのだろうか。社内の意見を聞いていくと過去も含めてこんな意見が出てきました。広告データを取得するためのコネクタ開発が追いつかないKPIモニタリングするために可視化をしているが、変更が入った場合の対応が属人化している分析目的のデータ抽出依頼が来るが、似たような依頼を何度も対応するのが効率的ではないどんなデータがあるのか。上記の要件以前の話として、そもそもデータ基盤は使われてなんぼ。とも思いますので、「気軽に使われ続けるものであること」を大前提として加え、整理を終えました。4も自動的に満たせることとなりました。Composerあたりのフルマネージドワークフローエンジンの組み合わせかなと当たりをつけ検討をはじめました。いえ、パイプラインを0から可用性やスケーラビリティを担保しつつ構築する時間の捻出は難しいし...おまけに頑張って構築しても取り込みたいデータソースが増えたら追加コストもバカにならんしな...と悩んでいた際に、少なくともEmbulkインスタンス群の構築を0からやるのだけは避けたい!何か良い感じにEmbulkをラップしているフルマネージドサービス無いかな〜?と探し始めた時に出会ったのがtroccoでした。スポンサードサーチ)があるのがありがたかったです。実際のデータを用いて利用にあたって問題になる点が無いかの検証を行いました。結果、導入にあたり大きな問題は無かったのですが、検証してみて想像以上に良かった点(単純に事前理解が浅かった点もありますが...)としては、「ワークフローエンジン機能も持っていた」というところでしょうか。一般的にワークフローエンジンに期待することとしては、ジョブの実行時間の把握を簡潔に行いボトルネックの特定・対処が容易になるジョブの再実行がGUIから簡易に行い、リカバリー処理が容易になるジョブの依存関係定義を簡易に行える(=依存関係が把握しやすい)あたりかと思いますが、現状はtroccoの場合1と3はジョブが増えてくると、見通しが良くはないというのが正直な感想です。Composerなどのマネージドワークフローエンジンを組み合わせることで1と3も解消可能かと思います。転送処理完了をトリガーにして更新日時を対象に、重複データの排除をするようなSQL実行処理を入れ込むためにtroccoのワークフローエンジン機能を活用しています。1;加えて、サポートツールがslackでレスが早く、初期構築が大変はかどったのも想像以上に良かった点です。処理のボトルネック把握やタスクの改善・改修をしていく上で、将来やりづらくなる可能性があるだろう。感じているため、現時点ではあえて使い倒すことはしていません。Composerなどの組み合わせにより、タスクの依存関係や前後の処理時間の見通しをあげるかどうかを判断する。いう宿題を今回は残しました。00:00社内の現状を聞いていくとデータ基盤をそろそろ作った方がはかどりそうだ。9日目にな...2018-12-06libpcapでVPNのアクセスを可視化するWHITEPLUSで基盤回りの担当をしているakaimoです。Reservedスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。