งานการสตรีมที่มีโครงสร้าง Spark ออกมาอย่างเงียบๆ

ฉันมีงานการสตรีมแบบมีโครงสร้าง Spark ซึ่งเสียชีวิตอย่างเงียบๆ โดยไม่มีข้อความแสดงข้อผิดพลาดที่ชัดเจนในบันทึกของแอปพลิเคชัน มันทำงานได้ดีประมาณ 10 ชั่วโมง และจากนั้นก็เริ่มมีข้อความแสดงข้อผิดพลาดที่ไม่ร้ายแรง มันยังคงให้ผลอยู่ประมาณหนึ่งวัน จากนั้นคนขับตู้คอนเทนเนอร์ก็ตายอย่างเงียบๆ

งานกำลังทำงานอยู่ในคลัสเตอร์ที่ใช้แพลตฟอร์ม HDP แบบ 3 โหนด ซึ่งได้รับการจัดการในโหมดคลัสเตอร์เส้นด้าย โดยจะนำเข้าข้อมูลจาก Kafka ทำการคำนวณ จากนั้นส่งออกเอาต์พุตไปยัง Kafka และ HDFS

ก่อนอื่น ฉันดูบันทึกแอปพลิเคชันเส้นด้ายสำหรับคอนเทนเนอร์ไดรเวอร์ และพบข้อความแสดงข้อผิดพลาดเหล่านี้:

19/05/19 21:02:08 ERROR AsyncEventQueue: Listener EventLoggingListener threw an exception
java.io.IOException: Failed to replace a bad datanode on the existing pipeline due to no more good datanodes being available to try. (Nodes: curr
ent=[DatanodeInfoWithStorage[10.8.0.247:50010,DS-6502520b-5b78-408b-b18d-a99df4fb76ab,DISK], DatanodeInfoWithStorage[10.8.0.145:50010,DS-d8133dc8
-cfaa-406d-845d-c819186c1450,DISK]], original=[DatanodeInfoWithStorage[10.8.0.247:50010,DS-6502520b-5b78-408b-b18d-a99df4fb76ab,DISK], DatanodeIn
foWithStorage[10.8.0.145:50010,DS-d8133dc8-cfaa-406d-845d-c819186c1450,DISK]]). The current failed datanode replacement policy is DEFAULT, and a
client may configure this via 'dfs.client.block.write.replace-datanode-on-failure.policy' in its configuration.
        at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.findNewDatanode(DFSOutputStream.java:1059)
        at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.addDatanode2ExistingPipeline(DFSOutputStream.java:1122)
        at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.setupPipelineForAppendOrRecovery(DFSOutputStream.java:1280)
        at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.processDatanodeError(DFSOutputStream.java:1005)
        at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.run(DFSOutputStream.java:512)

End of LogType:stderr
***********************************************************************

ข้างต้นเป็นข้อความสุดท้ายของคนขับ

ดูน่ากลัว แต่งานกลับให้ผลลัพธ์ด้วยข้อผิดพลาดดังกล่าวถึง 36,628 รายการในหนึ่งวัน จึงไม่ทำให้งานตายโดยตรง ดูเหมือนว่าระบบ HDFS จะทำงานเช่นกัน

จากนั้นฉันก็ดูบันทึกของผู้ดำเนินการ พวกเขาออกหลังจากคนขับเสียชีวิต และไม่มีข้อผิดพลาดหรือข้อยกเว้นใดๆ:

19/05/19 21:02:09 ERROR CoarseGrainedExecutorBackend: Executor self-exiting due to : Driver ip-10-8-0-247.us-west-2.compute.internal:11269 disass
ociated! Shutting down.

ฉันไม่ทราบสาเหตุ ดังนั้นฉันจึงดูบันทึกของผู้จัดการทรัพยากรเส้นด้าย และพบข้อความเหล่านี้:

