Datalake ยังไง(วะ) #3 : ประกอบร่าง

หลังจากโพสที่แล้ว นานมาก เพิ่งมีเวลามาต่อ

Datalake ยังไง(วะ)? #2 : Lambda Architecture

ก็มี flow ครบ cycle ตั้งแต่เอาเข้ามา แล้วก็มีช่องทางสำหรับเอาออก โพสนี้ก็จะเอาเครื่องมือมาประกบ ในแต่ละชั้นของ architecture แต่คงไม่ได้ลงรายละเอียดนะครับ ข้อสงสัยอื่นๆ อาจจะต้องศึกษาด้วยตัวเอง

Data Acquisition Layer

ที่มีหน้าที่รับข้อมูลจากแหล่งต่างๆ หลายๆ ที่

มีเครื่องมือดังนี้

• Apache Sqoop สำหรับ batch data
• Apache Flume สำหรับ streaming data

Apache Sqoop

SQL to Hadoop == SQOOP

หน้าที่หลักๆ ของมันคือส่งข้อมูลประเภท non-hadoop ไปยัง hadoop ecosystem มันทำตามชื่อของมันเลยครับคือ sc(q)oop ที่แปลว่าตัก แบบ ตักข้าวด้วยทัพพี แต่เปลี่ยนจากข้าว เป็นข้อมูล ซึ่งเทียบได้กับการทำเป็น batch พอดี

ความสามารถของ Sqoop คือ ติดต่อ(import/export)กับ non-hadoop datasource เช่น RDBMS หรือ NoSql ก็ได้ แต่หลักๆ คือต้องเป็นข้อมูลประเภท structured คือถูก process มาแล้ว นอกจากนี้ยังมี interface ไว้ต่อกับเครื่องมือบน Hadoop ecosystem อย่าง Apache Oozie, Apache Hbase และ Apache Hive อีกด้วย

Sqoop data flow

วิธีการใช้งาน(ทั้ง import และ export) Sqoop คือใช้ command line

เราต้อง ระบุใน command ว่าจะ data source คืออะไรและที่ไหน เช่น MySql หรือ Postgresql แล้วก็ระบุให้ว่าให้มันไปที่ไหน ในที่นี้ก็อาจจะเป็น HDFS storage หรือจะเป็น HBase เป็นต้น

มีจุดเด่นคือ

• ต่อกับ structured data source ได้หลายตัว
• ในแต่ละ batch process สามารถทำงานแบบขนานได้
• มี connecter ไป data source ได้หลายประเภท
• รองรับได้หลายชนิดของไฟล์ เช่น Arvo, Text หรือ SequenceFile

ส่วนจุดด้อย

• ใช้ JDBC connection อาจจะทำงานได้ไม่มีประสิทธิภาพพอ
• อาจจะใช้เวลานาน เพราะ map-reduce job ในการทำ de-normalization
• อาจจะทำให้ data source รับ load เยอะๆ ได้ เพราะการทำ batch data

Apache Flume

ก่อนจะไปถึง Flume เรามาดูก่อนว่าข้อมูลประเภท streaming เป็นยังไง

คือข้อมูลประเภทนี้ เป็นข้อมูลมาไหลมาเรื่อยๆ และเร็ว เช่น ข้อความใน twitter มันก็มีคน tweet มาทั้งวัน เรื่อยๆ ตัวอย่างของข้อมูลประเภทนี้ก็เช่น logging ที่มาจาก application หรือ action จากผู้ใช้เช่นข้อมูลการคลิก หรือจะมาจาก device ที่เป็นตัวรับเซนเซอร์ ก็เป็นได้

