Unify DNS management using Amazon Route 53 Profiles with multiple VPCs and AWS accounts If you are managing lots of accounts and Amazon Virtual Private Cloud (Amazon VPC) resources, sharing and then associating many DNS resources to each VPC can present a significant burden. You often hit limits around sharing and association, and you may have gone as far as building your own orchestration layers
この記事では、Apache HTTP Server で稼働している Web サーバへ Fluentd (td-agent) を導入し、Treasure Data でアクセスログを収集し、R で収集したデータのアクセスログ解析を行うまでの手順を解説します。 Treasure Data (トレジャーデータ) とは Treasure Data は Cloud 型 DWH (Data Warehouse) サービスの一つで、Cloud 上で SaaSとしてビッグデータの格納、処理を利用できるサービスです。 （Treasure Data 社では BigData-as-a-Service と呼んでいます） 同様のサービスでは、Amazon Web Services の Amazon Redshift や Elastic MapReduce 等がありますが、Treasure Data の特長で、バッチで
Facebookは、数ペタバイト級の大規模データに対しても、対話的にアドホックな問い合わせを可能にする分散SQLエンジン「Presto」を、オープンソースで公開しました。 PrestoはFacebook社内で大規模データの分析のために開発され、すでに同社社内使われているもの。 FacebookはPrestoを開発した背景として、大量のデータをHadoop/HDFSベースで保存したものの、バッチ指向のMapReduceではなく、リアルタイム性に優れた処理が必要になったためだと、次のように説明しています。 Facebook’s warehouse data is stored in a few large Hadoop/HDFS-based clusters. Hadoop MapReduce [2] and Hive are designed for large-scale, reliabl
Amazon Elastic MapReduce入門 〜 Apache Mahoutでレコメンデーション！ | DevelopersIO
よく訓練されたアップル信者、都元です。Hadoop使ってますか。試しにHadoopを使ってみよう、と思った時に主に障害となるのが以下の3つです。 Hadoopのクラスタを組むために実機を複数用意するのが厄介。それをクラスタとして組み上げるのも厄介。 Hadoopの上で動かすアプリケーションをMapReduceで書くのが厄介。 Hadoopで処理するほどのビッグデータを用意するのが厄介。 1つ目はAmazon Elastic MapReduce (EMR)を使う事でスマートに解決しましょう。 2つ目については、オープンソースのMapReduceアプリケーションを使います。私が強い興味を持っている分野に「機械学習」というものがあります。機械学習とは、コンピュータにデータを分析させ、未知の情報についての予測をさせたり、人間の知能に近い機能を実現しようという試みです。今回は、この機械学習の各種アル
Currently, I’ve been doing some stuffs using MongoDB. If you don’t know or haven’t use it, it’s a document based key-value database systems, that means it’s fundamentally different from traditional DBMS like MySQL, Oracle. Systems like MongoDB along with similar technologies like CouchDB make significant use of MapReduce. MapReduce is basically a two step process consisting of Map and Reduce where
MongoDBをMacにインストールして動かす 1. MongoDBをインストール $ sudo port install mongodb 2. DBファイルの置き場所を作成 $ mkdir /foo/bar/mongodb_data MongoDBは大きめのディスクスペースを必要とします。その理由は以下のリンク先に。 http://www.mongodb.org/pages/viewpage.action?pageId=17596968 3. DBを起動 $ mongod --dbpath=/foo/bar/mongodb_data Sun Oct 17 23:26:51 MongoDB starting : pid=1601 port=27017 dbpath=/foo/bar/mongodb_data 64-bit Sun Oct 17 23:26:51 db version v1.
RDBMSでは下記のようなSQLになると思います。(PostgreSQLでの例) SELECT to_char(timestamp, 'yyyy-mm-dd HH24'::text) AS ymdh ,count(*) FROM accesslog WHERE '2011-12-01' <= timestamp AND timestamp < '2011-12-02' GROUP BY ymdh ORDER BY ymdh ; MapReduceを実行する // 日本標準時を扱うためのユーティリティ関数 var JSTDate = function (str) { return ISODate(str + "T00+09:00"); }; // 日付範囲指定で対象を絞る。 // このように一時変数に記憶させておくと便利。 var query = { "timestamp" : { "$gt
副題: ビッグデータ時代の非ビッグデータ集計戦略 PHP と MySQL を使ってカジュアルに MapReduce する MyMR というものを作ってみました. とても安直な名前ですね. yuya-takeyama/mymr - GitHub とりあえず試してみる MyMR には, MapReduce のマナー (?) に従って, WordCount するためのサンプルコードとサンプルデータを同梱してみました. map/reduce 関数は PHP で書かれています. WordCount.php MySQL のユーザ名・パスワード等は適宜置き換えて下さい. 見事, 入力テーブル内の単語の出現回数を集計することができました. MyMR の特徴 データの入出力はいずれも MySQL のテーブル 入力と出力のデータベースは同じでもいいし別でもいい (入力はプロダクションサービスの Slave サ
というわけで冬休み最後の自由研究として、Amazon Elastic MapReduce（EMR）を使ってみました。今なら公式ページもほぼ日本語化していて楽チンです。Amazon Web Services (日本語) Amazon Elastic MapReduceとはAmazon EMRは、Amazonのインフラ上で動作する仮想サーバーを使ったHadoopクラスタを時間単価で貸し出すサービスです。少々わかりにくいので、Amazon Web Service(AWS)の関連する製品群について整理しておきます。EC2 (Elastic Compute Cloud) EC2は、仮想マシンを時間単価で貸し出すサービスです。 EMRを使わずに、EC2に自前でHadoopをインストールして使うやり方もあります（EMRが出来る以前はそれしかなかった）。 EMRを使う場合でも、バックグラウンドでは自動的に
米Yahoo!は、大規模データの分散処理を実現するMapReduceをリアルタイムに行うソフトウェア「S4」を、オープンソースとして公開しました。 MapReduceを実行するソフトウェアとして、オープンソースの「Hadoop」がありますが、Hadoopはあらかじめジョブを定義して投入するバッチ処理を前提としていました。 S4は、データをキーとバリューのペアで構成されるストリームデータとして非同期に受け取ることができ、処理結果もキーバリューのペアで構成されたストリームデータとして出力するようになっているとのこと。 この非同期なストリームデータによる入出力が、リアルタイムなMapReduceを実現するフレームワークとしてのS4の特徴といえます。 リアルタイムなMapReduceで何ができる？ リアルタイムなMapReduceにはどのような用途が考えられるのでしょうか？ S4の公開を表明したY
Googleで実用化されHadoopで流行しているところの分散処理フレームワークMapReduceをKyoto Cabinetにおいても実現してみた。その解説。 ローカルなMapReduce MapReduceは多数のマシンが連携して分散処理を行うためのフレームワークなので、プロセス組み込みDBMであって分散など全く関係ない世界に生きているKCでMapReduceを実行して意味があるのだろうか。答えは、「あんまりない」である。それにもかかわらず実装したのは、何となく話題性がありそうだからってのが最大の理由なのだが、もうひとつ理由がある。 スクリプト言語で集計処理をやろうとすると、めっちゃメモリ食うしCPUパワーを使うわりに遅いからである。1000万件のソートってだけでスクリプト言語だと結構辛いからね。そこで、MapReduceフレームワークをC++で実装してmapとreduceだけをスクリ
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
グーグルが「Evolution and Future Directions of Large-Scale Storage and Computation Systems at Google」（グーグルにおける、大規模ストレージとコンピュテーションの進化と将来の方向性）という講演を、6月に行われたACM（米国計算機学会）主催のクラウドコンピューティングのシンポジウム「ACM Symposium on Cloud Computing 2010」で行っています。 グーグルはどのようにして大規模分散システムを構築してきたのか、そして、そこからどのようなことを学んだのかが語られていますし、後半では大規模分散システムのデザインパターンという、非常に興味深いノウハウも公開している、非常に情報量の多い講演です。 その講演の内容を、全部で4つの記事、MapReduce編、BigTable編、教訓編、デザイン
グーグルの新しいインデックスシステムであるカフェインCaffeineで、グーグルはMapReduceに代わりまだ人に知られていないPercolatorを採用した。Percolatorはインクリメンタル処理する検索インフラストラクチャーで持続的にインデックスを更新するため、一から再度インデックスし直す必要がない。MapReduceのようなバッチ処理システムでは大量のデータを生み出し、小規模のデータ更新はできない。Percolatorはこの問題を解決し、一日で同数量のドキュメントを処理したとき、Percolatorでは検索結果ページのドキュメント年齢を半減することができるという。 Google Caffeine ― the revamped search infrastructure recently rolled out across Google's worldwide network o
Google I/O 2010で発表されたApp Engine新機能のひとつが「AppEngine-MapReduce（Mapper API）」です。このブログでもいろいろ憶測に憶測を重ねてきましたが、ついにApp EngineでMapReduceサポート！！…なんですが、しかし発表されたセッション会場もいまいち盛り上がりに欠ける感じ^^;; 理由は後述しますが、ともあれ（jw）、やっとのことApp EngineでもMapReduceがサポートされたわけです。 リンク集 appengine-mapreduce - Google Code Google I/O 2010 - Batch data processing with App Engine - YouTube Live Wave: Batch data processing with App Engine Exploring the
Fredさんへの別件メール中で「Mapper API遅いなぁ〜」とちょっとグチをこぼしたら、「そんなはずはない」的なリアクションだったので、先日のテスト結果をお知らせしたところ、こんな返事が来ました： You can adjust the processing_rate to be higher. The default of 100 is to prevent you from eating through quota too quickly. In mapreduce.yaml (Python) you add: - name: processing_rate default: {some large number} We missed this in the documentation. Thanks for point this out. We'll fix that. Fredな
Google I/O 2010では、Google Storageと合わせて利用する新機能「BigQuery」が発表されました（これもApp Engineとは個別のプロダクトです）。ひとことで言えば「何100億件のデータも数秒〜数10秒で集計できる、大規模並列クエリサービス」です。既存のOLAPやデータウェアハウスに相当するもので、更新処理には使えません。 MapReduceとはどう違う？ 大規模なデータセットに対して多数のサーバで並列処理するという点ではMapReduceに似ていますが、処理結果がすぐに得られる点、そしてSQLっぽいクエリ言語で表現できる集計処理しか実行できない（mapperやreducerを定義してデータを任意の方法で加工したりできない）点がMRとは異なります。MRよりさらに高水準の分散処理サービスです（MR＋Hiveに近いかもしれません）。 リンク集 BigQuery
大規模分散処理の技術として知られるMapReduceは、グーグルが検索エンジンの基盤技術として開発したもの。そして同社はMapReduceの特許を1月に取得していました。 グーグルがMapReduce特許を取得。Hadoopへの影響は？ － Publickey グーグルが特許を保有していることでMapReduceのオープンソース実装であるHadoopに対する影響が心配されていましたが、Apache Foundationの弁護士がグーグルの弁護団から特許の利用許可を得たことを明らかにしました。 予想通りの展開に 4月23日付けでYahoo!のHadoopチームアーキテクトOwen O’Malley氏がメーリングリストに投稿した「Re: License for Google's patent」というメッセージ。この中でApache Foundationの弁護士が、グーグルからの特許利用許可を伝
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
