DataLakes & DataWarehouses: ใช้งานอย่างไรใน SEO

เผยแพร่แล้ว: 2021-02-16

แม้ว่าแนวความคิดของ DataWarehouses และ DataLakes จะกลายเป็นส่วนหนึ่งของภาษาในชีวิตประจำวันของ Data Analyst และ Data Scientists มาเป็นเวลานานแล้ว แต่เราเพิ่งได้ยินเกี่ยวกับสิ่งเหล่านี้ในอุตสาหกรรมอื่นในช่วงไม่กี่ปีที่ผ่านมา
ตัวอย่างเช่น นักวิเคราะห์เว็บและผู้เชี่ยวชาญ SEO กำลังเริ่มพิจารณาแนวคิดเหล่านี้อย่างจริงจัง เนื่องจากลักษณะของงานและการเชื่อมต่อที่แข็งแกร่งระหว่างสิ่งที่พวกเขาทำกับการจัดการข้อมูล บทความล่าสุดจำนวนมากพูดถึงความสนใจในการติดตั้ง SEO DataLake หรือ SEO DataWarehouse โดยถือว่าคำสองคำนี้ใช้แทนกันได้และไม่ทำให้ความแตกต่างระหว่างสองคำนี้

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

DataWarehouse: คลังข้อมูลที่มีโครงสร้างสำหรับข้อมูล

การใช้คำว่า “DataWarehouse” ครั้งแรกเกิดขึ้นในปี 1988 ในบทความของ Paul Murphy และ Barry Delvin สถาปัตยกรรมสำหรับธุรกิจและระบบสารสนเทศ บทความนี้ให้คำจำกัดความแรกของแนวคิดว่าเป็นสภาพแวดล้อมฐานข้อมูลเชิงสัมพันธ์ที่เข้าถึงได้ง่าย โดยรวบรวมข้อมูลทางธุรกิจทั้งหมดที่เป็นประโยชน์สำหรับการตัดสินใจเชิงกลยุทธ์

DataWarehouse ประกอบด้วยอะไรบ้าง?

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

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

ใครคือผู้ใช้ DataWarehouse รายวัน?

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

ผู้ใช้สื่อสารกับ DataWarehouse อย่างไร

เมื่อระบุแหล่งข้อมูลแล้ว และข้อมูลที่ประมวลผล นำเข้า และเชื่อมโยงใน DataWarehouse แล้ว Data Analyst สามารถใช้ข้อมูลนี้ในการวิเคราะห์และเพื่อสร้างชุดข้อมูลใหม่ กระบวนการนี้สามารถใช้เพื่อรักษาแดชบอร์ดการรายงาน แดชบอร์ดการแจ้งเตือน ฯลฯ

ภาษาโปรแกรมที่ใช้บ่อยที่สุดสำหรับการสืบค้นใน DataWarehouse คือ SQL (หรือภาษาที่คล้าย SQL) SQL ช่วยให้ Data Analysts สามารถจัดการและประมวลผลข้อมูลเพื่อตอบสนองความต้องการทางธุรกิจ: การตรวจสอบ การตัดสินใจเชิงกลยุทธ์ ฯลฯ

DataWarehouses ให้บริการกรณีการใช้งานและประเภทโครงการใดบ้าง

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

การปรับปรุง DataWarehouse:
โปรเจ็กต์ประเภทนี้มักพบเมื่อตั้งค่า DataWarehouse แต่ยังรวมถึงเมื่อมีการระบุความต้องการใหม่หรือกรณีการใช้งานทางธุรกิจ
เป็นคำถามในการเพิ่มข้อมูลใหม่ให้กับ DWH (อีกครั้ง นี่อาจเป็นข้อมูลภายในหรือข้อมูลภายนอก)
ในกรณีนี้ เรามักจะพูดถึงกระบวนการ ETL (Extraction-Transformation-Loading):

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

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

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

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

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

นี่เป็นกรณีน้อยกว่าสำหรับแนวคิดของ DataLakes ซึ่งอายุน้อยกว่าและแพร่หลายน้อยกว่ามาก