มาถึงตัว Flume ตัวมันเองจากชื่อ มันคือทางน้ำที่ถูกสร้างเอาไว้ขนท่อนไม้ที่ตัดไว้ มันก็มีลักษณะการทำงานตามชื่อของมันเลย คือรับ streaming data หรือเทียบเท่ากับท่อนไม้ที่ถูกส่งลงมาตามทางน้ำ ซึ่งรับมาจาก data source ต่างๆ แล้วไหลลงไปยัง hadoop ecosystem ซึ่งใน Lambda architecture อันนี้ จะไม่เอาเข้า hadoop โดยตรง แต่จะเอาเข้าใน Apache Kafka ใน messaging layer แทน

Flume data flow

วิธีการใช้งาน Flume คือ ต้องระบุ source ก่อน และรูปแบบการดึงข้อมูล ซึ่งสามารถทำได้ทั้ง event-driven คือไป listen ใน source เลย พอมี data เข้าก็ดึงมาเลย หรือวิธี polling ก็ได้ คือ ดึงข้อมูลเรื่อยๆ ในช่วงเวลาที่กำหนดไม่ว่าจะมีข้อมูลหรือไม่มีก็ตาม

จากนั้นก็ระบุ channel ว่าจะเก็บข้อมูลชั่วคราวก่อนส่งไปยัง target ยังไง เช่น เก็บไว้ใน memory หรือเป็น file หรือจะเก็บไว้ใน messaging queue อย่าง JMS หรือ Apache Kafka อีกทีก็ได้

แล้วก็ระบุ target(ศัพท์ใน flume เรียก sink) ไว้ให้เอาไปใส่ที่ไหน ในที่นี้ก็จะเป็น Apache Kafka ในชั้น Messaging

มีจุดเด่นคือ

• Open source และมี document ที่ดี
• รับ data ได้เยอะ และ latency ต่ำ
• Scale แบบ horizontal ได้
• มีเครื่องมือสำหรับ monitor เยอะ
• รองรับ data flow หลายแบบ เช่น fan-in, fan-out หรือ multiple-hop

ส่วนจุดด้อย

• ไม่การันตีตามลำดับของข้อมูล
• มีโอกาสเกิดข้อมูลซ้ำ
• ถ้ามีข้อมูลเยอะระดับ enterprise จะทำการประเมิน hardware สำหรับการ scale ยาก

เหมือนจุดด้อยจะสำคัญ​แต่ว่าในหนังสือเขาเลือกว่ามีข้อดีที่แข็งแรงกว่า

ทางเลือกอื่นก็ยังพอมี เช่น

• Apache Flink
• Apache Nifi
• Apache Spark(streaming)

Messaging Layer

หน้าที่หลักๆ เลยคือให้แน่ใจว่าข้อมูลเราที่จะเอาเข้าไปเก็บใน datalake จะไม่หายไปไหน มีคุณสมบัติหลักๆ คือ

• สามารถรับข้อมูลในปริมาณที่มากๆ ในเวลาน้อยๆ ได้
• มี latency ต่ำ และให้ throughput สูง
• มีการดึงข้อมูลไปใช้ตามลำดับได้
• สามารถ aggregate และเอาข้อมูลมา monitor หรือ analyze ได้

ยังมีคุณสมบัติเสริมอีก 3–4 ข้อ แต่ผมว่ามันแค่เสริมการทำงานให้ดูขึ้นเท่านั้น

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

Messaging layer flow

ชั้น messaging ของเรา จะรับข้อมูลมาจาก Apache Flume เป็นแบบ stream มาเลย ก็มีทั้งจาก application ของเรา อาจจะเป็นข้อมูลจากพฤติกรรมผู้ใช้ เช่น การคลิก หรือการเข้าเยี่ยมชม web page

พอรับข้อมูลมา ก็พาไปหาชั้น Data ingestion layer ต่อไป เพื่อทำการเอาเข้าชั้น storage layer

สำหรับข้อมูลเบื้องต้นของ Apache Kafka ผมได้เขียนไว้แล้ว แวะไปอ่านได้ที่

Apache Kafka ฉบับผู้เริ่มต้น #1: Hello Apache Kafka

จุดเด่นของ Apache Kafka นะครับ