2019-05-19 18:36:44,047 INFO  availability.MetricSinkWriteShardHostnameHashingStrategy (MetricSinkWriteShardHostnameHashingStrategy.java:findColl
ectorShard(42)) - Calculated collector shard ip-10-8-0-145.us-west-2.compute.internal based on hostname: ip-10-8-0-145.us-west-2.compute.internal
2019-05-19 19:48:04,041 INFO  availability.MetricSinkWriteShardHostnameHashingStrategy (MetricSinkWriteShardHostnameHashingStrategy.java:findColl
ectorShard(42)) - Calculated collector shard ip-10-8-0-145.us-west-2.compute.internal based on hostname: ip-10-8-0-145.us-west-2.compute.internal
2019-05-19 21:02:08,797 INFO  rmcontainer.RMContainerImpl (RMContainerImpl.java:handle(422)) - container_e01_1557249464624_0669_01_000001 Contain
er Transitioned from RUNNING to COMPLETED
2019-05-19 21:02:08,797 INFO  scheduler.SchedulerNode (SchedulerNode.java:releaseContainer(220)) - Released container container_e01_1557249464624
_0669_01_000001 of capacity <memory:1024, vCores:1> on host ip-10-8-0-247.us-west-2.compute.internal:45454, which currently has 7 containers, <me
mory:19968, vCores:7> used and <memory:2560, vCores:1> available, release resources=true
2019-05-19 21:02:08,798 INFO  attempt.RMAppAttemptImpl (RMAppAttemptImpl.java:rememberTargetTransitionsAndStoreState(1209)) - Updating applicatio
n attempt appattempt_1557249464624_0669_000001 with final state: FAILED, and exit status: -104
2019-05-19 21:02:08,798 INFO  attempt.RMAppAttemptImpl (RMAppAttemptImpl.java:handle(809)) - appattempt_1557249464624_0669_000001 State change fr
om RUNNING to FINAL_SAVING
2019-05-19 21:02:08,798 INFO  integration.RMRegistryOperationsService (RMRegistryOperationsService.java:onContainerFinished(143)) - Container con
tainer_e01_1557249464624_0669_01_000001 finished, skipping purging container-level records (should be handled by AM)
2019-05-19 21:02:08,801 INFO  resourcemanager.ApplicationMasterService (ApplicationMasterService.java:unregisterAttempt(685)) - Unregistering app
 attempt : appattempt_1557249464624_0669_000001
2019-05-19 21:02:08,801 INFO  security.AMRMTokenSecretManager (AMRMTokenSecretManager.java:applicationMasterFinished(124)) - Application finished
, removing password for appattempt_1557249464624_0669_000001
2019-05-19 21:02:08,801 INFO  attempt.RMAppAttemptImpl (RMAppAttemptImpl.java:handle(809)) - appattempt_1557249464624_0669_000001 State change fr
om FINAL_SAVING to FAILED
2019-05-19 21:02:08,801 INFO  rmapp.RMAppImpl (RMAppImpl.java:transition(1331)) - The number of failed attempts is 1. The max attempts is 2
2019-05-19 21:02:08,801 INFO  rmapp.RMAppImpl (RMAppImpl.java:handle(779)) - application_1557249464624_0669 State change from RUNNING to ACCEPTED
2019-05-19 21:02:08,801 INFO  capacity.CapacityScheduler (CapacityScheduler.java:doneApplicationAttempt(812)) - Application Attempt appattempt_15
57249464624_0669_000001 is done. finalState=FAILED

ดูเหมือนว่าเส้นด้ายก็ไม่ได้ทำให้งานเสียหายเช่นกัน คอนเทนเนอร์ของไดรเวอร์เปลี่ยนจาก RUNNING เป็น COMPLETED ทันที

ฉันคาดว่าจะเห็นข้อความที่ชัดเจน เช่น OOM ทำให้งานขัดข้อง แต่ตอนนี้ฉันสับสนว่าทำไมข้อความถึงออกอย่างเงียบๆ มีความสัมพันธ์ใด ๆ กับข้อผิดพลาด HDFS หรือไม่ มีกลไกใดใน Spark ที่จะหยุดไดรเวอร์อย่างเงียบ ๆ เมื่อมีข้อยกเว้นมากเกินไป (แม้ว่าจะไม่ถึงแก่ชีวิตก็ตาม) ยินดีต้อนรับคำแนะนำใด ๆ ขอบคุณ!