Oncrawl Data³

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

DataLake: ทะเลสาบของเมกะดาต้า (BigData)

ที่มาของแนวคิดนี้มาจาก James Dixon, CTO ของ Penthao ผู้ซึ่งนิยามแนวคิดนี้ว่าเป็นโซลูชันสำหรับการจัดเก็บและใช้ประโยชน์จากข้อมูลจำนวนมาก โดยไม่ต้องมีการประมวลผลล่วงหน้าและไม่จำเป็นต้องมีกรณีการใช้งานเฉพาะ... ต่างจาก DWH ซึ่งมุ่งเน้นอย่างมาก ต่อการเปิดใช้งานทันที
DL พยายามเติมช่องว่าง ซึ่งมีความสำคัญมากขึ้นเรื่อยๆ กับการเกิดขึ้นของ BigData ว่าจะทำอย่างไรกับข้อมูลจำนวนมหาศาลที่เราสามารถรวบรวมได้ในวันนี้ และวิธีใช้ประโยชน์จากข้อมูลดังกล่าว

DataLake ประกอบด้วยอะไรบ้าง?

ฉันจะเริ่มต้นด้วยการอ้างคำพูดของ James Dixon ที่ใช้การเปรียบเทียบที่น่าสนใจมาก โดยทำหน้าที่เป็นทั้งคำอธิบายสำหรับชื่อ "ทะเลสาบ" ของแนวคิดของเขาและเพื่อสร้างความแตกต่างกับ DWH:

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

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

ในกรณีที่ DWH ถูกจำกัดเพื่อรองรับข้อมูลที่มีโครงสร้าง DataLake ถูกสร้างขึ้นเพื่อจัดเก็บข้อมูลดิบทุกประเภท (มีโครงสร้างหรือไม่) การอภิปรายระหว่าง Tamara Dull (Amazon Web Service) และ Anne Buff (Microsoft SAS) ทำให้เรามีวิสัยทัศน์ที่ชัดเจนขึ้นเล็กน้อยเกี่ยวกับเนื้อหาของ DataLake:

“ Data Lake เป็นที่เก็บข้อมูลที่มีข้อมูลดิบจำนวนมากในรูปแบบดั้งเดิม ซึ่งรวมถึงข้อมูลที่มีโครงสร้าง กึ่งมีโครงสร้าง และไม่มีโครงสร้าง โครงสร้างข้อมูลและข้อกำหนดไม่ได้กำหนดไว้จนกว่าข้อมูลจะมีความจำเป็น”

ใครคือผู้ใช้ DataLakes รายวัน?

ในที่ที่ Data Analyst เหมาะสมอย่างยิ่งที่จะทำงานกับข้อมูลที่มีโครงสร้างที่มีอยู่ใน DHW ข้อมูลดิบจะเป็นความเชี่ยวชาญพิเศษของ Data Scientists แทน ซึ่งมักจะพร้อมดีกว่าในการจัดการข้อมูลประเภทนี้
การเปลี่ยนแปลงในโปรไฟล์ข้อมูลและผู้ใช้หลักยังส่งผลให้เกิดภาษาโปรแกรมและกรณีการใช้งานที่แตกต่างกัน