• รองรับข้อมูลได้เยอะในเวลาที่น้อย
• มี latency ที่น้อยมาก
• มีคุณสมบัติ fault tolerant เนื่องจากมีการติดตั้งในลักษณะของ replication ถ้าเครื่องนึงดับ ยังมีเครื่องอื่นสำรองพร้อมใช้งาน
• เก็บข้อมูลลง disk ทำให้แน่ใจได้ว่าข้อมูลไม่หายง่ายๆ
• มีคุณสมบัตื distributed คือกระจายข้อมูลเป็น partition เพื่อการอ่านข้อมูลที่ไวขึ้น

ส่วนจุดด้อย

• ดูแลยาก
• ยังขาด monitoring tool ที่มีประสิทธิภาพ
• ยังต้องทำงานที่อาศัย Apache Zookeeper ซึ่งทำให้การดูแลและการติดตั้งยากขึ้น
• ต้องกำหนดและ fix ค่าสำหรับการสร้าง topic ไว้ก่อน การปรับหลังจากสร้างแล้ว สามารถทำได้ แต่ยุ่งยากและไม่แนะนำ

ยังมีทางเลือกอื่นครับ

• RabbitMQ
• Apache ActiveMQ

Data Ingestion Layer

หน้าที่ของชั้นนี้คือเตรียมข้อมูลเข้า storage ของเรา

การทำงานเริ่มจาก ดึงข้อมูลจากชั้น Messaging layer ถ้าจำเป็นต้องปรับแต่งข้อมูล ก็จะอยู่ที่ชั้นนี้ก่อนที่จะเอาเข้าชั้น Lambda ที่คอยรับข้อมูลแบบ batch และแบบ streaming ขึ้นอยู่กับลักษณะของข้อมูลที่รับมา

คุณสมบัติหลักๆ ที่ชั้นนี้ควรมีคือ

• สามารถจัดการกับการไหลของข้อมูลได้หลายแบบ เช่น asynchronous, streaming หรือ batch
• สามารถจัดการกับชนิดของข้อมูลได้หลายแบบ เช่น structured(RDBM-schema), unstructured(file) และ semi-constructured(json, xml)
• รองรับ protocol สำหรับส่งข้อมูลได้หลายแบบ

Apache Flink

ผมเองแปลกใจมากที่เขา(ผู้แต่งหนังสือ)เลือก Apache Flink แทน Apache Spark

สาเหตุที่เขาเลือก Flink เพราะ Spark ทำงานในลักษณะ micro-batch อาจจะเกิดคอขวดได้ในการทำงานกับ real-time data เขากังวลเรื่อง latency มาก เลยเลือก Flink ซึ่ง Flink ทำได้ดีกว่าตรงนี้

วิธีการใช้งานของ Flink คือเราต้องเตรียม code สำหรับจัดการข้อมูล จากนั้นก็ deploy ไปยังตัว master node แล้วมันก็จะส่ง code นี้ไปประมวลผลที่ worker node

ตัวข้อมูลทั้งแบบ batch และ stream จะถูกแบ่งและส่งไปยัง worker node เพื่อให้ code ที่เรา deploy ไป ทำการประมวลผล

เรื่องการกระจาย job ไปประมวลผลในแต่ละ node จะขอไม่พูดถึงครับ

Apache Flink on Data ingestion layer

จุดเด่นที่ Flink มีคือ

• มี API ที่ง่าย
• มี Latency ที่น้อยในการประมวลผลข้อมู฿ล
• มีคุณสมบัติ Fault tolerant
• config ง่าย
• รองรับการประมวลผลแบบ exactly once
• มี ML library รองรับ
• รองรับการติดตั้งแบบ cluster

จุดด้อย

