เลือกฐานข้อมูลสำหรับ Big Data

imagesความท้าทายอย่างสำคัญในเรื่อง Big Data ก็คือมันมาพร้อมกับเทคโนโลยีและแนวคิดใหม่หลายอย่างที่ แม้แต่ CIO หรือ IT Manager ยังต้องพยายามทำความเข้าใจ เพื่อจะได้เลือกใช้ให้เหมาะสมกับสถานการณ์

บทความนี้จะเน้นไปในเรื่องของการเลือกระบบฐานข้อมูล ข้อควรพิจารณาตลอดจนข้อดีข้อเสียของฐานข้อมูลแต่ละประเภท

ช่วงเวลาแห่งความสับสน

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

  • ขนาดข้อมูลที่เติบโตขึ้นอย่างรวดเร็ว
  • ความเชื่อมโยง หรือ connectedness ข้อมูลเชื่อมโยงกันมากขึ้นเรื่อยๆ เริ่มจาก hyperlink ไปจนถึง social graph
  • ลักษณะข้อมูลแบบ Multi-Structure คือทั้งแบบที่มีโครงสร้างเต็มรูปแบบ บางส่วนหรือผสมกัน
  • สถาปัตยกรรมของแอพลิเคชั่น ที่เคยเป็นแบบหนึ่งแอพลิเคชั่นหนึ่งฐานข้อมูลในยุค mainframe พัฒนามาเป็นแบบหนึ่งฐานข้อมูลหลายแอพลิเคชั่นในช่วง client-server จนมากลายเป็นสถาปัตยกรรมแบบให้บริการย่อยๆ แยกส่วนกัน และแต่ละบริการมีส่วนข้อมูลของตัวเอง (SOA)

แนวโน้มทั้งสี่ข้อ ส่งผลให้เกิดการพัฒนาฐานข้อมูลรูปแบบใหม่ขึ้นมามากมาย บริษัท startup หลายแห่งเติบโตและได้รับความสนใจเป็นอย่างมาก ดึงดูดให้มีผู้เล่นหน้าใหม่เข้ามาในตลาดอยู่เรื่อยๆ แนวคิด เทคนิค และศัพท์ใหม่ๆ ถูกพัฒนาและต่อยอดต่อไป ซึ่งนับเป็นผลดีเพราะเป็นการผลักดันเทคโนโลยีให้ก้าวหน้าขึ้น
แต่ในขณะเดียวกัน ก็ส่งผลเสียให้หลายคนที่อาจเกิดความสับสนขึ้นได้ โดยเฉพาะผู้ที่มีหน้าที่ต้องกำหนดและวางแนวทางการจัดการข้อมูลขององค์กร ความสับสนที่เกิดขึ้น ส่งผลให้เกิดความล่าช้าในการปรับเปลี่ยนแนวทางการทำงาน

สถาปัตยกรรมข้อมูล

หนึ่งในความรับผิดชอบของผู้นำ IT ในองค์กร คือการวางผังสถาปัตยกรรมของระบบ IT ต่างๆ ในองค์กร โดยมีสถาปัตยกรรมข้อมูล หรือ Data Architecture เป็นองค์ประกอบสำคัญหนึ่งในผังรวม

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

  • คุณภาพของบุคลากร
  • ความเข้าใจในธุรกิจ

โซลูชั่นต่างๆ ก็เหมือนกับเครื่องมือ หากเราได้ช่างฝีมือดี เครื่องมือแย่ก็ยังสามารถทำงานได้อยู่ แต่ถึงจะได้เครื่องมือชั้นยอดมา แต่หากใช้โดยช่างผู้ไม่มีทักษะเพียงพอกับเครื่องมือนั้น ผลลัพธ์ก็ออกมาแย่ได้เช่นกัน

ความเข้าใจในโจทย์ทางธุรกิจก็เป็นตัวแปรสำคัญ นั่นคือความสามารถในการแปลงเป้าหมายธุรกิจเป็นข้อกำหนดทางเทคนิค ตัวอย่างเช่น ลักษณะของแหล่งข้อมูลรวมถึงอัตราการเติบโตของข้อมูล รูปแบบการใช้ข้อมูล (ผ่านแอพลิเคชั่น หรือผ่าน API มี concurrent มากน้อยเพียงใด เป็นต้น) ความต้องการด้าน SLA เวลาในการตอบสนอง ระยะเวลาในการกู้ระบบ ต้นทุนการจัดการระบบ การวางแผน capaciy planning เผื่อช่องว่างสำหรับการเติบโตบ้าง แต่ไม่ต้องมากจนเกินไปในช่วงแรก

หากมีบริษัทแห่งหนึ่งประสบความสำเร็จในการใช้ฐานข้อมูล X ในการรับมือกับลูกค้าจำนวน 500 ล้านคน ก็ไม่ได้หมายความว่าบริษัทอื่นจะใช้ฐานข้อมูล X จัดการกับลูกค้า 100 ล้านคนได้ จำเป็นต้องพิจารณาบริบทประกอบด้วย

ปัจจัยที่ควรพิจารณาในการเลือกฐานข้อมูล

มีปัจจัยหลายข้อที่ส่งผลต่อการพิจารณาเลือกระบบฐานข้อมูล ความสำคัญของปัจจัยแต่ละข้ออาจมากน้อยแตกต่างกันไปตามความต้องการของธุรกิจ

Data Characteristics

ปัจจัยแรกคือคุณลักษณะของข้อมูลที่ต้องการจัดเก็บ ลักษณะข้อมูลมักเป็นตัวกำหนดกลุ่มเทคโนโลยีฐานข้อมูลที่จะเลือกใช้ ในขณะที่ฐานข้อมูลเชิงสัมพันธ์ RDBMS เหมาะกับข้อมูลที่มีลักษณะเป็นโครงสร้างสูง เช่นข้อมูลธุรกรรมจากระบบ OLTP แต่ไม่เหมาะกับข้อมูลในลักษณะอื่น เช่นเสียงรูปภาพหรือข้อมูลจาก social media

