เราจำเป็นต้องมี Data Lake หรือไม่? จะทำอย่างไรกับคลังข้อมูล?

บทความนี้เป็นการแปลบทความของฉันเกี่ยวกับสื่อ - เริ่มต้นใช้งาน Data Lakeซึ่งกลายเป็นที่นิยมอย่างมากอาจเป็นเพราะความเรียบง่าย ดังนั้นฉันจึงตัดสินใจเขียนเป็นภาษารัสเซียและเพิ่มเล็กน้อยเพื่อให้คนทั่วไปที่ไม่ใช่ผู้เชี่ยวชาญด้านข้อมูลเข้าใจได้อย่างชัดเจนว่าคลังข้อมูล (DW) คืออะไร และ Data Lake คืออะไร (Data Lake) และอย่างไร เข้ากันได้

เหตุใดฉันจึงอยากเขียนเกี่ยวกับ Data Lake ฉันทำงานกับข้อมูลและการวิเคราะห์มาเป็นเวลากว่า 10 ปีแล้ว และตอนนี้ฉันกำลังทำงานกับ Big Data ที่ Amazon Alexa AI ในเคมบริดจ์ ซึ่งอยู่ในบอสตัน แม้ว่าฉันจะอาศัยอยู่ในวิกตอเรียบนเกาะแวนคูเวอร์และมักจะไปบอสตัน ซีแอตเทิลบ่อยครั้ง และในแวนคูเวอร์ และบางครั้งแม้แต่ในมอสโกว ฉันก็พูดในที่ประชุม ฉันยังเขียนเป็นครั้งคราว แต่ฉันเขียนเป็นภาษาอังกฤษเป็นหลักและฉันก็เขียนไปแล้ว หนังสือบางเล่มฉันยังต้องแชร์แนวโน้มการวิเคราะห์จากอเมริกาเหนือด้วย และบางครั้งฉันก็เขียนมาด้วย โทรเลข.

ฉันทำงานกับคลังข้อมูลมาโดยตลอด และตั้งแต่ปี 2015 ฉันเริ่มทำงานอย่างใกล้ชิดกับ Amazon Web Services และโดยทั่วไปได้เปลี่ยนไปใช้การวิเคราะห์บนคลาวด์ (AWS, Azure, GCP) ฉันสังเกตเห็นวิวัฒนาการของโซลูชันการวิเคราะห์มาตั้งแต่ปี 2007 และเคยทำงานให้กับผู้จำหน่ายคลังข้อมูล Teradata และนำไปใช้ที่ Sberbank และนั่นคือตอนที่ Big Data พร้อม Hadoop ปรากฏขึ้น ทุกคนเริ่มพูดว่ายุคของการจัดเก็บข้อมูลได้ผ่านไปแล้ว และตอนนี้ทุกอย่างก็อยู่บน Hadoop แล้วพวกเขาก็เริ่มพูดถึง Data Lake อีกครั้งว่าตอนนี้จุดสิ้นสุดของคลังข้อมูลมาถึงแล้วอย่างแน่นอน แต่โชคดี (อาจเป็นโชคร้ายสำหรับบางคนที่ทำเงินได้มากมายในการตั้งค่า Hadoop) คลังข้อมูลก็ไม่หายไป

ในบทความนี้ เราจะดูว่า Data Lake คืออะไร บทความนี้มีไว้สำหรับผู้ที่มีประสบการณ์น้อยหรือไม่มีเลยกับคลังข้อมูล

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

ก่อนอื่น ต่อไปนี้เป็นคำจำกัดความยอดนิยมของ Data Lake:

“พื้นที่จัดเก็บไฟล์ข้อมูลดิบทุกประเภทที่ทุกคนในองค์กรพร้อมสำหรับการวิเคราะห์” - Martin Fowler

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

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

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