DataLakes ให้บริการกรณีการใช้งานและประเภทโครงการใดบ้าง

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

  • การใช้อัลกอริธึมการเรียนรู้ของเครื่องเพื่อสร้างมูลค่าเพิ่มให้กับ BigData:
    เรามักพูดถึงการวิเคราะห์เชิงคาดการณ์ที่นี่ โดยอิงจากอัลกอริธึมการเรียนรู้ของเครื่องที่ใช้ประโยชน์จากข้อมูลทุกประเภท
    เพื่อยกตัวอย่างที่เป็นรูปธรรมมากขึ้น สมมติว่าบริษัทในภาคการเงิน (การธนาคารและการประกันภัย) ต้องการกำหนดความน่าจะเป็นที่ธุรกรรมทางการเงิน X จะฉ้อโกง ซึ่งอาจเรียก Data Scientists ที่สามารถสร้างอัลกอริธึมการเรียนรู้ของเครื่องที่จะฝึกอบรมเกี่ยวกับปริมาณข้อมูลทางดาราศาสตร์ที่มีอยู่ใน DataLake (จำนวน วันที่ ความถี่ โปรไฟล์ปกติของการทำธุรกรรมที่ดำเนินการโดยเจ้าของบัญชี ฯลฯ) เป้าหมายคือการดำเนินการศึกษาเชิงคาดการณ์ที่จะใช้เพื่อระบุธุรกรรมที่อาจเป็นการฉ้อโกง และทำให้บริษัทลดเวลาในการตอบสนองในการตรวจจับและหลีกเลี่ยงการสูญเสียครั้งใหญ่สำหรับพวกเขาและลูกค้าในท้ายที่สุด
    นี่เป็นตัวอย่างง่ายๆ ที่ใช้เป็นประจำเพื่อแสดงความสนใจและมูลค่าเพิ่มของแมชชีนเลิร์นนิง แต่มีอีกมากเท่าที่คุณจะจินตนาการได้
  • DataLakes เป็นแหล่งข้อมูลสำหรับ DataWarehouse:
    พูดง่ายๆ ก็คือ DataLake สามารถทำหน้าที่เป็นเขตการขนส่งระหว่างแหล่งข้อมูลภายในและภายนอกต่างๆ กับ DWH ของคุณ หลักการของ DataLake ก็คือการรวมศูนย์ข้อมูลทุกประเภท ทั้งแบบมีโครงสร้างและแบบไม่มีโครงสร้าง เพื่อดำเนินการศึกษาเชิงพยากรณ์ผ่าน ML หรือสำหรับการสกัดเป็นตัวอย่างสำหรับการวิเคราะห์ DWH จึงดูเหมาะสมมากสำหรับโครงการประเภทที่สองนี้ และได้รับประโยชน์จาก DataLake เป็นแหล่งที่มีศักยภาพ (โดยมีเงื่อนไขว่าข้อมูล DataLake จะถูกนำเข้าในลักษณะที่มีโครงสร้างผ่านการประมวลผลล่วงหน้า หากจำเป็น)
  • จากซอฟต์แวร์ DataLake ถึง BI (Business Intelligence):
    เราสามารถเห็นสิ่งนี้เป็นการใช้งานที่คล้ายกับที่เราเห็นใน DataWarehouses โดยคิดว่ามีความจำเพาะเจาะจงบางอย่างสำหรับการใช้ DataLake เพื่อจุดประสงค์นี้ DataLake จะช่วยให้คุณสร้างภาพที่แปลกใหม่ขึ้นเล็กน้อย (เนื่องจากข้อมูลที่มีอยู่หลากหลาย) ผ่านเครื่องมือต่างๆ เช่น Tableau, Qlikview, Google Data Studio, Microstrategy เป็นต้น

ผู้ใช้สื่อสารกับ DataLake อย่างไร

จากกรณีการใช้งานและผู้ใช้ (นักวิทยาศาสตร์ข้อมูล) เรามักจะพบภาษาโปรแกรมเช่น Python, Java, R, Scala ฯลฯ...
โดยส่วนใหญ่แล้ว ภาษาเหล่านี้มีอยู่ในสาขาวิทยาศาสตร์ข้อมูลมาเป็นเวลานาน

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

โดยสรุป ต่อไปนี้คือตารางองค์ประกอบที่สร้างความแตกต่างตั้งแต่ตอนต้นของบทความนี้:

