4a0fd563c65ef0da418c9d0ef5da5ac2
หลังจากที่ได้แปลบทความเรื่อง Reporting Database ไป
มีการพูดคุยถึงวิธีการทำจะดึงข้อมูลจากฐานข้อมูลระบบ หรือ Operation Database
มายังฐานข้อมูลรายงาน (Report Database) อย่างไร
ซึ่งวิธีการนั้นมีมากมายหลากหลายลีลา
ตามความชอบ ความถนัดของตัวบุคคล ทีม และองค์กร
ซึ่งผมขอนำแนวคิดของ Lambda Architecture มาอธิบายครับ
และสามารถเลือกบางส่วนไปใช้งานได้ด้วย

รูปภาพทั้งหมดนำมาจากเว็บไซต์ http://www.lambda-architecture.net

เริ่มต้นด้วยวิธีการจัดการข้อมูลยอดนิยมใช้กันก็คือ

1. Batch processing คือการกำหนดตารางเวลาการทำงาน
เช่นในทุกๆ ชั่วโมง ครึ่งวัน หรือ ก่อนสิ้นวัน เป็นต้น

2. วิธีการสรุปในขณะประมวลผล แล้วจึงทำการบันทึกลงฐานข้อมูลรายงาน
ซึ่งอาจจะเป็นข้อมูลจากระบบ หรือ สรุปมาแล้วก็ได้
ตามความต้องการของระบบนั้นๆ

3. อาจจะเก็บข้อมูลไว้ที่ buffer หนึ่งก่อน เช่น
ในหน่วยความจำ
ในระบบไฟล์
หรือระบบอื่นๆ ที่ทำการเขียนข้อมูลได้รวดเร็ว
หรืออาจจะใช้ฐานข้อมูลเลยก็ได้
และทำงานร่วมกับวิธีการที่ 1 สำหรับกวาดข้อมูลลงฐานข้อมูลรายงาน

4. วิธีการอื่นๆ ก็ว่ากันไป เช่น
ซื้อระบบมาจาก vendor มา implement เลย เช่นพวก Data Warehouse, Data Mart เป็นต้น
หรือหา Opensource Software สำหรับง่านไปเลย
เช่นเก็บ log อาจจะใช้ Statd, Kibana และ Logstash เป็นต้น

ต่อจากนั้นคือที่จัดเก็บข้อมูล

ว่าจะจัดเก็บไว้ที่ใด
ซึ่งตรงนี้ก็ต้องมองปัจจัยหลายๆ อย่าง เช่น

  • ขนาดของข้อมูล
  • อัตราการเติบโตของข้อมูล
  • อัตราการเขียนและอ่านข้อมูล
  • รูปแบบของรายงาน
  • และอื่นๆ มาประกอบกัน

โดยในปัจจุบันเรื่องที่จัดเก็บข้อมูลไม่ได้จำกันเพียง RDBMS ( Relational DataBase Management System ) เท่านั้น
แต่ยังมีพวก NoSQL และ NewSQL ให้เลือกใช้ตามความเหมาะสมของระบบ
โดยตัวที่น่าจะได้รับความนิยมก็คือ Hadoop นั่นเอง แต่ยังมีตัวอื่นๆ อีกเพียบ

จากที่อธิบายมาพบว่าวิธีการจัดการ และ การจัดเก็บข้อมูล

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

หนึ่งในแนวคิดนั้นก็คือ Lambda Architecture (LA) คิดโดย Nathan Marz
ตอนนี้ทำงานอยู่ที่ Twitter และ Backbye
โดยได้นำแนวคิดบางอย่างไปใช้ในระบบการประมวลผลข้อมูลแบบกระจาย
ในระบบของ Twitter จนมี product ต่างๆ ออกมาเช่น Storm, Cascalog, ElephantDB เป็นต้น

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

โดยที่โครงสร้างของมันเป็นดังรูป

la-overview_small

การทำงานประกอบไปด้วย 5 ส่วน ดังนี้
1. Data คือข้อมูลชนิดต่างๆ ที่ถูกส่งเข้ามายังระบบ อยู่ในรูปแบบใดๆ ก็ได้
ซึ่งจะถูกส่งเข้าไปยัง Batch layer และ Speed layer

2.  Batch layer มีการทำงาน 2 ส่วนคือ
ส่วนที่ 1 ทำการจัดการข้อมูล master ซึ่งเป็นข้อมูลดิบ สามารถเพิ่มได้อย่างเดียวเท่านั้น
ส่วนที่ 2 ส่วนประมวลผลข้อมูลตามรายงานหรือข้อมูลรูปแบบต่างๆ ที่ต้องการ ซึ่งทำงานแบบ batch นั่นเอง

3. Serve layer คือส่วนที่จัดทำดัชนีข้อมูลที่ผ่านการสรุปมาแล้ว เพื่อให้การอ่านหรือดึงข้อมูลทำได้อย่างรวดเร็ว

4. Speed layer คือส่วนที่เข้ามาเพิ่มเติมสำหรับระบบที่มีการแก้ไขข้อมูลที่สูง และต้องการข้อมูลแบบ realtime
ซึ่งทำมาเพื่อสนับสนุน Serve layer อีกด้วย

5. Query ทำหน้าที่ดึงและรวมข้อมูลจาก Serve layer และ Speed layer เพื่อส่งข้อมูลกลับไปตามที่ผู้ใช้ต้องการ

กลับมายังที่มาของสถาปัตยกรรมนี้ดีกว่า

เนื่องจากการเก็บข้อมูลในปัจจุบันนี้ ส่วนใหญ่เก็บตามเหตุการณ์หรือการกระทำต่างๆ
โดยทำให้มีการทำงานแบบ CRUD ( Create Read Update Delete )
ดังตัวอย่าง

