ในโลกปัจจุบันที่แทบทุกคนต่างก็มี Social media account เป็นของตัวเองและต่างคนก็ต่างสร้างข้อมูลใหม่ ๆ เข้าสู่ platform อยู่เสมอ ไม่ว่าจะเป็น post, comment, share หรือแม้แต่ like ก็ตามและสิ่งนี้เองก็ทำให้เมื่อแบรนด์หรือสินค้าต่าง ๆ ใช้ความคิดเห็นหรืออารมณ์ต่อสถานการณ์ต่าง ๆ มาเป็นการส่วนหนึ่งในการวิเคราะห์ความคิดเห็นจากผู้บริโภคอีกด้วยหรือที่ภาษาอังกฤษเรียกสิ่งนี้ว่า social listening นั้นเอง แต่ social listening ไม่ได้จำเป็นที่จะต้องใช้ในการรับฟังความคิดเห็นของสังคมอย่างเดียว แต่ social listening ก็ยังสามารถที่จะใช้ในการวิเคราะห์ (Analysis) หรือ ทำนาย (Prediction) สิ่งที่เกิดขึ้นได้อีกด้วย แล้วจะเกิดอะไรขึ้นถ้าเรานำเอาข้อมูลที่เกี่ยวข้องกับสื่อต่าง ๆ ของเกาหลีไม่ว่าจะเป็น K-Pop, K-Movie, และ K-Drama มาลองวิเคราะห์ดูและนี่เองก็เป็นอีกหนึ่งผมได้เข้ามาพัฒนาที่ Boonme Lab นั้นเอง
ในโปรเจกต์นี้ทีมต้องพัฒนาเว็บไซต์แสดงผลข้อมูล social listening จาก topic และ keyword ต่าง ๆ ที่ถูกพูดถึงในหัวข้อ K-POP, K-Movie, และ K-Drama โดยในเว็บไซต์จะมีลักษณะเป็น single page website ที่แสดงผลข้อมูลออกมาบน visualization ต่าง ๆ ทั้งหมด 8 ชิ้น และด้วยข้อจำกัดบางอย่างทำให้สิ่งหนึ่งที่เป็น challenge ในโปรเจกต์นี้ เราจะไม่มีการพัฒนา back-end side และด้วยเหตุผลนี้เองจึงทำให้เกิด challenge อื่น ๆ ตามมาด้วยเช่นกัน
โดย challenge แรกคือการที่จะต้องเลือกว่าข้อมูลจะถูกคำนวณจากที่ไหน ฝั่ง front-end หรือทำ index file ไว้จากข้อมูลเพื่อช่วยลดการคำนวณที่จะเกิดขึ้นกับ user ใน front-end โดยปัจจัยที่จะทำให้เราได้คำตอบนี้ได้คือ ถ้าทำการคำนวณบนหน้า front-end จะต้องใช้เวลามากเท่าใด หรือถ้าจะทำ index file จะต้องทำจำนวนเท่าไหร่ โดยเบื้องต้นในโปรเจกต์นี้ข้อมูลที่จะถูกนำไปแสดงบน visualization จะมีความละเอียดอยู่ในระดับสัปดาห์ และจะสามารถถูก filter ด้วย ช่วงเวลา, genre, keyword, platform, sentiment, ภูมิภาค ทางทีมจึงได้ใช้ข้อมูลตรงนี้ในการตั้งต้นในการหา solution
โดย solution แรกที่เป็นไปได้คือทำการคำนวณ filter ทั้งหมดใน front-end โดยทุกครั้งที่มีการเปลี่ยน filter front-end จะต้องทำการคำนวณข้อมูลที่จะเอามาแสดงผลใหม่ทุกครั้งแต่วิธีการนี้จะทำให้ระหว่างการเปลี่ยน filter จะเกิดการหน่วงการคำนวณข้อมูลได้ อีกทั้งเมื่อมีการเพิ่มข้อมูลเข้ามาในอนาคตก็จะทำให้มีการหน่วงเพิ่มขึ้นตามไปด้วยเช่นกัน
วิธีการต่อมาคือการเตรียม index file สำหรับข้อมูลชุดนี้และไม่ให้เกิดการคำนวณที่ front-end เลย ทำให้ต้องเตรียมไฟล์ตามจำนวนของความเป็นไปได้ที่จะเกิดขึ้นเมื่อ user เลือก filter ใด ๆ ก็ตาม ทำให้ในกรณีนี้เราต้องเตรียมไฟล์มากกว่า 600,000 ไฟล์ ซึ่งเกิดจาก 12 สัปดาห์ * 500 keywords * 6 ความเป็นไปได้ทั้งหมดของ platform * 18 ความเป็นไปได้ของ filter ทั้งหมด ด้วยกัน แต่ในโปรเจกต์นี้ เราอาจไม่จำเป็นที่จะต้อง optimize ไฟล์ถึงขนาดไม่ต้องเกิดการคำนวณเลยก็ได้เพราะในบางความเป็นไปได้อาจจะไม่ได้ถูกเลือกเลยก็ได้ และในอนาคตถ้าข้อมูลมีขนาดใหญ่ขึ้นจำนวนไฟล์ก็จะเพิ่มตามจำนวนข้อมูลไปด้วยเช่นกัน
สุดท้ายทางทีมก็ได้เลือกวิธีที่อยู่ตรงกลางคือบีบอัดข้อมูลให้มีขนาดเล็กลงโดยการสร้างไฟล์ index ที่สรุปข้อมูลเป็นรายสัปดาห์ โดยให้แต่ละ row เป็นข้อมูลของแต่ละสัปดาห์และ column เป็นข้อมูลของแต่ละ keyword และ filter โดยวิธีการนี้จะทำให้เมื่อ front-end ต้องการที่จะเรียกใช้ข้อมูลก็จะไม่ต้องใช้การคำนวณที่เยอะอีกต่อไป
อีกสิ่งที่ทางทีม Data มองว่าเป็นความท้าทายในโปรเจกต์นี้คือ การต้องรับผิดชอบการเขียน function สำหรับ query ข้อมูลที่อยู่ในฝั่ง front-end และสาเหตุในการตัดสินใจในครั้งนี้คือในทุกครั้งที่ข้อมูลผ่าน ETL หรือเก็บลงในฐานข้อมูล หน้าที่นี้มักจะเป็นของ Front-end หรือ Back-end ในการ query ข้อมูลสู่หน้าเว็บไซต์ ทีม Data เพียงแค่ให้คำแนะนำหรือวิธีการ query เท่านั้น โดย workflow แบบนี้จะเหมาะกับทีมที่มีขนาดใหญ่ที่มีหลายคนรับผิดชอบตำแหน่งเดียวกัน แต่กลับกันในทีมที่มีขนาดเล็กเช่นทีมในโปรเจกต์นี้อาจเกิดปัญหา เพราะ Front-end จะไม่ได้โฟกัสกับการพัฒนาเว็บไซต์เพียงอย่างเดียว แต่ต้องมาใช้เวลาแก้ query ข้อมูลด้วย ในโปรเจกต์นี้ ทีมจึงเลือกให้ทีม Data เข้ามาช่วยในงานนี้เพื่อลดภาระงานของ front-end โดยทีมก็ปรับ process ในการทำงานตามนี้
- ทีม Data/Front-end ช่วยกันกำหนด function ที่ต้องการใช้งานข้อมูล
- ทีม Front-end ออกแบบ interface ของ function และกำหนดลักษณะของข้อมูลทั้งขาเข้าและออกจาก function
- ทีม Data ทำการ query ข้อมูลให้ตรงกับรูปแบบที่ถูกกำหนดมา
และหลังจากที่ทีมได้มีลองใช้ workflow นี้ในการทำงานผลลัพธ์ที่ได้คือ สามารถช่วยลดโหลดการทำงานของ front-end และทำให้การพัฒนาใช้เวลาที่ลดลง
โดยหลังจากนี้จะเป็นการเล่าประสบการณ์ส่วนตัวของผมในฐานะ Data Analyst ที่ทำหน้าที่ในการเขียน query ข้อมูลด้วย JavaScript ในครั้งนี้ ก่อนอื่นต้องบอกก่อนว่า ผมเป็นคนที่เรียกได้ว่าเขียน JavaScript ไม่เป็นเลยก็ได้ ถึงแม้จะพอรู้พื้นฐานมาบ้าง แต่ก็ไม่เคยได้ลองพัฒนาโปรเจกต์ด้วย JavaScript มาก่อน แต่พอมาในโปรเจกต์นี้ถือว่าเป็นก้าวที่ใหญ่มากสำหรับผม เพราะด้วยความที่เราทำงานอยู่แต่กับ Python ก็มีความกังวลว่า Library ต่าง ๆ จะเหมือนกับที่เคยได้ใช้ใน Python หรือไม่ แต่หลังจากได้ลองเขียนจริง ๆ ถึงแม้ว่า Library หรือ Syntax จะต่างจากที่เขียนใน Python ไปบ้าง ยกตัวอย่างเช่น Syntax ในประกาศตัวแปร ว่ากรณีไหนจะต้องใช้ let หรือ const, Syntax ในการเขียน loop แต่กลับกันการใช้ Library อย่าง Lodash ก็ช่วยให้การเขียน code จัดการงานข้อมูลนั้นง่ายเมื่อเทียบกับการใช้ Pandas แต่สุดท้ายการเขียน JavaScript ก็ไม่ได้ยากเกินความสามารถของตัวเองและนอกจากนั้นยังทำให้รู้สึกสนุกระหว่างทำงานตรงนี้เพราะได้เรียนรู้อะไรใหม่ ๆ อยู่ตลอดเวลา
สุดท้ายอยากจะฝากข้อคิดสั้น ๆ สำหรับ เพื่อน ๆ Devloper ที่ผ่านทางมา ทุกอย่างนั้นเริ่มต้นจากศูนย์เสมอ ขอเพียงเรามีเพียงเราเอาชนะความกลัวที่เกิดขึ้นในใจแค่นี้ก็เป็นจุดเริ่มต้นที่ดีที่จะทำให้ศูนย์กลายเป็นหนึ่งแล้วครับ