Linux +シェル
一般的に使用される高度なコマンド
トップiotop df -h grep sed awk netstat halt ps
プロセスの表示、ポート番号の表示、ディスク使用量の表示
トップps netstat df -h
一般的なツール
sed awkカットソート
作成されたシェルスクリプト
- クラスターの開始と停止のスクリプト(zk.sh kf.sh xcall.sh myjps.sh xsync.sh)
#! /bin/bash
case $1 in
"start") {
for I in hadoop102 hadoop103 hadoop104
do
ssh $I "绝对路径 start"
done
};;
"stop") {
};;
esac
- データウェアハウスレベルのインポートODS-> DWD-> DWS 5ステップ
#!/bin/bash
定义变量
hive/opt/module/hive/bin/hive
APP=gmall
定义时间
sql="
遇到表,前面加上数据库名称;
遇到时间,$do_date
"
hive -e "$sql"
- データウェアハウスとmysqlのインポートとエクスポート
-メインsqoop
二、Hadoop
入門
- ポート番号:
2.x Hadoopアクセス50070糸8088 19888 9000
3.x Hadoopアクセス9870糸8088 19888 8020 - 必要な構成ファイル
2.x core-site.xml hdfs-site.xml yarn-site.xml mapreduce.xml 3 env.sh salves(空白行やスペースなし)
3.x core-site.xml hdfs -site.xml yarn-site.xml mapreduce.xml 3つのenv.shワーカー
HDFS
- 概略図がある限り、読み書きプロセス(書かれたテスト問題)
- 小さなファイルは
-hazard:NNのメモリが十分ではない、128Gメモリ* 1024メートル* 1024キロバイト* 1024バイト/ 150バイト(ファイルブロックは150バイトを占有)= 9億128グラム保存することができ、計算:1つのスライスに一つのファイルの対応する- > maptask
-溶液方法:harアーカイブ[キー]、Inputformatをカスタマイズ-> nnメモリを
削減-CombineTextInputformat->スライス数を削減-> maptaskを削減
-jvm再利用:開始 - ブロックサイズ、コピー数
MapReduce [シャッフル+最適化]
mapメソッドの後、reduceメソッドの前に
128Gメモリをnodemanager100gメモリに
128mデータ、1gメモリを割り当てる必要があります
カフカ
カフカ紹介
Kafkaはトピックトピックに基づいた生産および消費モデルを採用しています。つまり、プロデューサーは指定されたトピックにデータを生成し、消費者はトピックからデータを消費します。1拡張を容易にし、スループットを向上させるために、トピックを複数のパーティションに分割できます; 2パーティションの設計と組み合わせて、コンシューマグループの概念が提案され、グループ内の各コンシューマが並行して消費します; 3各パーティションの可用性を向上させるNameNode HAと同様に、いくつかのコピーを追加します
基礎
- 構成:
カフカに配置されているユニット数:2 *(ピーク生産速度*コピー/ 100)+ 1 = 3ユニット - コピー:
-> 2/3、ほとんどは2;機能:信頼性を向上させることができる;副作用:ディスクIOを増加させ、ネットワークパフォーマンスを低下させる - 圧力測定:
2 *(ピーク生産速度*コピー/ 100)+ 1 = 3セット、ピーク生産速度は50m / s以下 - データ量:
100万の毎日のアクティビティ:1人あたり1日100万、100万* 100 = 1億、ログの大きさ= 0.5〜2k、一般に1K、カフカの1秒あたりのログ数:1億/(24 * 3600s )= 1150 bar / s、およそ1日1m / s - いつピークに達しますか?
週末の8時から12時まで、ピークは通常の20倍、20m / s、50m / s以下 - 保管時間
デフォルトの保管期間は7日間で、実稼働環境は3日間(oppo)6時間保管されます。 - ディスクサイズ
100g *コピー2 * 3日/0.7 =
Kafkaイーグルの監視は、Kafkaモニターよりも友好的です。自分で書いた?実行する方法?彼を賛美する
次のレベルのすべての消費者を満足させるトピックの数。テーブルごとに1 つのトピック-ミニプログラム-
"ミニプログラムトピック
-公式アカウント-"公式アカウントトピック-"kafka-" SparkStreaming / Flink分析-"
kafka -pc Webサイト-" pctopic- "ハイブDWD分析- isr:
リーダーが電話を切ったときに誰がリーダーであるか; isrキュー内の全員にチャンスがある;古いバージョン:遅延時間、遅延数;新しいバージョン:遅延時間 - パーティションの数(機能:同時実行性を高める)
最初にパーティションを設定します。圧力テストTp、Tcの
合計ターゲットスループットとTt、次にパーティションの数= Tt / min(Tp、Tc)
例:プロデューサースループット= 20m / s、コンシューマースループット= 50m / s、予想スループット100m / s、パーティション数= 100/20 = 5パーティション - パーティション割り当て戦略の
範囲のデフォルトとRoundRobin
範囲:10パーティション、3つのコンシューマスレッド(データホットスポットが存在する場合があります)
1 2 3 4
5 6 7
8 9 10
RoundRobinすべてのパーティションはハッシュ、ポーリングモードによってランダムに分散されます
バイバイ
Flumeチャネルは一定期間耐性がある場合があり、
ログサーバーは30日間ログを保存します。
失われたデータ
- ack
0送信、応答なし、最速の伝送速度、最悪の信頼性、本番環境ではほとんど使用されない、
1送信、リーダーが応答、伝送速度が高速、信頼性は大丈夫、
-1送信、リーダー+フォロワーが応答;伝送速度は遅く、信頼性は最高です。 - 本番環境での選択方法は?
0本番環境ではほとんど使用されない
1通常のログの場合、信頼性要件は特に高くないため、通常は1を選択し、ほとんどの企業は1を選択1
-1金融または金銭関連の分野で一般的に使用される
データが重複しています
- べき等+トランザクション+ ack = -1
Kafkaトランザクションは、
Kafkaダウンストリーム処理を保証します - HiveのDWDレイヤー、スパークストリーミング、Redis
がウィンドウを開いて最初のグループを取得します - べき等性:1つのセッションで単一パーティション、高効率
- トランザクション:カフカ全体で、IDはグローバルに維持され、非効率的です
データバックログ
- Self:2パーティションから10パーティションに増やすなど、パーティションを増やします。スパークストリーミングのCPU / flink並列処理のダウンストリーム処理速度を上げます。コンシューマも同時実行性を増やす必要があります。
- 兄弟を見つける:消費者の消費数を増やし、消費速度を上げる;バッチサイズ1000 /秒-> 2000 /秒、3000 /秒
カフカ最適化
- パーティションの数は、消費者の数の整数倍です
なぜカフカは速いのですか?データを効率的に読み取る理由は?
- カフカ自体はクラスターとパーティションです
- シーケンシャルな読み取りと書き込みは600m / sです。100m/ sの
Kafkaプロデューサープロダクションデータのランダムな読み取りと書き込みの場合は、ログファイルに書き込む必要があります。書き込みプロセスは、ファイルの最後に追加することで、順次書き込みです。公式ウェブサイトには、同じディスクに最大600M / sのシーケンシャルな順序で書き込むことができるというデータがありますが、ランダム書き込みでは100m / sしかありません。これは、ディスクの機械的メカニズムに関連していますが、シーケンシャル書き込みが高速である理由は、ヘッドアドレッシング時間を大幅に節約できるためです。 - ゼロコピー
Kafkaは時間に応じてデータを消費できます
KafkaUtil.fetchOffsetsWithTimestamp(topic、sTime、kafkaProp);
Kafkaの消費者は、データをプルするかプッシュするかを検討します
データをプルし、各コンシューマーは必要なデータをプルします
カフカのデータは注文されていますか?
単一のパーティション内での順序、複数のパーティション、パーティションとパーティション間の無秩序、パーティションを設定することもできます
Kafkaのフォロワーとリーダーはどのようにメッセージを同期しますか?
Kafkaのレプリケーションメカニズムは、完全な同期レプリケーションでも、純粋な非同期レプリケーションでもありません。KafkaはAckメカニズムを使用しています。Ack= -1の場合、完全な同期レプリケーションでは、このメッセージがコミットと見なされる前にAll Alive Followersがレプリケートされている必要があります。このレプリケーション方法は、スループットレートに大きく影響します。非同期複製モードでは、フォロワーはリーダーからデータを非同期的に複製します。データがリーダーによってログに書き込まれている限り、データはコミットされたと見なされます。この場合、フォロワーのコピーがすべてリーダーより遅れており、リーダーが突然ダウンした場合、データを失った。KafkaのISRの使用方法は、データが失われたり、スループットが失われたりしないようにするための適切なバランスです。FollowerはLeaderからバッチでデータをコピーでき、Leaderはディスクの順次読み取りと送信ファイル(ゼロコピー)メカニズムを最大限に活用します。これにより、コピーパフォーマンスが大幅に向上し、ディスクへの内部書き込みがバッチで行われるため、FollowerとLeaderのメッセージボリュームの違いが大幅に減少します。
フォロワーがカフカのISRで遅れている場合はどうすればよいですか?
リーダーがデータを受信すると、すべてのフォロワーがデータの同期を開始しますが、何らかの障害のためにリーダーと同期できないフォロワーがいます。リーダーは、ACKを送信する前に、同期が完了するまで待機する必要があります。この問題を解決するには?
リーダーは動的な同期レプリカセット(ISR)を維持します。これは、リーダーと同期するフォロワーセットを意味します。ISRのフォロワーがデータ同期を完了すると、リーダーはフォロワーにACKを送信します。フォロワーがデータをリーダーと長期間同期しない場合、フォロワーはISRから追い出されます。時間のしきい値は、replica.lag.time.max.msパラメーター(デフォルトは10秒)によって設定されます。リーダーが失敗すると、ISRから新しいリーダーが選出されます。
Ack設定
0:プロデューサーはブローカーのackを待機しません。この操作は最小の遅延を提供します。ブローカーはそれを受信し、ディスクに書き込まれていないとすぐに戻ります。ブローカーが失敗すると、データが失われる可能性があります
。1:プロデューサーはブローカーのackとパーティションを待機しますリーダーの配置が成功すると、ACKが返されます。フォロワーの同期が成功する前にリーダーが失敗すると、データは失われます。
-1(すべて):プロデューサーはブローカーのACKを待ち、リーダーとパーティションのフォロワーがすべて正常に配置された後でACKを返します。ただし、フォロワーの同期が完了した後、ブローカーがackを送信する前にリーダーが失敗すると、データが重複します。[プロデューサーが送信に失敗した後、再試行します]