Functionalities

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

Transactional Compliance

การจัดการธุรกรรมหรือ Transaction ในแง่ของระบบฐานข้อมูลหมายถึงกลุ่มของการเปลี่ยนแปลงข้อมูลในระบบ ที่ต้องการให้มีคุณสมบัติ ACID (Atomicity, Consistency, Isolation, Durability)

  • Atomicity – คือการรับประกันว่าการเปลี่ยนแปลงเกิดขึ้น “ทั้งหมด” หรือ “ไม่เกิดขึ้นเลย” อย่างใดอย่างหนึ่งท่านั้นในหนึ่งธุรกรรม ไม่มีการทำธุรกรรมแบบครึ่งๆ กลางๆ
  • Consistency – คือการรับประกันว่า ข้อมูลในฐานข้อมูลจะสอดคล้องกันในตลอดช่วงเวลาการทำธุรกรรม
  • Isolation – หมายถึงการที่ข้อมูลการทำธุรกรรมรายการหนึ่ง จะไม่สามารถอ่านข้อมูลจากอีกธุรกรรมหนึ่งได้หากธุรกรรมนั้นยังไม่สมบูรณ์ ซึ่งหมายถึงหากมีการทำธุรกรรมมากกว่าหนึ่งรายการพร้อมๆ กัน ระบบฐานข้อมูลจะจัดเรียงลำดับให้เหมือนกับว่าทำงานเรียงกัน
  • Durability – คือการรับประกันว่า เมื่อการทำธุรกรรมเสร็จสมบูรณ์แล้ว ผลลัพธ์นั้นจะถูกบันทึกลงในสื่อที่คงทนถาวร เช่น ฮาร์ดดิสก์ และคงอยู่ต่อไป

คุณสมบัติ ACID เหล่านี้มีความสำคัญอย่างยิ่ง ในระบบงานแบบ OLTP (Online Transaction Processing) ตัวอย่างเช่นการทำธุรกรรมโอนเงินระหว่างบัญชี หรือการจองที่นั่ง ที่หนึ่งรายการธุรกรรมมีหลายขั้นตอน และมีจำนวนผู้ทำรายการพร้อมๆ กันเป็นจำนวนมาก

Response Time

ระยะเวลาตอบสนองของระบบ โดยยังแบ่งเป็นสองส่วน คือ ความเร็วในการ “อ่าน” ข้อมูล และความเร็วในการ “เขียน” หรือบันทึกข้อมูล รูปแบบการทำงานหรือระยะเวลาตาม SLA (service level agreement) จะเป็นตัว กำหนดว่าระบบที่ต้องใช้ต้องมี response time อย่างไร

Scalability

ความสามารถในการขยายขีดความสามารถของระบบ เป็นอีกหนึ่งปัจจัยที่สำคัญ ในขณะที่เราต้องการหลีกเลี่ยงการซื้อระบบที่มีขนาดใหญ่ ราคาสูงเกินความจำเป็นตั้งแต่เริ่มต้น แต่เราก็ยังต้องการความสามารถที่จะขยายระบบให้ใหญ่ขึ้น รองรับปริมาณงานที่จะเพิ่มในอนาคตได้ โดยไม่ต้องรื้อสร้างใหม่ทั้งหมด
แนวคิดที่สำคัญอย่างหนึ่งคือ ความแตกต่างระหว่าง Scale Up กับ Scale Out ซึ่งเป็นการขยายเหมือนกันแต่คนละแนวทาง

  • Scale Up คือการเพิ่มความสามารถของระบบโดยขยายหน่วยเก็บข้่อมูลหรือหน่วยประมวลผลให้มีความสามารถสูงขึ้น อาจจะด้วยการเพิ่มจำนวนฮาร์ดดิสก์ เพิ่มหน่วยความจำ เพิ่มจำนวนซีพียู แน่นอนว่า องค์ประกอบอื่นๆ จะต้องรองรับด้วย เช่นฮาร์ดแวร์ต้องมีสล็อตว่าง ระบบปฎิบัติการต้องรองรับ แอพลิเคชั่นต้องเป็นแบบ multi-threads การขยายในลักษณะนี้จะมีต้นทุนค่อนข้างสูง
  • Scale Out เป็นการเพิ่มความสามารถโดยการ เพิ่มจำนวนหน่วยประมวลผลหรือหน่วยเก็บข้อมูลทั้งหน่วย โดยที่แต่ละหน่วย จะมีราคาไม่สูงนัก ทำให้ต้นทุนการขยายระบบโดยรวมแล้วต่ำกว่าและมีลักษณะเป็นเชิงเส้น คาดการณ์ได้ง่ายและคุ้มค่ากว่าแบบ Scale Up อย่างไรก็ตาม การที่จะสามารถ Scale Out ได้ จำเป็นต้องมีซอฟต์แวร์ที่ช่วยในการจัดการกระจายโหลดการทำงานทั้งหลาย ออกไปยังเครื่องโหนดแต่ละเครื่อง จึงจะสามารถใช้งานทุกโหนดได้เต็มที่

1-lusBWUjJPjdcqAGRfA9p3Q

ที่มาของภาพ : https://medium.com/cloud-mobile-the-products-around/database-sql-nosql-7244061b7697

Maintainability

ระบบงานสำคัญที่เป็นหัวใจหลักของการทำงานขององค์กรที่หยุดทำงานไม่ได้เลย หรือพวก mission-critical system จำเป็นต้องมีความสามารถเพิ่มเติมในแง่ของการบำรุงรักษา เช่น การสามารถเปลี่ยนหรือเพิ่มเติมอุปกรณ์ที่เสียบางชิ้นได้โดยไม่จำเป็นหยุดระบบทั้งระบบ หรือการสำรองข้อมูล ความสะดวกในการกู้ระบบหรือกู้ข้อมูบลในสถาณการณ์ที่เกิดภัยพิบัติเป็นต้น

Maturity

ข้อได้เปรียบประการหนึ่งสำหรับเทคโนโลยีที่เติบโตและมีการใช้งานมาจนถึงระดับหนึ่งแล้ว คือ การได้รับการสนับสนุนจากชุมชนต่างๆ มีฮาร์ดแวร์ซอฟต์แวร์มารองรับมากเพียงพอ สามารถทำงานร่วมกับเทคโนโลยีอย่างอื่นได้ มีกลุ่มผู้ใช้ที่สามารถช่วยแก้ไขปัญหา แบ่งปันความรู้ หรือผลักดันให้มีการพัฒนาต่อเนื่องในด้านต่างๆ อีกทั้งยังมีจำนวนผู้สนใจศึกษาเทคโนโลยี และมีความรู้ความชำนาญในเทคโนโลยีมากพอที่จะหาบุคลากรมาทำงานด้วยได้

Cost

ต้นทุนค่าใช้จ่าย คงไม่สามารถปฎิเสธได้ว่า นี่ก็เป็นปัจจัยสำคัญข้อหนึ่งที่ส่งผลเป็นอย่างมากต่อการเลือกใช้ฐานข้อมูล แต่การพิจารณาต้นทุน จำเป็นต้องพิจารณาให้รอบด้าน หรือที่เรียกว่า TCO – Total Cost of Ownership ไม่เพียงเฉพาะแค่ค่าฮาร์ดแวร์หรือค่า license software เท่านั้น แต่ยังรวมถึง ค่าใช้จ่ายอื่นๆ ที่เกี่ยวข้อง เช่นค่า suport ค่าฝึกอบรม เป็นต้น

 

ระบบฐานข้อมูล SQL vs NoSQL

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

SQL

ความจริงแล้ว SQL หรือ Structured Query Language ไม่ได้เป็นเทคโนโลยีฐานข้อมูลโดยตรง แต่เป็นชื่อเรียกภาษาที่ใช้ในการสืบค้นข้อมูล ระบบฐานข้อมูลพื้นฐานที่ใช้ร่วมกับ SQL คือระบบฐานข้อมูลเชิงสัมพันธ์ หรือ Relational Databases แต่เราเรียกกลุ่มนี้ว่า SQL ในเชิงเปรียบเทียบกับกลุ่ม NoSQL เท่านั้นเอง

Relational Databases

ระบบจัดการฐานข้อมูลเชิงสัมพันธ์ หรือ RDBMS เป็นเทคโนโลยีที่เติบโตพัฒนาเต็มที่ต่อเนื่องมายาวนานหลายทศวรรษแล้ว มีผลิตภัณฑ์สินค้าครอบคลุมทุกช่วงการใช้งาน ข้อมูลในฐานข้อมูลกลุ่มนี้จะเก็บอยู่ในรูปแบบตาราง คือจัดเป็นคอลัมน์และแถว โดยจำเป็นต้องมีโครงสร้างข้อมูลชัดเจน

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

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

Analytical Databases

เทคโนโลยีฐานข้อมูลอีกกลุ่มหนึ่ง ซึ่งถูกพัฒนาต่อยอดมาจาก RDBMS คือฐานข้อมูลสำหรับการวิเคราะห์ หรือ OLAP (Online Analytical Processing) โดยทำการปรับแต่งฐานข้อมูล เพื่อให้เหมาะสมกับการวิเคราะห์ข้อมูล นั่นคือการคำนวณค่าต่างๆ ไว้ล่วงหน้า และการจัดรูปแบบโครงสร้างข้อมูลเป็นแบบหลายมิติ multi-dimensional เพื่อเปิดโอกาสให้ผู้ใช้ สามารถเลือกวิเคราะห์ข้อมูลตามมิติต่างๆ ที่ต้องการได้โดยสะดวก
โครงสร้างข้อมูลของ OLAP อาจเป็นรูปแบบที่ซับซ้อนมากขึ้น แต่ก็ยังจำเป็นต้องมีการกำหนดไว้ล่วงหน้า และฐานข้อมูลในลักษณะนี้กลายมาเป็นหัวใจหลักของระบบ Business Intelligence โดยทำหน้าที่เป็น Data Warehouse หรือ Data Mart เป็นศูนย์กลางของระบบ และมีข้อดีและข้อเสียโดยรวมไม่แตกต่างจาก Relational Databases เท่าใดนัก

NoSQL

กลุ่มต่อมาคือกลุ่มที่เรียกว่า NoSQL (Not Only SQL) คือกลุ่มระบบฐานข้อมูลที่ไม่ได้จัดเก็บข้อมูลในรูปแบบตารางที่มี data model ถูกกำหนดไว้ชัดเจนล่วงหน้าเหมือนอย่างระบบ RDBMS
แรงผลักดันของการออกแบบฐานข้อมูลในกลุ่มนี้ ก็เพื่อให้มีการออกแบบฐานข้อมูลทำได้ง่ายขึ้น การ Scale Out ทำได้ดีกว่าเดิม และมีประสิทธิภาพในการทำงาน “บางประเภท” ดีกว่าระบบฐานข้อมูลแบบ RDBMS

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

nosql

ที่มาของภาพ: https://kvaes.wordpress.com/2015/01/21/database-variants-explained-sql-or-nosql-is-that-really-the-question/

แบ่งออกเป็นประเภทหลักๆ ได้ดังนี้

  • Key-Value
  • Column-Family
  • Document
  • Graph

 

Key-Value Databases

ฐานข้อมูลแบบนี้มีรูปแบบโครงสร้างข้อมูลง่ายที่สุด คือเป็นการจับคู่ระหว่างข้อมูลที่เป็นกุญแจ และตัวข้อมูลเอง ไม่มีข้อกำหนดว่าคีย์ต้องเป็นข้อมูลอะไร หรือส่วนที่เป็น value ต้องเป็นข้อมูลรูปแบบไหน เรียกได้ว่าเป็นโครงสร้างข้อมูลแบบ schema-free มีข้อดีคือทำงานได้รวดเร็วมาก สามารถขยายขนาดให้ใหญ่มากๆ ได้ง่าย มีโมเดลที่ทำงานได้ง่ายและกระจายโหลดการทำงานได้สะดวก
ข้อเสียก็คือ รูปแบบโครงสร้างข้อมูลอย่างง่ายนี้ ไม่ได้เหมาะกับข้อมูลทุกประเภท และการควบคุมข้อมูลหรือทำความเข้าใจกับข้อมูล เป็นหน้าที่โดยตรงของแอพลิเคชั่นที่เรียกใช้โดยเฉพาะ
ตัวอย่างของระบบฐานข้อมูลในแบบ key-value ได้แก่ Dynamo ของ Amazon, Redis, Riak, Memcache และ SimpleDB