คลังข้อมูล DataLake
ประเภทของข้อมูล ข้อมูลที่มีโครงสร้าง ประมวลผลล่วงหน้า จัดระเบียบในตารางด้วยสคีมาที่กำหนดไว้ ข้อมูลดิบ จัดเก็บในลักษณะที่มีโครงสร้างหรือไม่มีโครงสร้าง
ผู้ใช้ นักวิเคราะห์ข้อมูล นักวิเคราะห์เว็บ นักวิทยาศาสตร์ข้อมูล
(บางครั้งนักวิเคราะห์ข้อมูล)
ปริมาณข้อมูล เล็ก-ใหญ่
(แล้วแต่ความต้องการและกรณีการใช้งาน)
อาจมีขนาดใหญ่มาก
(ข้อมูลใหญ่)
ภาษาโปรแกรมที่ใช้ SQL หรือ SQL-like Python, R, Java, Scala และอื่นๆ
ประเภทโครงการ โครงการวิเคราะห์และสถิติ การรายงาน การแจ้งเตือน โครงการประเภท ELT (ส่งออก แปลง โหลด) การวิเคราะห์เชิงคาดการณ์และบางส่วนจากข้อมูล การวิเคราะห์เชิงคาดการณ์, การเรียนรู้ของเครื่อง, เขตการขนส่งระหว่างแหล่งข้อมูลและ DWH, การแสดงภาพขั้นสูง – BI, การวิเคราะห์ที่ขับเคลื่อนด้วยข้อมูล

การวิเคราะห์เชิงคาดการณ์, การเรียนรู้ของเครื่อง, เขตการขนส่งระหว่างแหล่งข้อมูลและ DWH, การแสดงภาพขั้นสูง – BI, การวิเคราะห์ที่ขับเคลื่อนด้วยข้อมูล

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

ในความเห็นของฉัน DataLakes ตอบสนองต่อปัญหาข้อมูลใหม่ในศตวรรษที่ 21 มากกว่า โดยเฉพาะอย่างยิ่งกับการเกิดขึ้นของ BigData และความสามารถที่เพิ่มขึ้นของบริษัทในการรวบรวมข้อมูล มากกว่าการแทนที่ DWH อย่างที่บางคนอาจคิด
ทั้งสองมีข้อดี ข้อเสีย จุดแข็ง และจุดอ่อน วิธีที่ดีที่สุดในการใช้ประโยชน์สูงสุดจากทั้งสองอย่างคือยังคงใช้ทั้งสองร่วมกันเพื่อให้สามารถจัดการกับเหตุการณ์ที่ไม่คาดฝันและเพื่อตอบสนองความต้องการที่หลากหลายมากขึ้น

ตอนนี้เราได้กำหนดแนวคิดไว้อย่างชัดเจนแล้ว ในที่สุดเราจะมุ่งเน้นไปที่การใช้ DataWarehouses และ DataLakes สำหรับการตลาดและเฉพาะเจาะจงมากขึ้นสำหรับ SEO (แม้ว่าในหลาย ๆ กรณีสิ่งที่เป็นจริงสำหรับอดีตจะเป็นความจริงสำหรับหลังและรอง ในทางกลับกัน)

DataWarehouse และ DataLake SEO

เราจะพูดถึง DataWarehouse หรือ DataLake (หรือทั้งสองอย่าง) ในที่นี้ โดยที่ข้อมูลที่มีอยู่อย่างน้อยบางส่วนสามารถนำมาใช้สำหรับกรณีการใช้งาน SEO ได้

เหตุใดจึงเชื่อมโยง DataLakes และ DataWarehouses กับการตลาดและ SEO

SEO (และโดยทั่วๆ ไปคือ การตลาด) ได้เปลี่ยนไปใช้ข้อมูลอย่างเห็นได้ชัดในช่วงไม่กี่ปีที่ผ่านมา งานมากขึ้นเรื่อยๆ ต้องใช้แหล่งข้อมูลที่หลากหลาย:

  • ข้อมูลวิเคราะห์ (Google Analytics, AT internet เป็นต้น)
  • ข้อมูลประสิทธิภาพ (Google Search Console, Analytics)
  • บันทึกข้อมูล ซึ่งเป็น "แหล่งที่มา" ของข้อมูลขนาดใหญ่มากสำหรับบางไซต์ ซึ่งต้องการความถี่ในการอัปเดตสูงและความจุขนาดใหญ่
  • ข้อมูลเน็ตลิงค์ (Majestic, Ahrefs, Babbar)
  • ข้อมูลการจัดตำแหน่ง (SEMRush, Monitorank เป็นต้น)
  • รวบรวมข้อมูล (OnCrawl เป็นต้น)
  • บางครั้งข้อมูลธุรกิจ/อุตสาหกรรมก็เช่นกัน

