โบรกเกอร์ข้อความดั้งเดิมและสตรีมข้อมูล

ตามไซต์ Kafka :

" Kakfa ใช้สำหรับสร้างท่อข้อมูลและแอพสตรีมมิ่งแบบเรียลไทม์ "

การค้นหาอินเทอร์เน็ตอย่างกว้างขวางฉันได้พบคำจำกัดความที่เป็นที่ยอมรับโดยทั่วไปของคำว่า " ข้อมูลสตรีม " คืออะไร:

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

ตอนนี้ถ้ามีสิ่งใดที่ฉันกล่าวข้างต้นไม่ถูกต้องไม่สมบูรณ์หรือผิดทั้งหมดโปรดเริ่มต้นด้วยการแก้ไขฉัน! สมมติว่าฉันติดตามมากกว่าหรือน้อยกว่านั้น ...

ตอนนี้ฉันเข้าใจแล้วว่า "การสตรีมข้อมูล" คืออะไรจากนั้นฉันก็เข้าใจว่าคาฟคาและไคเนซิสหมายถึงอะไรเมื่อพวกเขาเรียกเก็บเงินด้วยตนเองว่าเป็นตัวกลางในการประมวลผล / การเป็นนายหน้าตัวกลางสำหรับแอปพลิเคชัน แต่มันทำให้ฉันสนใจ: สามารถ / ควร "สตรีมมิดเดิลแวร์" เช่น Kafka หรือ Kinesis ใช้สำหรับข้อมูลที่ไม่ได้สตรีมมิงเช่นโบรกเกอร์ข้อความแบบดั้งเดิมหรือไม่ และในทางกลับกัน: สามารถ / ควรใช้ MQ แบบดั้งเดิมเช่น RabbitMQ, ActiveMQ, Apollo และอื่น ๆ เพื่อใช้ในการสตรีมข้อมูล?

ลองมาตัวอย่างที่แอปพลิเคชันจะส่งแบ็กเอนด์ค่าคงที่แบ็กเอนด์ของข้อความ JSON ที่ต้องถูกประมวลผลและการประมวลผลค่อนข้างซับซ้อน (การตรวจสอบการแปลงข้อมูลการกรองการรวมตัว ฯลฯ ):

• กรณี # 1: ข้อความแต่ละเฟรมของภาพยนตร์ นั่นคือหนึ่งข้อความ JSON ต่อเฟรมวิดีโอที่มีข้อมูลเฟรมและข้อมูลเมตาที่สนับสนุนบางส่วน
• กรณีที่ # 2: ข้อความเป็นข้อมูลอนุกรมเวลาบางทีหัวใจของใครบางคนเป็นหน้าที่ของเวลา ดังนั้นข้อความ # 1 จะถูกส่งแทน heartbeat ของฉันที่ t = 1, ข้อความ # 2 มี heartbeat ของฉันที่ t = 2, ฯลฯ
• กรณีที่ # 3: ข้อมูลมีความแตกต่างอย่างสิ้นเชิงและไม่เกี่ยวข้องตามเวลาหรือเป็นส่วนหนึ่งของ "data stream" บางทีเหตุการณ์การตรวจสอบ / ความปลอดภัยที่ถูกไล่ออกเนื่องจากผู้ใช้หลายร้อยคนนำทางปุ่มคลิกแอปพลิเคชันและดำเนินการ

จากการที่ Kafka / Kinesis ถูกเรียกเก็บเงินและความเข้าใจของฉันเกี่ยวกับสิ่งที่ "สตรีมข้อมูล" พวกเขาดูเหมือนจะเป็นผู้สมัครที่ชัดเจนสำหรับคดี # 1 (ข้อมูลวิดีโอที่ต่อเนื่องกัน) และ # 2 (ข้อมูลอนุกรมเวลาต่อเนื่อง) อย่างไรก็ตามฉันไม่เห็นเหตุผลใด ๆ ว่าทำไมนายหน้าข้อความแบบดั้งเดิมเช่น RabbitMQ ไม่สามารถจัดการอินพุตทั้งสองได้อย่างมีประสิทธิภาพเช่นกัน