Column-Family Databases

ฐานข้อมูลแบบนี้ ดูเผินๆ อาจจะมีรูปแบบคล้ายคลึงกับตารางข้อมูลในแบบ relational แต่มีความแตกต่างกันอยู่พอสมควร โดยที่ข้อมูลในแต่ละแถว อาจมีจำนวนและรูปแบบคอลัมน์แตกต่างกันได้ แต่ละแถวจึงถูกเรียกว่า column-family ในแต่ละคอลัมน์ ข้อมูลจะเป็นแบบ key-value pair

Column-Family (หรือบางทีอาจเรียก wide-column หรือ column-oriented) มีความสามารถ scale ได้น้อยกว่า ฐานข้อมูลแบบ Key-Value แต่ข้อดีก็คือ สามารถรองรับรูปแบบข้อมูลที่ซับซ้อนกว่าแบบ KV
ตัวอย่างฐานข้อมูลแบบ Column-Family ได้แก่ Google BigTable, HBase, และ Cassandra

Document Databases

รูปแบบฐานข้อมูลแบบ document นี้ได้รับแรงบันดาลใจจากระบบจัดการเอกสารของ Lotus Notes โดยทำการรวบรวมค่า key-value หลายเวอร์ชั่นมารวมกันเป็นคอลเล็กชั่น แล้วประกอบกันเป็นเอกสาร โดยมีรูปแบบลักษณะคล้าย JSON (JavaScript Object Notation)

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

ตัวอย่างฐานข้อมูลแบบ Document ได้แก่ CouchDB และ MongoDB

Graph Databases

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

ถึงแม้ว่าเราจะสามารถออกแบบฐานข้อมูลที่เก็บความสัมพันธ์เหล่านั้นด้วยโครงสร้างแบบ Relational ได้ก็ตาม แต่เมื่อจำนวนโหนดเพิ่มมากขึ้น จำนวนความสัมพันธ์เพิ่มมากเป็นทวีคูณ การใช้ภาษาสืบค้นข้อมูลอย่าง SQL ต้องใช้เวลานานมาก ฐานข้อมูลแบบ Graph จะใช้อัลกอริทึมในการค้นหาเส้นทางที่สั้นที่สุดเพื่อเพิ่มประสิทธิภาพในการเรียกค้นข้อมูล

ตัวอย่างฐานข้อมูลแบบ Graph ได้แก่ Neo4J, InfoGrid และ Infinite Graph

NoSQL ในภาพรวม

ยังมีระบบฐานข้อมูล NoSQL อีกหลายแบบ ที่ไม่ได้กล่าวถึงในที่นี้ แต่โดยรวมแล้วฐานข้อมูลในกลุ่มนี้มีลักษณะสำคัญร่วมกันคือ

  • มีความยืดหยุ่นในแง่ของโครงสร้างข้อมูลมากกว่าฐานข้อมูลเชิงสัมพันธ์
  • สามารถขยายตัวและกระจายโหลดการเก็บข้อมูลไปบนคอมพิวเตอร์จำนวนมากได้ดีกว่า
  • มีประสิทธิภาพสูงมากในงานเฉพาะด้าน หากเลือกใช้ให้เหมาะกับงาน
  • การควรคุมโครงสร้างข้อมูล จำเป็นต้องขึ้นอยู่กับแอพลิเคชั่นที่ใช้
  • ความยืดหยุ่นและประสิทธิภาพของ NoSQL แลกมาด้วย การที่ไม่สามารถทำตาม ACID ได้ทั้งหมด จึงไม่เหมาะกับการใช้งานด้าน transaction
  • NoSQL เหมาะกับการเก็บข้อมูล แต่ไม่สามารถทำงานบางอย่างได้ดีนัก อย่างเช่น การทำ Reporting, Aggregation หรือ Analytics

 

nosql-databases

ที่มาของภาพ: http://www.tomsitpro.com/articles/rdbms-sql-cassandra-dba-developer,2-547-2.html

สรุป

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

ในขณะที่เทคโนโลยีดั้งเดิมที่คุ้นเคยกันมาก่อน ก็ได้รับการพัฒนามายาวนาน ถึงแม้ว่าอาจตอบสนองความต้องการใหม่ๆ บางอย่างได้ไม่ดีนัก แต่ก็ยังมีงานที่เหมาะสมกับเทคโนโลยีแบบเดิมอยู่

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

ตัวอย่างการใช้ Machine Learning มาเพื่อปรับ business process อัตโนมัติ

jun16-27-124625723

บทความจาก HBR เล่าถึงตัวอย่างการนำอัลกอริทึม Machine Learning มาใช้ในการปรับปรุงกระบวนการผลิต ทั้งแบบ Self-Adapting และ Self-Repairing หรือรวมกันทั้งสองแบบ ตัวอย่างแรกเป็นผู้ผลิตรถยนต์ในเยอรมันที่ใช้ ML มาใส่ในไลน์ประกอบรถยนต์ ทำให้สามารถ customize รถยนต์แต่ละรุ่นได้เป็นล้านรูปแบบ ตามความต้องการของลูกค้าได้โดยอัตโนมัติ

ตัวอย่างที่สองเป็นการปรับปรุงสายการผลิตอะไหล่รถยนต์ ที่ใช้ซอฟต์แวร์วิเคราะห์จุดเสี่ยงในกระบวนการผลิต แล้วปรับเปลี่ยนเพื่อลดปริมาณอะไหล่ที่ผลิตไม่ได้คุณภาพโดยอัตโนมัติ

