ในโลกที่สมบูรณ์แบบของนักวิศวกรสถาปัตยกรรมจะสวยงามเสมอ ในโลกที่แท้จริงของระบบขนาดใหญ่คุณต้องทําข้อบกพร่อง หนึ่งในปัญหาพื้นฐานที่นักวิศวกรต้องคิดเกี่ยวกับในตอนเริ่มต้นคือความชั่วร้าย trade-off between Write Speed and Read Speed. แต่ในกรณีของเราการทํางานกับ petabytes ของข้อมูลใน AWS ความเสียหายนี้ไม่ได้ส่งผลกระทบต่อความเร็วของเรา . wallet เราสร้างระบบที่เขียนข้อมูลได้อย่างสมบูรณ์แบบ แต่ทุกครั้งที่มันอ่านจากสถาปัตยกรรมมันเผาผ่านงบประมาณในวิธีที่เจ็บปวดที่สุดที่สามารถจินตนาการได้ หลังจากที่ทั้งหมดการอ่าน petabytes จาก AWS ค่าใช้จ่ายเงินสําหรับการถ่ายโอนข้อมูลจํานวนคําขอและการค้นหาชั้นเก็บข้อมูล... เงินจํานวนมาก! นี่คือเรื่องราวของวิธีการที่เราได้เพิ่มประสิทธิภาพเพื่อให้มีประสิทธิภาพและมีประสิทธิภาพในราคา! ส่วนหนึ่ง 0: วิธีที่เราสิ้นสุดใช้ $ 100,000 ในค่าธรรมเนียม AWS! เรื่องจริง: ไม่กี่เดือนที่ผ่านมาหนึ่งในสถาปัตยกรรมโซลูชั่นของเราต้องการดึงตัวอย่างออกจากเว็บไซต์ที่มีการเข้าชมต่ําหายากเพื่อแสดงผลิตภัณฑ์ให้กับลูกค้าที่มีศักยภาพ เนื่องจากข้อผิดพลาดใน API ไม่ได้ใช้ขีด จํากัด ความปลอดภัยในการคํานวณไฟล์ เนื่องจากข้อมูลสําหรับเว็บไซต์ "หายาก" นี้ถูกแพร่กระจายไปหลายล้านสถิติพร้อมกับเว็บไซต์ที่มีการเข้าชมสูงระบบพยายามที่จะกู้คืนเกือบครึ่งหนึ่งของพื้นที่เก็บข้อมูลประวัติศาสตร์ทั้งหมดของเราเพื่อหาหน้านี้ไม่กี่หน้า ข้อผิดพลาดที่ซื่อสัตย์ที่สิ้นสุดเสียค่าใช้จ่ายของเราโดยเฉพาะอย่างยิ่ง $100,000 in AWS fees! ตอนนี้ฉันแก้ไขข้อผิดพลาด API ได้ทันที (และเพิ่มขีด จํากัด อย่างเคร่งครัด) แต่ความเสี่ยงทางสถาปัตยกรรมยังคงอยู่ มันเป็นระเบิดเวลา... ให้ฉันบอกคุณเรื่องราวของข้อมูลที่สดใส สถาปัตยกรรม: วิธีที่ฉันขับขี่ระบบลงในฝีมือของการจัดเก็บข้อมูล "ราคาถูก" และวิธีการที่ฉันปีนออกโดยใช้ระบบ . เว็บแคมเปญ Rearrange Pipeline เว็บแคมเปญ เว็บแคมเปญ ส่วนหนึ่งที่ 1: The “Write-First” Legacy เมื่อฉันเริ่มทํางานบนเว็บอาร์กอริทึมระบบจะดูดซึมข้อมูลขนาดใหญ่: ล้านคําขอต่อนาทีสิบเทราไบต์ต่อวัน อาคารพื้นฐานถูกสร้างขึ้นด้วยเป้าหมายหลัก: การจับภาพทุกอย่างโดยไม่ต้องสูญเสียข้อมูล มันขึ้นอยู่กับกลยุทธ์ที่ทนทานที่สุดสําหรับระบบการไหลสูง: Append-only Log. 
 
 
 
 
 ข้อมูล (HTML, JSON) จะถูกลบ เมื่อกระเป๋าสูงถึง ~300 MB มันจะ "ปิดผนึก" ในไฟล์ TAR ไฟล์จะบินไป S3 หลังจาก 3 วันไฟล์จะย้ายไปยัง S3 Glacier Deep Archive สําหรับขั้นตอนการดูดซึมการออกแบบนี้ไม่มีข้อบกพร่อง การจัดเก็บข้อมูลใน Deep Archive ค่าใช้จ่ายเหรียญและปริมาณการเขียนเกือบไม่ จํากัด ปัญหา: ราคาที่แตกต่างกัน สถาปัตยกรรมทํางานอย่างสมบูรณ์แบบสําหรับการเขียน ... จนกระทั่งลูกค้ามาขอข้อมูลประวัติศาสตร์ นั่นคือเมื่อฉันเผชิญกับความขัดแย้งพื้นฐาน: 
 
 
 The System Writes by Time: คลังเก็บจาก 12:00 PM มีส่วนผสมของ cnn.com, google.com และ shop.xyz ระบบอ่านตามโดเมน: ลูกค้าถาม "ให้ฉันหน้าทั้งหมดจาก cnn.com สําหรับปีที่ผ่านมา" นี่คือข้อผิดพลาดที่สร้างแรงบันดาลใจสําหรับบทความนี้ เช่นเดียวกับวิศวกรหลายคนฉันเคยคิดเกี่ยวกับ แต่ฉันลืมว่า . latency, IOPS, and throughput AWS Glacier billing model ฉันคิดว่า“ ดีการกู้คืนไม่กี่พันไฟล์ช้า (48 ชั่วโมง) แต่ก็ไม่แพงมาก” AWS ค่าใช้จ่ายไม่เพียง แต่สําหรับการเรียกใช้ API แต่สําหรับ ($ ต่อ GB ได้รับการกู้คืน) The Reality: volume of data restored ผล “Golden Byte” ลองจินตนาการว่าลูกค้าขอ 1,000 หน้าจากโดเมนเดียว เนื่องจากกลยุทธ์การเขียนเป็นแบบชั่วคราวหน้าเหล่านี้สามารถแพร่กระจายได้ทั่ว 1,000 ตู้เก็บ TAR ที่แตกต่างกัน เพื่อให้ลูกค้า 50 MB ของข้อมูลที่มีประโยชน์นี้เกิดภัยพิบัติ: 
 
 
 
 
 ระบบต้องเปิดใช้งานการกู้คืนสําหรับ 1,000 ไฟล์ มันยก 300 GB ของข้อมูลออกจาก “ตู้แช่แข็ง” (1,000 เอกสาร × 300 MB) AWS ค่าใช้จ่ายเราสําหรับการกู้คืน 300 GB ฉันสกัด 50 MB ที่จําเป็นและโยน 299.95 GB อื่น ๆ เราจ่ายเพื่อกู้คืน terabytes ของขยะเพียงเพื่อสกัดเมล็ดทอง มันเป็นคลาสสิก ปัญหาที่กลายเป็นหลุมดําทางการเงิน Data Locality ส่วนที่ 2: แก้ไขข้อผิดพลาด: ท่อระบายความร้อน ฉันไม่สามารถเปลี่ยนวิธีการดูดซึมได้อย่างรวดเร็ว - กระแสเข้าเป็นแบบขนานและมีขนาดใหญ่เกินไปเพื่อให้สามารถจัดเรียงได้ "ในระหว่าง" (แม้ว่าฉันจะทํางานในเรื่องนี้) และฉันต้องการโซลูชั่นที่ทํางานสําหรับข้อมูลที่จัดเก็บไว้แล้วเช่นกัน ดังนั้นฉันได้ออกแบบ , กระบวนการพื้นหลังที่ “defragments” ไฟล์ Rearrange Pipeline นี่คือกระบวนการ ETL (Extract, Transform, Load) ที่ไม่ซิงโครนัสด้วยองค์ประกอบหลักที่สําคัญหลายประการ: 
 
 
 
 
 
 
  It makes no sense to sort data that clients aren’t asking for. Thus, I direct all new data into the pipeline, as well as data that clients have specifically asked to restore. We overpay for the retrieval the first time, but it never happens a second time. Selection: 
 
  Multiple workers download unsorted files in parallel and organize buffers by domain. Since the system is asynchronous, I don’t worry about the incoming stream overloading memory. The workers handle the load at their own pace. Shuffling (Grouping): 
 
 
  I write the sorted files back to S3 under a new prefix (to distinguish sorted files from raw ones). Rewriting: 
 
 
 Before:   →  2024/05/05/random_id_ts.tar [cnn, google, zara, cnn] After:   →  2024/05/05/cnn/random_id_ts.tar [cnn, cnn, cnn...]  
 
 
  In Snowflake, the metadata table is append-only. Doing   or   is prohibitively expensive. Metadata Swap: MERGE INTO UPDATE 
 
 The Solution: I found it was far more efficient to take all records for a specific day, write them to a separate table using a JOIN, delete the original day’s records, and insert the entire day back with the modified records. I managed to process   in just a few hours on a 4X-Large Snowflake warehouse. 300+ days and 160+ billion UPDATE operations ผล การเปลี่ยนแปลงนี้เปลี่ยนอย่างรุนแรงเศรษฐกิจของผลิตภัณฑ์: 
 
 
 
 ความแม่นยําของจุด: ตอนนี้เมื่อลูกค้าขอ cnn.com ระบบจะกู้คืนข้อมูลเฉพาะที่ cnn.com มีอยู่ ประสิทธิภาพ: ขึ้นอยู่กับความละเอียดของคําขอ (ป้อนโดเมน vs. URLs ที่เฉพาะเจาะจงผ่าน regex) ฉันได้บรรลุการลด 10% ถึง 80% ในการรับข้อมูลขยะ (ซึ่งเป็นสัดส่วนโดยตรงกับค่าใช้จ่าย) ความสามารถใหม่: นอกเหนือจากการประหยัดเงินเพียงแค่ในการขโมยสิ่งนี้เปิดตัวกรณีการใช้ธุรกิจใหม่ทั้งหมด เนื่องจากการกู้คืนข้อมูลทางประวัติศาสตร์ไม่แพงมากอีกต่อไปตอนนี้เราสามารถจ่ายค่าใช้จ่ายในการสกัดชุดข้อมูลขนาดใหญ่สําหรับการฝึกอบรมรุ่น AI การวิจัยตลาดระยะยาวและการสร้างฐานความรู้สําหรับระบบ AI ของตัวแทนเพื่อพิจารณา (คิดว่าเครื่องมือค้นหาเฉพาะ) สิ่งที่ก่อนหน้านี้เป็นภารกิจการฆ่าตัวเองทางการเงินตอนนี้เป็นการดําเนินงานมาตรฐาน เราจะจ้าง Bright Data จะขยายการจัดเก็บข้อมูลเว็บได้อีกต่อไป หากคุณชอบ: 
 
 
 
 
 
 ระบบกระจายการไหลสูง วิศวกรรมข้อมูลในขนาดใหญ่ สร้างท่อที่เชื่อถือได้ภายใต้การโหลดในโลกจริง ปุ่ม Node.js ไปยังขีด จํากัด อย่างแน่นอน แก้ปัญหาที่ไม่ได้ปรากฏในบทเรียน แล้วฉันจะรักที่จะพูดคุย เรากําลังจ้างวิศวกร Node.js ที่แข็งแกร่งเพื่อช่วยสร้าง Web Archive รุ่นถัดไป มีประสบการณ์ด้านวิศวกรรมข้อมูลและ ETL เป็นประโยชน์มาก อย่าลังเลที่จะส่ง CV ของคุณไปยัง . วินเทจ@brightdata.com วินเทจ@brightdata.com วินเทจ@brightdata.com การอัปเดตเพิ่มเติมมาในขณะที่ฉันยังคงขยายขนาดของสถิติและในขณะที่ฉันยังคงหาวิธีใหม่และสร้างสรรค์ในการทําลายมัน!

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

This writer has a vested interest be it monetary, business, or otherwise, with 1 or more of the products or companies mentioned within.

2022 - HackerNoon Contributor of the Year - Amazon

Request Your Own Data

Nominated for 2022 - HackerNoon Contributor of the Year - Amazon

เสียงนี้ผลิตในภาษาต้นฉบับของเรื่องราว!

สร้างไฟล์เว็บขนาด Petabyte

About Author

ความคิดเห็น

แขวนแท็ก

บทความนี้ถูกนำเสนอใน

Related Stories

Open AI Images on HackerNoon: The Conundrum

MOCKING AT FATE

Emphatic words must stand in emphatic positions

THE ADVENTURES IN COLORADO

Open AI Images on HackerNoon: The Conundrum

MOCKING AT FATE

Emphatic words must stand in emphatic positions

THE ADVENTURES IN COLORADO

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps