ระบบวิเคราะห์เซิร์ฟเวอร์

นี่เป็นส่วนที่สองของชุดบทความเกี่ยวกับระบบการวิเคราะห์ (ลิงค์ไปยังส่วนที่ 1).

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

นักวิเคราะห์ลูกค้า

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

นักวิเคราะห์เซิร์ฟเวอร์

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

ข้อดี
cons

คุณสามารถปรับแต่งอะไรก็ได้
บ่อยครั้งเป็นเรื่องยากมากและจำเป็นต้องมีนักพัฒนาแยกต่างหาก

ประการที่สอง: ใช้บริการ SaaS (Amazon, Google, Azure) แทนที่จะปรับใช้ด้วยตนเอง เราจะพูดถึงรายละเอียดเพิ่มเติมเกี่ยวกับ SaaS ในส่วนที่สาม

ข้อดี
cons

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

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

วิธีรวบรวมการวิเคราะห์เซิร์ฟเวอร์

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

1. การได้มาซึ่งข้อมูล

เช่นเดียวกับในกรณีของการวิเคราะห์ลูกค้า ประการแรก นักวิเคราะห์บริษัทจะเลือกประเภทของเหตุการณ์ที่ต้องการศึกษาเพิ่มเติมและรวบรวมไว้ในรายการ โดยปกติแล้ว เหตุการณ์เหล่านี้จะเกิดขึ้นในลำดับที่แน่นอน ซึ่งเรียกว่า "รูปแบบเหตุการณ์"
นอกจากนี้ ลองจินตนาการว่าแอปพลิเคชันมือถือ (เว็บไซต์) มีผู้ใช้ทั่วไป (อุปกรณ์) และเซิร์ฟเวอร์จำนวนมาก เพื่อถ่ายโอนเหตุการณ์อย่างปลอดภัยจากอุปกรณ์ไปยังเซิร์ฟเวอร์ จำเป็นต้องมีเลเยอร์กลาง ขึ้นอยู่กับสถาปัตยกรรม คิวเหตุการณ์ต่างๆ มากมายสามารถเกิดขึ้นได้
Apache Kafka - เป็น คิวผับ/ย่อยซึ่งใช้เป็นคิวในการรวบรวมเหตุการณ์

ตามที่ โพสต์บน Quora ในปี 2014 ผู้สร้าง Apache Kafka ตัดสินใจตั้งชื่อซอฟต์แวร์ตาม Franz Kafka เนื่องจาก “เป็นระบบที่ปรับให้เหมาะสมในการเขียน” และเพราะเขาชอบงานเขียนของ Kafka — วิกิพีเดีย

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

(รูปภาพ ด้วยเหตุนี้)

ในเวลาเดียวกัน Kafka ช่วยให้คุณสามารถอ่านเป็นชิ้น ๆ และประมวลผลโฟลว์ของเหตุการณ์เป็นชุดย่อยได้ Kafka เป็นเครื่องมือที่สะดวกมากซึ่งปรับขนาดได้ดีกับความต้องการที่เพิ่มขึ้น (เช่น ตามตำแหน่งทางภูมิศาสตร์ของเหตุการณ์)
โดยปกติแล้ว ชิ้นส่วนเดียวก็เพียงพอแล้ว แต่สิ่งต่างๆ จะซับซ้อนมากขึ้นด้วยการสื่อสารเมื่อปรับขนาด (เช่นเคย) อาจไม่มีใครต้องการใช้ชิ้นส่วนจริงเพียงชิ้นเดียวในการผลิต เนื่องจากสถาปัตยกรรมต้องทนทานต่อข้อผิดพลาด นอกจาก Kafka แล้ว ยังมีโซลูชันอื่นที่รู้จักกันดีนั่นคือ RabbitMQ เราไม่ได้ใช้มันในการผลิตเป็นคิวสำหรับการวิเคราะห์เหตุการณ์ (หากคุณมีประสบการณ์ดังกล่าว โปรดบอกเราเกี่ยวกับเรื่องนี้ในความคิดเห็น!) อย่างไรก็ตาม มีการใช้ AWS Kinesis

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

2. การจัดการกระแสเหตุการณ์