INSERT INTO TABLE VALUES ( “somkiat”, “Korat”)
UPDATE  TABLE SET address=“Bangkok” WHERE name = “somkiat”

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

INSERT INTO TABLE VALUES ( “somkiat”, “Korat”, 2011-01-01 10:00:00 )
INSERT INTO TABLE VALUES ( “somkiat”, “Ubon”, 2012-01-01 15:00:00 )
INSERT INTO TABLE VALUES ( “somkiat”, “Bangkok”, 2013-01-01 15:00:00 )

ซึ่งข้อมูลเหล่านี้จะจัดเก็บในระบบข้อมูลของเรา (Data System)
ข้อมูลเหล่านี้มักจะถูกรวม แปลงรูป ให้ไปอยู่ตามความต้องการหรือการ Query
โดยที่มีสมการดังนี้

Query =  function (All data)

จากสมการจะพบว่า เราต้องทำเอาข้อมูลทั้งหมดไปผ่าน function การทำงานหนึ่ง
เพื่อให้ได้ผลลัพธ์ตามที่ต้องการ จึงเป็นที่มาของ 3 layer คือ Batch, Serve และ Speed layer นั่นเอง

ผมเชื่อว่าระบบส่วนใหญ่จะมี Batch layer และ Serve อยู่แล้วนะ !!!

ตัวอย่างการนำแนวคิดของ Lambda Architecture ไป implement เป็นดังรูป

Screen Shot 2557-04-30 at 1.42.46 PM

ส่วนของ Batch layer
จะใช้ Hadoop มาช่วย ซึ่งใช้สำหรับการประมวลผลข้อมูลขนาดใหญ่
และต้องการเวลาในการประมวลผลพอสมควร
ข้อมูลในส่วนนี้ไม่จำเป็นต้อง De-normalize นะ
เพราะว่าต้องทำการประมวลผล batch อยู่บ่อยๆ
แต่ถ้าประมวลผลไม่บ่อยก็ทำการ De-normalize ซะ
และในส่วนนี้สามารถขยายออกด้านข้างได้ เช่นการเพิ่ม storage server เป็นต้น
และการเก็บข้อมูลจะเป็นแบบเพิ่มเข้าไปได้อย่างเดียวเท่านั้น

ในการประมวลผลจะใช้ Map-Reduce มาช่วย ดังรูป

Screen Shot 2557-04-30 at 1.48.11 PM

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

  • ฐานข้อมูลที่สร้างมาเพื่อ LA เลย เช่น ElephantDB และ SploutSQL
  • ฐานข้อมูลสำหรับการอ่านเลย เช่น Voldemort
  • ฐานข้อมูลอื่นๆ ที่แนะนำ เช่น ElasticSearch, Apache Solr, Hive และ Cassandra

ส่วนของ Speed layer
สร้างมาเพื่อแก้ไขปัญหาข้อมูลที่ล่าช้าไปจาก Batch layer
โดยในส่วนนี้ต้องรองรับการประมวลผลข้อมูลแบบ Stream ได้
ประมวลผลแบบต่อเนื่องได้
เมื่อเกิดข้อผิดพลาดขึ้นมา ต้องสามารถแก้ไขได้อย่างอัตโนมัติ
จากทฤษฎี CAP นั้นในส่วนนี้จะเลือก

  • A = Availability
  • C = Consistency

ตัวอย่างของเครื่องมือสำหรับ layer นี้ก็เช่น Storm
และทำงานร่วมกับพวก Kafka, Flume, Scribe  และพวกตระกูล Messaging Queue ทั้งหลาย

ที่จัดเก็บข้อมูลในส่วนนี้ต้องการ
การเขียนที่มีความเร็วสูงๆ
ตัวอย่างเช่น  Cassandra, Apache HBase, Redis, Riak, ElasticSearch เป็นตัน

ส่วนของ Serve layer
ต้องการความเร็วในการอ่านที่สูงมาก
รวมทั้งวิธีการรวมข้อมูลด้วย
เนื่องจากจะต้องทำการดึงข้อมูลตามเงื่อนไขต่างๆ
จากทั้ง Batch และ Speed layer มารวมกัน เพื่อส่งผลลัพธ์กลับไป
โดยขอแนะนำแนวคิดเรื่อง CQRS ( Command Query Responsibility Segregation )
และ Event Sourcing
เครื่องมือต่างๆ ที่ถูกใช้งานในส่วนนี้ได้แก่
Apache HBase, ElephantDB, Apache Drill

ตัวอย่างระบบที่นำแนวคิดของ Lambda Architecture ไปใช้งาน

ระบบ Hashtag ของ Twitter ทำงานแบบ realtime โดยใช้ Trident, Hadoop, Storm และ SploutSQL
Summingbird เป็น framework สำหรับการเขียนโปรแกรม Map-Reduce สนับสนุน Hadoop และ Storm

และนี่ก็เป็นเพียงแนวคิดหนึ่ง

ที่พยายามนำเอารูปแบบต่างๆ ที่ใช้กันทั่วไป
มารวมกัน เพื่อแก้ไขปัญหาต่างๆ
โดยเราสามารถนำเอาแนวคิดบางส่วนไปใช้งาน
ตามความต้องการของเราได้เลยครับ …

Reference Websites
http://www.slideshare.net/nathan_gs/a-realtime-lambda-architecture-using-hadoop-storm-nosql14
http://www.datasalt.com/2014/01/lambda-architecture-a-state-of-the-art/
http://www.drdobbs.com/database/applying-the-big-data-lambda-architectur/240162604