ตัวอย่างที่สามเป็นงานในด้านการก่อสร้างสะพานข้ามคลองในอัมสเตอร์ดัม ซึ่งก่อสร้างโดยการใช้เครื่องพิมพ์ 3 มิติพิมพ์สะพานมาจากทั้งสองฝั่ง เพื่อให้มาพบกันตรงกลาง โดยมีเซ็นเซอร์หลายตัวคอยส่งข้อมูลสภาพรอบด้านมาให้ เพื่อให้เครื่องพิมพ์สามารถปรับเปลี่ยนตัวเองได้กลางทาง เช่นในกรณีที่ตลิ่งฝากหนึ่งยุบมากกว่าที่คาดไว้ เป็นต้น (ตัวสะพานคาดว่าจะสร้างเสร็จในปี 2017)

ก้าวต่อไปที่จะเกิดขึ้นก็คงเป็น AI ที่บริหารโรงงานได้เอง และสายการผลิตหุ่นยนต์อัตโนมัติเต็มรูปแบบอย่างในหนัง

ที่มา : https://hbr.org/2016/06/business-processes-are-learning-to-hack-themselves

แนวโน้ม Big Data ในปี 2016 ที่ส่งผลกระทบต่อสถาบันการเงิน

big-data_0เมื่อ Big Data กลายร่างจากโครงการที่ฝ่าย IT เป็นผู้ผลักดัน มาเป็นโซลูชั่นที่จะช่วยผลักดันธุรกิจของทั้งองค์กร หน่วยงานในภาคธุรกิจต่างๆ ก็รีบปรับตัวมาใช้เทคโนโลยีนี้อย่างจริงจัง และนี่คือแนวโน้มที่จะส่งผลกระทบต่อสถาบันการเงินต่างๆ

  • ตัวอย่างความสำเร็จที่เห็นได้ชัดเจนมากขึ้นเรื่อยๆ
    จากเดิมที่ IT เป็นผู้นำเอาเครื่องมือหรือเทคโนโลยีเข้ามา เป็นแค่ a solution looking for a problem to solve ก็เริ่มมีหน่วยงานที่ประสบความสำเร็จในการสร้างโซลูชั่นเพื่อแก้ปัญหาทางธุรกิจด้วยข้อมูล โดยเห็นตัวอย่างได้ชัดเจนจากสองด้าน
    ด้านแรกคืองานด้านการกำกับดูแลอย่าง compliance, regularatory risk reporting, cyber security หรือ trade surveillance ส่วนที่สองคือด้านการสร้างรายได้จากการเรียนรู้และเข้าใจลูกค้ารอบด้านมากขึ้น

  • Smart (Semantic) Data Lake
    ปัญหาข้อมูลกระจัดกระจายในองค์กรเป็นหนึ่งในสถานการณ์ที่พบได้ในทุกองค์กร แนวคิด Data Lake คือการเป็นแหล่งรวมข้อมูลทั้งหมดในองค์กร โดยเก็บไว้ในรูปแบบดั้งเดิมและมีค่าใช้จ่ายต่ำ แต่ Data Lake ก็ยังมีข้อจำกัดในเรื่องของการธรรมาภิบาลข้อมูล (Data Governance – Link) การทำแคตาล็อกข้อมูล และการเชื่อมโยงข้อมูลเข้าด้วยกัน ทำให้ใช้ประโยชน์ไม่ได้เต็มที่นักเทคโนโลยีที่น่าจะเข้ามาช่วยแก้ปัญหานี้ได้เรียกว่า Smart (Semantic) Data Lake (SDL) เป็นการกำหนด “ไวยากรณ์” หรือโครงร่างที่สามารถอธิบายข้อมูลต่างๆ ใน Data Lake ได้ มีการพัฒนา semantic ที่เป็นมาตรฐานเปิด และที่สำคัญคือ หากมีการนำเอาโมเดลเฉพาะธุรกิจการเงิน อย่าง Financial Industry Business Ontology (FIBO) มาใช้ร่วมกับ SDL ก็จะกลายเป็นเครื่องมือที่ทรงพลังในการที่สถาบันการเงินต่างๆ จะใช้ประโยชน์จากข้อมูลที่มีอยู่ได้
  • Democratization of Data Access
    สิ่งที่จะเกิดตามมาอันเนื่องจาก Smart Data Lake ก็คือการเข้าถึงข้อมูลได้ง่ายขึ้น จากบุคลากรภายในองค์กร จากที่เดิมการเข้าถึงและเข้าใจข้อมูลเคยถูกจำกัดอยู่ในวงแคบๆ แค่เจ้าหน้าที่ IT หรือกลุ่ม data scientists ที่สามารถเขียนโปรแกรมดึงข้อมูลมาได้ แต่หาก SDL ใช้ไวยากรณ์ที่เป็นที่เข้าใจกันในวงการ ก็ทำให้บุคลากรอีกเป็นจำนวนมากไม่ว่าจะเป็น analysts, planner หรือแม้แต่ผู้บริหารระดับกลาง ก็จะสามารถสืบค้นข้อมูลและทำการวิเคราะห์ข้อมูลตามความต้องการของตัวเองได้ง่ายมากขึ้น
  • การใช้งาน Big Data Solution ที่เพิ่มมากขึ้นในองค์กรขนาดกลาง
    จากความใหม่และความซับซ้อนของเทคโนโลยี ทำให้ที่ผ่านมา มีแต่หน่วยงานขนาดใหญ่เท่านั้นที่ลงทุนนำ Big Data มาใช้งาน อย่างไรก็ตาม เมื่อ cloud computing ราคาถูกลง เข้าถึงได้ง่ายขึ้น รวมกับเครื่องมือและโซลูชั่นสำเร็จรูปทำให้กำแพงที่เคยขวางกั้นหน่วยงานขนาดกลาง ลดระดับลง เราจะได้เห็นองค์กรในขนาดต่างๆ เริ่มนำเทคโนโลยีใหม่ๆ มาใช้อย่างกว้างขวางมากขึ้น
  • The rise of Big Data Governance
    ในขณะที่สถาบันการเงินส่วนใหญ่เข้าใจและเห็นความสำคัญของงานด้าน data governance คือหากไม่ได้มี enterprise data governance program อยู่ก่อนแล้ว ก็อยู่ในระหว่างการจัดตั้งอยู่
    การมาถึงของ Big Data และ Data Lake จะทำให้ขอบเขตงานของการกำกับดูแลข้อมูล ขยายตัวเพิ่มมากขึ้น จากเดิมที่เคยเป็นเฉพาะข้อมูลแบบโครงสร้างภายในองค์กร ก็ต้องเริ่มมากำกับดูแลข้อมูลแบบ 3V ที่อยู่บน data lake เพิ่มขึ้นอีกด้วย
    ข้อดีอย่างหนึ่งก็คือ การลงทุนในกิจกรรม data governance ไม่ได้มีผลดีเฉพาะกับการกำกับดูแลให้เป็นไปตามข้อกำหนดทางกฏหมายเท่านั้น แต่ยังส่งผลดีต่อการดำเนินงานโดยทั่วไปของสถาบันการเงินด้วย โดยเฉพาะอย่างยิ่งในสภาวะที่การแข่งขันกับคู่แข่งหน้าใหม่อย่าง FinTech กำลังจะเริ่มขึ้น ข้อมูลที่มีคุณภาพคือเสบียงและอาวุธสำคัญที่จำเป็นต้องมี