ทุกอย่างง่ายมาก เราถ่ายรูปบนโทรศัพท์ รูปภาพจะถูกบันทึกไว้ในโทรศัพท์และสามารถบันทึกลงใน iCloud (ที่เก็บไฟล์บนคลาวด์) โทรศัพท์ยังรวบรวมข้อมูลเมตาของภาพถ่าย: สิ่งที่แสดง แท็กภูมิศาสตร์ เวลา ด้วยเหตุนี้ เราจึงสามารถใช้อินเทอร์เฟซที่ใช้งานง่ายของ iPhone เพื่อค้นหารูปภาพของเรา และเรายังเห็นตัวบ่งชี้ด้วย เช่น เมื่อฉันค้นหารูปภาพที่มีคำว่าไฟ ฉันพบรูปภาพ 3 รูปที่มีรูปภาพของไฟ สำหรับฉัน นี่เป็นเหมือนเครื่องมือ Business Intelligence ที่ทำงานได้อย่างรวดเร็วและชัดเจนมาก

และแน่นอนว่าเราต้องไม่ลืมเกี่ยวกับความปลอดภัย (การอนุญาตและการรับรองความถูกต้อง) มิฉะนั้นข้อมูลของเราอาจกลายเป็นสาธารณสมบัติได้อย่างง่ายดาย มีข่าวมากมายเกี่ยวกับองค์กรขนาดใหญ่และสตาร์ทอัพที่ข้อมูลเปิดเผยต่อสาธารณะเนื่องจากความประมาทเลินเล่อของนักพัฒนาและไม่ปฏิบัติตามกฎง่ายๆ

แม้แต่ภาพง่ายๆ ก็ช่วยให้เราจินตนาการได้ว่า Data Lake คืออะไร ความแตกต่างจากคลังข้อมูลแบบเดิมและองค์ประกอบหลัก:

1. กำลังโหลดข้อมูล (การกลืนกิน) เป็นองค์ประกอบสำคัญของ Data Lake ข้อมูลสามารถเข้าสู่คลังข้อมูลได้สองวิธี - แบทช์ (โหลดตามช่วงเวลา) และสตรีมมิ่ง (กระแสข้อมูล)
2. ที่เก็บไฟล์ (Storage) เป็นองค์ประกอบหลักของ Data Lake เราต้องการให้พื้นที่จัดเก็บข้อมูลสามารถปรับขนาดได้ง่าย เชื่อถือได้อย่างยิ่ง และต้นทุนต่ำ ตัวอย่างเช่น ใน AWS จะเป็น S3
3. แคตตาล็อกและการค้นหา (แคตตาล็อกและการค้นหา) - เพื่อให้เราหลีกเลี่ยง Data Swamp (นี่คือเมื่อเราทิ้งข้อมูลทั้งหมดไว้ในกองเดียว และจากนั้นจึงไม่สามารถดำเนินการได้) เราจำเป็นต้องสร้างชั้นข้อมูลเมตาเพื่อจำแนกข้อมูล เพื่อให้ผู้ใช้สามารถค้นหาข้อมูลที่จำเป็นสำหรับการวิเคราะห์ได้อย่างง่ายดาย นอกจากนี้ คุณยังสามารถใช้โซลูชันการค้นหาเพิ่มเติม เช่น ElasticSearch การค้นหาช่วยให้ผู้ใช้ค้นหาข้อมูลที่ต้องการผ่านอินเทอร์เฟซที่ใช้งานง่าย
4. การประมวลผล (กระบวนการ) - ขั้นตอนนี้รับผิดชอบในการประมวลผลและการแปลงข้อมูล เราสามารถเปลี่ยนข้อมูล เปลี่ยนโครงสร้าง ทำความสะอาด และอื่นๆ อีกมากมาย
5. ความปลอดภัย (ความปลอดภัย) - สิ่งสำคัญคือต้องใช้เวลาในการออกแบบความปลอดภัยของโซลูชัน ตัวอย่างเช่น การเข้ารหัสข้อมูลระหว่างการจัดเก็บ การประมวลผล และการโหลด สิ่งสำคัญคือต้องใช้วิธีการรับรองความถูกต้องและการอนุญาต สุดท้ายนี้ จำเป็นต้องมีเครื่องมือตรวจสอบ

จากมุมมองเชิงปฏิบัติ เราสามารถระบุลักษณะของ Data Lake ได้ด้วยคุณลักษณะสามประการ:

