Digdagへ日次バッチを移行して幸せになるお話
DMM.comラボではビッグデータ基盤の日次バッチ（ETL処理）のワークフローエンジンとしてDigdagを採用しました。 ワークフローの運用は、障害時のリカバリ、進捗状況に応じた他システム連携、JOB実行時間の局所化など様々な課題があります。 Digdag選定理由や設計の勘所（サーバ構成・ワークフローの設計方針）、Digdag Plugin実装、他チーム連携のためのClient実装など、課題解決のために取り組んだ内容について紹介させていただきました！
Googleの虎の子「BigQuery」をFluentdユーザーが使わない理由がなくなった理由 #gcpja - Qiita
「BigQueryは120億行を5秒でフルスキャン可能」は本当か？ 先日、kaheiさんがGoogle BigQuery（Googleクラウドの大規模クエリサービス）について、こんなエントリを書いていた。 とにかくパフォーマンスがすごい。（Fluentd Meetupでの）プレゼン中のデモで、ディスクに収められた5億件のデータをSQLでフルスキャンするのに3秒しかかからない。9億件のデータを正規表現を含んだSQLでスキャンしても、7秒で終わる（これ、記憶がちょっとあいまい。もう少しかかったかも）。これには驚いた。佐藤さんがGoogleに入社して一番驚いた技術が、一般公開される前のBigQueryだったと言っていたが、その気持ちはわかる。 From Fluentd Meetupに行ってきました これを読んだ時、BigQueryの検索スピードについてちょっと補足したくなった。確かにFluent
ハッシュタグのリアルタイム分析のためのラムダ・アーキテクチャー
この記事で私たちは、Trident、Hadoop、Splout SQLを連携させて、簡単な「ラムダ・アーキテクチャー」の例をどのように構築したかを示すつもりです。 私たちはStormの上位における高レベルAPIであるTrident、Hadoopに対する高速リードオンリーSQLであるSplout SQLについて学んでいきます。この事例のアーキテクチャーは、このgithubプロジェクトでホストされています。私たちはツイートにおけるハッシュタグの出現数を、日付によってカウントする作業をシミュレートします。完全なゴールは、この単純な問題を完全にスケーラブルな方法で解き、問い合わせに対するリモートの低レイテンシー・サービスを提供することにより、ハッシュタグのカウントに進化をもたらすことです。この中には、二つのシステムの連結とそれに対するリアルタイム集計が含まれます。 そこで、すべてのハッシュタグに対
lambda-architecture.net - このウェブサイトは販売用です！ - lambda architecture リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
Big Data Lambda Architecture
Database Software Development Videos and Tutorials - MySQL, Oracle, SQL Server, NoSQL, MongoDB, PostgreSQL In order to meet the challenges of Big Data, you must rethink data systems from the ground up. You will discover that some of the most basic ways people manage data in traditional systems like the relational database management system (RDBMS) is too complex for Big Data systems. The simpler,
【進撃の巨大データ】Log集計用DBとシステム構成の美しい設計を考える - Y's note
[:W560] Log集計用DB設計 考える問題 Document無しのAgile開発をガチで推奨したい@yutakikuchi_です。【進撃の巨大データ】の第2回目として巨大アクセスLog集計用DBの設計について勉強した内容についてメモしたいと思います。DB周りはそこまで詳しく無いので詳しい皆様からの突っ込み大歓迎でございます。また図々しいですが知恵をください(笑)。 今日の主目的は下の2要件を叶えるためのDB設計を考える事です。特に問題になるのがRealTimeの話でTableにLogDataを書き込む処理と集計のSQLをどのように組み立てるか、それ以外にもSystemPerformanceとArchitectureにも関わってきます。 リアルタイムで大量データを集計したい 定期処理で大量データを集計したい 使うもの Fluentd : Fluentd: Open Source Log
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Datadog: a Real-Time Metrics Database for One Quadrillion Points/Day
spotify/luigi · GitHub -- Luigi is a Python module that helps you build complex pipelines of batch jobs. It handles dependency resolution, workflow management, visualization etc. It also comes with Hadoop support built in.