データ基盤チーム0人で運用は回るのか？！ 前人未踏チャレンジ・クックパッドデータ基盤のすべて2020 - クックパッド開発者ブログ
技術部データ基盤グループの青木です。 ここ1、2年はなぜか成り行きでBFFをでっちあげたり、 成り行きでiOSアプリリニューアルのPMをしたりしていたので あまりデータ基盤の仕事をしていなかったのですが、 今年は久しぶりに本業に戻れたのでその話をします。 突然の1人チーム、そして0人へ…… 今年のデータ基盤チームは消滅の危機から始まりました。 間違いなく去年末は5人のチームだったと思うのですが、 メンバーがイギリスへグローバルのデータ基盤チームを作りに行ったり、 山へ検索システムを直しに行ったり、川へレシピ事業の分析業務をやりに行ったり、 海へ広告のエンジニアリングをしに行ったりするのをホイホイと気前よく全部聞いていたら、 なんと4月から1人だけのチームになってしまいました。 事はそれで終わりません。 恐ろしいことに10月にはわたし自身も育休に入ることになったので、 10月はデータ基盤が0
[Tips] サクッと MySQL と PostgreSQL と Redshiftに大量データを作成する方法 | DevelopersIO
はじめに 前々から社内で書く書くって言ってた、サクッと大量データを作成する方法を紹介します。（これで書く書く詐欺って言われない♪） 大量データを作成の共通点 大量データを作成の流れは、大量データ用テーブルに自らの空レコードをコピーすることで大量のレコードを作成します。作成したいレコード数に達すると、一気に乱数を用いてレコードに値を設定します。今回の例では、以下のバリエーションのデータに対して値を設定しています。 オートインクリメントの主キーであるid 可変長文字列であるnameとdescription 符号なしINTであるprice フラグであるdelete_flag 日時データであるcreated_atとupdated_at MySQL5.7 / Amazon Aurora(MySQL5.7互換) の場合 items テーブルのidカラムは、AUTO_INCREMENTを用いて自動採番し
![[Tips] サクッと MySQL と PostgreSQL と Redshiftに大量データを作成する方法 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/a6e11f0321ff2b808b3c2e8f450654e734b7b0eb/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2018%2F11%2Feyecatch_aws-services_1200x630.jpeg)
Treasure Data Service と Redshift のハイブリッドアーキテクチャ - トレジャーデータ（Treasure Data）ブログ
*トレジャーデータはデータ収集、保存、分析のためのエンドツーエンドでサポートされたクラウドサービスです。 Treasure Data Service はそれ自身がデータの収集から可視化までの一気通貫したサービスですが，他の様々なサービスと連携することによって各々の分析ニーズにマッチしたアーキテクチャを構成することができます。今回は Amazon Redshift とのハイブリッドアーキテクチャ等の具体的なケースを見て，視野を広めていきましょう。 バッチ処理 Treasure Data Service は標準ではHiveQLによってクラウドストレージに集計処理を実行することができるのですがこれはいわゆる「バッチ処理」という分類で，スケジューリングされたクエリが定時的にバックエンドで集計されるものです。 以前紹介したダッシュボード（上図）：MetricInsights などでは独立したウィジェ
MPP on Hadoop, Redshift, BigQuery - Go ahead!
Twitterで「早く今流行のMPPの大まかな使い方の違い書けよ！」というプレッシャーが半端ないのでてきとうに書きます．この記事は俺の経験と勉強会などでユーザから聞いた話をもとに書いているので，すべてが俺の経験ではありません(特にBigQuery)．各社のSAの人とかに聞けば，もっと良いアプローチとか詳細を教えてくれるかもしれません． オンプレミスの商用MPPは使ったことないのでノーコメントです． MPP on HadoopでPrestoがメインなのは今一番使っているからで，Impalaなど他のMPP on Hadoop的なものも似たような感じかなと思っています． もちろん実装の違いなどがあるので，その辺は適宜自分で補間してください． 前提 アプリケーションを開発していて，そのための解析基盤を一から作る． 簡単なまとめ データを貯める所が作れるのであれば，そこに直接クエリを投げられるPre
データを一箇所に集めることでデータ活用の民主化が進んだ話 - once upon a time,
先日、この記事を読んで分析のハードルを下げること大事だよね、というのを思い出したのでつらつらと書いてみようと思います。 qiita.com 内容としては正直タイトル詐欺で、SlackからRDSにクエリ発行できるようにして、各種権限を持っているエンジニアでなくても分析できるようになったよ、という話です。 ここでいう「データ活用の民主化」というのはかっこ良く言ってみたかっただけで、「データ分析を生業にしている人以外もデータを活用してビジネスを進められるようになる」というくらいのニュアンスだと思って下さい。 「データ分析」というとアナリストの人がやること、みたいな職務が分かれている環境もあるとは思いますが、そうではない会社（前職）の一例です。 データ活用が広まった流れ 数秒〜数十秒で対話的にクエリが返ってくると、トライアンドエラーが100倍くらいできる 今まで実行計画を気にして避けていたことにガ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
