Datalake ยังไง(วะ)? #2 : Lambda Architecture
โพสที่แล้ว
จบไว้ที่ภาพนี้
หนังสือเล่มนี้ จบที่ภาพนี้เลย ถ้าเข้าใจก็จบเลย
ตามที่เกริ่นไปโพสที่แล้วนะครับ ตัว pattern ของ Lambda architecture มันถูกออกแบบให้สามารถขยายได้(scalable) ทำงานแบบ distributed computing(สามารถให้สั่งให้มันประมวลผลแบบหลายๆ เครื่องช่วยกัน) ได้ดี ทั้งกับการทำ batch และ real-time processing
มาลงรายละเอียดกันนะครับ ว่าแต่ชั้นเนี่ย มันควรมีคุณสมบัติอะไรบ้าง
Data Acquisition Layer
ชั้นนี้ จะรับข้อมูลมาจากหลายแหล่ง หลายรูปแบบ แต่รูปแบบ ยังไงก็ไม่หลุดไปจาก Structured, Semi-structured และ Unstructured หรอกครับ แต่จากส่วนใหญ่ที่เจอ มันจะเป็น data source อย่างระบบ database ทั้ง RDBMS หรือ NoSQL ตามเครื่องไม้เครื่องมือสมัยนี้ หรืออาจจะเป็นพวก json/xml/csv ที่ export มาจากหน่วยงานที่ยังไม่พร้อมกับการมีระบบ database ของตัวเอง หรือพวก plain text/raw image/raw video พวกนี้ก็อีกแบบ พอเอามาจัดรวมๆ กันนี่ ดูไร้รูปแบบมาก
คุณสมบัตินึงเลยที่ต้องมีของชั้นนี้คือ จะต้องสามารถแปลงไอ้ของไร้รูปแบบนี้ ให้สามารถเอาไปเข้ากระบวณการอื่นๆ ต่อได้ ถ้าอิงตามในรูปด้านบน ก็คือเอาเข้าชั้น Messaging layer
ผมขอ spoil ก่อนสั้นๆ ว่า ไอ้ Messaging layer เนี่ย มันคือระบบ queue นี่เอง จุดประสงค์ก็เพื่อ buffer ข้อมูลทีเข้ามา เพราะฉะนั้นข้อมูลที่จะเข้ามามันต้องพร้อมที่จะเอาเข้าคิว ท่าที่นิยมใช้กันคือมี connector ที่เอาไว้ใช้แปลง source มาเป็นรูปแบบที่พร้อมเอาเข้าคิว
คุณสมบัติของตัว connector นี้ข้อนึงเลยคือต้องมี latency ที่ต่ำมากๆ (จริงๆ ก็ทุกเครืองมือและทุกชั้นแหละ 5555) และต้องมี connector หลายแบบหน่อย สำหรับต่อ RDBMS เช่น Postgresql/Mysql หรือ NoSQL อย่าง MongoDB/ElasticSearch เป็นต้น
ละถ้าชั้น Messaging ของเราเน่าขึ้นมา มันก็ต้องรองรับสถานการณ์ แบบนี้ด้วย คือต้องรองรับ fail-safty และ fail-over เช่น อาจจะมี local message queue รองรับไว้อีกชั้น และควรจะต้อง retry ได้หลังจากชั้น Messaging ที่เน่าไป กลับคืนมา
Messaging Layer
คือ spoil ไปแล้วก่อนหน้า มันคือระบบ message queue นี่แหละ มันมีไว้เพื่อให้แน่ใจว่า ข้อมูลที่เอาเข้าไปมันจะไม่หนีหายไปไหน ถ้าไฟดับเครื่องเน่า หลังจากปลุกมันขึ้นมาควรจะอยู่ครบ อีกคุณสมบัตินึงของชั้นนี้คือ ต้องเก็บข้อมูลลง disk เพื่อความแน่ใจว่า ในขณะที่มีคิวอยู่ แล้วมันดับไป ปลุกมาคิวจะยังอยู่เท่าเดิม
แต่ถ้าคุณสมบัติแค่นี้ มันก็ไม่มีความจำเป็นที่จะต้องใช้ message queue หรือเปล่า?? เราต้องไม่ลืมว่า ข้อมูลที่เข้ามา มันสามารถเข้ามาเป็นแบบ streaming ถ้าเราไม่เข้าคิวให้มัน จะแน่ใจได้ไงว่ามันทำตามลำดับ
นอกจากนี้ คุณสมบัติอย่างกลไก pub-sub หรือการจัดหมวดหมู่ของข้อมูล(topic) ก็ควรมีอยู่ในชั้นนี้ เพราะฉะนั้น เครื่องมืออย่าง message queue จึงพอดีกับชั้นนี้เป็นอย่างมาก
Data Ingestion Layer
ในชั้นนี้ เป็นชั้นที่เป็นแกนของ Lambda architecture เลย เป็นชั้นที่เอาไว้ควบคุมข้อมูลที่จะวิ่งเข้า Lambda layer
คือชั้นนี้ ตอนที่อ่านตอนนี้อาจจะยังงง ว่ามันมาทำไม เอาไว้ทำอะไร ต้องมีด้วยหรอ?
ก่อนจะเอาเข้าชั้น Lambda layer เราต้อง transform มันก่อน ว่า data แต่ละแบบ ควรจัดเก็บในรูปแบบไหนและเก็บที่ไหน ซึ่งเราจะทำการ transform มันที่ชั้นตรงนี้ แต่ยังคงรูปแบบดั้งเดิมไว้(transform ในที่นี้ไม่ใช่การ transform ในส่วนของ ETL ในการนำไปใช้งาน ตรงนี้จะอยู่ในการ transform ในชั้นของ Service layer ใน Lambda Layer)
คุณสมบัติเบื้องต้นที่ชั้นนี้ควรจะมีคือ
- สามารถ transform รูปแบบของข้อมูลได้ (พระเอก)
- สามารถ scale ตามใจได้
- มีความ fault tolerant
- มี fail-safety/fail-over ตามที่อธิบายไปในชั้น Acquisition แล้ว
- สามารถทำประมวลผลแบบ multi-thread ได้ เพราะการเอาข้อมูลออกจากชั้น messaging ให้เร็ว ไม่ใช่เรื่องง่าย ต้องช่วยๆ กันทำ
Lambda Layer
ชั้นนี้จะประกอบ 3 ชั้นย่อยคือ
- Batch layer
- Speed layer
- Serving layer
Batch layer
ถ้าข้อที่จะเอาเข้ามาเก็บหรือ process เพื่อเก็บในชั้น storage มันใหญ่มาก รวมถึงการเอาไปใช้งานในส่วนของการ view เราก็หนีไม่พ้นการแบ่งก้อนข้อมูลแล้วช่วยกันทำ ตามชื่อของมันคือการทำ batch process
Speed layer
ถ้าข้อมูลเป็นการที่เอาเข้าในลักษณะ streaming ล่ะ คือ มีข้อมูลเข้ามาที่ชั้นนี้ปุ๊บ ก็ต้องถูก process ก็จะเอามาเข้าที่ชั้นนี้ ซึ่งต่างจาก batch ตรงนี้ส่วนของ batch จะเป็นข้อมูลที่ใหญ่มากๆ แต่ชั้นนี้จะเป็นชั้นสำหรับข้อมูลที่เล็กๆ และต้องการการ process ทันที
Serving layer
มีไว้สำหรับให้บริการการเข้าถึงข้อมูลให้ผู้ใช้ ขึ้นอยู่กับการใช้งานของการเอาข้อมูลไปใช้ เช่น ต้องสามารถ export ข้อมูลได้ในรูปแบบต่างๆ กัน อาจจะมีการ aggregate ก่อนเอาไปใช้งาน เพราะฉะนั้น ควรมีเครื่องมือที่ใช้ทำ ETL อยู่ในชั้นนี้ด้วย หรือต้องสามารถที่จะสั่งให้ publish ข้อมูลไปยัง target ต่างๆ ได้ด้วย
และอีกหนึ่งคุณสมบัติที่ต้องมีคือ service สำหรับให้ external service เรียกใช้งานข้อมูลใน storage ของเรา อาจจะเป็น view ในมุมมองต่างๆ เช่น time series สรุปข้อมูลรายเดือน รายวันเอาไว้ก่อน
Data Storage Layer
คือส่วนที่ไว้รองรับการสั่งงานจาก Serving layer ทั้งในรูปแบบ streaming จาก Speed layer และ batch process จาก Batch layer
ด้วยพลังของ Hadoop stack (NoSQL)สามารถช่วยให้ชั้น storage นี้สามารถรองรับการเขียนและอ่านในรูปของ streaming ทีมีการใช้ index ช่วยการทำ random access และ batch process ที่มีการเก็บข้อมูลเป็น block ช่วยในการทำ sequential access ได้
นอกจาก Hadoop stack แล้ว ควรจะรวมไปถึง RDBMS ด้วย สำหรับการเก็บข้อมูลในลักษณะที่ควรมี relationship
PROs and CONs
ข้อดีเนี่ย ตามที่อธิบายไปแล้วในแต่ละหัวข้อ เอาข้อเสียดีกว่า
- มีหลาย layer ซับซ้อนมาก นี่เป็นต้นตอของปัญหาเลย
- มีหลาย layer ก็มีหลายเครื่องมือ ซับซ้อนต่ออีก
- เครื่องมือเยอะ ก็หาคนยากอีก
- ดูแลยากอีก
- deployment CI/CD ยากอีก
ดูเหมือนปัญหาเยอะมาก แต่ถามว่าแปลกไหม? ก็ไม่แปลกนะครับ เพราะองค์ประกอบและเครื่องมือมันหลายอย่าง
ถ้าถามว่ามีดีกว่านี้ไหม ผมก็หาอยู่ครับ 55555 ใครมีรบกวนบอกหน่อย
ตอนหน้า จะเอาเครื่องมือจริงๆ มาประกบแต่ละชั้นครับ