เรียบเรียงจาก: 5 Big Data Trends Impacting Financial Institutions in 2016

แนวโน้มสำคัญ 6 ประการที่ผลักดันการใช้ Big Data ให้มีประโยชน์เพิ่มมากขึ้น

Six-Megatrendsถึงแม้ว่า ณ วันนี้ Big Data จะไม่ใช่เรื่องใหม่อีกต่อไปแล้ว แต่องค์กรส่วนใหญ่ ก็ยังมองเทคโนโลยี Big Data เป็นเพียงแค่ “ส่วนประกอบหนึ่ง” เท่านั้น ไม่ต่างจากเทคโนโลยี reporting หรือ Business Intelligence ในอดีตมากนัก

 

แต่แนวโน้มสำคัญ 6 อย่างนี้ จะช่วยผลักดันให้เทคโนโลยีที่เกี่ยวข้อง Big Data มีความสำคัญเพิ่มยิ่งขึ้นไปอีก

 

  • Internet of Anything (IoAT) เราคงเคยได้ยินนักวิเคราะห์พูดถึงเรื่องกระแสและความสำคัญของ IoT มาบ้างแล้ว แต่เพิ่งจะในปีนี้เองที่องค์กรต่างๆ เริ่มนำข้อมูลจาก IoT มาใช้เป็นส่วนประกอบสำคัญในด้านต่างๆ ของการทำงาน การหลอมรวมข้อมูลที่ได้จาก IoT เข้ากับข้อมูลอื่นๆ เช่น Social Media, เว็บคลิ้ก และ Server Log สร้างเป็น data products ใหม่ๆ เกิดเป็นกระแสใหม่ที่ทาง Gartner ตั้งชื่อว่า Digital Mesh

 

  • Unified Architecture – จากเดิมที่แพลตฟอร์ม Big Data เริ่มต้นที่ Batch processing แต่เมื่อพัฒนาต่อมาเรื่อยๆ ก็จะเริ่มเห็น architecture ที่เป็นหนึ่งเดียวกันมากขึ้น สามารถรองรับแอพลิเคชั่นขององค์กรได้หลากหลายมากขึ้น ตั้งแต่ batch procesing, realtime processing และ interactive and streaming บนแพลตฟอร์มเดียวกัน

 

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

 

  • Machine Learning, Data Science และ Predictive Analytics – เมื่อองค์กรส่วนใหญ่ เริ่มมีความสามารถในการจัดเก็บและจัดการกับข้อมูลจำนวนมาก ขั้นต่อไปคือการนำข้อมูลเหล่านั้นมาแก้ปัญหาเชิงธุรกิจ และนำผลลัพธ์เหล่านั้นย้อนกลับไปปรับปรุงกระบวนการทำงานในระดับปฏิบัติการต่อไป

 

  • Visualization เมื่อข้อมูลมีจำนวนเพิ่มมากขึ้น ความสามารถด้าน data visualization จึงกลายมาเป็นองค์ประกอบบสำคัญเพื่อสื่อสารสิ่งที่ซ่อนอยู่ในข้อมูลเหล่านั้น พัฒนาการของเครื่องมืออย่าง intelligence dashboard และ scorecard นอกจากจะส่งผลให้ Big Data ได้รับความนิยมเพิ่มขึ้นแล้ว ยังทำให้แนวทางการใช้งานข้อมูลเปลี่ยนไปด้วย

 

  • DevOps เมื่อแพลตฟอร์ม Big Data มีบทบาทในองค์กรเพิ่มมากขึ้น แนวทางการพัฒนาและสนับสนุนระบบงานก็ต้องเปลี่ยนแปลงไปด้วย DevOps เป็นแนวทางที่ประสบความสำเร็จในการปรับเปลี่ยนระบบงาน ให้ยืดหยุ่นและรองรับความเปลี่ยนแปลงได้อย่างรวดเร็ว เริ่มมีองค์กรจาก Fortune 1000 หลายแห่งในหลายอุตสาหกรรมอย่างภาคการผลิต บริการทางการเงิน และสาธารณสุข ที่นำ DevOps มาใช้มากขึ้น

 

แนวโน้มเหล่านี้ กำลังทำให้เกิดปรากฎการณ์ที่เรียกว่า Big Data Analytics is everywhere ไม่ใช่เฉพาะในด้านการสนับสนุนการตัดสินใจในองค์กรธุรกิจขนาดใหญ่เท่านั้น แต่กำลังเข้ามามีส่วนร่วมในชีวิตประจำวันของเราทุกคน

