こんにちは！delyのクラシルリワードでデータエンジニアをしている harry(@gappy50)です〜。 これまで、クラシルやクラシルリワードのデータエンジニアリングに関する発信をこのブログでしてきました。 tech.dely.jp tech.dely.jp tech.dely.jp が、最近ブログのネタに困っていたのと、社内でキーボードにまつわる宗教戦争(?)が勃発したこともあって、 様々な企業ブログで散々こすりにこすられた企画である「突撃！隣のキーボード！ 」のdely版をやってみようと思います。 ただただ、エンジニアメンバーたちのキーボードを中心としたデスク環境を紹介するというだけの企画です。 あとは、個人的にキーボード買い替えたい気持ちがあるので勉強させてもらおうと思っている裏企画も同時並行で走っています。 これを期にdelyのエンジニアの楽しげな人となり(?)を知ってもらえれば

使いたい開発ツールがきっと見つかるFindy Toolsは、実際に利用している企業の レビューから 開発ツールの導入、 検討に関わる意思決定をサポートします。

ナカミチといいます。freeeのデータ基盤でエンジニア業に勤しむ日々です。 今回は長年freeeの分析環境を支えてくれたRedshiftをBigQueryに移行したお話。 なお技術的な詳細までは触れず、移行プロジェクト全体に関して記述しています。 (Techieな記事を期待した方スミマセンｍｍ) 移行の規模はどんなもんか ボリューム的にはざっと下記の通りです。 テーブル数: 約2,000テーブル データ量: 約180TB(snappy) クエリ数: 約500件 移行期間: 約1年4ヶ月(準備期間含む) そもそもなんで移行したの？ 大別すると移行を決めた理由は3つほど。 パフォーマンス向上が見込めた 手段を多様化したい エンジニアリソースの最適化 以下にそれぞれ細かく記述します。 1. パフォーマンス向上が見込めた SQLによりますが、それまで使っていたRedshift環境と比べて平均5〜6

自家製パンチェッタ @jikapan 敷金取り戻しの話で国交省の原状回復ガイドラインが話題ですが，オススメしても「難しくて長い文章読んでたら鼻血が出ました！」っていつも苦情言われるので，都民以外は完全には対応してないのですが，鼻血の出ない長さの賃貸住宅トラブル防止ガイドラインjuutakuseisaku.metro.tokyo.jp/juutaku_seisak… をどうぞ。 2019-10-09 10:39:22

浮気発覚でもなく　DVでもなく　私が1人の時間が無くなるのが本当にダメなタイプだった。結婚する前はそこまでじゃねーだろと思ってたけど、あかんやつだった。そんでまた運が悪いことに、旦那は1人の時間を1人で過ごせないタイプだった。家事でもなんでも一緒にやりたがる。結婚してから余計にそうだった。私が絵、漫画、ゲームと自分の趣味に興じていると不機嫌になったし、拗ねたし、直接不満を言ってきたりもした。それがとてもとてもとてもとてもとても面倒で面倒で面倒で面倒で。ご機嫌取りがめちゃめちゃめちゃめちゃに面倒だった。 家に帰るたびイライラして　家にはわたしのかわいいかわいい猫たちがいるのに家に帰りたくなくなって　もーだめだってなって割と強引に別れた。 他にもいろいろなことにイライラしてたけど一番はこれだったんじゃないかなあ…… 結婚する前はちゃんと同棲もしてて、大丈夫だと思ったのにな。同じ経験をすると同じ

In the evidently tiny professional circles that I run in, the “modern data stack” is having a moment. The concept, which is a new framework to move data around an organization and make it available for people to use and analyze, is inspiring conferences, historical retrospectives, listicles, how-to guides, and companies themselves. A decade after The Economist warned us we’d all soon be drowning i

以前購入した下記書籍『AWSで始めるデータレイク』を切っ掛けにこの書籍を題材にした読書会を始めた、というのはエントリ内でも言及していました。その読書会も今月末の第24回を以て無事最終回を迎える予定です。ほぼ週2回(1回1時間)のペースで駆け抜けた形となりましたが、様々なトピックで大いに盛り上がる内容となりました。 その中でも盛り上がったトピックが『データカタログ』でした。書籍ではAWS Glueのデータカタログが言及・紹介されていましたが、Glueデータカタログ機能そのものの話から、『データカタログ』に求めるもの、また『俺達の欲しいデータカタログ機能はこういうものなのだ』というディスカッションは参加者各位の経験やノウハウ等も相まって熱量が最も多く、また様々な示唆に飛んだ知見を共有することが出来てとても有意義な時間となりました。これだけでも読書会をやった価値があったな、と思った次第です。 そ

