เราอยู่ในช่วงเวลาที่น่าทึ่งเมื่อคุณสามารถเชื่อมต่อเครื่องมือโอเพ่นซอร์สสำเร็จรูปหลายๆ เครื่องมือได้อย่างรวดเร็วและง่ายดาย ตั้งค่าเครื่องมือเหล่านั้นโดย “ปิดการรับรู้” ของคุณตามคำแนะนำของ Stackoverflow โดยไม่ต้องเจาะลึกถึง “ตัวอักษรหลายตัว” และเปิดตัว ไปสู่การดำเนินการเชิงพาณิชย์ และเมื่อคุณต้องการอัปเดต/ขยาย หรือมีคนรีบูทเครื่องสองสามเครื่องโดยไม่ตั้งใจ คุณจะตระหนักได้ว่าฝันร้ายที่ครอบงำจิตใจได้เริ่มต้นขึ้นแล้ว ทุกอย่างกลายเป็นเรื่องซับซ้อนอย่างมากเกินกว่าจะรับรู้ ไม่มีการหันหลังกลับ อนาคตที่คลุมเครือและปลอดภัยยิ่งขึ้น แทนที่จะเขียนโปรแกรม ให้ผสมพันธุ์ผึ้งและทำชีส
ไม่ใช่เพื่อสิ่งใดเลยที่เพื่อนร่วมงานที่มีประสบการณ์มากกว่า โดยที่หัวของพวกเขาเต็มไปด้วยแมลงและเป็นสีเทาอยู่แล้ว โดยใคร่ครวญถึงการติดตั้งชุด "คอนเทนเนอร์" ใน "คิวบ์" อย่างรวดเร็วอย่างไม่น่าเชื่อบนเซิร์ฟเวอร์หลายสิบเครื่องใน "ภาษาที่ทันสมัย" พร้อมการสนับสนุนในตัวสำหรับ I/O แบบไม่บล็อคแบบอะซิงโครนัส ยิ้มอย่างสุภาพ และพวกเขายังคงอ่าน “man ps” อีกครั้งอย่างเงียบๆ เจาะลึกซอร์สโค้ด “nginx” จนกว่าพวกเขาจะเลือดออกตา และเขียน เขียน และเขียนการทดสอบหน่วย เพื่อนร่วมงานรู้ดีว่าสิ่งที่น่าสนใจที่สุดจะเกิดขึ้นเมื่อวันหนึ่ง "ทั้งหมดนี้" กลายเป็นเดิมพันในคืนวันส่งท้ายปีเก่า และพวกเขาจะได้รับความช่วยเหลือจากความเข้าใจอย่างลึกซึ้งเกี่ยวกับธรรมชาติของยูนิกซ์ ตารางสถานะ TCP/IP ที่จดจำไว้ และอัลกอริธึมการค้นหาการเรียงลำดับพื้นฐานเท่านั้น เพื่อให้ระบบกลับมามีชีวิตชีวาอีกครั้งเมื่อมีเสียงระฆังดังขึ้น
โอ้ ใช่ ฉันฟุ้งซ่านเล็กน้อย แต่ฉันหวังว่าฉันจะสามารถถ่ายทอดสภาวะแห่งความคาดหวังได้
วันนี้ฉันต้องการแบ่งปันประสบการณ์ของเราในการปรับใช้สแต็กที่สะดวกและราคาไม่แพงสำหรับ DataLake ซึ่งช่วยแก้ปัญหางานวิเคราะห์ส่วนใหญ่ในบริษัทสำหรับแผนกโครงสร้างที่แตกต่างกันโดยสิ้นเชิง
เมื่อไม่นานมานี้ เราเข้าใจว่าบริษัทต่างๆ ต้องการผลของทั้งการวิเคราะห์ผลิตภัณฑ์และทางเทคนิคเพิ่มมากขึ้น (ไม่ต้องพูดถึงสิ่งสำคัญในรูปแบบของการเรียนรู้ของเครื่อง) และเพื่อทำความเข้าใจแนวโน้มและความเสี่ยง - เราจำเป็นต้องรวบรวมและวิเคราะห์ ตัวชี้วัดเพิ่มมากขึ้นเรื่อยๆ
การวิเคราะห์ทางเทคนิคขั้นพื้นฐานใน Bitrix24
เมื่อหลายปีก่อน พร้อมกับการเปิดตัวบริการ Bitrix24 เราได้ทุ่มเทเวลาและทรัพยากรอย่างแข็งขันในการสร้างแพลตฟอร์มการวิเคราะห์ที่เรียบง่ายและเชื่อถือได้ ซึ่งจะช่วยให้มองเห็นปัญหาในโครงสร้างพื้นฐานได้อย่างรวดเร็วและวางแผนขั้นตอนต่อไป แน่นอนว่าขอแนะนำให้ใช้เครื่องมือสำเร็จรูปที่เรียบง่ายและเข้าใจง่ายที่สุด ด้วยเหตุนี้ Nagios จึงได้รับเลือกให้เป็นผู้เฝ้าติดตามและคอยดูแลการวิเคราะห์และการแสดงภาพ ตอนนี้เรามีเช็คหลายพันเช็คใน nagios มีแผนภูมิหลายร้อยรายการใน munin และเพื่อนร่วมงานของเราใช้เช็คเหล่านี้อย่างประสบความสำเร็จทุกวัน ตัวชี้วัดมีความชัดเจน กราฟมีความชัดเจน ระบบทำงานได้อย่างน่าเชื่อถือมาหลายปีแล้ว และมีการเพิ่มการทดสอบและกราฟใหม่ๆ เข้าไปเป็นประจำ เมื่อเราเริ่มให้บริการใหม่ เราจะเพิ่มการทดสอบและกราฟต่างๆ ขอให้โชคดี.
Finger on the Pulse - การวิเคราะห์ทางเทคนิคขั้นสูง
ความปรารถนาที่จะได้รับข้อมูลเกี่ยวกับปัญหา "โดยเร็วที่สุด" นำเราไปสู่การทดลองเชิงรุกด้วยเครื่องมือที่เรียบง่ายและเข้าใจได้ - pinba และ xhprof
Pinba ส่งสถิติมาให้เราในแพ็กเก็ต UDP เกี่ยวกับความเร็วการทำงานของส่วนต่างๆ ของหน้าเว็บใน PHP และเราเห็นออนไลน์ในที่เก็บข้อมูล MySQL (Pinba มาพร้อมกับกลไก MySQL ของตัวเองสำหรับการวิเคราะห์เหตุการณ์ที่รวดเร็ว) รายการปัญหาสั้นๆ และตอบสนองต่อ พวกเขา. และ xhprof อนุญาตให้เรารวบรวมกราฟการดำเนินการของหน้า PHP ที่ช้าที่สุดจากไคลเอนต์โดยอัตโนมัติ และวิเคราะห์สิ่งที่อาจนำไปสู่สิ่งนี้ - อย่างใจเย็น การรินชาหรืออะไรที่แข็งแกร่งกว่า
เมื่อไม่นานมานี้ ชุดเครื่องมือได้รับการเติมเต็มด้วยเอ็นจิ้นอื่นที่ค่อนข้างเรียบง่ายและเข้าใจได้ซึ่งใช้อัลกอริธึมการจัดทำดัชนีย้อนกลับ ซึ่งนำไปใช้อย่างสมบูรณ์แบบในไลบรารี Lucene ในตำนาน - Elastic/Kibana แนวคิดง่ายๆ ในการบันทึกเอกสารแบบมัลติเธรดลงในดัชนี Lucene แบบผกผันโดยอิงตามเหตุการณ์ในบันทึกและการค้นหาอย่างรวดเร็วโดยใช้การแบ่งด้านพบว่ามีประโยชน์จริงๆ
แม้จะมีลักษณะทางเทคนิคที่ค่อนข้างชัดเจนของการแสดงภาพใน Kibana ด้วยแนวคิดระดับต่ำเช่น "ถัง" "ไหลขึ้นไปข้างบน" และภาษาที่คิดค้นใหม่ของพีชคณิตเชิงสัมพันธ์ที่ยังไม่ถูกลืมไปโดยสิ้นเชิง แต่เครื่องมือก็เริ่มช่วยเราได้ดีในงานต่อไปนี้:
- ไคลเอนต์ Bitrix24 มีข้อผิดพลาด PHP กี่ครั้งบนพอร์ทัล p1 ในชั่วโมงที่ผ่านมา และข้อผิดพลาดใด เข้าใจ ให้อภัย และแก้ไขอย่างรวดเร็ว
- ใน 24 ชั่วโมงที่ผ่านมา มีการวิดีโอคอลบนพอร์ทัลในเยอรมนีกี่ครั้ง คุณภาพเป็นเท่าใด และมีปัญหากับช่อง/เครือข่ายหรือไม่
- ฟังก์ชันการทำงานของระบบ (ส่วนขยาย C ของเราสำหรับ PHP) ซึ่งรวบรวมจากแหล่งที่มาในการอัปเดตบริการล่าสุดและเผยแพร่สู่ไคลเอนต์ทำงานได้ดีเพียงใด มี segfault หรือไม่?
- ข้อมูลลูกค้าพอดีกับหน่วยความจำ PHP หรือไม่ มีข้อผิดพลาดเกี่ยวกับหน่วยความจำเกินที่จัดสรรให้กับกระบวนการ: "หน่วยความจำไม่เพียงพอ" หรือไม่ ค้นหาและทำให้เป็นกลาง
นี่เป็นตัวอย่างที่ชัดเจน แม้จะมีการทดสอบอย่างละเอียดและหลายระดับ ลูกค้าซึ่งมีเคสที่ไม่ได้มาตรฐานและข้อมูลอินพุตที่เสียหาย ได้รับข้อผิดพลาดที่น่ารำคาญและไม่คาดคิด เสียงไซเรนดังขึ้นและกระบวนการแก้ไขอย่างรวดเร็วก็เริ่มต้นขึ้น:
นอกจากนี้ kibana ยังช่วยให้คุณสามารถจัดระเบียบการแจ้งเตือนสำหรับเหตุการณ์ที่ระบุ และในช่วงเวลาสั้นๆ เครื่องมือในบริษัทก็เริ่มถูกใช้โดยพนักงานหลายสิบคนจากแผนกต่างๆ ตั้งแต่การสนับสนุนด้านเทคนิคและการพัฒนาไปจนถึง QA
กิจกรรมของแผนกใดๆ ภายในบริษัทกลายเป็นเรื่องง่ายในการติดตามและวัดผล - แทนที่จะวิเคราะห์บันทึกบนเซิร์ฟเวอร์ด้วยตนเอง คุณเพียงแค่ต้องตั้งค่าการแยกวิเคราะห์บันทึกเพียงครั้งเดียว และส่งไปยังคลัสเตอร์ยืดหยุ่นเพื่อเพลิดเพลิน เช่น การใคร่ครวญในคิบานะ แดชบอร์ดจำนวนลูกแมวสองหัวที่ขายได้ซึ่งพิมพ์ด้วยเครื่องพิมพ์ 3 มิติในเดือนจันทรคติที่ผ่านมา
การวิเคราะห์ธุรกิจขั้นพื้นฐาน
ทุกคนรู้ดีว่าการวิเคราะห์ธุรกิจในบริษัทต่างๆ มักจะเริ่มต้นด้วยการใช้งาน Excel อย่างกระตือรือร้น แต่สิ่งสำคัญคือมันไม่ได้จบเพียงแค่นั้น Google Analytics บนคลาวด์ยังช่วยเติมเชื้อเพลิงให้กับกองไฟ - คุณจะเริ่มคุ้นเคยกับสิ่งดีๆ อย่างรวดเร็ว
ในบริษัทที่กำลังพัฒนาอย่างกลมกลืนของเรา เริ่มปรากฏ "ศาสดาพยากรณ์" ที่ทำงานเข้มข้นมากขึ้นพร้อมข้อมูลขนาดใหญ่ขึ้นที่นี่และที่นั่น ความต้องการรายงานเชิงลึกและหลากหลายมากขึ้นเริ่มปรากฏให้เห็นเป็นประจำ และด้วยความพยายามของบุคลากรจากแผนกต่างๆ เมื่อไม่นานมานี้จึงมีการจัดเตรียมโซลูชันที่เรียบง่ายและใช้งานได้จริง - การผสมผสานระหว่าง ClickHouse และ PowerBI
เป็นเวลานานแล้วที่โซลูชันที่ยืดหยุ่นนี้ช่วยได้มาก แต่ค่อยๆ ความเข้าใจเริ่มมาว่า ClickHouse ไม่ใช่ยางและไม่สามารถล้อเลียนแบบนั้นได้
สิ่งสำคัญคือต้องเข้าใจให้ดีว่า ClickHouse เช่น Druid เช่น Vertica เช่น Amazon RedShift (ซึ่งใช้ postgres) เป็นเครื่องมือวิเคราะห์ที่ได้รับการปรับให้เหมาะสมสำหรับการวิเคราะห์ที่ค่อนข้างสะดวก (ผลรวม การรวม ขั้นต่ำ-สูงสุดตามคอลัมน์ และการรวมที่เป็นไปได้สองสามรายการ ), เพราะ จัดระเบียบเพื่อการจัดเก็บคอลัมน์ของตารางเชิงสัมพันธ์อย่างมีประสิทธิภาพ ซึ่งแตกต่างจาก MySQL และฐานข้อมูล (เชิงแถว) อื่น ๆ ที่เรารู้จัก
โดยพื้นฐานแล้ว ClickHouse เป็นเพียง "ฐานข้อมูล" ที่กว้างขวางกว่าโดยมีการแทรกแบบจุดต่อจุดไม่สะดวกนัก (นั่นคือสิ่งที่ตั้งใจไว้ ทุกอย่างก็โอเค) แต่เป็นการวิเคราะห์ที่น่าพึงพอใจและชุดฟังก์ชันที่ทรงพลังที่น่าสนใจสำหรับการทำงานกับข้อมูล ใช่ คุณสามารถสร้างคลัสเตอร์ได้ แต่คุณเข้าใจว่าการตอกตะปูด้วยกล้องจุลทรรศน์นั้นไม่ถูกต้องทั้งหมด และเราเริ่มมองหาวิธีแก้ปัญหาอื่น
ความต้องการหลามและนักวิเคราะห์
บริษัทของเรามีนักพัฒนาจำนวนมากที่เขียนโค้ดเกือบทุกวันเป็นเวลา 10-20 ปีใน PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash นอกจากนี้ยังมีผู้ดูแลระบบที่มีประสบการณ์จำนวนมากที่เคยประสบกับภัยพิบัติที่น่าเหลือเชื่อมากกว่าหนึ่งครั้งที่ไม่สอดคล้องกับกฎสถิติ (ตัวอย่างเช่นเมื่อดิสก์ส่วนใหญ่ใน raid-10 ถูกทำลายด้วยฟ้าผ่าที่รุนแรง) ในสถานการณ์เช่นนี้ เป็นเวลานานแล้วที่ยังไม่ชัดเจนว่า "นักวิเคราะห์ Python" คืออะไร Python ก็เหมือนกับ PHP เพียงชื่อจะยาวกว่าเล็กน้อยและมีสารที่เปลี่ยนแปลงความคิดในซอร์สโค้ดของล่ามน้อยกว่าเล็กน้อย อย่างไรก็ตาม เมื่อมีการสร้างรายงานการวิเคราะห์มากขึ้นเรื่อยๆ นักพัฒนาที่มีประสบการณ์ก็เริ่มเข้าใจมากขึ้นถึงความสำคัญของความเชี่ยวชาญเฉพาะทางในเครื่องมือต่างๆ เช่น numpy, pandas, matplotlib, seaborn
บทบาทชี้ขาดน่าจะเกิดจากการที่พนักงานเป็นลมอย่างกะทันหันจากการรวมกันของคำว่า "การถดถอยโลจิสติก" และการสาธิตการรายงานที่มีประสิทธิภาพเกี่ยวกับข้อมูลขนาดใหญ่โดยใช้ใช่ใช่ pyspark
Apache Spark ซึ่งเป็นกระบวนทัศน์การทำงานที่พีชคณิตเชิงสัมพันธ์เข้ากันได้อย่างสมบูรณ์แบบ และความสามารถของมันสร้างความประทับใจให้กับนักพัฒนาที่คุ้นเคยกับ MySQL จนความจำเป็นในการเสริมอันดับด้วยนักวิเคราะห์ที่มีประสบการณ์นั้นชัดเจนในทุกวันนี้
ความพยายามเพิ่มเติมของ Apache Spark/Hadoop ในการดำเนินการและสิ่งที่ไม่เป็นไปตามสคริปต์
อย่างไรก็ตาม ในไม่ช้าก็ชัดเจนว่ามีบางอย่างไม่ถูกต้องกับ Spark อย่างเป็นระบบ หรือจำเป็นต้องล้างมือให้ดีขึ้น หากสแต็ก Hadoop/MapReduce/Lucene ถูกสร้างขึ้นโดยโปรแกรมเมอร์ที่มีประสบการณ์พอสมควร ซึ่งเห็นได้ชัดหากคุณดูซอร์สโค้ดใน Java หรือแนวคิดของ Doug Cutting ใน Lucene อย่างใกล้ชิด ทันใดนั้น Spark ก็ถูกเขียนด้วยภาษาแปลกใหม่ Scala ซึ่งก็คือ มีข้อโต้แย้งอย่างมากจากมุมมองของการปฏิบัติจริงและขณะนี้ยังไม่มีการพัฒนา และการคำนวณที่ลดลงเป็นประจำบนคลัสเตอร์ Spark เนื่องจากการทำงานที่ไร้เหตุผลและไม่โปร่งใสมากนักด้วยการจัดสรรหน่วยความจำเพื่อลดการดำเนินการ (หลายคีย์มาถึงพร้อมกัน) ได้สร้างรัศมีรอบ ๆ บางสิ่งที่มีพื้นที่ว่างให้เติบโต นอกจากนี้ สถานการณ์ยังเลวร้ายลงด้วยพอร์ตเปิดแปลก ๆ จำนวนมาก ไฟล์ชั่วคราวที่เติบโตในสถานที่ที่เข้าใจยากที่สุด และการพึ่งพาอาศัยกันอย่างล้นหลาม ซึ่งทำให้ผู้ดูแลระบบมีความรู้สึกหนึ่งที่รู้จักกันดีตั้งแต่วัยเด็ก: ความเกลียดชังที่รุนแรง (หรือบางที พวกเขาต้องล้างมือด้วยสบู่)
ด้วยเหตุนี้ เราจึงสามารถ "รอดพ้น" โครงการวิเคราะห์ภายในหลายโครงการที่ใช้ Apache Spark อย่างจริงจัง (รวมถึง Spark Streaming, Spark SQL) และระบบนิเวศ Hadoop (และอื่นๆ อีกมากมาย) แม้ว่าเมื่อเวลาผ่านไปเราจะเรียนรู้ที่จะเตรียมและตรวจสอบ "มัน" ได้ค่อนข้างดีและ "มัน" ก็หยุดทำงานกะทันหันเนื่องจากการเปลี่ยนแปลงในลักษณะของข้อมูลและความไม่สมดุลของการแฮช RDD ที่สม่ำเสมอความปรารถนาที่จะทำสิ่งที่พร้อมแล้ว อัปเดตและจัดการที่ไหนสักแห่งในระบบคลาวด์แข็งแกร่งขึ้นเรื่อยๆ ในเวลานี้เองที่เราพยายามใช้แอสเซมบลีคลาวด์สำเร็จรูปของ Amazon Web Services - และต่อมาก็พยายามแก้ไขปัญหาการใช้งาน EMR คือ Apache Spark ที่ Amazon เตรียมไว้พร้อมกับซอฟต์แวร์เพิ่มเติมจากระบบนิเวศ เช่นเดียวกับ Cloudera/Hortonworks builds
การจัดเก็บไฟล์ Rubber เพื่อการวิเคราะห์มีความจำเป็นเร่งด่วน
ประสบการณ์การ "ทำอาหาร" Hadoop/Spark ที่มีรอยไหม้ตามส่วนต่างๆ ของร่างกายนั้นไม่ได้ไร้ประโยชน์ ความจำเป็นในการสร้างพื้นที่จัดเก็บไฟล์เดียว ราคาไม่แพง และเชื่อถือได้ ซึ่งสามารถทนทานต่อความล้มเหลวของฮาร์ดแวร์ และเป็นไปได้ที่จะจัดเก็บไฟล์ในรูปแบบที่แตกต่างจากระบบที่แตกต่างกัน และสร้างตัวอย่างที่มีประสิทธิภาพและประหยัดเวลาสำหรับรายงานจากข้อมูลนี้เพิ่มมากขึ้น ชัดเจน.
ฉันยังต้องการให้การอัปเดตซอฟต์แวร์ของแพลตฟอร์มนี้ไม่ได้กลายเป็นฝันร้ายของปีใหม่ด้วยการอ่านการติดตาม Java 20 หน้าและการวิเคราะห์บันทึกโดยละเอียดของคลัสเตอร์ความยาวกิโลเมตรโดยใช้ Spark History Server และแว่นขยายแบบมีแสงด้านหลัง ฉันอยากได้เครื่องมือที่เรียบง่ายและโปร่งใสซึ่งไม่จำเป็นต้องดำเนินการใดๆ เป็นประจำ หากคำขอ MapReduce มาตรฐานของนักพัฒนาหยุดดำเนินการเมื่อผู้ปฏิบัติงานลดข้อมูลหลุดออกจากหน่วยความจำเนื่องจากอัลกอริธึมการแบ่งพาร์ติชันข้อมูลต้นทางที่เลือกมาไม่ดีนัก
Amazon S3 เป็นผู้สมัครสำหรับ DataLake หรือไม่
ประสบการณ์กับ Hadoop/MapReduce สอนเราว่าเราต้องการระบบไฟล์ที่ปรับขนาดได้และเชื่อถือได้ และพนักงานที่ปรับขนาดได้ นอกเหนือจากนั้น โดย "เข้าใกล้" ข้อมูลให้ใกล้กับข้อมูลมากขึ้น เพื่อไม่ให้ขับเคลื่อนข้อมูลผ่านเครือข่าย พนักงานควรสามารถอ่านข้อมูลในรูปแบบต่างๆ ได้ แต่ไม่ควรอ่านข้อมูลที่ไม่จำเป็นและสามารถจัดเก็บข้อมูลล่วงหน้าในรูปแบบที่สะดวกสำหรับพนักงานได้
อีกครั้งหนึ่งที่แนวคิดพื้นฐาน ไม่มีความปรารถนาที่จะ "เท" ข้อมูลขนาดใหญ่ลงในเครื่องมือวิเคราะห์คลัสเตอร์เดียว ซึ่งจะทำให้ไม่ช้าก็เร็วและคุณจะต้องแยกส่วนมันน่าเกลียด ฉันต้องการจัดเก็บไฟล์ในรูปแบบที่เข้าใจได้ และดำเนินการสืบค้นเชิงวิเคราะห์ที่มีประสิทธิภาพโดยใช้เครื่องมือที่แตกต่างแต่สามารถเข้าใจได้ และก็จะมีไฟล์ในรูปแบบต่างๆเพิ่มมากขึ้นเรื่อยๆ และเป็นการดีกว่าที่จะไม่แยกส่วนเครื่องยนต์ แต่เป็นข้อมูลต้นฉบับ เราต้องการ DataLake ที่ขยายได้และเป็นสากล เราตัดสินใจ...
จะเป็นอย่างไรหากคุณจัดเก็บไฟล์ในพื้นที่จัดเก็บข้อมูลบนคลาวด์ Amazon S3 ที่คุ้นเคยและเป็นที่รู้จัก โดยไม่ต้องเตรียมสับของคุณเองจาก Hadoop
เป็นที่แน่ชัดว่าข้อมูลส่วนบุคคลนั้น "ต่ำ" แต่ข้อมูลอื่นๆ ถ้าเรานำออกไปและ "ขับเคลื่อนอย่างมีประสิทธิภาพ" ล่ะ?
ระบบนิเวศการวิเคราะห์คลัสเตอร์-ข้อมูลขนาดใหญ่-ของ Amazon Web Services พูดง่ายๆ ก็คือ
เมื่อพิจารณาจากประสบการณ์ของเรากับ AWS พบว่า Apache Hadoop/MapReduce มีการใช้งานที่นั่นมาเป็นเวลานานภายใต้ซอสต่างๆ เช่น ในบริการ DataPipeline (ฉันอิจฉาเพื่อนร่วมงานของฉัน พวกเขาเรียนรู้วิธีการเตรียมอย่างถูกต้อง) ที่นี่เราตั้งค่าการสำรองข้อมูลจากบริการต่างๆ จากตาราง DynamoDB:
และพวกมันทำงานเป็นประจำบนคลัสเตอร์ Hadoop/MapReduce แบบฝังเหมือนเครื่องจักรมาหลายปีแล้ว “ตั้งค่าและลืมมัน”:
คุณยังสามารถมีส่วนร่วมในลัทธิซาตานข้อมูลได้อย่างมีประสิทธิภาพโดยการตั้งค่าแล็ปท็อป Jupiter ในระบบคลาวด์สำหรับนักวิเคราะห์ และใช้บริการ AWS SageMaker เพื่อฝึกอบรมและปรับใช้โมเดล AI ในการต่อสู้ นี่คือสิ่งที่ดูเหมือนสำหรับเรา:
ใช่แล้ว คุณสามารถเลือกแล็ปท็อปสำหรับตัวคุณเองหรือนักวิเคราะห์ในระบบคลาวด์แล้วแนบเข้ากับคลัสเตอร์ Hadoop/Spark ทำการคำนวณ จากนั้นจัดการทุกอย่างให้เรียบร้อย:
สะดวกมากสำหรับโครงการวิเคราะห์แต่ละโครงการ และสำหรับบางโครงการ เราได้ใช้บริการ EMR สำหรับการคำนวณและการวิเคราะห์ขนาดใหญ่ได้สำเร็จ แล้วโซลูชันระบบสำหรับ DataLake จะใช้งานได้หรือไม่ ในขณะนี้เราใกล้จะสิ้นหวังและสิ้นหวังแล้วจึงค้นหาต่อไป
AWS Glue - Apache Spark ที่บรรจุอย่างประณีตบนสเตียรอยด์
ปรากฎว่า AWS มีสแต็ก “Hive/Pig/Spark” เวอร์ชันของตัวเอง บทบาทของไฮฟ์ ได้แก่ แค็ตตาล็อกของไฟล์และประเภทของไฟล์ใน DataLake ดำเนินการโดยบริการ "แค็ตตาล็อกข้อมูล" ซึ่งไม่ได้ซ่อนความเข้ากันได้กับรูปแบบ Apache Hive คุณต้องเพิ่มข้อมูลลงในบริการนี้ว่าไฟล์ของคุณอยู่ที่ไหนและอยู่ในรูปแบบใดในบริการนี้ ข้อมูลสามารถไม่เพียงแต่ใน s3 เท่านั้น แต่ยังอยู่ในฐานข้อมูลด้วย แต่นั่นไม่ใช่หัวข้อของโพสต์นี้ นี่คือวิธีการจัดระเบียบไดเร็กทอรีข้อมูล DataLake ของเรา:
ไฟล์ได้รับการลงทะเบียนแล้ว เยี่ยมมาก หากไฟล์ได้รับการอัปเดต เราจะเปิดตัวโปรแกรมรวบรวมข้อมูลด้วยตนเองหรือตามกำหนดเวลา ซึ่งจะอัปเดตข้อมูลเกี่ยวกับไฟล์เหล่านั้นจาก Lake และบันทึกไว้ จากนั้นจึงสามารถประมวลผลข้อมูลจากทะเลสาบและอัปโหลดผลลัพธ์ไว้ที่ใดที่หนึ่งได้ ในกรณีที่ง่ายที่สุด เรายังอัปโหลดไปยัง s3 ด้วย การประมวลผลข้อมูลสามารถทำได้ทุกที่ แต่ขอแนะนำให้คุณกำหนดค่าการประมวลผลบนคลัสเตอร์ Apache Spark โดยใช้ความสามารถขั้นสูงผ่าน AWS Glue API ในความเป็นจริง คุณสามารถใช้โค้ด Python เก่าและคุ้นเคยได้โดยใช้ไลบรารี pyspark และกำหนดค่าการดำเนินการบนโหนด N ของคลัสเตอร์ที่มีความจุบางส่วนพร้อมการตรวจสอบ โดยไม่ต้องเจาะเข้าไปในความกล้าของ Hadoop และลากคอนเทนเนอร์ docker-moker และกำจัดข้อขัดแย้งในการพึ่งพา .
อีกครั้งกับแนวคิดง่ายๆ ไม่จำเป็นต้องกำหนดค่า Apache Spark คุณเพียงแค่ต้องเขียนโค้ด Python สำหรับ pyspark ทดสอบในเครื่องบนเดสก์ท็อปของคุณ จากนั้นรันบนคลัสเตอร์ขนาดใหญ่ในระบบคลาวด์ โดยระบุตำแหน่งของข้อมูลต้นฉบับและตำแหน่งที่จะวางผลลัพธ์ บางครั้งสิ่งนี้ก็จำเป็นและมีประโยชน์ และนี่คือวิธีที่เราตั้งค่า:
ดังนั้น หากคุณต้องการคำนวณบางสิ่งบนคลัสเตอร์ Spark โดยใช้ข้อมูลใน s3 เราจะเขียนโค้ดใน python/pyspark ทดสอบ และขอให้โชคดีกับคลาวด์
แล้วการเรียบเรียงล่ะ? จะเกิดอะไรขึ้นถ้างานล้มและหายไป? ใช่ มีการเสนอให้สร้างไปป์ไลน์ที่สวยงามในสไตล์ Apache Pig และเรายังลองใช้มันด้วย แต่ตอนนี้เราตัดสินใจใช้การเรียบเรียงที่ปรับแต่งอย่างล้ำลึกใน PHP และ JavaScript (ฉันเข้าใจว่ามีความไม่สอดคล้องกันทางปัญญา แต่มันได้ผลสำหรับ ปีและไม่มีข้อผิดพลาด)
รูปแบบของไฟล์ที่จัดเก็บไว้ในทะเลสาบเป็นกุญแจสำคัญในประสิทธิภาพ
เป็นสิ่งสำคัญมากที่จะต้องเข้าใจประเด็นสำคัญอีกสองประเด็น เพื่อให้การสืบค้นข้อมูลไฟล์ใน Lake ดำเนินการได้เร็วที่สุดเท่าที่จะเป็นไปได้และประสิทธิภาพไม่ลดลงเมื่อมีการเพิ่มข้อมูลใหม่ คุณต้อง:
- จัดเก็บคอลัมน์ของไฟล์แยกกัน (เพื่อที่คุณจะได้ไม่ต้องอ่านทุกบรรทัดเพื่อทำความเข้าใจว่ามีอะไรอยู่ในคอลัมน์) สำหรับสิ่งนี้เราใช้รูปแบบไม้ปาร์เก้ที่มีการบีบอัด
- สิ่งสำคัญมากคือต้องแบ่งไฟล์ออกเป็นโฟลเดอร์ต่างๆ เช่น ภาษา ปี เดือน วัน สัปดาห์ เอ็นจิ้นที่เข้าใจการแบ่งส่วนประเภทนี้จะดูเฉพาะโฟลเดอร์ที่จำเป็น โดยไม่ต้องกรองข้อมูลทั้งหมดในแถว
โดยพื้นฐานแล้ว ด้วยวิธีนี้ คุณจะจัดวางข้อมูลต้นฉบับในรูปแบบที่มีประสิทธิภาพสูงสุดสำหรับกลไกการวิเคราะห์ที่แขวนอยู่ด้านบน ซึ่งแม้แต่ในโฟลเดอร์ที่แบ่งส่วนก็สามารถเลือกป้อนและอ่านเฉพาะคอลัมน์ที่จำเป็นจากไฟล์ได้ คุณไม่จำเป็นต้อง "เติม" ข้อมูลทุกที่ (ที่เก็บข้อมูลจะระเบิด) - เพียงใส่ลงในระบบไฟล์ในรูปแบบที่ถูกต้องทันทีอย่างชาญฉลาด แน่นอนว่า ไม่แนะนำให้จัดเก็บไฟล์ csv ขนาดใหญ่ใน DataLake ซึ่งต้องอ่านทีละบรรทัดก่อนจึงจะแตกคอลัมน์ได้ ลองคิดถึงสองประเด็นข้างต้นอีกครั้งหากยังไม่ชัดเจนว่าเหตุใดจึงเกิดเรื่องทั้งหมดนี้ขึ้น
AWS Athena - แจ็คอินเดอะบ็อกซ์
จากนั้น ขณะที่สร้างทะเลสาบ เราก็บังเอิญบังเอิญไปเจอกับอเมซอนเอเธน่า ทันใดนั้นปรากฎว่าด้วยการจัดเรียงไฟล์บันทึกขนาดใหญ่ของเราอย่างระมัดระวังลงในชิ้นส่วนโฟลเดอร์ในรูปแบบคอลัมน์ที่ถูกต้อง (ปาร์เก้) คุณสามารถเลือกข้อมูลที่เป็นประโยชน์อย่างยิ่งจากไฟล์เหล่านี้ได้อย่างรวดเร็ว และสร้างรายงานโดยไม่ต้องใช้คลัสเตอร์ Apache Spark/Glue
เอ็นจิ้น Athena ที่ขับเคลื่อนโดยข้อมูลใน s3 มีพื้นฐานมาจากตำนาน - ตัวแทนของกลุ่ม MPP (การประมวลผลแบบขนานขนาดใหญ่) ของแนวทางการประมวลผลข้อมูล โดยรับข้อมูลที่อยู่ในตำแหน่งตั้งแต่ s3 และ Hadoop ไปจนถึง Cassandra และไฟล์ข้อความธรรมดา คุณเพียงแค่ต้องขอให้ Athena ดำเนินการค้นหา SQL จากนั้นทุกอย่าง “ทำงานอย่างรวดเร็วและอัตโนมัติ” สิ่งสำคัญคือต้องทราบว่า Athena นั้น "ฉลาด" โดยไปที่โฟลเดอร์ที่แบ่งส่วนที่จำเป็นเท่านั้นและอ่านเฉพาะคอลัมน์ที่จำเป็นในคำขอ
ราคาสำหรับคำขอไปยัง Athena ก็น่าสนใจเช่นกัน เราจ่ายสำหรับ . เหล่านั้น. ไม่ใช่จำนวนเครื่องในคลัสเตอร์ต่อนาที แต่... สำหรับข้อมูลที่สแกนจริงบนเครื่อง 100-500 เครื่อง เป็นเพียงข้อมูลที่จำเป็นในการดำเนินการตามคำขอเท่านั้น
และโดยการขอเฉพาะคอลัมน์ที่จำเป็นจากโฟลเดอร์ที่แบ่งส่วนอย่างถูกต้อง ปรากฎว่าบริการ Athena มีค่าใช้จ่ายเราหลายสิบดอลลาร์ต่อเดือน เยี่ยมมาก เกือบจะฟรี เมื่อเทียบกับการวิเคราะห์บนคลัสเตอร์!
อย่างไรก็ตาม นี่คือวิธีที่เราแบ่งส่วนข้อมูลของเราใน s3:
เป็นผลให้ในช่วงเวลาสั้น ๆ แผนกที่แตกต่างกันโดยสิ้นเชิงใน บริษัท ตั้งแต่ความปลอดภัยของข้อมูลไปจนถึงการวิเคราะห์เริ่มส่งคำขอไปยัง Athena และรับคำตอบที่เป็นประโยชน์จากข้อมูล "ขนาดใหญ่" อย่างรวดเร็วในระยะเวลาอันยาวนาน: เดือน ครึ่งปี ฯลฯ ป.
แต่เราไปไกลกว่านั้นและเริ่มไปที่คลาวด์เพื่อหาคำตอบ : นักวิเคราะห์เขียนแบบสอบถาม SQL ในคอนโซลที่คุ้นเคย ซึ่งในเครื่อง 100-500 เครื่อง "สำหรับเพนนี" จะส่งข้อมูลไปที่ s3 และส่งคืนคำตอบโดยปกติภายในไม่กี่วินาที สะดวกสบาย. และรวดเร็ว ฉันยังไม่อยากจะเชื่อเลย
ด้วยเหตุนี้ เมื่อตัดสินใจจัดเก็บข้อมูลใน s3 ในรูปแบบคอลัมน์ที่มีประสิทธิภาพและด้วยการแบ่งส่วนข้อมูลที่เหมาะสมลงในโฟลเดอร์... เราได้รับ DataLake และเครื่องมือวิเคราะห์ที่รวดเร็วและราคาถูก - ฟรี และเขาได้รับความนิยมอย่างมากในบริษัทเพราะว่า... เข้าใจ SQL และทำงานตามลำดับความสำคัญได้เร็วกว่าการเริ่ม/หยุด/ตั้งค่าคลัสเตอร์ “แล้วถ้าผลลัพธ์เท่ากันจะจ่ายแพงกว่าทำไม?”
คำขอไปยัง Athena มีลักษณะเช่นนี้ หากต้องการคุณสามารถสร้างฟอร์มได้เพียงพอ แต่เราจะจำกัดตัวเองอยู่เพียงการจัดกลุ่มแบบง่ายๆ มาดูกันว่ารหัสตอบกลับใดที่ไคลเอ็นต์มีเมื่อไม่กี่สัปดาห์ก่อนในบันทึกของเว็บเซิร์ฟเวอร์ และตรวจสอบให้แน่ใจว่าไม่มีข้อผิดพลาด:
ผลการวิจัย
หลังจากผ่านเส้นทางที่ยาวไกลแต่เจ็บปวด ประเมินความเสี่ยงและระดับความซับซ้อนและค่าใช้จ่ายในการสนับสนุนอย่างเพียงพออย่างต่อเนื่อง เราพบโซลูชันสำหรับ DataLake และการวิเคราะห์ที่ไม่เคยหยุดนิ่งที่จะทำให้เราพึงพอใจทั้งในด้านความเร็วและต้นทุนการเป็นเจ้าของ
ปรากฎว่าการสร้าง DataLake ที่มีประสิทธิภาพ รวดเร็วและราคาถูกสำหรับความต้องการของแผนกที่แตกต่างกันโดยสิ้นเชิงของบริษัทนั้นอยู่ในความสามารถของนักพัฒนาที่มีประสบการณ์ซึ่งไม่เคยทำงานเป็นสถาปนิกมาก่อนและไม่รู้วิธีวาดสี่เหลี่ยมบนสี่เหลี่ยมด้วย ลูกศรและรู้คำศัพท์ 50 คำจากระบบนิเวศ Hadoop
ในช่วงเริ่มต้นของการเดินทาง หัวของฉันแตกแยกจากสวนสัตว์หลายแห่งที่มีซอฟต์แวร์แบบเปิดและแบบปิด และความเข้าใจในภาระความรับผิดชอบต่อผู้สืบทอด เพียงเริ่มสร้าง DataLake ของคุณจากเครื่องมือง่ายๆ: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3... รวบรวมคำติชมและทำความเข้าใจฟิสิกส์ของกระบวนการที่เกิดขึ้นอย่างลึกซึ้ง ทุกอย่างซับซ้อนและมืดมน - มอบให้กับศัตรูและคู่แข่ง
หากคุณไม่ต้องการไปที่ระบบคลาวด์และต้องการสนับสนุน อัปเดต และแพตช์โปรเจ็กต์โอเพนซอร์ส คุณสามารถสร้างโครงร่างที่คล้ายกับแผนของเราในพื้นที่ได้บนเครื่องสำนักงานราคาไม่แพงที่มี Hadoop และ Presto อยู่ด้านบน สิ่งสำคัญคือไม่หยุดและก้าวไปข้างหน้า นับ มองหาวิธีแก้ปัญหาที่ง่ายและชัดเจน แล้วทุกอย่างจะออกมาดีอย่างแน่นอน! ขอให้ทุกคนโชคดีแล้วพบกันใหม่!
ที่มา: will.com