และด้วย Case # 3 เราได้รับเฉพาะเหตุการณ์ที่เกิดขึ้นและเราต้องดำเนินการตอบสนองต่อเหตุการณ์นั้น ดังนั้นสำหรับฉันนี่พูดถึงการต้องการนายหน้าแบบดั้งเดิมเช่น RabbitMQ แต่ก็ไม่มีเหตุผลใดที่คุณจะไม่มี Kafka หรือ Kinesis จัดการกับการประมวลผลข้อมูลเหตุการณ์เช่นกัน

โดยพื้นฐานแล้วฉันกำลังหารูบริกที่ระบุว่า: ฉันมีข้อมูล X พร้อมคุณสมบัติ Y ฉันควรใช้สตรีมโปรเซสเซอร์เช่น Kafka / Kinesis เพื่อจัดการมัน หรือในทางกลับกันสิ่งหนึ่งที่ช่วยฉันพิจารณา: ฉันมีข้อมูล W พร้อมคุณสมบัติ Z ฉันควรใช้นายหน้าข้อความแบบดั้งเดิมเพื่อจัดการมัน

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

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

รสชาติของการสตรีมของคาฟคาย่อมาจากการเรียกกระบวนการระยะไกลเช่น Thrift หรือ HTTP และการประมวลผลแบบแบทช์เช่นในระบบนิเวศ Hadoop ซึ่งแตกต่างจาก RPC ส่วนประกอบสื่อสารแบบอะซิงโครนัส: ชั่วโมงหรือวันที่อาจผ่านระหว่างเมื่อมีการส่งข้อความและเมื่อผู้รับตื่นขึ้นมาและดำเนินการกับมัน อาจมีผู้รับหลายคนในเวลาต่างกันหรืออาจไม่มีใครใส่ใจที่จะใช้ข้อความ ผู้ผลิตหลายรายสามารถผลิตในหัวข้อเดียวกันโดยปราศจากความรู้ของผู้บริโภค คาฟคาไม่ทราบว่าคุณเป็นสมาชิกหรือไม่หรือมีการใช้ข้อความหรือไม่ ข้อความส่งถึงบันทึกซึ่งผู้สนใจสามารถอ่านได้

คุณสนใจข้อความเดียวไม่ใช่แค่การรวบรวมข้อความจำนวนมาก (แม้ว่าไม่ใช่เรื่องแปลกที่จะเก็บข้อความ Kafka ลงในไฟล์ Parquet บน HDFS และทำการสืบค้นเป็นตาราง Hive)

กรณีที่ 1 : คาฟคาไม่ได้รักษาความสัมพันธ์ชั่วคราวระหว่างผู้ผลิตและผู้บริโภค มันเป็นแบบที่ไม่ดีสำหรับการสตรีมวิดีโอเพราะ Kafka ได้รับอนุญาตให้ชะลอความเร็วเพิ่มความเร็วเคลื่อนย้ายได้พอดีและเริ่มต้น ฯลฯ สำหรับสื่อสตรีมมิ่งเราต้องการแลกเปลี่ยนปริมาณงานโดยรวมเพื่อแลกกับราคาต่ำและที่สำคัญกว่าคือความเสถียรแฝง เรียกว่ากระวนกระวายใจต่ำ) คาฟคาใช้ความเจ็บปวดอย่างมากที่จะไม่สูญเสียข้อความ ด้วยการสตรีมวิดีโอเรามักจะใช้ UDP และเป็นเนื้อหาที่จะวางเฟรมที่นี่และที่นั่นเพื่อให้วิดีโอทำงานต่อไป SLA ในกระบวนการที่ได้รับการสนับสนุนจากคาฟคานั้นโดยปกติแล้วจะใช้เวลาไม่กี่วินาทีในการมีสุขภาพดี SLA บนสื่อการสตรีมมีหน่วยเป็นสิบมิลลิวินาที

Netflix สามารถใช้ Kafka เพื่อย้ายเฟรมไปรอบ ๆ ในระบบภายในที่แปลงรหัสวิดีโอเป็นเทราไบต์ต่อชั่วโมงและบันทึกลงดิสก์ แต่ไม่ส่งไปที่หน้าจอของคุณ

