BigQuery ของ Google ทำให้การวิเคราะห์ข้อมูลเป็นประชาธิปไตยได้อย่างไร ส่วนที่ 2

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

อ่านส่วนแรก

การจัดการข้อมูล

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

เพื่อค้นหาและจัดการข้อมูล เราได้ขยาย Data Access Layer ของเราเป็น DAL) เพื่อจัดเตรียมเครื่องมือสำหรับทั้งข้อมูลในองค์กรและข้อมูล Google Cloud โดยมีอินเทอร์เฟซและ API เดียวสำหรับผู้ใช้ของเรา ในฐานะกูเกิล แค็ตตาล็อกข้อมูล กำลังก้าวไปสู่ความพร้อมใช้งานทั่วไป เราจะรวมไว้ในโปรเจ็กต์ของเราเพื่อมอบฟีเจอร์ต่างๆ ให้กับผู้ใช้ เช่น การค้นหาคอลัมน์

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

• การแชร์แบบจำกัดโดเมน: คุณลักษณะเบต้าเพื่อป้องกันไม่ให้ผู้ใช้แชร์ชุดข้อมูล BigQuery กับผู้ใช้ภายนอก Twitter
• การควบคุมบริการ VPC: การควบคุมที่ป้องกันการขโมยข้อมูลและกำหนดให้ผู้ใช้เข้าถึง BigQuery จากช่วงที่อยู่ IP ที่รู้จัก

เราได้ใช้ข้อกำหนดการรับรองความถูกต้อง การอนุญาต และการตรวจสอบ (AAA) เพื่อความปลอดภัยดังต่อไปนี้:

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

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

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

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

• ชุดข้อมูลที่ละเอียดอ่อนสูงจะพร้อมใช้งานตามความจำเป็นโดยยึดหลักการของสิทธิ์ขั้นต่ำ ชุดข้อมูลแต่ละชุดมีกลุ่มผู้อ่านแยกกัน และเราจะติดตามการใช้งานตามแต่ละบัญชี
• ชุดข้อมูลที่มีความอ่อนไหวปานกลาง (นามแฝงทางเดียวที่ใช้การแฮชแบบเค็ม) ไม่มีข้อมูลส่วนบุคคลที่สามารถระบุตัวตนได้ (PII) และพนักงานกลุ่มใหญ่สามารถเข้าถึงได้ นี่เป็นความสมดุลที่ดีระหว่างข้อกังวลด้านความเป็นส่วนตัวและยูทิลิตี้ข้อมูล ช่วยให้พนักงานสามารถดำเนินการวิเคราะห์ได้ เช่น การคำนวณจำนวนผู้ใช้ที่ใช้ฟีเจอร์ โดยไม่รู้ว่าใครคือผู้ใช้จริง
• ชุดข้อมูลความไวต่ำพร้อมข้อมูลการระบุผู้ใช้ทั้งหมด นี่เป็นแนวทางที่ดีจากมุมมองความเป็นส่วนตัว แต่ไม่สามารถใช้สำหรับการวิเคราะห์ระดับผู้ใช้ได้
• ชุดข้อมูลสาธารณะ (เผยแพร่นอก Twitter) มีให้สำหรับพนักงาน Twitter ทุกคน

สำหรับการบันทึก เราใช้งานตามกำหนดเวลาเพื่อระบุชุดข้อมูล BigQuery และลงทะเบียนกับ Data Access Layer (DAL) ที่เก็บข้อมูลเมตาของ Twitter ผู้ใช้จะใส่คำอธิบายประกอบชุดข้อมูลด้วยข้อมูลส่วนบุคคลและระบุระยะเวลาการเก็บรักษาด้วย สำหรับการทำความสะอาด เราประเมินประสิทธิภาพและราคาของสองตัวเลือก: 1. การล้างชุดข้อมูลใน GCS โดยใช้เครื่องมืออย่าง Scalding และโหลดลงใน BigQuery 2. การใช้คำสั่ง BigQuery DML เรามีแนวโน้มที่จะใช้ทั้งสองวิธีร่วมกันเพื่อตอบสนองความต้องการของกลุ่มและข้อมูลที่แตกต่างกัน

การทำงานของระบบ