เรียบเรียงจาก Six (Mega)Trends for Deriving Massive Value from Big Data

ตัวอย่างการปฏิวัติ Personal Healthcare ด้วยเทคโนโลยีข้อมูล

shutterstock_175646576หนึ่งในวงการที่คาดว่าจะถูกปฏิวัติอย่างขนานใหญ่จากเทคโนโลยีในยุคปฏิวัติอุตสาหกรรม 4.0 ก็คือด้านการดูแลสุขภาพ  ต้นทุนการดูแลสุขภาพจากภาครัฐสูงขึ้นเรื่อยๆ ในขณะที่หลายประเทศรวมถึงไทยก็เข้าสู่สังคมผู้สูงอายุเต็มตัวแล้ว แนวทางการให้บริการด้านสุขภาพจึงจำเป็นต้องปรับตัวอย่างขนานใหญ่

เราเห็นแนวคิดเรื่อง personalized healthcare กันมาพอสมควรแล้ว แต่วันนี้เริ่มมีตัวอย่างการใช้งานจริงมาให้เห็นแล้ว

ไมโครซอฟต์ร่วมมือกับศูนย์สุขภาพ Dartmouth Hitchcock ใน New Hampshire นำเทคโนโลยีหลายอย่างมาใช้ร่วมกันเพื่อสร้างบริการการดูแลสุขภาพที่เฉพาะตัวบุคคลมากยิ่งขึ้น เรียกว่าโครงการ ImagineCare  โดยใช้เทคโนโลยีอาทิเช่น

 

  • Dynamics CRM ใช้เก็บข้อมูลการปฏิสัมพันธ์ระหว่างแพทย์และผู้ป่วย
  • Cortana Intelligence Suite ใช้เพื่อวิเคราะห์และเรียกค้นข้อมูลโดยผู้ให้บริการ
  • Azure Machine Learning เพื่อทำการพยากรณ์โอกาสที่อาจเกิดอันตรายด้านสุขภาพได้
  • Power BI ใช้สร้าง Patient Dashboard ที่ทั้งแพทย์ ศูนย์บริการ และผู้ป่วยสามารถเข้าถึงได้ และรับรู้ข้อมูลที่เปลี่ยนแปลงไป
  • อุปกรณ์ตรวจวัดด้านสุขภาพที่ใช้ในบ้าน เช่น เครื่องชั่วน้ำหนัก ความดัน และเลือด สามารถวัดผลและส่งข้อมูลกลับไปที่ศูนย์ได้ทันที
  • ศูนย์บริการที่ทำงาน 24 ชม. คอยติดตามสุขภาพผู้ป่วย และแจ้งเตือนเมื่อเกิดความเสี่ยงขึ้น
  • Wearable Devices ใช้ส่ง alert จากศูนย์บริการสู่ผู้ป่วยและผู้ดูแล

ตัวอย่าง Patient Dashboard

imaginecare

การทำงานร่วมกันของเทคโนโลยีหลายๆ ส่วน เชื่อว่าจะสามารถส่งผลให้การดูแลสุขภาพที่ดีขึ้น และลดต้นทุนค่าใช้จ่ายโดยรวมลงได้

Dartmouth-Hitchcock revolutionizes the U.S. healthcare system

https://youtu.be/-wVeHZNn8aU

ไมโครซอฟต์ประกาศการสนับสนุน Apache Spark อย่างจริงจัง

microsoft and spark summitในงาน Spark Summit สัปดาห์นี้ ไมโครซอฟต์ประกาศรายละเอียดการสนับสนุน Apache Spark หลายอย่าง ทั้ง Cortana Intelligence Suite, Power BI และ Microsoft R Server

  • Spark for Azure HDInsight เปิดให้ใช้แบบ General Availability แล้วหลังจากเป็น Public Preview มาตั้งแต่กลางปี 2015
  • R Server for HDInsight in the cloud powered by Spark ตัวนี้เพิ่งเปิด public preview ไปเมื่อเดือนมีนานี้ แต่จะเปิดใช้ได้ทั่วไปในช่วงหน้าร้อน (ภายในเดือนสิงหาคม)
  • R Server for Hadoop on-premises now powered by Spark
  • เปิดตัวโปรแกรมฟรี R Client สำหรับ data scientists โดยทำงานร่วมกับบริการต่างๆ เช่น SQL Server R Services, R Server for Hadoop และ HD Insight with Spark สามารถดาวน์โหลด R Client ได้แล้วที่ http://aka.ms/rclient
  • Power BI support for Spark Streaming ซึ่งแต่เดิม Power BI สนับสนุน Spark อยู่แล้ว แต่ตอนนี้เพิ่มการสนับสนุน Spark Streaming ช่วยในการทำงานวิเคราะห์ข้อมูลแบบ real-time

ที่มา : Microsoft announces major commitment to Apache Spark

การทำงานร่วมกันระหว่าง SSRS 2016 กับ Power BI

ssrs-and-powerbiไมโครซอฟต์เพิ่งออก SQL Server 2016 ซึ่งมีการปรับปรุงความสามารถของ SSRS (SQL Server Reporting Services) เพิ่มมาอีกหลายอย่าง วีดีโอข้างล่างนี้อธิบายถึงความสามารถที่จะใช้ SSRS 2016 ร่วมกับ Power BI ซึ่งสามารถสรุปได้ 3 แนวทางดังนี้
  • Upload PBIX ไฟล์ขึ้นไปบน SSRS Web portal แต่ยังต้องเปิดด้วย Power BI Desktop อยู่ดี แต่ใช้ SSRS Web Portal เป็น portal เท่านั้นเอง แต่ก็เป็นตัวเลือกอย่างหนึ่งในการทำ report library ส่วนความสามารถที่จะอ่านไฟล์และ interact กับ PBIX ไฟล์โดยตรงผ่าน SSRS Web Portal นั้น กำลังพัฒนาอยู่ ยังไม่ทราบว่าจะเสร็จเมื่อไหร่

 

  • Power BI Mobile App เชื่อมต่อเข้ากับ Report Server หมายความว่าใช้ Power BI Mobile App เป็น client สำหรับเรียกใช้รายงานที่อยู่บน SSRS แต่ก็มีข้อจำกัดคือ ณ เวลานั้นอุปกรณ์ของเราจำเป็นต้องเชื่อมต่อเน็ตเวิร์คอยู่ เพื่อ access รายงานบน SSRS

 

  • Pin หรือ “ปักหมุด” รายงานหรือ visualization ที่สร้างไว้ใน SSRS ให้มาแสดงผลอยู่ Power BI dashboard ซึ่งจำเป็นต้องมีการ config ให้ SSRS เชื่อมต่อกับ Power BI ในลักษณะ subscription เสียก่อน แถมยังจำเป็นต้องคอย sign-in เข้าสู่ Power BI  ทุก 90 วันด้วย เพราะ authentication token กำหนดให้หมดอายุใน 90 วัน
