เฮ้ ฮาเบอร์! การลงทะเบียนสำหรับสตรีมหลักสูตรใหม่เปิดอยู่ที่ OTUS ในขณะนี้ . ในความคาดหมายของการเริ่มหลักสูตร เราได้เตรียมการแปลเนื้อหาที่น่าสนใจสำหรับคุณตามธรรมเนียม
ทุกๆ วัน ผู้คนมากกว่าหนึ่งร้อยล้านคนเข้าเยี่ยมชม Twitter เพื่อดูว่าเกิดอะไรขึ้นในโลกและหารือเกี่ยวกับเรื่องนี้ ทวีตแต่ละรายการและการกระทำอื่นๆ ของผู้ใช้จะสร้างเหตุการณ์ที่พร้อมสำหรับการวิเคราะห์ข้อมูลภายในภายใน Twitter พนักงานหลายร้อยคนวิเคราะห์และแสดงภาพข้อมูลนี้ และการปรับปรุงประสบการณ์ของพวกเขาถือเป็นสิ่งสำคัญสูงสุดสำหรับทีมแพลตฟอร์มข้อมูลของ Twitter
เราเชื่อว่าผู้ใช้ที่มีทักษะด้านเทคนิคที่หลากหลายควรจะสามารถค้นหาข้อมูลและสามารถเข้าถึงเครื่องมือการวิเคราะห์และการแสดงภาพโดยใช้ SQL ที่ทำงานได้ดี สิ่งนี้จะช่วยให้ผู้ใช้กลุ่มใหม่ที่มีเทคนิคน้อย รวมถึงนักวิเคราะห์ข้อมูลและผู้จัดการผลิตภัณฑ์ สามารถดึงข้อมูลเชิงลึกจากข้อมูลได้ ทำให้พวกเขาเข้าใจและใช้พลังของ Twitter ได้ดีขึ้น นี่คือวิธีที่เราทำให้การวิเคราะห์ข้อมูลบน Twitter เป็นประชาธิปไตย
เนื่องจากเครื่องมือและความสามารถของเราในการวิเคราะห์ข้อมูลภายในได้รับการปรับปรุง เราจึงได้เห็นการปรับปรุงบริการ Twitter อย่างไรก็ตาม ยังมีช่องว่างสำหรับการปรับปรุง เครื่องมือในปัจจุบัน เช่น Scalding จำเป็นต้องมีประสบการณ์ในการเขียนโปรแกรม เครื่องมือวิเคราะห์ที่ใช้ SQL เช่น Presto และ Vertica มีปัญหาด้านประสิทธิภาพในวงกว้าง นอกจากนี้เรายังประสบปัญหาในการกระจายข้อมูลไปยังหลายระบบโดยไม่มีการเข้าถึงข้อมูลอย่างต่อเนื่อง
ปีที่แล้วเราได้ประกาศ ซึ่งภายในนั้นเราถ่ายโอนส่วนต่างๆ ของเรา บนแพลตฟอร์ม Google Cloud (GCP) เราสรุปได้ว่าเครื่องมือของ Google Cloud สามารถช่วยเราได้ในการริเริ่มเพื่อทำให้การวิเคราะห์ การแสดงภาพ และการเรียนรู้ของเครื่องบน Twitter เป็นประชาธิปไตย:
- : คลังข้อมูลองค์กรที่ใช้โปรแกรม SQL ซึ่งขึ้นชื่อในด้านความเร็ว ความเรียบง่าย และการรับมือด้วย .
- เครื่องมือสร้างภาพข้อมูลขนาดใหญ่พร้อมคุณสมบัติการทำงานร่วมกันเช่น Google เอกสาร
ในบทความนี้ คุณจะได้เรียนรู้เกี่ยวกับประสบการณ์ของเรากับเครื่องมือเหล่านี้: สิ่งที่เราได้ทำไปแล้ว สิ่งที่เราได้เรียนรู้ และสิ่งที่เราจะทำต่อไป ตอนนี้เราจะมุ่งเน้นไปที่การวิเคราะห์แบบกลุ่มและเชิงโต้ตอบ การวิเคราะห์แบบเรียลไทม์จะกล่าวถึงในบทความถัดไป
ประวัติความเป็นมาของคลังข้อมูลบน Twitter
ก่อนที่จะเจาะลึก BigQuery การเล่าประวัติคลังข้อมูลบน Twitter ให้ฟังสั้นๆ นั้นคุ้มค่า ในปี 2011 การวิเคราะห์ข้อมูล Twitter ได้ดำเนินการใน Vertica และ Hadoop ในการสร้างงาน MapReduce Hadoop เราใช้ Pig ในปี 2012 เราได้แทนที่ Pig ด้วย Scalding ซึ่งมี Scala API พร้อมคุณประโยชน์ต่างๆ เช่น ความสามารถในการสร้างไปป์ไลน์ที่ซับซ้อนและความง่ายในการทดสอบ อย่างไรก็ตาม สำหรับนักวิเคราะห์ข้อมูลและผู้จัดการผลิตภัณฑ์จำนวนมากที่คุ้นเคยกับการใช้งาน SQL มากกว่า ถือเป็นช่วงการเรียนรู้ที่ค่อนข้างชัน ประมาณปี 2016 เราเริ่มใช้ Presto เป็นส่วนหน้า SQL สำหรับข้อมูล Hadoop Spark นำเสนออินเทอร์เฟซ Python ซึ่งทำให้เป็นตัวเลือกที่ดีสำหรับวิทยาศาสตร์ข้อมูลเฉพาะกิจและการเรียนรู้ของเครื่อง
ตั้งแต่ปี 2018 เราได้ใช้เครื่องมือต่อไปนี้สำหรับการวิเคราะห์ข้อมูลและการแสดงภาพ:
- การลวกสำหรับสายการผลิต
- Scalding และ Spark สำหรับการวิเคราะห์ข้อมูลเฉพาะกิจและการเรียนรู้ของเครื่อง
- Vertica และ Presto สำหรับการวิเคราะห์ SQL แบบเฉพาะกิจและเชิงโต้ตอบ
- Druid สำหรับการเข้าถึงเมตริกอนุกรมเวลาเชิงโต้ตอบ เชิงสำรวจ และมีเวลาแฝงต่ำ
- Tableau, Zeppelin และ Pivot สำหรับการแสดงข้อมูล
เราพบว่าแม้ว่าเครื่องมือเหล่านี้จะนำเสนอฟีเจอร์ที่ทรงพลังมาก แต่เราประสบปัญหาในการทำให้ฟีเจอร์เหล่านี้พร้อมใช้งานสำหรับผู้ชมในวงกว้างบน Twitter ด้วยการขยายแพลตฟอร์มของเราด้วย Google Cloud เรากำลังมุ่งเน้นไปที่การทำให้เครื่องมือวิเคราะห์ของเราง่ายขึ้นสำหรับ Twitter ทั้งหมด
คลังข้อมูล BigQuery ของ Google
หลายทีมที่ Twitter ได้รวม BigQuery ไว้ในขั้นตอนการผลิตบางส่วนแล้ว จากประสบการณ์ของพวกเขา เราเริ่มประเมินความเป็นไปได้ของ BigQuery สำหรับกรณีการใช้งาน Twitter ทั้งหมด เป้าหมายของเราคือการเสนอ BigQuery ให้กับทั้งบริษัท และเพื่อสร้างมาตรฐานและสนับสนุนภายในชุดเครื่องมือ Data Platform นี่เป็นเรื่องยากด้วยเหตุผลหลายประการ เราจำเป็นต้องพัฒนาโครงสร้างพื้นฐานเพื่อรับข้อมูลจำนวนมากได้อย่างน่าเชื่อถือ สนับสนุนการจัดการข้อมูลทั่วทั้งบริษัท รับประกันการควบคุมการเข้าถึงที่เหมาะสม และรับประกันความเป็นส่วนตัวของลูกค้า นอกจากนี้เรายังต้องสร้างระบบสำหรับการจัดสรรทรัพยากร การตรวจสอบ และการปฏิเสธการชำระเงินเพื่อให้ทีมใช้ BigQuery ได้อย่างมีประสิทธิภาพ
ในเดือนพฤศจิกายน 2018 เราได้เปิดตัว BigQuery และ Data Studio รุ่นอัลฟ่าสำหรับทั้งบริษัท เราได้นำเสนอสเปรดชีตที่มีการล้างข้อมูลส่วนบุคคลซึ่งมีการใช้งานมากที่สุดแก่เจ้าหน้าที่ Twitter BigQuery มีผู้ใช้มากกว่า 250 รายจากทีมต่างๆ รวมถึงวิศวกรรม การเงิน และการตลาด ล่าสุด มีการเรียกใช้คำขอประมาณ 8 รายการ โดยประมวลผลประมาณ 100 PB ต่อเดือน ไม่นับคำขอที่กำหนดเวลาไว้ หลังจากได้รับผลตอบรับเชิงบวกอย่างมาก เราจึงตัดสินใจก้าวไปข้างหน้าและเสนอ BigQuery เป็นแหล่งข้อมูลหลักสำหรับการโต้ตอบกับข้อมูลบน Twitter
นี่คือแผนภาพของสถาปัตยกรรมระดับสูงของคลังข้อมูล Google BigQuery ของเรา
เราคัดลอกข้อมูลจากคลัสเตอร์ Hadoop ในเครื่องไปยัง Google Cloud Storage (GCS) โดยใช้เครื่องมือ Cloud Replicator ภายใน จากนั้นเราใช้ Apache Airflow เพื่อสร้างไปป์ไลน์ที่ใช้ "» เพื่อโหลดข้อมูลจาก GCS เข้าสู่ BigQuery เราใช้ Presto เพื่อสืบค้นชุดข้อมูล Parquet หรือ Thrift-LZO ใน GCS BQ Blaster เป็นเครื่องมือ Scalding ภายในสำหรับการโหลดชุดข้อมูล HDFS Vertica และ Thrift-LZO ลงใน BigQuery
ในส่วนต่อไปนี้ เราจะหารือเกี่ยวกับแนวทางและความเชี่ยวชาญของเราในด้านความง่ายในการใช้งาน ประสิทธิภาพ การจัดการข้อมูล ความสมบูรณ์ของระบบ และต้นทุน
ใช้งานง่าย
เราพบว่าผู้ใช้เริ่มต้นใช้งาน BigQuery ได้ง่าย เนื่องจากไม่จำเป็นต้องติดตั้งซอฟต์แวร์ และผู้ใช้สามารถเข้าถึงได้ผ่านอินเทอร์เฟซเว็บที่ใช้งานง่าย อย่างไรก็ตาม ผู้ใช้จำเป็นต้องทำความคุ้นเคยกับฟีเจอร์และแนวคิดบางอย่างของ GCP รวมถึงทรัพยากร เช่น โปรเจ็กต์ ชุดข้อมูล และตาราง เราได้พัฒนาบทช่วยสอนและบทช่วยสอนเพื่อช่วยให้ผู้ใช้เริ่มต้นได้ เมื่อได้รับความเข้าใจพื้นฐานแล้ว ผู้ใช้จะไปยังส่วนต่างๆ ของชุดข้อมูล ดูสคีมาและข้อมูลตาราง เรียกใช้คำสั่งง่ายๆ และแสดงภาพผลลัพธ์ใน Data Studio ได้อย่างง่ายดาย
เป้าหมายของเราในการป้อนข้อมูลใน BigQuery คือเพื่อให้โหลดชุดข้อมูล HDFS หรือ GCS ได้อย่างราบรื่นด้วยการคลิกเพียงครั้งเดียว เราพิจารณาแล้ว (จัดการโดย Airflow) แต่ไม่สามารถใช้งานได้เนื่องจากโมเดลความปลอดภัย "การแชร์โดเมนแบบจำกัด" ของเรา (เพิ่มเติมเกี่ยวกับเรื่องนี้ในส่วนการจัดการข้อมูลด้านล่าง) เราทดลองโดยใช้ Google Data Transfer Service (DTS) เพื่อจัดระเบียบงานโหลด BigQuery แม้ว่า DTS จะตั้งค่าได้อย่างรวดเร็ว แต่ก็ไม่ยืดหยุ่นสำหรับการสร้างไปป์ไลน์ที่มีการพึ่งพา สำหรับรุ่นอัลฟ่าของเรา เราได้สร้างสภาพแวดล้อม Apache Airflow ของเราเองใน GCE และกำลังเตรียมการสำหรับการผลิตและความสามารถในการรองรับแหล่งข้อมูลเพิ่มเติม เช่น Vertica
หากต้องการแปลงข้อมูลเป็น BigQuery ผู้ใช้จะสร้างไปป์ไลน์ข้อมูล SQL แบบง่ายโดยใช้การค้นหาตามกำหนดเวลา สำหรับไปป์ไลน์แบบหลายขั้นตอนที่ซับซ้อนที่มีการขึ้นต่อกัน เราวางแผนที่จะใช้เฟรมเวิร์ก Airflow หรือ Cloud Composer ของเราเองร่วมกับ .
การปฏิบัติ
BigQuery ได้รับการออกแบบมาเพื่อการค้นหา SQL ทั่วไปที่ประมวลผลข้อมูลจำนวนมาก ไม่ได้ออกแบบมาสำหรับการสืบค้นที่มีเวลาแฝงต่ำ ปริมาณงานสูงที่ต้องการโดยฐานข้อมูลธุรกรรม หรือการวิเคราะห์อนุกรมเวลาเวลาแฝงต่ำที่นำมาใช้ . สำหรับการสืบค้นเชิงวิเคราะห์เชิงโต้ตอบ ผู้ใช้ของเราคาดว่าเวลาตอบสนองจะน้อยกว่าหนึ่งนาที เราต้องออกแบบการใช้ BigQuery ให้ตรงตามความคาดหวังเหล่านี้ เพื่อให้ผู้ใช้ของเราได้รับประสิทธิภาพที่คาดการณ์ได้ เราได้ใช้ฟังก์ชัน BigQuery ซึ่งพร้อมให้บริการแก่ลูกค้าโดยมีค่าธรรมเนียมคงที่ ซึ่งช่วยให้เจ้าของโปรเจ็กต์จองช่องขั้นต่ำสำหรับการค้นหาของตนได้ BigQuery คือหน่วยของพลังการประมวลผลที่จำเป็นในการดำเนินการค้นหา SQL
เราวิเคราะห์คำค้นหามากกว่า 800 รายการที่ประมวลผลข้อมูลประมาณ 1 TB ในแต่ละครั้ง และพบว่าเวลาดำเนินการโดยเฉลี่ยอยู่ที่ 30 วินาที นอกจากนี้เรายังได้เรียนรู้ว่าประสิทธิภาพนั้นขึ้นอยู่กับการใช้สล็อตของเราในโครงการและงานต่างๆ เราต้องแยกการสำรองช่องการผลิตและช่องเฉพาะกิจอย่างชัดเจน เพื่อรักษาประสิทธิภาพสำหรับกรณีการใช้งานจริงและการวิเคราะห์เชิงโต้ตอบ สิ่งนี้มีอิทธิพลอย่างมากต่อการออกแบบของเราสำหรับการจองสล็อตและลำดับชั้นของโครงการ
เราจะพูดถึงการจัดการข้อมูล ฟังก์ชันการทำงาน และต้นทุนของระบบในอีกไม่กี่วันข้างหน้าในส่วนที่สองของการแปล และตอนนี้เราขอเชิญชวนทุกคน ซึ่งคุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับหลักสูตรนี้ ตลอดจนถามคำถามกับผู้เชี่ยวชาญของเรา - Egor Mateshuk (วิศวกรข้อมูลอาวุโส, MaximaTelecom)
อ่านเพิ่มเติม:
ที่มา: will.com