データ基盤の3分類と進化的データモデリング - 下町柚子黄昏記 by @yuzutas0
この記事は、下書き供養 Advent Calendar 2018 - Adventarの2日目の記事です。 めっちゃ専門的な内容になってしまいました。ごめんなさい。 某Slackでの議論内容をブログに書こうとしたのですが、下書きのまま放置していました。 Wednesday, August 15th と書いてあるので、約半年前の内容となります。 もくじ もくじ はじめに 「データ基盤の3分類」と「（一般的な）技術要素」 1.データレイク（Data Lake） 2.データウェアハウス（Data Warehouse） 3.データマート（Data Mart） 私が考えるデータ基盤の定義 私が考える「あるべき構成」 技術要素を分けるのはアンチパターン 進化的データモデリングを容易にしよう チームとアーキテクチャを選ぶ まとめ 参考 余談 追記 はじめに データ基盤と世間一般で言われるシステムには分類
最新のログもすぐクエリできる速くて容量無限の最強ログ基盤をRedshift Spectrumで作る - クックパッド開発者ブログ
こんにちは。去年の今頃は Rust を書いていました。 インフラストラクチャー部データ基盤グループの id:koba789 です。 背景 クックパッドではデータ基盤の DBMS として Amazon Redshift を利用しています。 既存のデータ基盤について詳しいことは クックパッドのデータ活用基盤 - クックパッド開発者ブログ を参照してください。 今まで、ログは数時間に1度、定期実行ジョブで Redshift 内のテーブルにロードしていました。 ロードジョブの実行間隔が "数時間" と長めなのは、Redshift のトランザクションのコミットが遅いためです。 クックパッドでは数百ものログテーブルがあるため、仮に1分おきにすべてを取り込もうとすると秒間数回以上のコミットを行わなければなりません。 このような頻繁なコミットは Redshift 全体のパフォーマンスを悪化させてしまいます
どのようにデータ基盤を作ったのか？「俺の考えた最強のデータ基盤」は使われない
どのようにデータ基盤を作ったのか？「俺の考えた最強のデータ基盤」は使われない：開発現場に“データ文化”を浸透させる「データ基盤」大解剖（3）（1/2 ページ） 「ゼクシィ縁結び・恋結び」の開発現場において、筆者が実際に行ったことを題材として、「データ基盤」の構築事例を紹介する連載。今回は、「データ基盤」の開発プロセスについてお伝えします。 「使われるデータ基盤」を構築するために筆者が取り組んだ試行錯誤を紹介する本連載『開発現場に“データ文化”を浸透させる「データ基盤」大解剖』。前回はデータパイプラインを支える基盤システム設計について解説しました。第3回となる今回は開発プロセスについてお伝えします。 なお、技術要素としてはPythonやBigQuery、ツールとしてGitHubやJIRAを扱いますが、他の手段でも代替可能な内容です。細部にとらわれずにご自身の担当する業務や組織に当てはめながら
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