• ยังไม่เป็นที่นิยม เลยมี comunity ที่เล็ก
• ยังไม่มีการข้อจำกัดการใช้ memory ในการประมวลผล(มี 100 ก็ใช้ 100)
• ทำงานกับ raw bytes เป็นหลัก การเขียน code ก็จะวุ่นวายขึ้นหน่อย (ลองนึกว่าต้องแปลง string ทุกอันให้เป็น bytes)
• API ในการ query ยังไม่นิ่ง อาจจะมีการเปลี่ยนได้อีก
• only Java & Scala API จ้าา

ส่วนทางเลือกอื่นก็ยังมี

• Apache Spark
• Apache Tez
• Apache Storm

Data Storage Layer & Lambda Batch layer

ในหนังสือยกสองเรื่องนี้มาอธิบายคู่กัน คือ Storage layer และ Lamda batch layer น่าจะเป็นเพราะ use case ที่นิยมใช้กัน คือการทำ batch processing กับข้อมูลดิบ ที่อาจจะรับมาจากชั้น Data ingestion มาทำการปรับแต่ง แล้วเอาเข้าชั้น Storage หรืออาจจะรับข้อมูลจากชั้น Storage มา process เพื่อเอาไปใช้งาน อาจจะไปแสดงผล หรือส่งต่อให้ระบบอื่นๆ

Apache Hadoop

ส่วนของ Storage layer ชั้นนี้มีหน้าที่เก็บข้อมูล และเครื่องมือตอนนี้มี 1 เดียวด้วยคุณสมบัติอย่าง

• รองรับ Data ที่มากๆ ได้
• มีการทำ Fault Tolerant
• ง่ายต่อการ scale
• มี cost ที่ถูกมาก
• มีเครื่องมือให้เลือกใช้งานเยอะตามลักษณะงาน
• มีสถาปัตยกรรมแบบช่วยกันประมวลผล

ไม่ต้องหาคำตอบอะไรให้ยาก ก็คือ Apache Hadoop นี่แหละครับ

ข้อเสียก็มีครับ

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

แต่ถ้าต้องแลกกับข้อดีที่มีก็ยังสมเหตุสมผลอยู่

ด้วย ecosystem ที่ Apache Hadoop มี อย่าง Yarn, HDFS หรือ MapReduce ล้วนสนับสนุนการทำงานในชั้นของ Storage นี้ทั้งนั้น

Lambda batch layer flow

ด้วยชุดเครื่องมือที่ Apache Hadoop มี การทำงานชั้น batch layer จึงพอดีกับเครื่องมืออย่าง

• Apache Hadoop Yarn ทำหน้าที่ต่อจัดการ resource อย่าง cpu, memory หรือ job tasks
• Hadoop MapReduce เป็น API ไว้ให้สั่งงาน Map Reduce jobs
• Apache Hive ที่ทำงานกับ Map Reduce API ทำหน้าที่ดึงข้อมูลออกมา analyse ด้วย SQL syntax

โดย Yarn จะเป็นตัวจัดการ task ที่เข้ามาแล้วกระจายไปให้ MapReduce ทำ ไม่ว่าจะเป็นทั้งขาเข้าและขาออกของข้อมูล

ส่วนชั้น Data storage ก็เป็นหน้าทีที่คุยกับ MapReduce แล้วก็เอาข้อมูลไปเก็บหรือเอาออกใน HDFS ซึ่งจะถูกเข้าถึงจาก Hive อีกที

Data Storage Layer & Lambda Speed layer

การที่เราเก็บข้อมูลลงใน HDFS จากชั้น Data ingestion layer แล้วเราจะเอามาใช้งาน ไม่ใช่เรื่องที่ง่ายเท่าไหร่ เราเลยต้องมี layer นี้เพื่อเข้ามาช่วยให้การเข้าถึงข้อมูลได้ไวขึ้น

ในหนังสือเลือก Elasticsearch มาช่วยเรื่องการ search และ query

จุดเด่นของ Elasticsearch

• Index แล้ว search ได้ไวมาก
• ทำ data aggregation ได้ง่าย
• มีกำรทำ Fault Tolerant

จุดด้อย

