私は長い間友達とこのプロジェクトに取り組んできましたが、オンライン期間中にも多くの問題に遭遇しました。ここで自分自身を要約し、次回は再発しないようにします。
開発に関しては、プロジェクトは主に、sparkコア、spark sql、spark Streamingをプログラミングに使用するsparkに基づいて開発されています。プロジェクトには、ユーザーセッション分析モジュール、単一コンバージョン率モジュール、地域で人気のある製品モジュールなど、複数のモジュールがあります。リアルタイムクリックストリーム統計モジュールなどの広告。
プロジェクトで発生した
問題：1。ClassNotFoundの問題
mavenを使用してプロジェクトをjarパッケージに入力しますが、ここでは、プロジェクトに必要ないくつかの依存関係をjarパッケージに入れることを忘れないでください。
2. mysqlへのデータ書き込みに問題があります。
検査の結果、mysqlが閉じていることがわかりました。解決策：サービスmysqld startをスケジューリングスクリプトに追加して、mysqlが確実に開始されるようにします。
3.クラスターメモリが不足しています。解決策：hadoopクラスターを拡張し、データノードを増やします。
4. Sparkのシリアル化の問題、シリアル化可能なエラー、およびこのタイプの他のエラーは、通常、クラスがシリアル化されていないことが原因です。解決策：pojoクラスを定義するときにシリアル化可能なインターフェイスを実装します。
5.シャッフル…ファイルが見つかりませんエラーは、sparkプログラムの実行中に時々報告されます。理由：通常、ノードはシャッフル中に他のノードからリモートでデータをプルしますが、そのノードはgc操作を実行しています。ノードの他のすべてのプロセスは一時的に動作を停止するため、より長いgcが発生した場合、データのプルに失敗してエラーを報告します。解決策：sparkConfにいくつかのパラメーターを設定します：
spark.shuffle.io.maxRetries、20 //データのプルの最大試行回数、デフォルトは3回
spark.shuffle.io.retrywait、60 //各プルデータの待機時間はデフォルトで5秒です
。6 。スパークストリーミングのバッチ内部デバッグは、大きすぎたり小さすぎたりしてはならず、200ミリ秒未満であってはなりません
。7。スパークダウンタイムの消費カフカのデータは1回限りであることが保証されています。スパークプログラムが停止したり、予期せず死んだりした場合、設定がないと、カフカの死から再起動までのデータを消費できません。これは損失に相当し、私たちには受け入れられません。はい、解決策：sparkがKafkaデータを消費するとき、各トピックパーティションの消費オフセットを維持します。Kafkaデータの読み取りを開始するときは、オフセットを指定してKafkaデータを読み取る必要があります。乾物のコード：
// dbから自分で管理しているオフセットデータを読み取ります。kafkaTopicはカスタム
pojoリストですlastestOffset = DBUtil.getLastestOffset（）;
Map <String、String> kafkaParams = new HashMap <String、String>（）;
kafkaParams .put（ "metadata.broker.list"、 "192.168.56.101:9092,192.168.56.102:9092,192.168.56.103:9092"）;
Map <TopicAndPartition、Long> fromOffset = new HashMap <TopicAndPartition、Long>（）;
//複数のトピックとパーティションを追加するように指定できます。ここではバッチクエリとmysqlからの設定です。
for（kafkaTopic kafkaTopic：lastestOffset）{ fromOffset.put（new TopicAndPartition（kafkaTopic.getTopic（）、kafkaTopic.getPartition（））、kafkaTopic.getOffset（））; } JavaInputDStream source = KafkaUtils.createDirectStream（jsc、String.class、String .class、StringDecoder.class、StringDecoder.class、String.class、kafkaParams、fromOffset、new Function <MessageAndMetadata <String、String>、String>（）{ //前処理、ここでは処理を行わず、メッセージを直接返しますprivate static final long serialVersionUID = 1L; public String call（MessageAndMetadata <String、String> v1）throws Exception { return v1.message（）; } }）; //対応するDstreamを使用するときにデータベースのオフセットを維持する/ ** * * @ paramソースソースデータストリーム
* /
public static void StoredToDb（JavaInputDStream source）{ source.foreachRDD（new Function <JavaRDD、Void>（）{ private static final long serialVersionUID = 1L; @Override public Void call（JavaRDD v1）throws Exception { kafkaTopic kafkaTopic = new kafkaTopic （）; OffsetRange [] offsets =（（HasOffsetRanges）v1.rdd（））。offsetRanges（）; System.out.println（“我是オフセット：” + offsets ）; for（OffsetRange o：offsets）{ System.out .println（ "我是トピック：" + o.topic（）+ "我是パーティション：" + o.partition（）+ "我是fromoffset：" + o.fromOffset（）+ "我是untiloffset：" + o .untilOffset（））; kafkaTopic.setTopic（o.topic（））; kafkaTopic.setPartition（o.partition（））; kafkaTopic.setOffset（o.fromOffset（））;
DBUtil.updateOffset（kafkaTopic）;
}
// DBに更新… returnnull
;
}
}）;
}
8. OutOfMemory、原因：メモリ不足。通常、シャッフル中に発生しやすい。解決策：ジョブリソースを増やし、不要なものを減らす永続的なRddの使用、broadCastの使用、Kryoシリアル化の使用、およびシャッフルの最適化（統合メカニズムがオンになり、シャッフル内のシャッフルマップタスクからreduceタスクによってプルされるデータのサイズが適切に縮小されます。spark.reducer.maxSizeInFlight、デフォルトは48M、調整してみてください）
9。スパークストリーミングのバッチ期間のデバッグプロセス
最初に、sparkのジョブを開いて、webUI
のストリーミングページ内のいくつかの重要なインジケーターを監視します：
（1）：このインジケーターは、ソースから毎秒受信されるデータソースの受信です。データソースが受信したタイムイベントの数。ここで私のデータソースはkafkaです。
（2）：データを処理できますか？まず、このインジケーターを確認してください。このインジケータは、より重要なスパークジョブ送信の遅延時間を示します。スパークが指定された期間内にデータのバッチを処理できるかどうかを確認できます。通常、遅延時間が1期間以内であれば問題ありません。期間が長すぎる場合、または継続する場合成長（私の場合のように）は、あなたが定義した期間内にデータを処理できず、データが積み上げられていることを意味します。現時点での解決策は次のとおりです。最初の最も効果的なステップは、クラスターリソースを増やしてクラスターを拡張することですが、拡張はそれほど単純ではありません。リーダーがデイリーを拡張することに同意すると、寒くなるので、拡張を実行できます。通常、この種の計画動かない。2番目のステップは、現在使用できるクラスターリソースが完全に使用されているかどうかを確認することです。sparkConfで並列処理conf.set（ "spark.default.parallelism"、 "10"）を設定します。3番目のステップは、期間を長くすることです。特定の時間は、特定のビジネスに応じてゆっくりと調整されます。
（3）：このインジケーターはジョブの処理時間を示します
。10：sparkStreamingの高可用性
（1）：ドライバーの高可用性
プログラムでストリーミングファクトリを作成します。操作中にドライバーが電話を切ると、自動的に再起動します。もちろん、データの読み取りはチェックポイントに依存するため、チェックポイントディレクトリを設定する必要があります。
具体的な使用法は次のとおりです。
public static void main(String[] args) {
final String checkPoint="hdfs://master:9000/check/";
JavaStreamingContextFactory javaStreamingContextFactory = new JavaStreamingContextFactory() {
@Override
public JavaStreamingContext create() {
SparkConf conf = new SparkConf()
.setAppName("wordCount")
.setMaster("local")
.set("spark.default.parallelism","10");
JavaStreamingContext jsc = new JavaStreamingContext(conf, Durations.seconds(2));
jsc.checkpoint(checkPoint);
//.......具体处理逻辑都写在这里
return jsc;
}
};
JavaStreamingContext jsc = JavaStreamingContext.getOrCreate(checkPoint, javaStreamingContextFactory);//外部获取
jsc.start();
jsc.awaitTermination();
jsc.close();
}
さらに、ドライバーの高可用性を確保する場合は、sparkジョブを送信するときにクラスターモードを使用し、-superviseパラメーターをspark-submitに追加する必要があります。
（2）：WAL
先読みログがオンになっているconf.set（ "spark.streaming.receiver.writeAheadLog.enable"、 "true"）;
11.プロジェクトではハードコーディングは許可されておらず、通常は構成ファイルに書き込まれます。後のメンテナンスを容易にするために、ベストプラクティスは、構成ファイルをプロジェクトの外部に配置することです。これにより、変更が非常に便利になります。Sparkは、sparkプログラムでこの機能、spark-submit、–filesプロパティファイルの順に提供します。 streamメソッドを使用して、ファイルのプロパティを読み取ります。load（new FileInPutStream（ "fileName"））;
簡単な小さな乾物は次のとおりです。
public static void main(String[] args) throws Exception{
SparkConf conf = new SparkConf()
.setAppName("test").setMaster("local");
JavaSparkContext jsc = new JavaSparkContext(conf);
Properties properties =new Properties();
properties.load(new FileInputStream("test.properties"));
String name = properties.getProperty("name");
System.out.println("从配置文件读取的名字为："+name);
jsc.close();
}
（持续更新中）