Amazon Web Services ブログ 【資料＆動画公開】AWS で実践！Analytics Modernization ～ETL 編～ 2021年7月14日に、「AWS で実践！Analytics Modernization ～ETL 編～」というオンラインセミナーを開催しました。昨今、データレイクをクラウド上に作ることが一般的になりつつありますが、データレイクに溜まったデータを活用する際に重要になるのが前処理（ETL）であり、その前処理をどのようにAWS上で実現し、モダン化するかという点を解説しました。 今回このセミナーの動画と資料を公開しましたのでご紹介します。全部で3つのセッションがありますが、各セッションの中も内容単位で区切った動画にしていますので、必要なところだけ見ていただけるようになっています。 セッション１： AWSのETLソリューション紹介（アマゾン ウェブ サー

CI/CD Conference 2021

About こちらはRedash Advent Calender 2017 19日目の記事です。 qiita.com ノリでFargateを使ってRedashを構築してみました。 もともとのdocker-compose.yml version: '3' services: server: image: redash/redash:${REDASH_VERSION:-latest} command: server command: create_db depends_on: - postgres - redis ports: - "5000:5000" environment: PYTHONUNBUFFERED: 0 REDASH_LOG_LEVEL: "INFO" REDASH_REDIS_URL: "redis://redis:6379/0" REDASH_DATABASE_URL: "

Snowflakeの新機能「Snowpark」が、すぐに試せる「Snowpark Accelerator」を試してみた こんにちは！DA(データアナリティクス)事業本部 サービスソリューション部の大高です。 SnowflakeのPreview機能として、Snowparkという機能がPreview公開されています。 ZoharさんのSnowtire v2プロジェクト「zoharsan/snowtire_v2」では、このSnowparkの機能をすぐに試せるDockerイメージ「Snowpark Accelerator」が公開されています。 下記ブログで「Snowpark Accelerator」について紹介されていましたので、当エントリでは、このブログの手順に従って、実際にSnowparkを軽くさわるまでを紹介したいと思います。 なお、以前に手動でVisual Studio Codeで環境設定

今回、フジロック出演を辞退します。 直前の報告となってしまい、申し訳ありません。 https://t.co/rLLbaQbJpy

条件 現職で管理している現行のデータパイプラインである Treasure Workflow（managed digdag on TD）+ Presto に適用できること ウェブでメタデータのドキュメントが公開でき、社内に共有できること Data Lineage 的なデータの依存関係がわかること dbt dbt は構築したプロジェクトとその内部のクエリを元にドキュメントを自動で生成してくれる。データの依存関係のDAGを可視化してくれるようで、良さそう。dbt docs serve というドキュメントサイトをホストする機能も提供しているが、現時点では本番稼働を想定していないものらしい。その代わりに dbt Cloud を使う、生成したドキュメントを S3 でホストするなどの方法を推奨している。 The dbt docs serve command is only intended for lo

bq_sushi #17 にて、「Data Management by dbt」という発表をしました。

tl;drすべてのデータを高品質に保とうとしない。事業フェーズやプロダクト仕様、マネタイズ方法に応じて、品質を守るべきデータを明確に定義し、「品質が守られた箱の中の世界」を明確にする。データ品質維持の前提は、Single Source of Truth。SSOTなDWHを構築することとセットな取り組みであることが大切。データ品質管理のHowとしては、dbtがおすすめ。not_nullやrelationshipなどdbtがもつtest機能を活用し、データ品質監視を実現しよう。当然、dbtだけでは品質は守られない。Data Meshのような議論から運用体制を考えていく必要もある。聞こえのよい新しいものに踊らされる前に、着実に必要なデータ品質を守っていこうね。 こんにちは、こんばんは。Ubie Discoveryのsotaronです。データエンジニアをやったり、小倉唯さんのファンクラブ会員などを

DeequはAWSがリリースしているデータテストを行うためのライブラリです（Deequの説明ではUnit Testと表現されています）。 ここで言うデータテストは、ETL処理やデータマート作成処理などの意図通り動いているどうか、取り込んだデータが昔と変化していないかを確認するための検証処理のことを指しています。 ETL処理などを最初に作成したタイミングでは、その処理が意図したものになっているか確認すると思います。一方で、日次のバッチ処理や、動き続けているストリーム処理について、本当に意図したようにデータが加工されているかどうかは、通常の方法では処理自体が成功したかどうかくらいしか確認するすべがありません。 しかし、日々のデータ処理は簡単に意図しないデータを生み出してしまう可能性があります。気づいたらデータの中身が変わっていて、変換処理が意図しない動作をしてしまっていたり、そもそもソースデー