พลิกโฉมแนวทางของ Sprout Social สู่ข้อมูลขนาดใหญ่

Sprout Social เป็นบริษัทที่ขับเคลื่อนด้วยข้อมูล Sprout ประมวลผลข้อความหลายพันล้านข้อความจากเครือข่ายโซเชียลต่างๆ ทุกวัน ด้วยเหตุนี้ วิศวกรของ Sprout จึงเผชิญกับความท้าทายที่ไม่เหมือนใคร นั่นคือวิธีจัดเก็บและอัปเดตข้อความเดียวกันหลายเวอร์ชัน (เช่น รีทวีต แสดงความคิดเห็น ฯลฯ) ที่เข้ามาในแพลตฟอร์มของเราในปริมาณที่สูงมาก

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

ตัวอย่างเช่น การติดตามการถูกใจ การแสดงความคิดเห็น และการรีทวีตของโพสต์ Twitter เดียว ในอดีต เราพึ่งพาคลัสเตอร์ Hadoop ที่จัดการด้วยตนเองในการบำรุงรักษาและทำงานผ่านข้อมูลจำนวนมากเช่นนี้ แต่ละคลัสเตอร์ Hadoop จะรับผิดชอบส่วนต่าง ๆ ของแพลตฟอร์ม Sprout ซึ่งเป็นวิธีปฏิบัติที่ทีมวิศวกรรมของ Sprout ใช้ร่วมกันเพื่อจัดการโครงการข้อมูลขนาดใหญ่ตามขนาด

กุญแจสู่แนวทางข้อมูลขนาดใหญ่ของ Sprout

ระบบนิเวศ Hadoop ของเราขึ้นอยู่กับ Apache Hbase ซึ่งเป็นฐานข้อมูล NoSQL ที่ปรับขนาดได้และกระจายได้ สิ่งที่ทำให้ Hbase มีความสำคัญต่อแนวทางของเราในการประมวลผลข้อมูลขนาดใหญ่คือความสามารถที่ไม่เพียงแต่ทำการสแกนช่วงอย่างรวดเร็วทั่วทั้งชุดข้อมูลเท่านั้น แต่ยังทำการค้นหาเรกคอร์ดเดียวที่รวดเร็ว สุ่มอีกด้วย

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

เพื่อช่วยลดระยะเวลาที่มาจากการจัดการระบบเหล่านี้ด้วยข้อมูลหลายร้อยเทราไบต์ ทีมโครงสร้างพื้นฐานและการพัฒนาของ Sprout จึงมารวมตัวกันเพื่อหาทางออกที่ดีกว่าการเรียกใช้คลัสเตอร์ Hadoop ที่จัดการด้วยตนเอง เป้าหมายของเราคือ:

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

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

การประเมินทางเลือกรูปแบบข้อมูลใหม่

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

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

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

ลดค่าใช้จ่ายและการบำรุงรักษาด้วย AWS EMR

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

นี่คือตอนที่เราเริ่มประเมินบริการที่มีการจัดการ Elastic Map Reduce (EMR) ของ Amazon สำหรับ Hbase การประเมิน EMR จำเป็นต้องมีการประเมินประสิทธิภาพในลักษณะเดียวกับที่เราทดสอบคลังข้อมูลและทะเลสาบ เช่น การทดสอบการนำเข้าข้อมูลเพื่อดูว่าสามารถตอบสนองความต้องการด้านประสิทธิภาพของเราได้หรือไม่ เรายังต้องทดสอบการจัดเก็บข้อมูล ความพร้อมใช้งานสูง และการกู้คืนระบบเพื่อให้แน่ใจว่า EMR เหมาะสมกับความต้องการของเราจากมุมมองด้านโครงสร้างพื้นฐาน/การดูแลระบบ

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

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

กระบวนการย้ายข้อมูลได้รับการทดสอบล่วงหน้าอย่างง่ายดายและดำเนินการเพื่อย้ายข้อมูลหลายพันล้านรายการไปยังคลัสเตอร์ EMR ใหม่โดยที่ลูกค้าไม่ต้องหยุดทำงาน คลัสเตอร์ใหม่แสดงประสิทธิภาพที่ดีขึ้นและลดต้นทุนได้เกือบ 40% หากต้องการอ่านเพิ่มเติมเกี่ยวกับวิธีที่การย้ายไปยัง EMR ช่วยลดต้นทุนโครงสร้างพื้นฐานและปรับปรุงประสิทธิภาพของเรา โปรดดูกรณีศึกษาของ Sprout Social กับ AWS

สิ่งที่เราได้เรียนรู้

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

หากคุณสนใจในสิ่งที่เรากำลังสร้าง เข้าร่วมทีมของเราและสมัครในตำแหน่งงานวิศวกรรมแบบเปิดของเราวันนี้