Sparkクラスタハードウェア構成リファレンス
5934 ワード
Sparkクラスタハードウェア構成リファレンス
ラベル(スペース区切り):Spark
Hardware Provisioning
A common question received by Spark developers is how to configure hardware for it. While the right hardware will depend on the situation, we make the following recommendations.
ハードウェア構成
Spark開発者が直面している最も一般的な問題は、クラスタの構成ハードウェアです.一般的に、合理的なハードウェア構成は、自身の実際の状況に依存し、以下のいくつかの面から提案するしかありません.
Storage Systems
Because most Spark jobs will likely have to read input data from an external storage system (e.g. the Hadoop File System, or HBase), it is important to place it as close to this system as possible. We recommend the following:
If at all possible, run Spark on the same nodes as HDFS. The simplest way is to set up a Spark standalone mode cluster on the same nodes, and configure Spark and Hadoop’s memory and CPU usage to avoid interference (for Hadoop, the relevant options are mapred.child.java.opts for the per-task memory and mapred.tasktracker.map.tasks.maximum and mapred.tasktracker.reduce.tasks.maximum for number of tasks). Alternatively, you can run Hadoop and Spark on a common cluster manager like Mesos or Hadoop YARN.
If this is not possible, run Spark on different nodes in the same local-area network as HDFS.
For low-latency data stores like HBase, it may be preferrable to run computing jobs on different nodes than the storage system to avoid interference.
ストレージシステム
ほとんどのSparkジョブでは、外部ストレージシステム(HadoopファイルシステムやHbaseなど)から入力データが読み込まれるため、ストレージシステムに近いほど良いので、以下のアドバイスを行います.
可能であればHDFSと同じノードでSparkを実行します.最も簡単な方法は、同じノードにSpark standaloneモードクラスタをインストールし、SparkとHadoopのメモリとCPUを構成して干渉を避けることです(Hadoopの場合、関連するオプションは、各タスクのメモリ構成が
これが実現できない場合、SparkクラスタはHDFSと同じローカルエリアネットワークにある必要があります.
HBAseのような低遅延データストレージの場合、異なるノードで計算ジョブを実行することは、ストレージシステムよりも容易であり、干渉を回避することができる.
Local Disks
While Spark can perform a lot of its computation in memory, it still uses local disks to store data that doesn’t fit in RAM, as well as to preserve intermediate output between stages. We recommend having 4-8 disks per node, configured without RAID (just as separate mount points). In Linux, mount the disks with the noatime option to reduce unnecessary writes. In Spark, configure the spark.local.dir variable to be a comma-separated list of the local disks. If you are running HDFS, it’s fine to use the same disks as HDFS.
ローカルディスク
Sparkの多くの計算はメモリで行われていますが、データがメモリに入れられない場合は、ローカルディスクを使用してデータを格納し、異なるフェーズ間で中間の出力を保持します.各ノードに4～8個のディスクがあり、RAIDを作らないことをお勧めします(個別のマウントポイントのように).Linuxでは、noatimeオプションでディスクをマウントし、不要な書き込みを削減します.Sparkでは、複数のマウントされたディスクを
Memory
In general, Spark can run well with anywhere from 8 GB to hundreds of gigabytes of memory per machine. In all cases, we recommend allocating only at most 75% of the memory for Spark; leave the rest for the operating system and buffer cache.
How much memory you will need will depend on your application. To determine how much your application uses for a certain dataset size, load part of your dataset in a Spark RDD and use the Storage tab of Spark’s monitoring UI (http://:4040) to see its size in memory. Note that memory usage is greatly affected by storage level and serialization format – see the tuning guide for tips on how to reduce it.
Finally, note that the Java VM does not always behave well with more than 200 GB of RAM. If you purchase machines with more RAM than this, you can run multiple worker JVMs per node. In Spark’s standalone mode, you can set the number of workers per node with the SPARK_WORKER_INSTANCES variable in conf/spark-env.sh, and the number of cores per worker with SPARK_WORKER_CORES.
メモリ
一般的には、1台あたり8 GBから数百GBのメモリがあり、Sparkはよく動作します.すべての状況を考慮すると、Sparkに最大75%のメモリを割り当て、残りの部分はオペレーティングシステムとバッファキャッシュに残すことをお勧めします.
どのくらいのアクセスが必要かは、アプリケーションによって決まります.アプリケーションのデータセットでのメモリの使用状況を確認するには、データセットの一部をRDDにロードし、Sparkの監視UI(
最後に、メモリが200 GBを超える場合、Java仮想マシンの稼働状況は常に良好ではないことに注意してください.購入したマシンのメモリが200 Gを超える場合は、各ノードで複数のWorkerを実行できます.SparkのStandaloneモードでは、
Network
In our experience, when the data is in memory, a lot of Spark applications are network-bound. Using a 10 Gigabit or higher network is the best way to make these applications faster. This is especially true for “distributed reduce” applications such as group-bys, reduce-bys, and SQL joins. In any given application, you can see how much data Spark shuffles across the network from the application’s monitoring UI (http://:4040).
ネットワーク
我々の経験によれば,メモリにデータが存在する場合,多くのSparkアプリケーションがネットワークと密接に関連している.10ギガビット以上のネットワークを使用することは、これらのアプリケーションをより速くする最善の方法です.これは、
CPU Cores
Spark scales well to tens of CPU cores per machine because it performes minimal sharing between threads. You should likely provision at least 8-16 cores per machine. Depending on the CPU cost of your workload, you may also need more: once data is in memory, most applications are either CPU- or network-bound.
CPUコア数
Sparkは、スレッド間で最小共有されるため、各マシン上で数十個のCPUコアに拡張できます.各マシンに少なくとも8〜16個のコアが提供される.ワークロードのCPU消費量に応じて、メモリにデータが格納されると、ほとんどのアプリケーションがCPU関連かネットワーク関連かのいずれかになる可能性があります.
翻訳元アドレス:http://spark.apache.org/docs/1.6.3/hardware-provisioning.html
ラベル(スペース区切り):Spark
Hardware Provisioning
A common question received by Spark developers is how to configure hardware for it. While the right hardware will depend on the situation, we make the following recommendations.
ハードウェア構成
Spark開発者が直面している最も一般的な問題は、クラスタの構成ハードウェアです.一般的に、合理的なハードウェア構成は、自身の実際の状況に依存し、以下のいくつかの面から提案するしかありません.
Storage Systems
Because most Spark jobs will likely have to read input data from an external storage system (e.g. the Hadoop File System, or HBase), it is important to place it as close to this system as possible. We recommend the following:
If at all possible, run Spark on the same nodes as HDFS. The simplest way is to set up a Spark standalone mode cluster on the same nodes, and configure Spark and Hadoop’s memory and CPU usage to avoid interference (for Hadoop, the relevant options are mapred.child.java.opts for the per-task memory and mapred.tasktracker.map.tasks.maximum and mapred.tasktracker.reduce.tasks.maximum for number of tasks). Alternatively, you can run Hadoop and Spark on a common cluster manager like Mesos or Hadoop YARN.
If this is not possible, run Spark on different nodes in the same local-area network as HDFS.
For low-latency data stores like HBase, it may be preferrable to run computing jobs on different nodes than the storage system to avoid interference.
ストレージシステム
ほとんどのSparkジョブでは、外部ストレージシステム(HadoopファイルシステムやHbaseなど)から入力データが読み込まれるため、ストレージシステムに近いほど良いので、以下のアドバイスを行います.
可能であればHDFSと同じノードでSparkを実行します.最も簡単な方法は、同じノードにSpark standaloneモードクラスタをインストールし、SparkとHadoopのメモリとCPUを構成して干渉を避けることです(Hadoopの場合、関連するオプションは、各タスクのメモリ構成が
mapred.child.java.optsであり、タスク数の構成がmapred.tasktracker.map.tasks.maximumとmapred.tasktracker.reduce.tasks.maximumです).また、MesosやHadoop YARNなどのHadoopやSparkをクラスタマネージャで実行することもできます.これが実現できない場合、SparkクラスタはHDFSと同じローカルエリアネットワークにある必要があります.
HBAseのような低遅延データストレージの場合、異なるノードで計算ジョブを実行することは、ストレージシステムよりも容易であり、干渉を回避することができる.
Local Disks
While Spark can perform a lot of its computation in memory, it still uses local disks to store data that doesn’t fit in RAM, as well as to preserve intermediate output between stages. We recommend having 4-8 disks per node, configured without RAID (just as separate mount points). In Linux, mount the disks with the noatime option to reduce unnecessary writes. In Spark, configure the spark.local.dir variable to be a comma-separated list of the local disks. If you are running HDFS, it’s fine to use the same disks as HDFS.
ローカルディスク
Sparkの多くの計算はメモリで行われていますが、データがメモリに入れられない場合は、ローカルディスクを使用してデータを格納し、異なるフェーズ間で中間の出力を保持します.各ノードに4～8個のディスクがあり、RAIDを作らないことをお勧めします(個別のマウントポイントのように).Linuxでは、noatimeオプションでディスクをマウントし、不要な書き込みを削減します.Sparkでは、複数のマウントされたディスクを
spark.local.dir変数にカンマで区切って配置します.HDFSを実行している場合は、HDFSと同じディスクを使用できます.Memory
In general, Spark can run well with anywhere from 8 GB to hundreds of gigabytes of memory per machine. In all cases, we recommend allocating only at most 75% of the memory for Spark; leave the rest for the operating system and buffer cache.
How much memory you will need will depend on your application. To determine how much your application uses for a certain dataset size, load part of your dataset in a Spark RDD and use the Storage tab of Spark’s monitoring UI (http://:4040) to see its size in memory. Note that memory usage is greatly affected by storage level and serialization format – see the tuning guide for tips on how to reduce it.
Finally, note that the Java VM does not always behave well with more than 200 GB of RAM. If you purchase machines with more RAM than this, you can run multiple worker JVMs per node. In Spark’s standalone mode, you can set the number of workers per node with the SPARK_WORKER_INSTANCES variable in conf/spark-env.sh, and the number of cores per worker with SPARK_WORKER_CORES.
メモリ
一般的には、1台あたり8 GBから数百GBのメモリがあり、Sparkはよく動作します.すべての状況を考慮すると、Sparkに最大75%のメモリを割り当て、残りの部分はオペレーティングシステムとバッファキャッシュに残すことをお勧めします.
どのくらいのアクセスが必要かは、アプリケーションによって決まります.アプリケーションのデータセットでのメモリの使用状況を確認するには、データセットの一部をRDDにロードし、Sparkの監視UI(
http://:4040 )のStorageタブを使用してメモリの使用状況を表示します.メモリの使用量は、ストレージレベルとシーケンス化フォーマットによって大きく影響されることに注意してください.ヒントを減らすためのチューニングガイドを参照してください.最後に、メモリが200 GBを超える場合、Java仮想マシンの稼働状況は常に良好ではないことに注意してください.購入したマシンのメモリが200 Gを超える場合は、各ノードで複数のWorkerを実行できます.SparkのStandaloneモードでは、
conf/spark-env.shのSPARK_WORKER_INSTANCES変数を使用して各ノードのworker数を構成し、SPARK_WORKER_CORESで各workerのCPUコア数を構成できます.Network
In our experience, when the data is in memory, a lot of Spark applications are network-bound. Using a 10 Gigabit or higher network is the best way to make these applications faster. This is especially true for “distributed reduce” applications such as group-bys, reduce-bys, and SQL joins. In any given application, you can see how much data Spark shuffles across the network from the application’s monitoring UI (http://:4040).
ネットワーク
我々の経験によれば,メモリにデータが存在する場合,多くのSparkアプリケーションがネットワークと密接に関連している.10ギガビット以上のネットワークを使用することは、これらのアプリケーションをより速くする最善の方法です.これは、
group-by、reduce-by、SQL joinなどの分散reduceアプリケーションに特に適しています.任意のアプリケーションでは、アプリケーションの監視UI(http://:4040 )からネットワークに大量のshuffleデータが表示されます.CPU Cores
Spark scales well to tens of CPU cores per machine because it performes minimal sharing between threads. You should likely provision at least 8-16 cores per machine. Depending on the CPU cost of your workload, you may also need more: once data is in memory, most applications are either CPU- or network-bound.
CPUコア数
Sparkは、スレッド間で最小共有されるため、各マシン上で数十個のCPUコアに拡張できます.各マシンに少なくとも8〜16個のコアが提供される.ワークロードのCPU消費量に応じて、メモリにデータが格納されると、ほとんどのアプリケーションがCPU関連かネットワーク関連かのいずれかになる可能性があります.
翻訳元アドレス:http://spark.apache.org/docs/1.6.3/hardware-provisioning.html