• ไม่มี ACID สำหรับ transaction
• ไม่เหมาะกับการใช้เป็นที่เก็บข้อมูลตัวหลัก เพราะข้อมูลอาจถูกลบแล้วสร้างใหม่ได้เสมอจากการสร้าง index ใหม่เพื่อทำให้การ search ได้ไวขึ้น

หลังจากได้รับข้อมูลมา จะต้องแปลงให้เป็น Parquet format ไปเก็บใน HDFS เพื่อให้สามารถถูกเข้าถึงจาก Hive ได้ โดยแปลงจาก Apache Flink ในชั้นของ Data ingestion และในขณะเดียวกันก็ทำการเก็บใน ElasticSearch ด้วย

และถ้าหาก import ข้อมูลโดยตรงจาก Apache Sqoop ไป Apache HBase ในชั้น Data acquisition ก็จะมี HBase อยู่ในชั้น Lambda Speed layer นี้ด้วย เพื่อช่วยในชุดประสงค์เดียวกันคือ search และ query

Lambda speed layer flow

ทางเลือกอื่น

• Apache Solr

Lambda Serving Layer

มาถึงชั้นที่ท้าทายอีกชั้นครับ หน้าที่ของชั้นนี้จะต้องสามารถเอาข้อมูลออกไปยังโลกภายนอกได้

ณ จุดนี้ เราสามารถมีเครื่องมือมาเชื่อมต่อได้อีกหลายท่าเลย เพราะเรามี ElasticSearch แล้ว เราสามาถเอา Kibana มาต่อได้

หรือแม้กระทั่งเครื่องมืออย่าง Hue ที่ติดตั้งเพิ่มเพื่อไว้ query เข้า HBase หรือ Hive ได้

หรือในเชิง programming เรายังสร้าง REST/GraphQL service ที่มาต่อกับ Elasticsearch หรือ HBase ที่มี Thrift API

บางที อาจจะต้อง export ข้อมูลออกในจำนวนที่มากๆ เรายังมี Sqoop เพื่อทำ scheduler สำหรับ export ข้อมูล

อันที่จริงเรายังมี Flink หรือจะติดตั้ง Spark เพิ่ม ก็ยังสามารถช่วยเพิ่มช่องทางการทำ etl ในเชิงการใช้งานกับฝั่ง Data Science ได้อีก

Datalake implementation

ยังเพิ่มได้อีก

ยังมีอีกหลายสิ่งที่ผมยังไปไม่ถึง และยังต้องเก็บไว้ศึกษาต่อ ถ้าหากจะมี datalake มาใช้

• เรามีวิธี compress ข้อมูลให้เล็กลงแต่ยังเข้าถึงได้อย่างไร
• ใช้ data partition อย่างไรจึงช่วยให้เข้าถึงข้อมูลได้เร็วขึ้น
• ทำ validate and cleansing อย่างไร ถึงลดข้อมูลที่ไม่สร้างประโยชน์
• ต่อ machine learning อย่างไร
• ถ้าต้องมี scheduler/workflow ในการ process จะทำอย่างไร
• data security/encryption ก็สำคัญ
• ไหนจะเรื่อง data governance/lineage/traceability อีก
• ถ้าต้อง audit จะทำอย่างไร

และอีกหลายรายละเอียดยิบย่อย ที่เรายังต้องพิจารณาก่อนจะมี datalake

สรุป

Post ชุดนี้ (รวม #1 และ #2 ด้วย) ก็แสดงให้เห็นถึงชุดเครื่องมือและจุดประสงค์ในการขึ้น Datalake ขึ้นมา และเป็นเพียงแค่ 1 ทางเลือกในการใช้งานเท่านั้น ซึ่งจริงๆ แล้วในแต่ละ environment ของแต่ละการใช้งาน อาจจะสามารถลดหรือเพิ่มเครื่องมือตามความเหมาะสมได้อีก

หวังว่าจะได้ idea ในการเลือกใช้เครื่องมือกันนะครับ