สร้างกิจกรรมแบบเกือบเรียลไทม์ด้วย Fleet Engine และโซลูชันอ้างอิงเหตุการณ์ของ Fleet

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

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

เอกสารนี้จะแสดงวิธีที่นักพัฒนาแอปสามารถเปลี่ยนสัญญาณจาก "บริการการเดินทาง" ของ Google Maps Platform ("Last Mile Fleet Solution" (LMFS) หรือ "โซลูชันการโดยสารและการนำส่งแบบออนดีมานด์" (ODRD) เป็นเหตุการณ์ที่กำหนดเองที่ดำเนินการได้ นอกจากนี้ เรายังอธิบายแนวคิดหลักและการตัดสินใจด้านการออกแบบของโซลูชันข้อมูลอ้างอิงเหตุการณ์ของ Fleet ที่มีอยู่ใน GitHub ด้วย

เอกสารนี้เกี่ยวข้องกับ

ในตอนท้ายของเอกสารฉบับนี้ คุณควรมีความเข้าใจพื้นฐานเกี่ยวกับองค์ประกอบหลักและข้อควรพิจารณาของระบบสตรีมมิง รวมถึงการสร้างองค์ประกอบจาก Google Maps Platform และ Google Cloud ที่ประกอบขึ้นเป็นโซลูชันข้อมูลอ้างอิงกิจกรรมเกี่ยวกับแพ็กเกจ

ภาพรวมโซลูชันการอ้างอิงเหตุการณ์ของกลุ่มยานพาหนะ

Fleet Event Reference Solution เป็นโซลูชันโอเพนซอร์สที่ช่วยให้ลูกค้าและพาร์ทเนอร์ที่ใช้ระบบเคลื่อนที่สามารถสร้างเหตุการณ์สำคัญนอกเหนือจาก Fleet Engine และคอมโพเนนต์ของ Google Cloud ได้ ปัจจุบัน โซลูชันการอ้างอิงนี้สนับสนุนลูกค้าที่ใช้โซลูชัน Last Mile Fleet พร้อมรองรับการโดยสารและการจัดส่งแบบออนดีมานด์

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

  • เวลาถึงโดยประมาณที่กำลังจะถึง
  • การเปลี่ยนแปลงเวลาถึงโดยประมาณแบบสัมพัทธ์สำหรับการมาถึงงาน
  • เวลาที่เหลือในการมาถึงงาน
  • ระยะทางที่เหลืออยู่จะถึงงาน
  • การเปลี่ยนสถานะ Taskresults

แต่ละองค์ประกอบของโซลูชันข้อมูลอ้างอิงสามารถปรับแต่งให้เหมาะกับความต้องการทางธุรกิจของคุณ

องค์ประกอบที่ใช้สร้างสรรค์เชิงตรรกะ

แผนภาพ : แผนภาพต่อไปนี้แสดงองค์ประกอบที่ใช้สร้างสรรค์ระดับสูงซึ่งประกอบเป็นโซลูชันการอ้างอิงเหตุการณ์กลุ่ม

ภาพรวมกิจกรรมกองทัพเรือและองค์ประกอบ ในการสร้างเชิงตรรกะ

โซลูชันการอ้างอิงประกอบด้วยองค์ประกอบต่อไปนี้

  • แหล่งที่มาของเหตุการณ์: แหล่งที่มาของสตรีมเหตุการณ์เดิม ทั้ง "โซลูชัน ขบวนการไมล์สุดท้าย" หรือ "โซลูชันการโดยสารและการนำส่งแบบออนดีมานด์" มีการผสานรวมกับ Cloud Logging ที่ช่วยเปลี่ยนการบันทึกการโทรของ Fleet Engine RPC เป็นสตรีมเหตุการณ์ที่พร้อมใช้งานสำหรับนักพัฒนาแอป ซึ่งเป็นแหล่งที่มาหลัก ของการรับชม
  • การประมวลผล: ระบบจะแปลงประวัติการโทร RPC ดิบเป็นเหตุการณ์การเปลี่ยนแปลงสถานะภายในบล็อกนี้ ซึ่งจะคำนวณผ่านสตรีมของเหตุการณ์ในบันทึก ในการตรวจหาการเปลี่ยนแปลงดังกล่าว คอมโพเนนต์นี้ต้องมีที่เก็บสถานะเพื่อให้สามารถเปรียบเทียบเหตุการณ์ขาเข้าใหม่กับเหตุการณ์ก่อนหน้าเพื่อตรวจหาการเปลี่ยนแปลงได้ กิจกรรมอาจไม่ได้มีข้อมูลที่สนใจทั้งหมดเสมอไป ในกรณีดังกล่าว การบล็อกนี้อาจค้นหาการเรียกไปยังแบ็กเอนด์ตามความจำเป็น
    • พื้นที่เก็บข้อมูลของรัฐ: เฟรมเวิร์กการประมวลผลบางอย่างจะให้ข้อมูลตัวกลางแบบถาวรด้วยตนเอง แต่หากไม่ ก็ต้องการเก็บสถานะไว้เอง เนื่องจากข้อมูลเหล่านี้ควรเป็นข้อมูลเฉพาะของยานพาหนะและประเภทเหตุการณ์ บริการดูแลข้อมูลประเภท K-V จึงจะเหมาะสม
  • ซิงก์ (เหตุการณ์ที่กำหนดเอง): การเปลี่ยนแปลงสถานะที่ตรวจพบควรพร้อมใช้งานสำหรับแอปพลิเคชันหรือบริการใดก็ตามที่อาจได้รับประโยชน์จากซิงก์ ดังนั้น จึงเป็นตัวเลือกปกติในการเผยแพร่เหตุการณ์ที่กำหนดเองนี้ไปยังระบบการแสดงเหตุการณ์สำหรับการบริโภคดาวน์
  • บริการดาวน์สตรีม: โค้ดที่ใช้เหตุการณ์ที่สร้างขึ้นและดำเนินการเฉพาะกับ Use Case ของคุณ

การเลือกบริการ

เมื่อพูดถึงการใช้โซลูชันข้อมูลอ้างอิงสำหรับ "โซลูชัน Fleet ล่าสุด" หรือ "โซลูชันการโดยสารและการนำส่งแบบออนดีมานด์" (จะเปิดตัวช่วงปลายไตรมาสที่ 3 ปี 2023) การเลือกเทคโนโลยีสำหรับ "แหล่งที่มา" และ "อ่างล้าง" นั้น ตรงไปตรงมาเสมอ ในทางกลับกัน "การประมวลผล" มีตัวเลือกที่หลากหลาย โซลูชันข้อมูลอ้างอิงได้เลือกบริการของ Google ดังต่อไปนี้

แผนภาพ : แผนภาพต่อไปนี้แสดงบริการของ Google Cloud เพื่อนำโซลูชันการอ้างอิงไปใช้

การบล็อกการสร้างโซลูชัน การอ้างอิงเหตุการณ์

เลย์เอาต์โปรเจ็กต์ที่อยู่ในระบบคลาวด์

เราขอแนะนําให้คุณตั้งค่าเริ่มต้นเป็นการติดตั้งใช้งานหลายโปรเจ็กต์ ทั้งนี้เพื่อให้การใช้งาน Google Maps Platform และ Google Cloud แยกจากกันได้ชัดเจนและเชื่อมโยงกับวิธีการเรียกเก็บเงินที่คุณเลือก

แหล่งที่มาของเหตุการณ์

"Last Mile Fleet Solution" และ "โซลูชันการโดยสารและการนำส่งแบบออนดีมานด์" เขียนคำขอ API และเพย์โหลดการตอบกลับไปยังการบันทึกบนระบบคลาวด์ Cloud Logging จะส่งบันทึกไปยังบริการที่เลือกอย่างน้อย 1 บริการ การกำหนดเส้นทางไปยัง Cloud Pub/Sub เป็นตัวเลือกที่ยอดเยี่ยมสำหรับที่นี่ ซึ่งช่วยให้แปลงบันทึกเป็นสตรีมเหตุการณ์ได้โดยไม่ต้องเขียนโค้ด

อ่างล้างจาน

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

กำลังประมวลผล

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

  • Cloud Functions เป็นแพลตฟอร์มคำนวณสำหรับรุ่นแรก (*)
    • Serverless เพิ่มและลดขนาดด้วยการควบคุมการปรับขนาดเพื่อจัดการต้นทุน
    • Java เป็นภาษาโปรแกรมเพราะมีความพร้อมใช้งานของไลบรารีไคลเอ็นต์สำหรับ API ที่เกี่ยวข้องกับ Fleet Engine ซึ่งช่วยให้ติดตั้งใช้งานได้ง่าย
  • Cloud Firestore ในฐานะร้านค้าสถานะ
    • ที่เก็บคีย์-ค่าแบบ Serverless
  • Cloud Pub/Sub เป็นจุดผสานรวมที่มีคอมโพเนนต์อัปสตรีมและดาวน์สตรีม
    • จับคู่แบบหลวมๆ แบบเกือบเรียลไทม์

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

*หมายเหตุ: โซลูชันข้อมูลอ้างอิงนี้วางแผนที่จะเปิดตัวการใช้งานทางเลือกที่ช่วยให้เป็นไปตามข้อกำหนดที่แตกต่างกัน

การทำให้ใช้งานได้

เพื่อให้กระบวนการติดตั้งใช้งานโซลูชันการอ้างอิงสามารถทำซ้ำ ปรับแต่งได้ ควบคุมได้ และควบคุมซอร์สโค้ดได้ เราจึงเลือก Terraform เป็นเครื่องมืออัตโนมัติ terform เป็นเครื่องมือ IaC (โครงสร้างพื้นฐานเป็นโค้ด) ที่นิยมใช้กันอย่างแพร่หลาย พร้อมรองรับการใช้งานกับ Google Cloud อย่างสมบูรณ์

โมดูล Terraform

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

โมดูลที่รวมอยู่ในโซลูชันการอ้างอิง:

  • การกำหนดค่าการบันทึก Fleet Engine: ทำการกำหนดค่าที่เกี่ยวข้องกับ Cloud Logging โดยอัตโนมัติเพื่อใช้กับ Fleet Engine ในโซลูชันการอ้างอิง ใช้เพื่อกำหนดเส้นทางบันทึกที่เกี่ยวข้องกับ Fleet Engine ไปยังหัวข้อ Pub/Sub ที่ระบุ
  • การติดตั้งใช้งาน Cloud Fleet Event: มีตัวอย่างการติดตั้งใช้งานโค้ดฟังก์ชัน และยังจัดการการตั้งค่าสิทธิ์แบบอัตโนมัติที่จำเป็นสำหรับการผสานรวมข้ามโปรเจ็กต์ที่ปลอดภัย
  • การติดตั้งใช้งานโซลูชันการอ้างอิงทั้งหมด: เรียกใช้โมดูล 2 รายการก่อนหน้าและรวมโซลูชันทั้งหมด

ความปลอดภัย

มีการนำ IAM มาใช้เพื่อใช้หลักการของสิทธิ์ขั้นต่ำควบคู่ไปกับแนวทางปฏิบัติแนะนำด้านความปลอดภัยของ Google Cloud เช่น การแอบอ้างเป็นบัญชีบริการ อ่านบทความต่อไปนี้เพื่อให้เข้าใจสิ่งที่ Google Cloud นำเสนอเพื่อให้คุณควบคุมการรักษาความปลอดภัยได้มากขึ้น

การดำเนินการถัดไป

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

ภาคผนวก

รวบรวมข้อกำหนดของคุณ

เราขอแนะนำให้คุณรวบรวมข้อกำหนดตั้งแต่เนิ่นๆ

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

  • ข้อมูลใดที่จำเป็นสำหรับสตรีมเหตุการณ์จึงจะมีประโยชน์
    • ผลลัพธ์อาจได้มาจากข้อมูลที่บันทึกไว้หรือในบริการของ Google เพียงอย่างเดียวเท่านั้นหรือไม่ หรือการเพิ่มความสมบูรณ์ให้กับข้อมูลด้วยระบบภายนอกที่ผสานรวมเข้ามานั้นจำเป็นไหม ถ้าใช่ ระบบเหล่านั้นมีอินเทอร์เฟซใด และอินเทอร์เฟซการผสานรวมใด
    • เมตริกที่คุณต้องการวัดในฐานะธุรกิจมีอะไรบ้าง มีคำจำกัดความว่าอย่างไร
    • หากต้องการคำนวณเมตริกข้ามเหตุการณ์ ต้องใช้การรวบรวมข้อมูลประเภทใด พยายามวางเค้าโครงขั้นตอนที่สมเหตุสมผล (เช่น เปรียบเทียบเวลาถึงโดยประมาณ/ATA กับ SLO ในกลุ่มย่อยของกลุ่มอุปกรณ์ในช่วงเวลาที่มีการใช้งานสูงสุดเพื่อคำนวณประสิทธิภาพภายใต้ข้อจำกัดด้านทรัพยากร)
  • เหตุใดคุณจึงสนใจโมเดลที่อิงจากเหตุการณ์หรือสนใจมากกว่าแบบกลุ่ม ฟีเจอร์นี้เป็นไปเพื่อเวลาในการตอบสนองที่ต่ำ (เวลาดำเนินการ) หรือสำหรับการผสานรวมแบบใช้คู่หลวม (ความคล่องตัว)
    • หากเวลาในการตอบสนองต่ำ ให้ระบุว่า "ต่ำ" นาที วินาที วินาทีย่อย และเวลาในการตอบสนอง เท่าใด
  • คุณเคยลงทุนใน Technology Stack และทักษะที่เกี่ยวข้องในฐานะทีมไหม หากใช่ ผลิตภัณฑ์ดังกล่าวคืออะไรและมีฟีเจอร์การผสานรวมอะไรบ้าง
    • มีข้อกำหนดใดที่ระบบปัจจุบันของคุณทำไม่ได้หรืออาจประสบความยุ่งยากเมื่อประมวลผลเหตุการณ์ที่มาจากกลุ่มอุปกรณ์ของคุณไหม

หลักการออกแบบ

การติดตามกระบวนการคิดมีดังนี้ วิธีนี้จะช่วยให้ตัดสินใจเกี่ยวกับการออกแบบได้สอดคล้องกัน โดยเฉพาะอย่างยิ่งเมื่อคุณมีตัวเลือกที่หลากหลายให้เลือก

  • กำหนดให้ใช้ตัวเลือกที่ง่ายกว่า
  • ค่าเริ่มต้นคือ Time-to-Value ที่สั้นลง เขียนโค้ดน้อยลง เส้นโค้งการเรียนรู้ต่ำลง
  • สำหรับเวลาในการตอบสนองและประสิทธิภาพ ให้มุ่งทำให้ได้ตามขอบเขตที่คุณกำหนดไว้ ไม่ใช่การเพิ่มประสิทธิภาพสูงสุด นอกจากนี้ ให้หลีกเลี่ยงการเพิ่มประสิทธิภาพแบบสุดโต่งเนื่องจากมักจะนำไปสู่การเพิ่มความซับซ้อน
  • ต้นทุนก็เช่นกัน รักษาราคาให้สมเหตุสมผล คุณอาจยังไม่ได้ตัดสินใจใช้บริการที่มีมูลค่าสูงแต่ราคาค่อนข้างแพง
  • ในระยะทดลอง การลดขนาดมีความสำคัญพอๆ กับการเพิ่มทรัพยากร ลองนึกถึงแพลตฟอร์มที่ให้ความยืดหยุ่นในการปรับขนาดด้วยการเพิ่มขีดจำกัดและลดขนาดลง (ตามหลักแล้วคือ 0) เพื่อให้คุณไม่ต้องเสียเงินไปโดยไม่ทำอะไรเลย ประสิทธิภาพระดับสูงที่มีโครงสร้างพื้นฐานที่เปิดตลอดเวลาจะนำมาพิจารณาในภายหลังได้เมื่อคุณมีความมั่นใจในความต้องการของระบบ
  • สังเกตและวัดผลเพื่อให้คุณระบุจุดที่ควรปรับปรุงในภายหลังได้
  • เชื่อมต่อบริการให้หลวม เพราะช่วยให้สลับอุปกรณ์ทีละรายการได้ง่ายขึ้น
  • สุดท้ายแต่ไม่ท้ายสุด การรักษาความปลอดภัยต้องไม่หลุดโฟกัส เนื่องจากเป็นบริการที่ทำงานบนสภาพแวดล้อมระบบคลาวด์สาธารณะ จึงไม่สามารถเข้าถึงระบบที่ไม่ปลอดภัยได้

แนวคิดเกี่ยวกับสตรีมมิง

หากคุณยังไม่คุ้นเคยกับเหตุการณ์หรือสตรีมมิง มีแนวคิดสำคัญที่ควรทราบไว้ ซึ่งบางแนวคิดอาจแตกต่างจากการประมวลผลแบบกลุ่ม

  • การปรับขนาด : ตรงข้ามกับการประมวลผลแบบกลุ่ม ที่ปกติแล้วคุณพอจะมีแนวคิดที่ดีเกี่ยวกับปริมาณข้อมูลที่ต้องประมวลผลแต่ทำไม่ได้ในการสตรีม การจราจรติดขัดในเมืองอาจทำให้เกิดเหตุการณ์ต่างๆ มากมายอย่างฉับพลันจากพื้นที่ใดพื้นที่หนึ่ง และคุณยังคงต้องประมวลผลเหตุการณ์นั้นให้ได้
  • กรอบเวลา : แทนที่จะประมวลผลเหตุการณ์ทีละรายการ คุณต้องจัดกลุ่มเหตุการณ์บนไทม์ไลน์เป็น "หน้าต่าง" เล็กลงเป็นหน่วยเพื่อการคำนวณ มีกลยุทธ์กรอบเวลาต่างๆ เช่น "กรอบเวลาคงที่ (เช่น ทุกวันตามปฏิทิน)" "หน้าต่างเลื่อน (5 นาทีที่ผ่านมา)" "กรอบเวลาเซสชัน (ระหว่างการเดินทาง)" ซึ่งคุณควรเลือกใช้ ยิ่งระยะเวลาทำงานนานขึ้น ก็ยิ่งได้ผลลัพธ์ล่าช้า เลือกโมเดลและการกำหนดค่าที่เหมาะสมซึ่งตรงกับความต้องการของคุณ
  • การทริกเกอร์ : มีกรณีที่คุณไม่มีทางเลือกอื่นนอกจากกรอบเวลาที่นานขึ้น อย่างไรก็ตาม คุณไม่ควรรอจนถึงช่วงท้ายของกรอบเวลาเพื่อสร้างเหตุการณ์ แต่ให้ปล่อยผลลัพธ์ระดับกลางแทน แนวคิดนี้นําไปใช้กับกรณีการใช้งานที่เป็นค่า ในการแสดงผลลัพธ์อย่างรวดเร็วก่อน แล้วค่อยแก้ไขในภายหลัง ลองนึกภาพการส่งสถานะขั้นกลางที่ 25%, 50% หรือ 75% ของการแสดงโฆษณา
  • การจัดลำดับ : เหตุการณ์ไม่จำเป็นต้องส่งไปถึงระบบตามลำดับที่ระบบสร้างขึ้น โดยเฉพาะอย่างยิ่งสำหรับกรณีการใช้งานที่เกี่ยวข้องกับการสื่อสารผ่านเครือข่ายมือถือที่เพิ่มความล่าช้าและเส้นทางการกำหนดเส้นทางที่ซับซ้อน คุณต้องตระหนักถึงความแตกต่างระหว่าง "เวลาของกิจกรรม" (เมื่อเหตุการณ์เกิดขึ้นจริง) และ "เวลาประมวลผล" (เมื่อเหตุการณ์มาถึงระบบ) และจัดการกับเหตุการณ์ได้สอดคล้องกัน โดยทั่วไป คุณต้องประมวลผลเหตุการณ์ตาม "เวลาของกิจกรรม"
  • การส่งข้อความ - ส่งเพียงครั้งเดียวเทียบกับครั้งเดียว: แพลตฟอร์มกิจกรรมที่ต่างกันมีการรองรับแพลตฟอร์มเหล่านี้ต่างกัน คุณต้องลองใช้กลยุทธ์การลองอีกครั้งหรือการกรองข้อมูลที่ซ้ำกันออก ทั้งนี้ขึ้นอยู่กับกรณีการใช้งานของคุณ
  • ความสมบูรณ์ : โอกาสที่ข้อความจะสูญหายก็เช่นเดียวกับการเปลี่ยนแปลงคำสั่งซื้อ ซึ่งอาจเป็นเพราะมีการปิดแอปพลิเคชันและอุปกรณ์เนื่องจากอายุการใช้งานแบตเตอรี่ของอุปกรณ์ ความเสียหายกับโทรศัพท์โดยไม่เจตนา ขาดการเชื่อมต่อขณะอยู่ในอุโมงค์ หรือข้อความที่ได้รับนอกหน้าต่างที่ยอมรับได้เท่านั้น ความไม่สมบูรณ์จะส่งผลต่อผลลัพธ์อย่างไร

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

ผู้ร่วมให้ข้อมูล

Google เป็นผู้ดูแลเอกสารนี้ ผู้เขียนต่อไปนี้เป็นคนเขียน

ผู้เขียนหลัก:

  • Mary Pishny | ผู้จัดการผลิตภัณฑ์ ของ Google Maps Platform
  • Ethel Bao| วิศวกรซอฟต์แวร์ ของ Google Maps Platform
  • Mohanad Almiski | วิศวกรซอฟต์แวร์ของ Google Maps Platform
  • Naoya Moritani | วิศวกรโซลูชันของ Google Maps Platform