เวลาแฝงใน Activator
Fabric Activator จะเรียกใช้กฎกับข้อมูลในเวลาจริง ผลลัพธ์ใกล้เคียงกันทันที แต่มีปัจจัยที่สามารถทําให้เกิดเวลาแฝงได้ ในกรณีส่วนใหญ่ เวลาแฝงดังกล่าวจะมองไม่เห็น แต่ในกรณีอื่น ๆ ที่เวลาแฝงสามารถสูงถึง 10 นาที การรับข้อมูลที่ถูกต้องและทันเวลาเป็นข้อควรพิจารณาที่สําคัญเมื่อสร้างและรับกฎ บทความนี้ตรวจทานกระบวนการและการตั้งค่าที่กําหนดความสมดุลระหว่างการรวมเหตุการณ์และโครงสร้างของกฎ และความเร็วในการส่งตัวเปิดใช้งาน ตัวอย่างเช่น Activator ควรอนุญาตให้มีข้อมูลเพิ่มเติมให้มาถึงและควรมี Activator หรือควรตรวจสอบให้แน่ใจว่าผู้รับได้รับการแจ้งเตือนของพวกเขาในเวลาที่กําหนดไว้หรือไม่ และวิธีการที่มีโครงสร้างกฎจะส่งผลต่อความเร็วที่การเปิดใช้งานถูกส่งไปยังผู้รับอย่างไร
มีสามปัจจัยสําคัญที่ส่งผลกระทบต่อเวลาแฝงการเปิดใช้งานกฎ:
- การตั้งค่าผู้ใช้สําหรับการยอมรับสาย
- การหน่วงเวลาสูงสุดหนึ่งนาที ซึ่งอาจแนะนําโดยการประมวลผลส่วนหลังของ Activator
- การรวมกฎ
ค่าเผื่อการมาสาย
ตั้งค่าการยอมรับการมาถึงสายในหน้าจอข้อกําหนดของกฎตัวเปิดใช้งานและนําไปใช้กับเวลามาถึงของเหตุการณ์ หากต้องการเรียนรู้วิธีการตั้งค่าระดับการยอมรับการมาถึงสาย ให้ดู การตั้งค่าระดับการยอมรับการมาสาย
เวลาแฝงในการประมวลผล Backend
กฎอาจจําเป็นต้องมีการประมวลผลก่อนที่กฎจะเปิดใช้งาน ตัวอย่างเช่น ถ้ากฎเปรียบเทียบกับชุดเหตุการณ์ก่อนหน้า จะใช้การประมวลผล backend เพื่อดึงข้อมูลก่อนหน้า ทําการเปรียบเทียบ และคํานวณผลลัพธ์ อีกตัวอย่างหนึ่งคือถ้ากฎกําลังทํางานกับข้อมูล 10,000,000 แถว เวลาแฝงจะถูกแนะนําโดยการประมวลผล backend ของข้อมูลนั้น
เวลาแฝงของการรวม
ถ้ามีการใช้การรวมในข้อกําหนดของกฎ กฎจะทํางานเฉพาะเมื่อดําเนินการในหน้าต่างเวลาที่ระบุเสร็จสิ้น ตัวอย่างเช่น สมมติว่ากฎถูกสร้างขึ้นเพื่อเฉลี่ยข้อมูลมากกว่าสี่ชั่วโมง ถ้าเหตุการณ์ที่ตรงตามเงื่อนไขของกฎถูกส่งเข้าในเวลา 23.00 น. กฎจะทริกเกอร์เมื่อ 16:00 น. เวลาแฝงคือผลลัพธ์ของการตั้งค่าการรวม แม้ว่ากฎจะมีการรวมอย่างง่าย เช่น ค่าเฉลี่ย Activator ไม่สามารถส่งการเปิดใช้งานได้จนกว่า Activator จะเรียกใช้การรวมทั่วข้อมูลเหตุการณ์ที่เข้ามา
แนวคิดเวลาพื้นหลัง
เพื่อจัดกรอบการสนทนาให้ดียิ่งขึ้น มากําหนดแนวคิดพื้นหลังบางอย่าง
- เวลาเหตุการณ์: เวลาเมื่อเกิดเหตุการณ์ต้นฉบับ ส่วนนี้เป็นส่วนหนึ่งของส่วนข้อมูลเหตุการณ์ ตัวอย่างเช่นเมื่อรถเคลื่อนที่บนทางหลวงจะเข้าใกล้บูธค่าผ่านทางและสังเกตเห็นโดยเซ็นเซอร์
- เวลาการประมวลผล: เวลาเมื่อเหตุการณ์มาถึงระบบประมวลผลและจะสังเกตได้ ตัวอย่างเช่น เมื่อเซ็นเซอร์ตู้โทรเข้าเห็นรถยนต์และระบบคอมพิวเตอร์ใช้เวลาสักครู่ในการประมวลผลข้อมูล
- เวลา ขาเข้า (เวลาในลายน้ําหรือเวลาการนําเข้า): เครื่องหมายที่ระบุเมื่อข้อมูลเหตุการณ์ถึง Activator ด้วยลักษณะของสตรีม ข้อมูลเหตุการณ์ขาเข้าจะไม่มีหยุด ดังนั้นเวลาในการเข้าถึงจึงระบุความคืบหน้าของ Activator ไปยังจุดใดจุดหนึ่งในสตรีม ซึ่งอยู่ที่จุดนี้ที่ Activator สามารถสร้างผลลัพธ์ที่สมบูรณ์ ถูกต้อง และทําซ้ําได้ซึ่งไม่จําเป็นต้องถอน และถึงจุดนี้ที่ Activator สามารถเริ่มประมวลผลข้อมูลได้ การประมวลผลสามารถทําได้ในลักษณะที่คาดการณ์ได้และทําซ้ําได้ ตัวอย่างเช่น ถ้าจําเป็นต้องนับจํานวนครั้งสําหรับเงื่อนไขการจัดการข้อผิดพลาดบางอย่าง เวลาในการมาถึงจะปลอดภัยในการเริ่มต้นและจุดสิ้นสุด
การมาถึงสายเกิดขึ้นเมื่อกฎมีพารามิเตอร์เวลาและ เวลา เหตุการณ์อยู่ภายในพารามิเตอร์เวลานั้น แต่ เวลา ขาเข้าจะอยู่นอกพารามิเตอร์ดังกล่าว หากเราใช้ตัวอย่างบูธเก็บค่าผ่านทางอีกครั้ง รถจะถูกรับรู้โดยเซ็นเซอร์บูธโทรและเวลาเหตุการณ์จะอยู่ภายในพารามิเตอร์เวลา Activator เห็นว่ากฎมีการรวมและดําเนินการรวมข้อมูลนั้นผ่านข้อมูล เวลาที่ใช้ในการดําเนินการรวมดังกล่าว จะ ใส่เวลา การมาถึงนอกพารามิเตอร์เวลา เหตุการณ์นั้นถือว่าดึกแล้ว หากคุณต้องการรวมการมาถึงสาย ให้ตั้งค่าสําหรับ ค่าการยอมรับการมาถึงสาย
สําหรับแหล่งข้อมูลเพิ่มเติมในหัวข้อนี้ ดูบล็อกโพสต์ของ Tyler Akidau Streaming 101 และ Streaming 102
การตั้งค่าระดับการยอมรับการมาถึงล่าช้า
ระดับการยอมรับการมาถึงล่าช้าคือการตั้งค่าผู้ใช้ ค่าเผื่อการมาถึงล่าช้าหมายถึงระยะเวลาที่ Activator รอเหตุการณ์มาถึงและรับทราบและประมวลผล ค่าเริ่มต้นคือสองนาที ความคลาดเคลื่อนของการมาถึงล่าช้าช่วยเพิ่มเวลาแฝง กฎที่สร้างขึ้นด้วยการยอมรับสายมาถึงมีเวลาแฝงที่มีเวลาแฝงอย่างน้อยระยะเวลาที่การยอมรับสายถูกตั้งค่า เมื่อสร้างกฎ ตัดสินใจว่า จะใช้การยอมรับเริ่มต้นหรือเปลี่ยนแปลงกฎ การยอมรับเพื่อให้แน่ใจว่าเหตุการณ์และเหตุการณ์ที่ล่าช้าที่มาถึงคําสั่งซื้อมีโอกาสที่จะรวมอยู่ในการประเมินกฎ หากเหตุการณ์อยู่นอกระดับการยอมรับสาย Activator จะไม่คํานึงถึง เหตุการณ์ใด ๆ ที่มี เวลา มาถึงหลังจากการยอมรับนั้นไม่ได้เป็นปัจจัย
โดยรวมแล้ว ข้อควรพิจารณาคือสิ่งสําคัญมากกว่าหรือไม่:
- รอจุดข้อมูลที่ล่าช้า หรือ
- เรียกใช้กฎในข้อมูลที่ไม่สมบูรณ์เพื่อให้กฎเปิดใช้งานเร็วขึ้น
ในตัวอย่างนี้ จุดข้อมูลจะวัดทีละ 15 นาที สามจุดแรกซึ่งเป็นสีน้ําเงิน ทําให้อยู่ในหน้าต่างเวลา จุดที่สี่ ซึ่งเป็นสีส้ม ไม่เป็นแบบนั้น เวลาของเหตุการณ์จะอยู่ภายในช่วงเวลา 15 นาที แต่เหตุการณ์ไม่ได้ส่งโดย Activator ภายในช่วงเวลา 15 นาที Activator จะประเมินกฎผ่านข้อมูลด้วยเวลาขาเข้าภายในหน้าต่าง 15 นาทีเท่านั้น เว้นแต่ว่าผู้ใช้ระบุว่าพวกเขาต้องการอนุญาตให้มีการยอมรับมาสายและรอเพื่อดูว่าจุดข้อมูลอื่น ๆ มาถึงหรือไม่
ตัวกระตุ้นไม่สามารถแสดงความล่าช้าจากข้อมูลของผู้ใช้ได้ ตัวอย่างเช่น ผู้ใช้สามารถมีเซ็นเซอร์ IoT ที่ออฟไลน์เป็นเวลา 1 ชั่วโมง เมื่อพวกเขากลับไปออนไลน์ Activator สามารถรับข้อมูล แต่ข้อมูลล่าช้าเป็นเวลา 1 ชั่วโมงจากสถานะออฟไลน์นั้น ซึ่งเกิดขึ้นภายนอก Activator
นี่เป็นอีกตัวอย่างหนึ่ง
ผู้ใช้สร้างกฎที่คํานวณอุณหภูมิเฉลี่ยในช่วงเวลานาที ระดับการยอมรับการมาถึงสายถูกตั้งค่าเป็นค่าเริ่มต้น ค่าเริ่มต้น คือสองนาที รวมค่าอุณหภูมิ 20 และ 30 และอุณหภูมิเฉลี่ย 25 อย่างไรก็ตาม เหตุการณ์ที่มาถึงล่าช้าสําหรับอุณหภูมิ 40 องศาจะไม่ถูกรวมไว้จนกว่าการเปิดใช้งานกฎถัดไปจะเกิดขึ้น
เวลาเหตุการณ์ | เวลาที่มาถึง | อุณหภูมิ |
---|---|---|
09:00 | 09:02 | 20 |
09:01 | 09:03 | 30 |
09:02 | 09:07 | 40 |
สำคัญ
ในขณะนี้คุณไม่สามารถแทนที่การยอมรับการมาสายตามค่าเริ่มต้นได้ การตั้งค่านี้ไม่สามารถใช้งานได้กับกฎ Power BI
กฎที่สร้างขึ้นบนวิชวล Power BI
เวลาแฝงที่มีอยู่ภายในแตกต่างกันตามบริการ เวลาแฝงสําหรับเหตุการณ์จะแตกต่างจากเวลาแฝงสําหรับวิชวล Power BI มีสองส่วนที่สร้างเวลาแฝงสําหรับกฎที่สร้างขึ้นบนวิชวล Power BI: ความถี่ของการคิวรีวิชวล Power BI ที่สร้างขึ้นในระบบ และความล่าช้าที่แบ็กเอนด์ของ Activator อาจแนะนํา
กฎของ Power BI จะถูกประเมินทุกครั้งที่มีข้อมูลใหม่เข้ามาในตัวเปิดใช้งาน Activator ingests ข้อมูลใหม่จาก Power BI ทุกชั่วโมง ซึ่งหมายความว่าเหตุการณ์ที่ตรงตามเงื่อนไขกฎจะทริกเกอร์การเปิดใช้งานไม่เกินหนึ่งชั่วโมงหลังจากเหตุการณ์เกิดขึ้น สําหรับข้อมูลเพิ่มเติม ดูรับข้อมูลสําหรับ Activator จาก Power BI