โดยรวมแล้วยังถือว่า ค่อนข้างผิวเผินและเชื่อมโยงกันไม่ได้สนิทนัก เพราะโครงสร้างที่แตกต่างกันพอสมควร แต่ก็เป็นจุดเริ่มความพยายามที่จะตอบสนองผู้ใช้ทั้งสองกลุ่ม คาดว่าจะยังคงมีการเพิ่มเติมความฟีเจอร์ หรือปรับให้มีความสะดวกเพิ่มมากกว่านี้อยู่เรื่อยๆ
ไปดูรายละเอียดได้จากวีดีโอเลยครับ

Big Data จะช่วยให้ตลาด App โตขึ้นเป็น $100bn ในปี 2020

global app revenueตลาด App มีศักยภาพที่จะโตได้ถึง $100 billion ภายในปี 2020 จากการคาดการของบริษัทวิจัยตลาด app ทั้งนี้เพราคาดว่าตลาด app จะโตเป็นสองเท่าจากที่เคยคาดไว้ว่าจะถึง $50 bn ในปีนี้ ทำให้คาดได้ว่าภายในปี 2020 จะแตะที่หลัก 100 billion ได้

แต่ผลวิจัยยังกล่าวอีกว่า มูลค่าตลาดที่เพิ่มขึ้นนี้จะอยู่ในกลุ่มผู้ผลิต app จำนวนไม่มากนัก และปัจจัยสำคัญคือการใช้ Big Data และการวิเคราะห์ข้อมูล เพื่อปรับปรุงคุณภาพของ app บริษัทที่ใช้ insights จากข้อมูลที่เก็บรวมรวมลักษณะการใช้งาน app ของลูกค้า แล้วนำมาปรับให้สอดคล้องกับลักษณะการใช้งานและกลุ่มลูกค้าเป้าหมาย จะมีศักยภาพในการสร้างกลุ่มผู้ใช้ในลักษณ “ชุมชน” ที่เหนียวแน่นกับ app

จากการศึกษาบริษัทผู้สร้าง app 12 แห่งที่ใช้ big data มาเพื่อมองหา customer insights พบว่า การใช้ข้อมูลจะช่วยให้ผู้ใช้มีส่วนร่วมกับ app มากขึ้นถึง 35% ส่งผลให้สร้างรายได้เพิ่มขึ้นได้อีก 20%

ที่มา : Big data is the key to the app market reaching $100 billion in 2020

อธิบายไลเซนส์ของ Power BI แต่ละแบบ

logo_squareMicrosoft Power BI มีไลเซนส์ทั้งหมด 3 แบบ (หน้า pricing)

  • Power BI (Free)
  • Power BI Pro – ราคาปัจจุบันอยู่ที่ $9.99 ต่อผู้ใช้ต่อเดือน
  • Power BI for Office 365

ทั้งตัว Free และ Pro สามารถดาวน์โหลดและใช้งานโปรแกรม Power BI Desktop แล้ว publish ขึ้น Web ได้ทั้งคู่ แต่ต่างกันที่

  • ปริมาณข้อมูลทั้งหมดใน dataset ผู้ใช้แบบฟรีจะจำกัดที่ 1 GB แบบ Pro จะได้สูงถึง 10 GB
  • ผู้ใช้แบบ Pro หลายคนในองค์กรเดียวกัน สามารถสร้าง Group ได้ โดยแต่ละกลุ่มมีข้อมูลได้สูงสุด 10 GB และข้อมูลรวมทั้งองค์กรต้องไม่เกิน 10 GB คูณจำนวนผู้ใช้แบบ Pro
  • การรีเฟรชข้อมูล ผู้ใช้แบบฟรีตั้งให้รีเฟรชข้อมูลอัตโนมัติได้แค่ วันละหนึ่งครั้ง ผู้ใช้แบบโปรกำหนดได้สูงสุด 8 ครั้งต่อวัน
  • ปริมาณการสตรีมข้อมูลผ่าน Power BI REST API ผู้ใช้แบบฟรีทำได้ด้วยอัตรา 10,000 เรคอร์ดต่อชั่วโมง แต่ถ้าเป็นโปร จะทำได้ที่ไม่เกิน 1 ล้านเรคอร์ดต่อชั่วโมง
  • ผู้ใช้แบบฟรีไม่สามารถเชื่อมต่อกับแหล่งข้อมูล on-premise ได้ แต่แบบโปรจะทำได้ผ่าน data connectivity gateway
  • ผู้ใช้แบบโปร มีความสามารถในการทำงานร่วมกัน (Collaboration) ได้อีกหลายอย่าง เช่น การใช้งาน Office 365 Groups การสร้าง Content Pack ในองค์กร การจัดการสิทธิผู้ใช้ผ่าน Active Directory groups และการแชร์ data catalog เป็นต้น

ส่วน Power BI for Office 365 ดูเหมือนจะเป็นบริการเก่า ซึ่งตกทอดมาตั้งแต่สมัยเริ่มขาย Office 365 (เหมือนกับซื้อ Office 365 ได้ Power BI พ่วงมาด้วย)

รายละเอียดเพิ่มเติม : Power BI Licensing Revisited!

1 2 3 4 6