คำตอบ (2)


รหัสทางออกของ Yarn -104 หมายความว่า ขีดจำกัดหน่วยความจำกายภาพสำหรับ เกินคอนเทนเนอร์เส้นด้าย

คอนเทนเนอร์ถูกยกเลิกเนื่องจากเกินขีดจำกัดหน่วยความจำกายภาพที่ได้รับการจัดสรร

ขณะที่คุณใช้งานบน AWS คุณสามารถใช้ประเภทอินสแตนซ์ RAM ที่สูงกว่าสำหรับโหนดไดรเวอร์ของคุณได้

person Liam Clarke    schedule 21.05.2019
comment
ขอบคุณเลียม ใช่แล้ว ฉันคิดว่าเป็นเพราะเส้นด้ายทำลายคอนเทนเนอร์หลังจากที่หน่วยความจำเกินขีดจำกัด คุณรู้ไหมว่าทำไมสิ่งนี้จึงเกิดขึ้น ฉันหมายถึงว่าปัญหาหน่วยความจำที่ฉันเห็นก่อนหน้านี้มักจะพิมพ์ข้อความแสดงข้อผิดพลาดในบันทึกแอปพลิเคชัน Spark บ่นว่ามีหน่วยความจำไม่เพียงพอ ดังนั้นฉันจึงรู้ว่าหน่วยความจำไม่เพียงพอและจะเพิ่มหน่วยความจำ แต่ดูเหมือนว่าจากมุมมองของประกายไฟจะมีความทรงจำเพียงพอ และจากมุมมองของเส้นด้ายไม่มี นี่เป็นความสับสน - person Kevin Li; 24.05.2019

โปรดตรวจสอบลิงค์ด้านล่างเพื่อดูรายละเอียด -

อ้างอิง: ปัญหาความล้มเหลวของ DataNode ไม่ถูกต้อง Hortonworks-

สาเหตุ:- ปัญหานี้เกิดขึ้นเมื่อเรารันงานบนคลัสเตอร์ขนาดเล็ก (คลัสเตอร์ที่มีโหนดข้อมูลน้อยกว่า 5 โหนด) และมีการโหลดข้อมูลจำนวนมาก หากมีความล้มเหลวของดาต้าโหนด/เครือข่ายในไปป์ไลน์การเขียน DFSClient จะพยายามลบดาต้าโหนดที่ล้มเหลวออกจากไปป์ไลน์ จากนั้นจึงเขียนต่อด้วยดาต้าโหนดที่เหลือ ส่งผลให้จำนวนดาต้าโหนดในไปป์ไลน์ลดลง คุณสมบัติที่อธิบายด้านล่างช่วยเราในการแก้ไขปัญหา

วิธีแก้ปัญหา:- โปรดเปลี่ยนนโยบายการเปลี่ยน DataNode ดังต่อไปนี้-

เพื่อแก้ไขปัญหานี้ ให้ตั้งค่าคุณสมบัติสองรายการต่อไปนี้จาก Ambari > HDFS > Configs > ไซต์ HDFS แบบกำหนดเอง > เพิ่มคุณสมบัติ:

dfs.client.block.write.replace-datanode-on-failure.enable=NEVER
dfs.client.block.write.replace-datanode-on-failure.policy=NEVER
person MIKHIL NAGARALE    schedule 21.05.2019
comment
ขอบคุณ MIKHIL นี่เป็นปัญหาสำหรับ HDP 2.6.1, 2.5.5, 2.6, 2.6.3, 2.6.4 แต่ฉันใช้ HDP 2.6.5 และไม่พบพารามิเตอร์การกำหนดค่านั้น ฉันคิดว่ามันอธิบายข้อผิดพลาด HDFS ได้แล้ว และฉันจะพยายามปรับแต่งการตั้งค่า HDFS แต่ปัญหาหลักของฉันยังคงเป็นปัญหาทางออกของไดรเวอร์ - person Kevin Li; 24.05.2019