1. รวบรวมและจัดเก็บอะไรก็ได้ — Data Lake ประกอบด้วยข้อมูลทั้งหมด ทั้งข้อมูลดิบที่ยังไม่ได้ประมวลผลในช่วงเวลาใดๆ และข้อมูลที่ถูกประมวลผล/ล้างข้อมูล
2. ตรวจสอบอย่างล้ำลึก — Data Lake ช่วยให้ผู้ใช้สามารถสำรวจและวิเคราะห์ข้อมูลได้
3. การเข้าถึงที่ยืดหยุ่น — Data Lake ให้การเข้าถึงข้อมูลที่แตกต่างกันและสถานการณ์ที่แตกต่างกันได้อย่างยืดหยุ่น

ตอนนี้เราสามารถพูดถึงความแตกต่างระหว่างคลังข้อมูลและ Data Lake ได้แล้ว ปกติแล้วคนจะถามว่า:

• แล้วคลังข้อมูลล่ะ?
• เรากำลังแทนที่คลังข้อมูลด้วย Data Lake หรือเรากำลังขยายคลังข้อมูลหรือไม่
• เป็นไปได้ไหมที่จะทำโดยไม่มี Data Lake?

สรุปคือไม่มีคำตอบที่ชัดเจน ทุกอย่างขึ้นอยู่กับสถานการณ์เฉพาะ ทักษะของทีม และงบประมาณ ตัวอย่างเช่น การย้ายคลังข้อมูลไปยัง Oracle ไปยัง AWS และการสร้าง Data Lake โดย Woot บริษัทในเครือของ Amazon เรื่องราว Data Lake ของเรา: Woot.com สร้าง Data Lake แบบไร้เซิร์ฟเวอร์บน AWS ได้อย่างไร.

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

โดยสรุป ความเห็นส่วนตัวของฉันคือเรายังคงต้องการคลังข้อมูลเป็นแหล่งข้อมูลหลักสำหรับการรายงานของเรา และอะไรก็ตามที่ไม่เหมาะสม เราก็จัดเก็บไว้ใน Data Lake บทบาททั้งหมดของการวิเคราะห์คือการช่วยให้ธุรกิจตัดสินใจได้ง่าย ไม่ว่าใครจะพูดอย่างไร ผู้ใช้ทางธุรกิจก็ทำงานกับคลังข้อมูลได้อย่างมีประสิทธิภาพมากกว่า Data Lake เช่น ใน Amazon มี Redshift (คลังข้อมูลเชิงวิเคราะห์) และมี Redshift Spectrum/Athena (อินเทอร์เฟซ SQL สำหรับ Data Lake ใน S3 ที่ใช้ ไฮฟ์/เพรสโต) เช่นเดียวกับคลังข้อมูลเชิงวิเคราะห์สมัยใหม่อื่นๆ

มาดูสถาปัตยกรรมคลังข้อมูลทั่วไปกัน:

นี่เป็นวิธีแก้ปัญหาแบบคลาสสิก เรามีระบบต้นทาง โดยใช้ ETL/ELT เพื่อคัดลอกข้อมูลลงในคลังข้อมูลเชิงวิเคราะห์และเชื่อมต่อกับโซลูชัน Business Intelligence (รายการโปรดของฉันคือ Tableau แล้วของคุณล่ะ)

โซลูชันนี้มีข้อเสียดังต่อไปนี้:

• การดำเนินงาน ETL/ELT ต้องใช้เวลาและทรัพยากร
• ตามกฎแล้ว หน่วยความจำสำหรับการจัดเก็บข้อมูลในคลังข้อมูลเชิงวิเคราะห์นั้นไม่ถูก (เช่น Redshift, BigQuery, Teradata) เนื่องจากเราจำเป็นต้องซื้อคลัสเตอร์ทั้งหมด
• ผู้ใช้ทางธุรกิจสามารถเข้าถึงข้อมูลที่สะอาดและมักจะรวบรวมไว้ และไม่สามารถเข้าถึงข้อมูลดิบได้

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