หลังจากที่เราได้เตรียมกิจกรรมทั้งหมดและวางไว้ในคิวที่เหมาะสมแล้ว เราจะไปยังขั้นตอนการประมวลผล ที่นี่ฉันจะพูดถึงสองตัวเลือกการประมวลผลที่พบบ่อยที่สุด
ตัวเลือกแรกคือเปิดใช้งาน Spark Streaming บนระบบ Apache ผลิตภัณฑ์ Apache ทั้งหมดใช้งานบน HDFS ซึ่งเป็นระบบไฟล์จำลองที่ปลอดภัย Spark Streaming เป็นเครื่องมือที่ใช้งานง่ายซึ่งประมวลผลข้อมูลสตรีมมิ่งและปรับขนาดได้ดี อย่างไรก็ตาม การบำรุงรักษาอาจทำได้ยาก
อีกทางเลือกหนึ่งคือการสร้างตัวจัดการเหตุการณ์ของคุณเอง เมื่อต้องการทำเช่นนี้ คุณต้องเขียนแอปพลิเคชัน Python สร้างแอปพลิเคชันดังกล่าวใน Docker และสมัครรับคิวของ Kafka เมื่อทริกเกอร์มาถึงตัวจัดการใน Docker การประมวลผลจะเริ่มต้นขึ้น ด้วยวิธีนี้ คุณจะต้องให้แอปพลิเคชันทำงานอย่างต่อเนื่อง
สมมติว่าเราได้เลือกหนึ่งในตัวเลือกที่อธิบายไว้ข้างต้นและดำเนินการประมวลผลต่อไป ผู้ประมวลผลควรเริ่มต้นด้วยการตรวจสอบความถูกต้องของข้อมูล กรองขยะและเหตุการณ์ "เสียหาย" สำหรับการตรวจสอบเรามักจะใช้ เซอร์เบอรัส. หลังจากนั้น สามารถทำการแมปข้อมูลได้ โดยข้อมูลจากแหล่งต่างๆ จะถูกทำให้เป็นมาตรฐานและเป็นมาตรฐานเพื่อที่จะเพิ่มลงในตารางทั่วไป

3. ฐานข้อมูล

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

4. การรวมกลุ่ม

หลังจากบันทึกเหตุการณ์ทั้งหมดอย่างรอบคอบแล้ว เราต้องการรวบรวมข้อมูลสำคัญทั้งหมดจากชุดที่มาและอัปเดตฐานข้อมูล เราต้องการแดชบอร์ดและตัวชี้วัดที่เกี่ยวข้องทั่วโลก ตัวอย่างเช่นจากกิจกรรมไปจนถึงการรวบรวมโปรไฟล์ผู้ใช้และการวัดพฤติกรรม เหตุการณ์จะถูกรวบรวม รวบรวม และบันทึกอีกครั้ง (มีอยู่ในตารางผู้ใช้แล้ว) ในเวลาเดียวกัน คุณสามารถสร้างระบบในลักษณะที่ตัวกรองเชื่อมต่อกับผู้รวบรวมที่ประสานงานด้วย เพื่อรวบรวมผู้ใช้จากเหตุการณ์บางประเภทเท่านั้น
หลังจากนั้น หากคนในทีมต้องการเพียงการวิเคราะห์ระดับสูง คุณสามารถเชื่อมต่อระบบการวิเคราะห์ภายนอกได้ คุณสามารถใช้ Mixpanel อีกครั้ง แต่เนื่องจากมีราคาค่อนข้างแพง จึงไม่ได้ส่งกิจกรรมผู้ใช้ทั้งหมดไปที่นั่น แต่จะส่งเฉพาะสิ่งที่จำเป็นเท่านั้น ในการทำเช่นนี้ เราจำเป็นต้องสร้างผู้ประสานงานที่จะถ่ายโอนเหตุการณ์ดิบบางอย่างหรือสิ่งที่เรารวบรวมไว้ก่อนหน้านี้ไปยังระบบภายนอก API หรือแพลตฟอร์มโฆษณา

5. ส่วนหน้า

คุณต้องเชื่อมต่อส่วนหน้ากับระบบที่สร้างขึ้น ตัวอย่างที่ดีคือการบริการ แดงเป็น GUI ฐานข้อมูลที่ช่วยสร้างพาเนล การโต้ตอบทำงานอย่างไร:

1. ผู้ใช้สร้างแบบสอบถาม SQL
2. เขาได้รับสัญญาณตอบกลับ
3. สร้าง 'การแสดงภาพใหม่' ให้กับมันและรับกราฟที่สวยงามซึ่งคุณสามารถช่วยตัวเองได้แล้ว

การแสดงภาพในบริการเป็นการอัปเดตอัตโนมัติ คุณสามารถกำหนดค่าและติดตามการตรวจสอบของคุณได้ Redash นั้นฟรี ในกรณีที่โฮสต์เอง แต่สำหรับ SaaS จะมีราคา 50 ดอลลาร์ต่อเดือน

ข้อสรุป

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

ขอบคุณที่อ่าน! ฉันยินดีที่จะตอบคำถามในความคิดเห็น

ที่มา: will.com