Apache Kafka Meetup Japan #13の発表資料です。 2023年6月16日(JST)時点での、Apache Kafkaのアップデートやロードマップを紹介しています。
こんにちは。松本です。 Kubernetes コントロールプレーンの HA(High Available) 構成は二通りありますが、公式ドキュメント内に次のような記述があり、いずれの方式でも 3 台以上のマシンでクラスターを構成することが求められています。 For both methods you need this infrastructure: Three machines that meet kubeadm’s minimum requirements for the masters （中略） For the external etcd cluster only, you also need: Three additional machines for etcd members この、最小が "three" である必要性は、どこからくる制約なのでしょうか。"two" じゃだめなのでし
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 初版: 2018/9/28 著者: 伊藤 雅博, 株式会社日立製作所 はじめに この投稿ではオープンソースカンファレンス2017.Enterpriseで発表した「めざせ！Kafkaマスター ～Apache Kafkaで最高の性能を出すには～」の検証時に調査した内容を紹介します（全8回の予定）。本投稿の内容は2017年6月にリリースされたKafka 0.11.0 時点のものです。 第1回目となる今回は、Apache Kafkaの概要とアーキテクチャについて紹介します。 投稿一覧： Apache Kafkaの概要とアーキテクチャ (本投稿)
分散システムについては、もう随分と前から学びたいと思っていました。ただ、それは一度首を突っ込んだら最後、ゴールのない迷路に迷い込むようなものなのです。どこまでも続いているウサギの穴のようなものです。分散システムに関する文献は星の数ほど存在します。様々な大学からたくさんの論文が発表されているばかりでなく、膨大な数の書籍もあるのです。私のような全くの初心者には、どの論文を読んだらいいのか、どの書籍を買ったらいいのか、見当もつきません。 そんなとき、一部のブロガーが、 分散システムエンジニア （それがどういう意味であれ）になるなら知っておくべき論文というものを推奨しているのを見つけました。その一部を紹介しましょう。 FLP , Zab , Time, Clocks and the Ordering of Events in a Distributed Systems , Viewstamped
こんにちは。 Sparkについて調べてみよう企画第２段（？）です。 １回目はまずSparkとは何かの概要資料を確認してみました。 その先はRDDの構造を説明している論文と、後Spark Streamingというストリーム処理基盤の資料がありました。 とりあえず、そんなわけで（？）お手軽に概要がわかりそうなSpark Streamingの方を調べてみました。 まず見てみた資料は「Overview of Spark Streaming」（http://spark.incubator.apache.org/talks/strata_spark_streaming.pdf）です。 というわけで、読んだ結果をまとめてみます。 Spark Streamingとは何か？ 大規模ストリーム処理フレームワーク ・100オーダーのノードにスケールする ・秒単位のレイテンシで処理を実行可能 ・Sparkのバッチ
自分用のメモです。 ビッグデータ分散処理 Hadoop Spark インメモリー処理を主体 Storm リアルタイムHadoop Hadoop Hadoop による分散データ処理: 第 1 回 導入編 Hadoop による分散データ処理: 第 2 回 拡張編 Hadoop による分散データ処理: 第 3 回 アプリケーション開発 Spark Apache Sparkは、Scalaで（Hadoopのような）分散処理を行う為のライブラリー（OSS） HadoopのMapReduce部分に置き換わることを目指して開発された、Scalaで分散処理を行うフレームワークで、いわば高速化されたMapReduceといえる Spark を活用する:ビッグデータアプリケーション用の高速インメモリコンピューティング 分散処理に入門してみた（Hadoop+Spark） Apache Spark Apache Sp
Apache SparkをAmazon EC2にインスール 今回は、SparkをAmazon EC2のインスタンスにインスールしていきます。やっていることは下記と同じで、ビルド済みのパッケージをダウンロードして配置しているだけです。 高速な分散処理エンジンApache Sparkの操作を対話シェルで試してみる！ cd /tmp wget http://d3kbcqa49mib13.cloudfront.net/spark-1.2.0-bin-hadoop2.4.tgz tar xzf spark-*.tgz rm spark-*.tgz sudo mv spark-* /opt/spark これでSparkが配置完了です。 Apache Mesosを利用するためのApache Sparkの設定 Mesosで構築したクラスタを利用するために、Sparkの設定を変更していきます。 spark-
Apache Sparkを試しています。 高速な分散処理エンジンApache Sparkの操作を対話シェルで試してみる！ Apache SparkをJavaアプリケーションから使う。 ここまでは、単一のホストで動作を試していましたが、分散処理のためのライブラリなので、複数ホストで試さなければ本当の性能は得られません。 そこで、ここからはSparkのクラスタを構築していきたいと思います。 Apache Mesosは汎用のクラスタマネージャー 分散処理クラスタを構築する方法として、SparkのドキュメントにApache Mesosを使う方法が書かれています。 Apache Mesos Mesosは汎用のクラスタマネージャーです。具体的に何をしてくれるかというと、クラスタを管理して、ホストごとのリソースの余裕を見て、タスクを振り分けたりしてくれます。 もうひとつ、YARNという選択肢があります。
Apache Sparkは高速な分散処理エンジン 「高速に」といっても、「スループットが高い」という意味と、「レスポンスが早い」という意味があります。 「スループットが高い」というのは、一定時間にどれだけたくさんの処理ができるかです。「レスポンスが早い」というのは、処理を要求してから完成までにかかる時間が短いという意味です。 分散処理といえばHadoopが浮かびますが、Hadoopはスループット重視です。レスポンスタイムを重視したい場合には向きません。レスポンスを重視したい場合というのはたとえば、ユーザーからリクエストを受けてすぐに分析結果を返したい場合のような場合です。 Apache Sparkは、レスポンスタイムを重視した分散処理エンジンです。 Apache Spark™ – Lightning-Fast Cluster Computing 先日書いたPrestoもレスポンスタイムを重
バッチを高速にした後はリアルタイムの世界へ！ 現在、さまざまな業種の企業でビッグデータ分析の取り組みが行われている。ビッグデータへの最初の取っ掛かりは、既存のバッチ処理の高速化や、大量の業務データを用いた分析レポートの作成という企業が多いことだろう。そして、バッチ処理の高速化が一段落した次のステップとして、「リアルタイム処理」をテーマに掲げる企業も多いかと思われる。具体的には、 直近10秒間のトラフィックを集計したい。 直近10分間で自社商品がTwitterで話題になった回数を知りたい。 直近10時間での全店舗での来客数を集計したい。 といったリアルタイムなモニタリングを実現したくなるのではないだろうか？こういったモニタリング用の集計は、技術的には「ウインドウ集計（Time-Window Operation）」と呼ばれる。そこで本コラムでは、近頃、「ポストHadoop」として話題のApac
概要 [/2017-01-14] Hadoopとの比較 [/2014-09-12] サンプル [/2017-01-22] インストール 開発環境の構築 [2017-01-22] インストール [/2017-01-14] Sparkシェル [/2014-09-19] 実行方法 [/2017-01-18] API（RDD系） SparkContext [/2014-09-15] RDD [/2017-07-26] パーティション [2014-09-07] Kryo（シリアライズ） [/2015-01-15] Spark SQL [/2014-09-02] Hive操作 [2014-09-01] Streaming [2014-09-02] API（Dataset系） SparkSession [2017-01-14] Dataset [/2020-10-08] Encoder [2017-01
じゃんけんをシミュレートしてみる。練習問題だ。 人間を五人ほど作り、グー／チョキ／パーのなにを出させるかをそれぞれに決めさせ、勝負する。引き分けを考慮し、勝者が最後の一人になるまで繰り返す。 せっかくElixir (Erlang) でつくるのだから、各人間をプロセスにしてみる。 まずPersonモジュールをstructにする。Elixirはstructが入って大変便利になった。それまではrecoedを使ってゐたもので、プロセスの関数を含むモジュールとrecordのモジュールは別にしなければならなかった。Ruby人間としてstructは助かる。 spawnしてPersonを五人作る。PersonのプロセスIDが得られるので、これで話しかけられる。 さて、五人に手を出してもらう。そして五人が何の手を出したか確認せねばならない。おお。五人全員の手が揃わなければならないのだ。四人で勝ちを決めても五
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
