2016-10-24 4 views
0

Ich habe ein Protokollierungssystem, das 5-Minuten-Aggregate nach Hadoop schreibt, über 60 GB Daten pro Stunde. Mein Problem tritt auf, wenn beim Überprüfen der Daten einige Spitzenzeiten unvollständig erscheinen (nur ein Teil der Protokolle wird geschrieben). Dieser Informationsverlust stimmt mit den höchsten Ladeperioden überein. Ich folge den Logs und lese jede Spur, die ich kann, aber ich kann nicht herausfinden, was genau das Problem ist.Hadoop schreibt unvollständige Datei nach HDFS

Der Stapelprozess ruft Protokollzeilen vieler Server von Kafka ab und stellt diese Zeilen dann in Writer-Threads ein, die Dateien in HDFS öffnen und in alle Zeilen schreiben (eine Datei pro Quellserver). Bei niedrigen bis mittleren Lasten ist alles in Ordnung. Bei hohen Auslastungen ist, beginnen die Protokolle einige Fehler zu spucken und warnt:

2016-10-08 14:16:24 INFO Exception in createBlockOutputStream 
java.io.IOException: Got error, status message , ack with firstBadLink as <dnip>:50010 
     at org.apache.hadoop.hdfs.protocol.datatransfer.DataTransferProtoUtil.checkBlockOpStatus(DataTransferProtoUtil.java:140) 
     at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.createBlockOutputStream(DFSOutputStream.java:1397) 
     at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.nextBlockOutputStream(DFSOutputStream.java:1299) 
     at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.run(DFSOutputStream.java:464) 
2016-10-08 14:16:24 INFO Abandoning BP-1891784736-10.118.249.120-1467026091136:blk_1077950482_131390250 
2016-10-08 14:16:24 INFO Excluding datanode DatanodeInfoWithStorage[<dnip>:50010,DS-d1b79bfe-3ee8-4dba-b3a3-48e50a357b30,DISK] 

Nach einigen Sekunden neue Fehler auftreten:

2016-10-08 14:17:34 INFO Exception in createBlockOutputStream 
java.net.SocketTimeoutException: 65000 millis timeout while waiting for channel to be ready for read. ch : java.nio.channels.SocketChannel 

Nach dem Fehler, startet der Batch-Prozess Dateien zu schließen. Dann, nur für einige Dateien, gibt es einige neue Fehler:

Für diese spezifischen Dateien ist die Größe cero. Ansonsten werden sie nur teilweise geschrieben und verlieren Daten. Außerdem protokolliert HDFS heißt es:

2016-10-08 14:21:22,789 WARN datanode.DataNode (BlockReceiver.java:receivePacket(694)) - Slow BlockReceiver write data to disk cost:2143ms (threshold=300ms) 

und

DataXceiver error processing WRITE_BLOCK operation 

alle Protokolle Anzeigen, scheint die WARN auf HDFS korreliert mit dem Verlust von Informationen und auch createBlockOutputStream. Immer wenn es viele Zeilen mit diesen Fehlern gibt, gibt es Datenverlust.

Alle Protokolle, die ich überprüfen sollte? Vielleicht Hadoop Tunning?

+0

Es wird erwähnt, dass 2 von 2 Datenpunkten ausgeschlossen sind. Verfügen diese Knoten über genügend Speicherkapazität? (Innerhalb und außerhalb von hdfs). Abhilfe könnte natürlich die Verwendung von 1-Minuten-Aggregaten sein. –

Antwort

0

Als Teilantwort fanden wir, dass der GC in den Worker-Knoten alle sechs Stunden viele lange Pausen (3 ~ 5 Sekunden) verursachte (die vordefinierte GC-Spanne). Wir haben den Heap von 1 GB auf 4 GB erhöht und scheint gelöst zu sein. Was bewirkt, dass der Haufen ständig voll wird, ist immer noch eine offene Frage, aber das geht über den Rahmen. Nachdem der Heap erhöht wurde, gibt es keine weiteren Fehler (in Zusammenhang damit) in den Protokollen.

+0

Konnte das Problem dadurch gelöst werden? Bitte teilen Sie mir mit, welchen Heapspeicher Sie erhöht haben. –