กรณีที่ 2 : อย่างแน่นอน เราใช้คาฟคาแบบนี้กับนายจ้างของฉัน

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

Kafka / Kinesis ถูกสร้างแบบจำลองเป็นสตรีม สตรีมมีคุณสมบัติแตกต่างจากข้อความ

• สตรีมมีบริบทกับพวกเขา พวกเขามีระเบียบ คุณสามารถใช้ฟังก์ชั่นหน้าต่างกับสตรีม แม้ว่าแต่ละรายการในสตรีมจะมีความหมาย แต่อาจมีความหมายมากขึ้นกับบริบทที่อยู่รอบ ๆ
• เนื่องจากสตรีมมีคำสั่งซื้อคุณสามารถใช้สิ่งนั้นเพื่อสร้างข้อความบางอย่างเกี่ยวกับความหมายของการประมวลผล เช่น Apache ตรีศูลคาดคะเนความหมายที่แน่นอนครั้งเดียวเมื่อบริโภคจากกระแสคาฟคา
• คุณสามารถใช้ฟังก์ชั่นกับสตรีม คุณสามารถแปลงกระแสโดยไม่ต้องบริโภคมัน คุณสามารถใช้สตรีมอย่างเกียจคร้านได้ คุณสามารถข้ามบางส่วนของสตรีมได้
• คุณสามารถเล่นซ้ำสตรีมใน Kafka ได้ แต่คุณไม่สามารถ (ไม่ต้องมีซอฟต์แวร์เพิ่มเติม) รอคิวข้อความซ้ำ สิ่งนี้มีประโยชน์เมื่อคุณไม่รู้ด้วยซ้ำว่าคุณต้องการทำอะไรกับข้อมูล นอกจากนี้ยังมีประโยชน์สำหรับการฝึกอบรม AI

โดยทั่วไปใช้ Kafka สำหรับการประมวลผลสตรีมออฟไลน์ใช้คิวข้อความสำหรับข้อความไคลเอ็นต์ - เซิร์ฟเวอร์แบบเรียลไทม์

ตัวอย่างการใช้เคสจากการพิจาณา :

Kafka: การติดตามกิจกรรมเว็บไซต์, การวัด, การรวบรวมบันทึก, การประมวลผลสตรีม, การจัดหากิจกรรมและบันทึกการกระทำ

RabbitMQ: การส่งข้อความที่มีวัตถุประสงค์ทั่วไป ... มักใช้เพื่ออนุญาตให้เว็บเซิร์ฟเวอร์ตอบสนองต่อการร้องขออย่างรวดเร็วแทนที่จะถูกบังคับให้ทำตามขั้นตอนการใช้ทรัพยากรจำนวนมากในขณะที่ผู้ใช้รอผล ใช้เมื่อคุณต้องการใช้โปรโตคอลที่มีอยู่เช่น AMQP 0-9-1, STOMP, MQTT, AMQP 1.0

บางครั้งอาจมีประโยชน์ในการใช้งานทั้งสองอย่าง! ตัวอย่างเช่นใน Use Case # 2 หากนี่คือสตรีมข้อมูลจากเครื่องกระตุ้นหัวใจบอกว่าฉันจะให้เครื่องกระตุ้นหัวใจส่งข้อมูล heartbeat ไปยังคิวข้อความ RabbitMQ (โดยใช้โปรโตคอล cool เช่น MQTT) ซึ่งจะประมวลผลทันทีเพื่อ ดูว่าหัวใจของแหล่งที่มายังคงเต้นอยู่หรือไม่ สิ่งนี้สามารถเพิ่มประสิทธิภาพแดชบอร์ดและระบบตอบกลับฉุกเฉิน คิวข้อความจะฝากข้อมูลอนุกรมเวลาลงใน Kafka เพื่อให้เราสามารถวิเคราะห์ข้อมูลการเต้นของหัวใจเมื่อเวลาผ่านไป ตัวอย่างเช่นเราอาจใช้อัลกอริทึมในการตรวจจับโรคหัวใจโดยการสังเกตแนวโน้มในกระแสการเต้นของหัวใจ