การสร้างแบบจำลองข้อมูลด้วย Kafka? หัวข้อและพาร์ติชัน

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

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

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

เมื่อรู้สิ่งนี้จะเป็นตัวอย่างที่ดีที่แสดงวิธีใช้หัวข้อและพาร์ติชันได้อย่างไร เมื่อไรควรเป็นหัวข้อ? เมื่อใดที่ควรเป็นพาร์ติชัน

ตัวอย่างเช่นสมมติว่าข้อมูล (Clojure) ของฉันดูเหมือน:

{:user-id 101 :viewed "/page1.html" :at #inst "2013-04-12T23:20:50.22Z"}
{:user-id 102 :viewed "/page2.html" :at #inst "2013-04-12T23:20:55.50Z"}

หัวข้อควรเป็นไปตามuser-id? viewed? at? แล้วพาร์ติชั่นล่ะ

ฉันจะตัดสินใจได้อย่างไร

เมื่อจัดโครงสร้างข้อมูลของคุณสำหรับคาฟคานั้นขึ้นอยู่กับความหมายของการบริโภค

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

มีการลงทะเบียนหัวข้อใน ZooKeeper ซึ่งหมายความว่าคุณอาจพบปัญหาหากพยายามเพิ่มมากเกินไปเช่นกรณีที่คุณมีผู้ใช้งานนับล้านคนและได้ตัดสินใจสร้างหัวข้อต่อผู้ใช้

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

การแบ่งพาร์ติชันสามารถตั้งค่าได้อย่างชัดเจนโดยใช้พาร์ติชั่นคีย์ด้านผู้ผลิตหรือถ้าไม่ได้ระบุพาร์ติชั่นแบบสุ่มจะถูกเลือกสำหรับทุกข้อความ

เมื่อคุณทราบวิธีแบ่งพาร์ทิชันกิจกรรมของคุณชื่อหัวข้อจะง่ายดังนั้นลองตอบคำถามนั้นก่อน

@Ludd ถูกต้อง - โครงสร้างพาร์ติชั่นที่คุณเลือกจะขึ้นอยู่กับว่าคุณต้องการประมวลผลสตรีมเหตุการณ์อย่างไร เป็นการดีที่คุณต้องการคีย์พาร์ทิชันซึ่งหมายความว่าการประมวลผลงานของคุณคือพาร์ทิชันท้องถิ่น

ตัวอย่างเช่น:

1. :user-idถ้าคุณดูแลเกี่ยวกับผู้ใช้เวลาบนเว็บไซต์เฉลี่ยแล้วคุณควรจะแบ่งพาร์ติชันโดย ด้วยวิธีนี้กิจกรรมทั้งหมดที่เกี่ยวข้องกับกิจกรรมไซต์ของผู้ใช้คนเดียวจะพร้อมใช้งานภายในพาร์ติชันเดียวกัน ซึ่งหมายความว่าเอ็นจิ้นการประมวลผลสตรีมเช่นApache Samzaสามารถคำนวณเวลาบนไซต์โดยเฉลี่ยสำหรับผู้ใช้ที่กำหนดเพียงแค่ดูเหตุการณ์ในพาร์ติชันเดียว สิ่งนี้หลีกเลี่ยงไม่ต้องทำการประมวลผลพาร์ติชันระดับโลกที่มีราคาแพง
2. หากคุณสนใจหน้าเว็บที่ได้รับความนิยมมากที่สุดในเว็บไซต์ของคุณคุณควรแบ่งพาร์ติชันตาม:viewedหน้า อีกครั้ง Samza จะสามารถนับจำนวนการดูหน้าเว็บที่กำหนดเพียงแค่ดูเหตุการณ์ในพาร์ติชันเดียว

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

หากคุณต้องการใช้ทั้งสองกรณีข้างต้นรูปแบบทั่วไปที่มี Kafka คือการแบ่งพาร์ติชันก่อนโดยพูด:user-idแล้วจึงทำการแบ่งพาร์ติชันใหม่โดย:viewedพร้อมสำหรับการประมวลผลในระยะต่อไป

ชื่อกระทู้ - หนึ่งที่เห็นได้ชัดที่นี่จะเป็นหรือevents user-eventsการจะมีความเฉพาะเจาะจงมากขึ้นคุณสามารถไปกับกับและevents-by-user-id / หรือevents-by-viewed

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

ประเด็นสำคัญในสรุป:

• โดยทั่วไปพาร์ติชันเพิ่มเติมที่มีอยู่ในคลัสเตอร์ Kafka ยิ่งอัตราการรับส่งข้อมูลสูงขึ้นเท่านั้น ให้สูงสุดตลอดทำได้บนพาร์ติชันเดียวสำหรับการผลิต พ.ศ. พีและการบริโภคเป็นค สมมติว่าผ่านเป้าหมายของคุณตัน จากนั้นคุณต้องมีพาร์ติชันอย่างน้อยสูงสุด ( t / p , t / c )

• ขณะนี้ใน Kafka โบรกเกอร์แต่ละรายเปิดตัวจัดการไฟล์ของทั้งดัชนีและไฟล์ข้อมูลของทุกเซกเมนต์บันทึก ดังนั้นยิ่งพาร์ติชั่นมากเท่าไหร่ก็ยิ่งจำเป็นต้องกำหนดค่าขีด จำกัด การจัดการไฟล์แบบเปิดในระบบปฏิบัติการที่รองรับ เช่นในระบบการผลิตของเราเราเคยเห็นข้อผิดพลาดว่าtoo many files are openในขณะที่เรามีพาร์ทิชันหัวข้อประมาณ 3600

• เมื่อนายหน้าปิดตัวลงอย่างไม่สะอาด (เช่น kill -9) การไม่พร้อมใช้งานที่สังเกตอาจเป็นสัดส่วนกับจำนวนพาร์ติชัน

• เวลาแฝงจากต้นทางถึงปลายทางในคาฟคาถูกกำหนดโดยเวลาตั้งแต่เมื่อข้อความถูกเผยแพร่โดยผู้ผลิตจนถึงเมื่อข้อความถูกอ่านโดยผู้ใช้ ตามกฎของหัวแม่มือหากคุณใส่ใจเรื่องความหน่วงอาจเป็นความคิดที่ดีที่จะ จำกัด จำนวนพาร์ติชั่นต่อหนึ่งโบรกเกอร์เป็น 100 x b x rโดยที่bคือจำนวนโบรกเกอร์ในกลุ่มคาฟคาและrคือปัจจัยการจำลองแบบ

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

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

Kafka ได้รับการพัฒนาโดย LinkedIn สำหรับการรวมบันทึกและการจัดส่ง ฉากนี้เป็นตัวอย่างที่ดีมาก

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

เกี่ยวกับกรณีและปัญหาของคุณคุณสามารถสร้างหนึ่งหัวข้อที่เรียกว่า "page-view-event" และสร้างพาร์ติชัน N ผ่านคีย์แฮชเพื่อแจกจ่ายบันทึกไปยังพาร์ติชันทั้งหมดอย่างเท่าเทียมกัน หรือคุณสามารถเลือกโลจิคัลพาร์ติชันเพื่อสร้างการกระจายบันทึกโดยวิญญาณของคุณ