เนื่องจาก BigQuery เป็นบริการที่มีการจัดการ จึงไม่จำเป็นต้องให้ทีม SRE ของ Twitter เข้ามามีส่วนร่วมในการจัดการระบบหรือหน้าที่โต๊ะ เป็นเรื่องง่ายที่จะเพิ่มความจุให้กับทั้งการจัดเก็บข้อมูลและการประมวลผล เราสามารถเปลี่ยนแปลงการจองช่องได้โดยสร้างตั๋วกับฝ่ายสนับสนุนของ Google เราระบุส่วนที่สามารถปรับปรุงได้ เช่น การจัดสรรช่องบริการตนเองและการปรับปรุงแดชบอร์ดสำหรับการตรวจสอบ และส่งคำขอเหล่านั้นไปยัง Google

ค่าใช้จ่ายของ

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

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

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

ขั้นตอนถัดไป

เราได้เห็นความสนใจอย่างมากใน BigQuery นับตั้งแต่เปิดตัวรุ่นอัลฟ่า เรากำลังเพิ่มชุดข้อมูลและคำสั่งเพิ่มเติมให้กับ BigQuery เราพัฒนาตัวเชื่อมต่อสำหรับเครื่องมือวิเคราะห์ข้อมูล เช่น Scalding เพื่ออ่านและเขียนไปยังพื้นที่เก็บข้อมูล BigQuery เรากำลังพิจารณาเครื่องมืออย่าง Looker และ Apache Zeppelin สำหรับสร้างรายงานและบันทึกคุณภาพระดับองค์กรโดยใช้ชุดข้อมูล BigQuery

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

ต่อไปนี้คือคำขอคุณลักษณะที่มีลำดับความสำคัญสูงบางส่วนของเราสำหรับ Google:

• เครื่องมือสำหรับการรับข้อมูลที่สะดวกและรองรับรูปแบบ LZO-Thrift
• การแบ่งส่วนรายชั่วโมง
• การปรับปรุงการควบคุมการเข้าถึง เช่น สิทธิ์ระดับตาราง แถว และคอลัมน์
• BigQuery แหล่งข้อมูลภายนอก ด้วยการรวม Hive Metastore และรองรับรูปแบบ LZO-Thrift
• ปรับปรุงการผสานรวมแคตตาล็อกข้อมูลในอินเทอร์เฟซผู้ใช้ BigQuery
• บริการตนเองสำหรับการจัดสรรและติดตามสล็อต

ข้อสรุป

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

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

โดยรวมแล้ว BigQuery ทำงานได้ดีสำหรับการวิเคราะห์ SQL ทั่วไป เราเห็นความสนใจอย่างมากใน BigQuery และเรากำลังดำเนินการเพื่อย้ายชุดข้อมูลมากขึ้น ดึงดูดทีมมากขึ้น และสร้างไปป์ไลน์เพิ่มเติมด้วย BigQuery Twitter ใช้ข้อมูลที่หลากหลายซึ่งจะต้องมีเครื่องมือหลายอย่างรวมกัน เช่น Scalding, Spark, Presto และ Druid เราตั้งใจที่จะเสริมความแข็งแกร่งให้กับเครื่องมือวิเคราะห์ข้อมูลของเราต่อไป และให้คำแนะนำที่ชัดเจนแก่ผู้ใช้ของเราเกี่ยวกับวิธีใช้ข้อเสนอของเราให้เกิดประโยชน์สูงสุด

คำขอบคุณ

ฉันขอขอบคุณผู้เขียนร่วมและเพื่อนร่วมทีม Anju Jha และ Will Pascucci สำหรับความร่วมมือที่ยอดเยี่ยมและการทำงานหนักในโครงการนี้ ฉันขอขอบคุณวิศวกรและผู้จัดการจากหลายทีมของ Twitter และ Google ที่ช่วยเหลือเราและผู้ใช้ BigQuery บน Twitter ที่ให้ข้อเสนอแนะอันมีค่า

หากคุณสนใจที่จะแก้ไขปัญหาเหล่านี้ ลองดูของเรา ตำแหน่งงานว่าง ในทีมแพลตฟอร์มข้อมูล

คุณภาพข้อมูลใน DWH - ความสอดคล้องของคลังข้อมูล

ที่มา: will.com