ด้วยการใช้แนวทาง Data Lake เราจะโหลดข้อมูลดิบลงใน Data Lake ของเรา (เป็นชุดหรือสตรีมมิ่ง) จากนั้นเราจะประมวลผลข้อมูลตามความจำเป็น Data Lake ช่วยให้ผู้ใช้ทางธุรกิจสามารถสร้างการแปลงข้อมูลของตนเอง (ETL/ELT) หรือวิเคราะห์ข้อมูลในโซลูชัน Business Intelligence (หากมีไดรเวอร์ที่จำเป็น)

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

เมื่อทำงานกับทั้งคลังข้อมูลและ Data Lake เราสามารถเปรียบเทียบทั้งสองโซลูชันได้:

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

ฉันอยากจะเล่าให้คุณฟังถึงกรณีหนึ่งเมื่อฉันเริ่มใช้แนวทาง Data Lake ทุกอย่างค่อนข้างเป็นเรื่องเล็กน้อย ฉันพยายามใช้เครื่องมือ ELT (เรามี Matillion ETL) และ Amazon Redshift โซลูชันของฉันใช้งานได้ แต่ไม่ตรงตามข้อกำหนด

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

1. ทีมการตลาดต้องการวิเคราะห์กิจกรรมบอทสำหรับ SEO
2. ฝ่ายไอทีต้องการดูตัวชี้วัดประสิทธิภาพของเว็บไซต์

บันทึกที่ง่ายมากและง่ายมาก นี่คือตัวอย่าง:

https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188 
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57 
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"

หนึ่งไฟล์มีน้ำหนัก 1-4 เมกะไบต์

แต่มีปัญหาอย่างหนึ่ง เรามี 7 โดเมนทั่วโลก และมีไฟล์ถึง 7000 ไฟล์ถูกสร้างขึ้นในหนึ่งวัน ปริมาณไม่มากเพียง 50 กิกะไบต์เท่านั้น แต่ขนาดของคลัสเตอร์ Redshift ของเราก็เล็กเช่นกัน (4 โหนด) การโหลดไฟล์เดียวด้วยวิธีดั้งเดิมใช้เวลาประมาณหนึ่งนาที นั่นคือปัญหาไม่ได้รับการแก้ไขตรงหน้า และนี่คือกรณีที่ฉันตัดสินใจใช้แนวทาง Data Lake วิธีแก้ปัญหามีลักษณะดังนี้:

มันค่อนข้างง่าย (ฉันต้องการทราบว่าข้อดีของการทำงานบนคลาวด์คือความเรียบง่าย) ฉันใช้:

• AWS Elastic Map ลด (Hadoop) สำหรับพลังการประมวลผล
• AWS S3 เป็นที่จัดเก็บไฟล์ที่มีความสามารถในการเข้ารหัสข้อมูลและจำกัดการเข้าถึง
• จุดประกายเป็นพลังการประมวลผล InMemory และ PySpark สำหรับการแปลงลอจิกและข้อมูล
• ไม้ปาร์เก้อันเป็นผลมาจากสปาร์ค
• AWS Glue Crawler เป็นตัวรวบรวมข้อมูลเมตาเกี่ยวกับข้อมูลและพาร์ติชันใหม่
• Redshift Spectrum เป็นอินเทอร์เฟซ SQL ไปยัง Data Lake สำหรับผู้ใช้ Redshift ที่มีอยู่

คลัสเตอร์ EMR+Spark ที่เล็กที่สุดประมวลผลสแต็กไฟล์ทั้งหมดภายใน 30 นาที มีกรณีอื่นๆ สำหรับ AWS โดยเฉพาะกรณีที่เกี่ยวข้องกับ Alexa ซึ่งมีข้อมูลจำนวนมาก

เมื่อเร็วๆ นี้ ฉันได้เรียนรู้ข้อเสียอย่างหนึ่งของ Data Lake ก็คือ GDPR ปัญหาคือเมื่อลูกค้าขอให้ลบและข้อมูลอยู่ในไฟล์ใดไฟล์หนึ่ง เราไม่สามารถใช้ Data Manipulation Language และ DELETE ได้เหมือนกับในฐานข้อมูล

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

ที่มา: will.com