อะไรคือความแตกต่างหลักระหว่าง Flink และ Storm?


140

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

ฉันพบสิ่งนี้ (สไลด์ # 4) ซึ่งบันทึกความแตกต่างหลักว่า "เวลาในการตอบสนองที่ปรับได้" สำหรับ Flink คำใบ้อีกอย่างน่าจะเป็นบทความของSlicon Angleที่แนะนำว่า Flink รวมเข้ากับโลก Spark หรือ HadoopMR ได้ดีขึ้น แต่ไม่มีการกล่าวถึงหรืออ้างอิงรายละเอียดที่แท้จริง สุดท้าย Fabian Hueske ให้สัมภาษณ์ว่า "เมื่อเทียบกับ Apache Storm แล้วฟังก์ชันการวิเคราะห์สตรีมของ Flink มี API ระดับสูงและใช้กลยุทธ์การยอมรับข้อผิดพลาดที่มีน้ำหนักเบามากขึ้นเพื่อให้การรับประกันการประมวลผลทุกครั้ง"

ทั้งหมดนั้นค่อนข้างเบาบางสำหรับฉันและฉันไม่ค่อยเข้าใจ ใครช่วยอธิบายได้ไหมว่าปัญหาของการประมวลผลสตรีมใน Storm คืออะไร (คือ?) แก้ไขได้โดย Flink หรือไม่? Hueske อ้างถึงอะไรจากปัญหา API และ "กลยุทธ์การยอมรับข้อผิดพลาดที่มีน้ำหนักเบามากขึ้น"


2
โปรดทราบว่า Apache Spark (จุดสำคัญของคำถามที่เชื่อมโยง) ไม่เหมือนกับ Apache Storm (คำถามนี้ที่นี่) - ดังนั้นไม่เลยนี่ไม่ใช่สิ่งที่ซ้ำกัน
fnl

คำตอบ:


215

ข้อจำกัดความรับผิดชอบ : ฉันเป็นผู้ให้บริการ Apache Flink และสมาชิก PMC และคุ้นเคยกับการออกแบบระดับสูงของ Storm เท่านั้นไม่ใช่ภายใน

Apache Flink เป็นเฟรมเวิร์กสำหรับสตรีมแบบรวมและการประมวลผลแบตช์ รันไทม์ของ Flink รองรับทั้งสองโดเมนเนื่องจากการถ่ายโอนข้อมูลแบบไปป์ไลน์ระหว่างงานคู่ขนานซึ่งรวมถึงการสับเปลี่ยนแบบไปป์ไลน์ บันทึกจะถูกจัดส่งทันทีตั้งแต่งานผลิตจนถึงงานรับ (หลังจากรวบรวมในบัฟเฟอร์สำหรับการถ่ายโอนเครือข่าย) งานแบทช์สามารถเลือกดำเนินการได้โดยใช้การบล็อกการถ่ายโอนข้อมูล

Apache Spark เป็นเฟรมเวิร์กที่รองรับการประมวลผลแบบแบตช์และสตรีม batch API ของ Flink มีลักษณะค่อนข้างคล้ายกันและระบุกรณีการใช้งานที่คล้ายกันกับ Spark แต่แตกต่างกันในด้านใน สำหรับการสตรีมทั้งสองระบบจะใช้วิธีการที่แตกต่างกันมาก (มินิแบทช์เทียบกับสตรีมมิง) ซึ่งทำให้เหมาะสำหรับแอปพลิเคชันประเภทต่างๆ ฉันจะบอกว่าการเปรียบเทียบ Spark กับ Flink นั้นถูกต้องและมีประโยชน์อย่างไรก็ตาม Spark ไม่ใช่เครื่องมือประมวลผลสตรีมที่คล้ายกับ Flink มากที่สุด

มาถึงคำถามเดิม Apache Storm เป็นตัวประมวลผลสตรีมข้อมูลที่ไม่มีความสามารถแบบแบตช์ ในความเป็นจริงเครื่องยนต์แบบท่อภายในของ Flink มีลักษณะคล้ายกับ Storm เล็กน้อยกล่าวคือส่วนต่อประสานของงานคู่ขนานของ Flink นั้นคล้ายกับสลักเกลียวของ Storm Storm และ Flink มีเหมือนกันที่พวกเขาตั้งเป้าไว้ที่การประมวลผลสตรีมเวลาแฝงต่ำโดยการถ่ายโอนข้อมูลแบบไปป์ไลน์ อย่างไรก็ตาม Flink มี API ระดับสูงกว่าเมื่อเทียบกับ Storm แทนที่จะใช้ฟังก์ชันการทำงานของสลักเกลียวกับผู้อ่านและตัวรวบรวมตั้งแต่หนึ่งตัวขึ้นไป DataStream API ของ Flink มีฟังก์ชันต่างๆเช่น Map, GroupBy, Window และ Join ต้องใช้ฟังก์ชันนี้จำนวนมากด้วยตนเองเมื่อใช้ Storm ความแตกต่างอีกประการหนึ่งคือการประมวลผลความหมาย Storm รับประกันการประมวลผลอย่างน้อยหนึ่งครั้งในขณะที่ Flink ให้บริการเพียงครั้งเดียว การใช้งานที่ให้การรับประกันการประมวลผลเหล่านี้แตกต่างกันเล็กน้อย ในขณะที่ Storm ใช้การตอบรับระดับเรกคอร์ด Flink ใช้อัลกอริทึม Chandy-Lamport ที่แตกต่างกัน โดยสรุปแหล่งข้อมูลจะฉีดเครื่องหมายลงในสตรีมข้อมูลเป็นระยะ เมื่อใดก็ตามที่ผู้ปฏิบัติงานได้รับเครื่องหมายดังกล่าวจะตรวจสอบสถานะภายในของมัน เมื่อได้รับเครื่องหมายจากซิงก์ข้อมูลทั้งหมดเครื่องหมาย (และระเบียนทั้งหมดที่ได้รับการประมวลผลก่อนหน้านี้) จะถูกคอมมิต ในกรณีที่เกิดความล้มเหลวตัวดำเนินการซอร์สทั้งหมดจะถูกรีเซ็ตเป็นสถานะของพวกเขาเมื่อพวกเขาเห็นเครื่องหมายที่ยืนยันครั้งสุดท้ายและการประมวลผลจะดำเนินต่อไป วิธีการตรวจสอบเครื่องหมายนี้มีน้ำหนักเบากว่าการตอบรับระดับบันทึกของ Storm นี้ แหล่งข้อมูลจะฉีดเครื่องหมายลงในสตรีมข้อมูลเป็นระยะ เมื่อใดก็ตามที่ผู้ปฏิบัติงานได้รับเครื่องหมายดังกล่าวจะตรวจสอบสถานะภายในของมัน เมื่อได้รับเครื่องหมายจากซิงก์ข้อมูลทั้งหมดเครื่องหมาย (และระเบียนทั้งหมดที่ได้รับการประมวลผลก่อนหน้านี้) จะถูกคอมมิต ในกรณีที่เกิดความล้มเหลวตัวดำเนินการซอร์สทั้งหมดจะถูกรีเซ็ตเป็นสถานะของพวกเขาเมื่อพวกเขาเห็นเครื่องหมายที่ยืนยันครั้งสุดท้ายและดำเนินการต่อ วิธีการตรวจสอบเครื่องหมายนี้มีน้ำหนักเบากว่าการตอบรับระดับบันทึกของ Storm นี้ แหล่งข้อมูลจะฉีดเครื่องหมายลงในสตรีมข้อมูลเป็นระยะ เมื่อใดก็ตามที่ผู้ปฏิบัติงานได้รับเครื่องหมายดังกล่าวจะตรวจสอบสถานะภายในของมัน เมื่อได้รับเครื่องหมายจากซิงก์ข้อมูลทั้งหมดเครื่องหมาย (และระเบียนทั้งหมดที่ได้รับการประมวลผลก่อนหน้านี้) จะถูกคอมมิต ในกรณีที่เกิดความล้มเหลวตัวดำเนินการซอร์สทั้งหมดจะถูกรีเซ็ตเป็นสถานะของพวกเขาเมื่อพวกเขาเห็นเครื่องหมายที่ยืนยันครั้งสุดท้ายและดำเนินการต่อ วิธีการตรวจสอบเครื่องหมายนี้มีน้ำหนักเบากว่าการตอบรับระดับบันทึกของ Storm นี้ ตัวดำเนินการแหล่งที่มาทั้งหมดจะถูกรีเซ็ตเป็นสถานะเมื่อพวกเขาเห็นเครื่องหมายที่มุ่งมั่นสุดท้ายและการประมวลผลจะดำเนินต่อไป วิธีการตรวจสอบเครื่องหมายนี้มีน้ำหนักเบากว่าการตอบรับระดับบันทึกของ Storm นี้ ตัวดำเนินการแหล่งที่มาทั้งหมดจะถูกรีเซ็ตเป็นสถานะเมื่อพวกเขาเห็นเครื่องหมายที่มุ่งมั่นสุดท้ายและการประมวลผลจะดำเนินต่อไป วิธีการตรวจสอบเครื่องหมายนี้มีน้ำหนักเบากว่าการตอบรับระดับบันทึกของ Storm นี้ชุดสไลด์และการพูดคุยที่เกี่ยวข้องจะกล่าวถึงแนวทางการประมวลผลสตรีมมิ่งของ Flink รวมถึงการยอมรับข้อผิดพลาดการตรวจสอบและการจัดการสถานะ

Storm ยังเสนอ API ระดับสูงแบบครั้งเดียวที่เรียกว่า Trident อย่างไรก็ตามตรีศูลนั้นมีพื้นฐานมาจากมินิแบทช์และด้วยเหตุนี้จึงคล้ายกับ Spark มากกว่า Flink

เวลาแฝงที่ปรับได้ของ Flink หมายถึงวิธีที่ Flink ส่งบันทึกจากงานหนึ่งไปยังอีกงานหนึ่ง ฉันเคยพูดไปแล้วว่า Flink ใช้การถ่ายโอนข้อมูลแบบไปป์ไลน์และส่งต่อบันทึกทันทีที่มีการผลิต เพื่อประสิทธิภาพบันทึกเหล่านี้จะถูกรวบรวมในบัฟเฟอร์ซึ่งจะถูกส่งผ่านเครือข่ายเมื่อข้อมูลเต็มหรือถึงเกณฑ์เวลาที่กำหนด ขีด จำกัด นี้ควบคุมเวลาในการตอบสนองของเร็กคอร์ดเนื่องจากระบุระยะเวลาสูงสุดที่เร็กคอร์ดจะอยู่ในบัฟเฟอร์โดยไม่ถูกส่งไปยังงานถัดไป อย่างไรก็ตามไม่สามารถใช้เพื่อให้การรับประกันอย่างหนักเกี่ยวกับเวลาที่ใช้ในการบันทึกตั้งแต่การเข้าสู่การออกจากโปรแกรมเนื่องจากยังขึ้นอยู่กับเวลาในการประมวลผลภายในงานและจำนวนการถ่ายโอนเครือข่าย


2
ขอบคุณมากจริงๆ! อาจจะมีจุดเปิดจุดหนึ่งหากฉันรบกวนคุณอีกครั้ง: ปัญหา "เวลาแฝงที่ปรับได้" เกี่ยวกับอะไร ดูเหมือนว่ามันจะค่อนข้างเกี่ยวข้องเนื่องจากโดเมนแอปพลิเคชันที่แตกต่างกันจะมีข้อกำหนดที่แตกต่างกันในแง่นี้ คุณอธิบายได้ไหมว่าสิ่งนี้หมายถึงอะไรอย่างน้อยก็ในแง่ของ Flink?
fnl

6
ได้เลยฉันขยายคำตอบและพูดคุยเกี่ยวกับเวลาแฝงที่ปรับได้ โปรดแจ้งให้เราทราบหากคุณมีคำถามเพิ่มเติม
Fabian Hueske

Flink อนุญาตให้มีการเปลี่ยนแปลง "ร้อน" ในเวิร์กโฟลว์ DAG หรือไม่เนื่องจากสามารถใช้งานได้เช่นใช้ Erlang หรือไม่ IE. สามารถเปลี่ยน DAG ระหว่างรันไทม์ได้หรือไม่?
Thomas Browne

1
ไม่สามารถแลกเปลี่ยนรหัสร้อนได้ อย่างไรก็ตามคุณสามารถคงสถานะของแอปพลิเคชันเป็นจุดประหยัดได้ สามารถใช้ savepoint เพื่อเริ่มโปรแกรมประยุกต์ที่แก้ไข ซึ่งสามารถทำได้ในขณะที่แอปพลิเคชันดั้งเดิมยังคงทำงานอยู่เพื่อให้สามารถพลิกเอาต์พุตได้ในบางจุด โปรดทราบว่าแอปไม่สามารถแก้ไขได้โดยพลการเมื่อเริ่มต้นใหม่จากจุดบันทึกที่มีอยู่
Fabian Hueske

1
ข้อได้เปรียบที่น่าสนใจและมากของ Flink คือความสามารถในการเรียกใช้ Apache Beam ด้วย API ระดับที่สูงกว่า เป็นนักวิ่งที่รวยและสมบูรณ์ที่สุดคนหนึ่งของบีม
Piotr Gwiazda

50

การเพิ่มคำตอบของ Fabian Hueske:

Flink ปรับปรุง Storm นอกจากนี้ด้วยวิธีต่อไปนี้:

  • Backpressure: รันไทม์สตรีมมิ่งของ Flink ทำงานได้ดีเมื่อตัวดำเนินการต่างกันทำงานด้วยความเร็วที่แตกต่างกันเนื่องจากตัวดำเนินการดาวน์สตรีมจะกดดันตัวดำเนินการอัพสตรีมได้เป็นอย่างดีแม้ว่าเลเยอร์เครือข่ายจะจัดการบัฟเฟอร์พูล

  • สถานะที่ผู้ใช้กำหนดเอง: Flink อนุญาตให้โปรแกรมรักษาสถานะที่กำหนดเองในตัวดำเนินการของคุณ รัฐนั้นสามารถมีส่วนร่วมในการตรวจสอบความทนทานต่อความผิดพลาดได้โดยให้การรับประกันเพียงครั้งเดียวสำหรับสถานะที่ผู้ใช้กำหนดเอง ดูตัวอย่างเครื่องสถานะที่ผู้ใช้กำหนดภายในโอเปอเรเตอร์ซึ่งตรวจสอบอย่างสม่ำเสมอพร้อมกับสตรีมข้อมูล

  • สตรีมมิง Windows: การสตรีมหน้าต่างและการรวมหน้าต่างเป็นส่วนประกอบสำคัญในการวิเคราะห์สตรีมข้อมูล Flink มาพร้อมกับระบบหน้าต่างที่มีประสิทธิภาพมากซึ่งรองรับหน้าต่างหลายประเภท


2
สำหรับประเด็นแรกของคุณ Storm มีพฤติกรรมที่ดีภายใต้แรงดันย้อนกลับ ณ 1.0 (เผยแพร่เมื่อเมษายน 2016)
Colin Nichols

สามารถลดแรงดันกลับของพายุได้โดยใช้คุณสมบัติ "spout_max_pending" ตั้งค่าขีด จำกัด สำหรับสิ่งสูงสุดที่สามารถมีอยู่ในพวยกาที่รอการรับทราบ Spout จะไม่กินสิ่งทออีกต่อไปจนกว่าจะเกิด ack
Aman Garg

5

ข้อจำกัดความรับผิดชอบ: ฉันเป็นพนักงานของ Cloudera ผู้สนับสนุนหลักของ Storm และ (เร็ว ๆ นี้) Flink

การทำงาน

มีการนำเสนอประเด็นทางเทคนิคที่ดีมากมายแล้ว สรุปสั้น ๆ ของไฮไลท์:

  • ทั้ง Flink และ Storm สามารถประมวลผลต่อเหตุการณ์ได้
  • Storm ไม่สนับสนุนเหตุการณ์และเวลานอกกรอบ
  • Storm ไม่ได้ยกการสนับสนุน SQL ออกจากขั้นตอนการทดลอง

ไม่ทำงาน

  • ลูกค้าหลายคนพบว่า Storm (เกินไป) ใช้งานยาก
  • การยอมรับของ Storm ช้าลงและชุมชนของ Flink ดูเหมือนจะมีความกระตือรือร้นมากกว่า Storm
  • Flink ยังคงมีสิ่งที่ต้องทำ (เช่นตัวอย่างเอกสาร) แต่โดยรวมแล้วมันได้พบในเกือบทุกพื้นที่ที่คุณอาจนึกถึง

สรุป

เมื่อเร็ว ๆ นี้ Cloudera ได้ประกาศเลิกใช้งาน Storm (ใน HDP) และในเวลาเดียวกัน Flink ก็ได้รับการประกาศให้เป็นผู้สืบทอด

ดังนั้นหากคุณมีปัญหาเกี่ยวกับพายุพวกเขาจะยังคงทำงานต่อไป แต่สำหรับการใช้งานใหม่ฉันจะดู Flink หรือเครื่องมือสตรีมมิ่งอื่น ๆ


3

จากประสบการณ์ของฉันเกี่ยวกับ Storm and Flink ฉันรู้สึกว่าเครื่องมือเหล่านี้สามารถแก้ปัญหาเดียวกันด้วยวิธีการต่างๆ คุณลักษณะทั้งหมดของ Flink ที่กล่าวถึงโดย @Stephan Ewen สามารถจับคู่ได้โดย Storm ด้วย API ภายใน (เช่นspoltsและbolts ) และTrident API ในขณะนี้ มีคนอ้างว่าตรีศูลเป็นสไตล์มินิแบทช์ในขณะที่ฉันคิดว่าแอพที่ซับซ้อนส่วนใหญ่ที่เกี่ยวข้องกับสถานะหรือการรวมอาจขึ้นอยู่กับการประมวลผลแบบแบทช์กับสไตล์หน้าต่าง ดังนั้นฉันจึงแสดงความแตกต่างหลัก ๆ ที่นี่โดยไม่บอกว่าอันไหนดีกว่า

  • รูปแบบการพัฒนา . ที่เน้นการคำนวณ (เช่นตัวดำเนินการ chainable) ใน Flink เทียบกับ data-stream-oriented (เช่นaddSpolt()/addBolt()) ใน Storm
  • ระดับสูง API ฟังก์ชั่น (เช่นแผนที่หน้าต่างเข้าร่วมในระดับการสตรีม) ใน Flink vs. Native Window และ Trident in Storm
  • รับประกันการประมวลผลข้อความ (GMP. เช่นที่ว่าครั้งหนึ่ง ) จุดตรวจที่มีตัวเชื่อมต่อ Commit สองเฟส (เช่น KafkaConsumer) ใน Flink เทียบกับ Tuple-tree กับเครื่องแสดงสถานะภายนอกหรือ Trident in Storm
  • ยอมรับความผิด เครื่องหมายจุดตรวจใน Flink เทียบกับบันทึกระดับ ACK ใน Storm
  • สถาปัตยกรรมภายใน นามธรรมอย่างง่ายและความขนานสัมพัทธ์ (เช่นสล็อตสำหรับแต่ละเธรดที่พิจารณาด้วยแกน CPU) ใน Flink เทียบกับนามธรรมหลายเลเยอร์ (เช่นสล็อตสำหรับ JVM แต่ละตัวในฐานะผู้ปฏิบัติงานในหัวหน้างานและหัวหน้างานแต่ละคนสามารถมีคนงานได้หลายคน) ใน Storm
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.