ในรายการนี้ เราควรเพิ่มการใช้ API ของเครื่องมือ เช่น Search Console, Majestic, Google Analytics เป็นต้น ซึ่งโดยปกติแล้วจะผลักดันเราไปสู่โซลูชันประเภทต่างๆ ที่อธิบายไว้ก่อนหน้าในบทความนี้
การเชื่อมต่อที่แน่นแฟ้นระหว่าง SEO กับข้อมูลที่ผลักดันให้นักวิเคราะห์เว็บและผู้เชี่ยวชาญ SEO เรียนรู้เกี่ยวกับวิธีการใหม่ในการจัดระเบียบไปป์ไลน์ข้อมูลของพวกเขา

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

กรณีการใช้งานของ SEO DataWarehouse หรือ SEO DataLake

ฉันจะเริ่มจากจุดปวดที่ผู้เชี่ยวชาญ SEO มักพบก่อนจะอธิบายว่าการใช้ DataLake หรือ DataWarehouse เป็นคำตอบที่ควรพิจารณาเมื่อกล่าวถึงอย่างไร
ในบรรดาจุดปวดหลัก ๆ สิ่งต่อไปนี้โดดเด่น:

  • การทวีคูณของไฟล์ Excel (กระดาษหลวมของทศวรรษของเรา) และการคัดลอกและวางที่เกี่ยวข้อง:
    สำหรับ SEO หลายๆ คน สิ่งนี้ยังคงเป็นบรรทัดฐาน แต่บอกตามตรง มันใช้เวลานาน มีข้อจำกัด และเอื้อต่อข้อผิดพลาดของมนุษย์ได้มาก สำหรับสิ่งนี้ DataWarehouse เป็นโซลูชันที่สมบูรณ์แบบ DataWarehouses ไม่เพียงแต่อนุญาต KPI ทั้งหมดที่จำเป็นเพื่อดำเนินการตรวจสอบ/วิเคราะห์นี้หรือนั้นเพื่อรวบรวมจากแหล่งข้อมูลต่างๆ ที่มีอยู่ แต่ยังอนุญาตให้มีการประมวลผลที่จำเป็นเพื่อให้ได้ผลลัพธ์ที่คาดหวังให้เป็นแบบอัตโนมัติ
    เมื่อสร้าง DataWarehouse แล้ว จะมีการระบุกรณีการใช้งานมากขึ้นเรื่อยๆ และปัญหาได้รับการแก้ไขมากขึ้นเรื่อยๆ ซึ่งนำไปสู่การประหยัดเวลาได้อย่างมีนัยสำคัญมากขึ้นเมื่อเวลาผ่านไป
  • ขีดจำกัดความจุ (เพื่อเป็นการเตือนความจำว่า Excel สามารถเปิดทั้งไฟล์ได้ก็ต่อเมื่อมีขนาดไม่เกิน 1,048,576 บรรทัด ดูเหมือนว่าจะเยอะ แต่จริงๆ แล้วไม่ได้มากมายขนาดนั้นในวอลุ่มของวันนี้): จริงๆ แล้วไม่มีกรณีการใช้งานเฉพาะใดๆ เลย เนื่องจากใน โดยทั่วไปแล้วทั้ง DataLakes และ DataWarehouses จะไม่ได้รับผลกระทบจากข้อจำกัดประเภทนี้ ทั้งสองเสนอวิธีการขอข้อมูลปริมาณมากสำหรับความต้องการทุกประเภท สำหรับกรณีเฉพาะนี้ สิ่งสำคัญคือต้องจำไว้ว่า ขึ้นอยู่กับความต้องการ อย่างใดอย่างหนึ่งจะช่วยให้คุณเป็นอิสระจากขีดจำกัดความสามารถ และในท้ายที่สุด เพื่อจัดการกับสถานการณ์เหล่านี้ได้ง่ายขึ้น
  • ตอบสนองต่อความจำเป็นในการเก็บประวัติข้อมูล
    สปอยเลอร์: หนึ่งในกรณีการใช้งานสามารถ เช่น เพื่อบันทึกประวัติของข้อมูลจาก Google Search Console ใน SEO DataWarehouse แทนที่จะคัดลอกและเพจข้อมูลใน Google ชีตทุกสัปดาห์เพื่อดูแลแดชบอร์ด Data Studio ใน ความคิดเห็นของฉัน เรามีกรณีการใช้งานที่พบบ่อยที่สุดกรณีหนึ่งในหมู่ผู้เชี่ยวชาญ SEO ไม่ว่าจะเป็นในหน่วยงานหรือภายในองค์กร: การทำประวัติข้อมูล อันที่จริง นักวิเคราะห์ SEO หลายคนดูข้อมูลในอดีตและหาข้อสรุปจากข้อมูลนั้น
    ตัวอย่างที่อาจเข้ามาในหัวคุณโดยตรงคือกรณีของ Google Search Console ให้การเข้าถึงประวัติ 16 เดือนในวันนี้เท่านั้น (แม้ผ่าน API) และหากงานในมือยังคงเป็นไปได้ผ่านการส่งออกที่จะวางลงใน Google ชีตทุกสัปดาห์ (หรือวิธีการอื่น ๆ ที่ไม่ชัดเจน) ก็จะเป็นการเสียเวลาอย่างมากนอกจากจะเจ็บปวดและน่าเบื่อแล้ว
    นั่นเป็นสิ่งที่ดีเพราะเป็นปัญหาที่ค่อนข้างง่ายในการจัดการกับ DataWarehouse สิ่งที่คุณต้องทำคือตั้งค่าการเชื่อมต่ออัตโนมัติกับ Google Search Console API กำหนดการประมวลผลล่วงหน้าและการรวมข้อมูลที่เป็นไปได้ต่างๆ ที่จำเป็นเพื่อให้ได้ข้อมูลที่มีมูลค่าเพิ่มจริง และสุดท้าย ทำการเรียก API โดยอัตโนมัติ
  • ความปรารถนาที่จะวิเคราะห์เพิ่มเติม เพื่อรวมหรือ "วิเคราะห์ข้าม" ข้อมูลการรวบรวมข้อมูล ข้อมูลผู้ชม บันทึก ฯลฯ ในรูปแบบอุตสาหกรรม
    เนื่องจากความได้เปรียบทางการแข่งขันเพียงเล็กน้อยไม่เคยสร้างความเสียหาย คำอธิบายที่เราได้ให้ไว้เกี่ยวกับ DataWarehouse และ DataLake ได้อธิบายไว้ที่นี่ จุดมุ่งหมายหลักของทั้งสองเครื่องมือคือการเปิดโอกาสใหม่ๆ สำหรับการวิเคราะห์ ผ่านการรวบรวมข้อมูลและการวิเคราะห์ข้ามสาย และ/หรือการเรียนรู้ของเครื่อง
    เพื่อยกตัวอย่างเพียงตัวอย่างเดียวเท่านั้น การใช้อัลกอริธึมการเรียนรู้ของเครื่อง เช่น Random Forest หรือ XG-Boost เพื่อคาดการณ์การจัดอันดับบน Google
    แนวคิดง่ายๆ คือ การฝึกอัลกอริทึมบน Google SERP จำนวนมาก (หน้าผลลัพธ์) และเมตริก SEO ทั้งหมดที่สามารถเก็บเกี่ยวได้สำหรับ SERP เหล่านี้ เพื่อกำหนดศักยภาพในการจัดอันดับของ URL ที่กำหนด (และ ดังนั้น โดยเฉพาะอย่างยิ่ง เพื่อกำหนดตัวชี้วัดที่สำคัญที่สุดในการจัดอันดับในภาค/ธีมเฉพาะ)
    → คุณจะพบวิธีการที่สมบูรณ์ในบทความโดย Vincent Terrasi ผู้อำนวยการฝ่ายผลิตภัณฑ์ของ Oncrawl “คาดการณ์การจัดอันดับ Google ที่ล้ำยุคของวิทยาศาสตร์ข้อมูลได้สำเร็จ” , 2018
  • ความปรารถนาที่จะทำให้การรายงานเป็นอัตโนมัติมากที่สุดเท่าที่จะเป็นไปได้ เพื่อมุ่งเน้นไปที่งานที่มีมูลค่าเพิ่มสูง อีกครั้ง สิ่งนี้อยู่ในกรณีการใช้งานแบบคลาสสิกของ DataWarehouse เสนอความเป็นไปได้ในการทำให้การกู้คืนทั้งหมดและการประมวลผลของแหล่งข้อมูลต่างๆ เป็นไปโดยอัตโนมัติ และจัดการกับจุดปวดนี้ได้อย่างสมบูรณ์แบบ เมื่อตั้งค่าแล้ว ตารางจะถูกป้อนโดยอัตโนมัติใน DWH และสามารถใช้เป็นการเชื่อมต่อกับซอฟต์แวร์ BI สำหรับแดชบอร์ด ไม่ว่าจะเป็นสำหรับการตรวจสอบ การแจ้งเตือน ฯลฯ แน่นอนว่าระบบอัตโนมัติไม่ได้หยุดอยู่แค่การรายงานโครงการเพียงอย่างเดียว ทั้ง DWH และ DL สามารถใช้สำหรับการเพิ่มประสิทธิภาพ SEO อัตโนมัติได้หลายอย่าง ตัวอย่างเช่น การอัปเดตแบบไดนามิกสำหรับบล็อกลิงก์ภายในที่อันดับ งบประมาณการรวบรวมข้อมูล ผู้ชม SEO ฯลฯ (ข้อมูลทั้งหมดอยู่ใน DWH)
  • ความปรารถนาที่จะยุติปัญหาด้านความปลอดภัยทันทีและเพื่อทั้งหมด (เรารู้ว่าใครทำอะไรและจะหาได้ที่ไหน) และหลีกเลี่ยงการใช้เวลาในการบำรุงรักษา เราขอจบที่นี่ด้วยแง่มุมที่มุ่งเน้นกระบวนการมากกว่ากรณีการใช้งาน พูดอย่างเคร่งครัด
    ทั้ง DataLakes และ DataWarehouses บ่งบอกถึงการใช้งานกระบวนการเฉพาะ ซึ่งสามารถนำเสนอด้วยวิธีง่าย ๆ ดังต่อไปนี้:

    • จุดเริ่มต้นคือการสังเกตที่แบ่งออกเป็นคำแถลงความต้องการ (ทีมธุรกิจ / SEO – นักวิเคราะห์ข้อมูล)
    • จากนั้นสิ่งนี้จะถูกแปลงเป็นข้อกำหนดทางเทคนิคเพิ่มเติมที่จะช่วยให้ทีมที่ดูแลเครื่องมือเพื่อทำความเข้าใจว่าต้องทำอะไรและต้องทำอย่างไร
    • ทีมบริหารเดียวกันนี้ดำเนินการตามคำขอ
    • ทีมธุรกิจและนักวิเคราะห์ข้อมูลจัดทำกรณีการใช้งานตามขั้นตอนสำหรับงานที่ดำเนินการ
    • มีกระบวนการต่อเนื่องที่ปลายทั้งสองด้านของห่วงโซ่ (ทีมธุรกิจและทีมบริหารของ DataWarehouse หรือ DataLake) ตรวจสอบให้แน่ใจว่าไม่มีอะไรเปลี่ยนแปลงในแง่ของอินพุตและเอาต์พุต
      โดยเฉพาะอย่างยิ่งกรณีของ DWH ซึ่งจะปฏิเสธข้อมูลใดๆ ที่ไม่ได้เป็นส่วนหนึ่งของโครงสร้าง (สคีมาที่กำหนดไว้ล่วงหน้า)

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

การเลือก DataWarehouse หรือ DataLake สำหรับการใช้งาน SEO ของคุณ

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

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