Data science

5 ข้อผิดพลาดที่ควรหลีกเลี่ยงเมื่อทำการ Replatform จาก Teradata

ในคุณสมบัติพิเศษของแขกรับเชิญนี้ Mike Waas ซีอีโอของ Datometry จะพิจารณาข้อผิดพลาดที่บริษัทต่างๆ ควรหลีกเลี่ยงเมื่อย้ายออกจาก Teradata Datometry เป็นแพลตฟอร์มการจำลองเสมือนของฐานข้อมูล SaaS ทำให้แอปพลิเคชันที่มีอยู่สามารถทำงานบนระบบการจัดการข้อมูลบนคลาวด์ที่ทันสมัยโดยไม่ต้องเขียนใหม่ Mike ดำรงตำแหน่งอาวุโสด้านวิศวกรรมที่ Microsoft, Amazon, EMC และ Pivotal และเป็นสถาปนิกของเครื่องมือเพิ่มประสิทธิภาพการสืบค้น ORCA ของ Greenplum เขาได้ประพันธ์ 40+ สิ่งพิมพ์ทางวิทยาศาสตร์ที่ผ่านการตรวจสอบโดยเพื่อนในด้านต่างๆ ของการวิจัยฐานข้อมูลและถือครองสิทธิบัตร 50 มีการเคลื่อนไหวที่เพิ่มขึ้นอย่างรวดเร็วของบริษัทต่างๆ ที่ย้ายออกจาก Teradata พวกเขาเบื่อที่จะถูกบอกว่าไอทีดำเนินธุรกิจอย่างไรแต่ไม่ได้ช่วยให้เติบโต และพวกเขาไม่สามารถพลาดโอกาสในการสร้างรายได้ใหม่ด้วยการใช้ประโยชน์จากสิ่งอำนวยความสะดวกในการประมวลผลข้อมูลมากมายในระบบคลาวด์สาธารณะ การปรับโครงสร้างใหม่ทำให้เกิดความกลัวแม้กระทั่งผู้นำด้านไอทีที่แข็งแกร่งที่สุด สำหรับมุมมอง ให้พิจารณาใบเสนอราคานี้ที่องค์กรขนาดใหญ่เพิ่งได้รับสำหรับการย้ายข้อมูลตามการเขียนใหม่: $10m สำหรับโครงการที่ควรดำเนินการ 36 เดือน. พิจารณาว่าการย้ายถิ่นแต่ละครั้งทำงานช้าและใช้งบประมาณเกินจริงได้อย่างไร ตอนนี้ คุณกำลังดูได้อย่างง่ายดายที่ $40m ถึง $50m ซึ่งอาจมากกว่า 5 ปี ผู้นำด้านไอทีที่คิดว่าตนเองสามารถเขียนแนวทางใหม่ในการออกจาก Teradata ได้ภายในเวลาไม่กี่เดือนจะต้องเผชิญกับการตื่นขึ้นอย่างหยาบคายพร้อมกับความผิดพลาดที่อาจนำไปสู่การสิ้นสุดอาชีพ ข้อผิดพลาดทั่วไปอื่นๆ ที่บริษัทควรหลีกเลี่ยงเมื่อทำการปรับแพลตฟอร์มจาก Teradata ใหม่มีอะไรบ้าง สมมติว่าแอปพลิเคชันของบุคคลที่สามที่มีอยู่สามารถระบุได้อีกครั้ง ผู้จำหน่าย BI/ETL ส่วนใหญ่สนับสนุนคลังข้อมูลบนคลาวด์ (CDW) ในซอฟต์แวร์เวอร์ชันล่าสุด (เน้นที่เวอร์ชันล่าสุด) บริษัทที่มีระบบนิเวศของแอปพลิเคชันที่เป็นที่ยอมรับมักจะใช้ระบบเวอร์ชันเก่า ดังนั้นพวกเขาจึงไม่สามารถชี้ให้เห็นถึงระบบดังกล่าวได้ เพื่อให้ทำงานกับคลังข้อมูลปลายทางใหม่ บริษัทต้องอัปเกรดก่อน ความพยายามนี้ขึ้นอยู่กับขนาดและโครงสร้างของระบบที่มีอยู่ แต่การอัปเกรดเป็นการดำเนินการที่โดยทั่วไปแล้วจะครอบคลุมหลายไตรมาสและมีค่าใช้จ่ายหลายล้านดอลลาร์อย่างรวดเร็ว อย่างไรก็ตาม แม้แต่การอัปเกรดที่มีราคาแพงก็ยังไม่ได้ผล เครื่องมือ BI/ETL เชิงพาณิชย์ทั้งหมดสนับสนุนการฉีด SQL ที่กำหนดเองลงในรายงานและไปป์ไลน์ข้อมูล เป็นผลให้มี Teradata SQL ฝังอยู่ในกระบวนการประจำวันทั้งหมดในทางปฏิบัติ ในการเขียนซ้ำแบบเดิม ตรรกะทั้งหมดนั้นจะต้องถูกแยกออก เขียนใหม่ แทรกใหม่ ทดสอบใหม่ และปรับใช้ใหม่ แม้ว่าจะเป็นการดึงดูดให้เชื่อว่าระบบนิเวศสามารถเคลื่อนย้ายได้ แต่ในทางปฏิบัตินั้นต้องใช้ความพยายามอย่างมากซึ่งต้องใช้แรงงานมาก การเขียน ETL ใหม่เมื่อไปที่ระบบคลาวด์ อาจดูไร้สาระเมื่อพิจารณาถึงความพยายามในการปรับใช้ ETL อีกครั้ง อย่างไรก็ตาม มักเกิดขึ้นจากสิ่งที่กล่าวข้างต้น (โปรดดู “สมมติว่าแอปพลิเคชันของบุคคลที่สามที่มีอยู่สามารถชี้ใหม่ได้”) หากการกำหนดตำแหน่งระบบที่มีอยู่ใหม่ไม่ใช่ตัวเลือกเนื่องจากจำเป็นต้องเขียนใหม่ทั้งหมด เราอาจเพียงแต่กัดสัญลักษณ์แสดงหัวข้อย่อยและเขียนไปป์ไลน์ข้อมูลใหม่ทั้งหมด หรือตรรกะดำเนินไป แต่นั่นเป็นข้อบกพร่องอย่างมหันต์ นี่เป็นตัวอย่างที่ดีว่าทำไมการโยกย้ายตามการเขียนซ้ำจึงล้มเหลวเป็นประจำ บริษัทต่างๆ ที่เปลี่ยนจากการปรับ ETL เป็นการออกแบบใหม่ทั้งหมดจะเลิกทำการลงทุนนานหลายปี และมีแนวโน้มว่าจะจบลงด้วยการออกแบบใหม่และคิดค้นตรรกะทางธุรกิจเดิมที่แน่นอนของระบบที่มีอยู่อยู่แล้ว แม้ว่าการเขียนใหม่และการพัฒนา ETL อาจเป็นโครงการออกแบบที่สำคัญสำหรับบริษัท แต่ก็มีเวลาและสถานที่สำหรับทุกสิ่ง เมื่อองค์กรต้องการสร้างแพลตฟอร์มใหม่บนคลาวด์ให้เร็วที่สุดเท่าที่จะเป็นไปได้ นั่นไม่ใช่เวลาหรือสถานที่สำหรับการออกแบบทดลองดังกล่าว คาดว่าจะย้ายจาก Teradata ไปเป็น CDW สมัยใหม่ในอีกไม่กี่เดือนข้างหน้า ความจริงก็คือบริษัทต่างๆ สามารถเปลี่ยนแพลตฟอร์มจาก Teradata เป็น CDW ได้ก็ต่อเมื่อพวกเขาไม่เขียนใหม่ การจัดเตรียม การเปลี่ยนเส้นทางแอปพลิเคชัน และการทดสอบเพียงอย่างเดียวจะใช้เวลาหลายเดือน พิจารณาสิ่งนี้เพื่อเปรียบเทียบ: การอัพเกรด Teradata นั้นใช้เวลาหลายเดือนในการวางแผนและดำเนินการ ไม่จำเป็นต้องเขียนแอปพลิเคชันเดียวใหม่ ปรับ SQL ที่ฝังตัวหรือเปลี่ยนตัวโหลดและยูทิลิตี้ หากการย้ายจาก Teradata ไปยัง CDW สมัยใหม่จำเป็นต้องเขียนใหม่ การเดิมพันทั้งหมดจะถูกยกเลิก หากบริษัทต้องเขียนใหม่ “สองสามเดือน” อาจกลายเป็นปีได้ การทดสอบเพียงอย่างเดียวเป็นความเจ็บปวดครั้งใหญ่ บริษัทต่างๆ จะต้องเขียนการทดสอบใหม่ทั้งหมด ตรวจสอบอีกครั้ง และปรับใช้ใหม่ การตรวจสอบความถูกต้องมีความซับซ้อนเนื่องจากใช้งานสภาพแวดล้อมการทดสอบที่แตกต่างกันสองแบบในขณะนี้ ต่อมาก็มาถึงการทดสอบการยอมรับของผู้ใช้ซึ่งเป็นภาระมากขึ้นเนื่องจากความแตกต่างของระบบ ในระยะสั้น สองสามเดือนเป็นขั้นต่ำเปล่าสำหรับการดำเนินการใดๆ หากบริษัทต่างๆ ต้องเขียนใบสมัครใหม่ พวกเขากำลังพิจารณาฐานจำนวนมากอย่างรวดเร็ว สมมติว่าการเขียนซ้ำนำไปสู่ประสิทธิภาพที่ดีขึ้น CDW สมัยใหม่ทุกคนภาคภูมิใจในการเป็นคลังข้อมูลเอนกประสงค์ เครื่องมือเพิ่มประสิทธิภาพการสืบค้นที่มีประสิทธิภาพซึ่งรวมอยู่ในระบบเหล่านี้ช่วยให้มั่นใจได้ว่าการสืบค้นข้อมูลจะดำเนินไปอย่างดีที่สุด พวกเขาสามารถประมวลผลอะไรก็ได้ที่ขว้างใส่พวกเขา ยังมีความเข้าใจผิดอยู่เรื่อยๆ ว่าข้อความค้นหาของ Teradata จำเป็นต้องเขียนใหม่ด้วยวิธีบางอย่างที่ไม่ระบุรายละเอียด น่าจะเป็นที่ทำให้พวกเขาทำงานได้ดีขึ้นใน CDW นี่เป็นเรื่องจริงเมื่อสองสามปีก่อนเมื่อระบบคลาวด์ยังอยู่ในช่วงเริ่มต้น แต่โชคดีที่วันเหล่านั้นผ่านพ้นไปนานแล้ว ไม่เพียงแต่บริษัทต่างๆ ไม่ต้องการการปรับแต่งเหล่านี้ แต่ควรอยู่ห่างจากพวกเขาจริงๆ การเพิ่มประสิทธิภาพดังกล่าวไม่ว่าจะมีเจตนาดีเพียงใด จะเพิ่มความซับซ้อนและเปลี่ยนเป็นหนี้ทางเทคนิคได้อย่างรวดเร็ว อยู่ในความสนใจหลักของผู้จำหน่ายระบบคลาวด์ที่จะขจัดความจำเป็นในการปรับแต่งหรือการกำหนดสูตรพิเศษของแบบสอบถาม สิ่งที่อาจดูเหมือนการปรับให้เหมาะสมอย่างชาญฉลาดในวันนี้ไม่ได้เป็นอะไรนอกจากอุปสรรคในวันพรุ่งนี้ กล่าวโดยย่อ “การเพิ่มประสิทธิภาพ” ต้องใช้ความพยายามอย่างมาก แต่ก็เกือบจะเสียเวลาเปล่าเกือบทุกครั้ง การแก้ปัญหาเท่านั้น 80% ของปัญหา การโยกย้ายส่วนใหญ่ล้มเหลวเนื่องจากผู้นำด้านไอทีประเมินความพยายามต่ำเกินไป การย้ายฐานข้อมูลเป็นปัญหา 50-20 – ครั้งแรก 80% ของการเดินทางต้องการเพียง 20% ของความพยายาม การเขียนซ้ำเป็นเรื่องง่ายที่จะทำให้ความคืบหน้าดีขึ้น และการย้ายข้อมูลเกือบทั้งหมดดูเหมือนง่ายอย่างน่าประหลาดใจ อย่างไรก็ตาม ส่วนที่เหลือ 10% ที่นำปัญหาทั้งหมดออกมา ใช้เวลาหลายปีและหลายปี และทำลายโครงการย้ายถิ่น มีเครื่องมือการย้ายข้อมูลจำนวนหนึ่งเกิดขึ้นเมื่อเร็วๆ นี้ พวกเขาพยายามแปลงโค้ด Teradata SQL เป็น SQL ที่เทียบเท่าใน CDW ตอนนี้ให้พิจารณาว่าการแปลงโค้ดอัตโนมัติเหล่านี้ส่วนใหญ่อ้างว่ามีอัตราความสำเร็จ 50-70% และเราจะทราบได้อย่างรวดเร็วว่าเหตุใดจึงเป็นเช่นนั้น ไม่ใช่วิธีแก้ปัญหานี้ โดยพื้นฐานแล้วพวกเขาจะแก้ปัญหาง่าย ๆ ส่วนใหญ่ซึ่งไม่ใช่ปัญหาที่จะเริ่มต้น ในกรณีที่ดีที่สุด โปรแกรมแปลงโค้ดอัตโนมัติจะลดความพยายามโดยรวมลง 10-%. แต่ในภาพรวมของสิ่งต่าง ๆ ที่เป็นเพียงเสียงรบกวน Replatforming จาก Teradata ไม่ใช่เรื่องง่ายอย่างที่หลายองค์กรเชื่อ ตรงกันข้ามกับสิ่งที่ผู้นำด้านไอทีได้รับการบอกกล่าว – การปรับแพลตฟอร์มใหม่ต้องการมากกว่าการเขียนใหม่ เป็นสิ่งสำคัญสำหรับองค์กรที่จะต้องตระหนักถึงความเข้าใจผิดทั่วไปเกี่ยวกับการปรับแพลตฟอร์มใหม่ เพื่อหลีกเลี่ยงการทำผิดพลาดที่มีค่าใช้จ่ายสูง และเพื่อให้แน่ใจว่าจะประสบความสำเร็จเมื่อย้ายจาก Teradata ลงทะเบียนเพื่อรับจดหมายข่าว InsideBIGDATA ฟรี เข้าร่วมกับเราบน Twitter: @InsideBigData1 – https://twitter.com/InsideBigData1

  • บ้าน
  • Business
  • Data science
  • Marketing
  • Leave a Reply

    Your email address will not be published. Required fields are marked *

    Back to top button