ระบบข้อมูลมีแนวโน้มไปสู่การผลิต

สิบปีที่ผ่านมาได้เห็นการหมุนเวียนเกือบสมบูรณ์ของเครื่องมือที่มีให้สำหรับผู้เชี่ยวชาญด้านข้อมูล เมื่อพิจารณาจาก Modern Data Stack ในปัจจุบัน เครื่องมือส่วนใหญ่ (dbt, Looker, Snowflake, Fivetran, Hightouch, Census) ไม่มีจำหน่ายในเชิงพาณิชย์ในปี 2012 หมวดหมู่ทั้งหมด (ELT, Reverse ETL, คลังข้อมูลบนคลาวด์) และเฟรมเวิร์ก (การเปิดใช้งานข้อมูล, ดาต้าเมช) , โครงสร้างข้อมูล, สัญญาข้อมูล) ได้ถูกสร้างขึ้นแล้ว (หรือในบางกรณี แนวทางปฏิบัติ SWE ที่มีอายุหลายสิบปีได้ถูกค้นพบอีกครั้งโดยทีมข้อมูล) การติดตาม Twitter + Substack โครงการโอเพ่นซอร์ส อาชีพ และบริษัทต่าง ๆ เพิ่มขึ้นและลดลง โอกาสมีมากมาย

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

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

ระบบมีแนวโน้มไปสู่การผลิต

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

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

• สรุป : ข้อมูลสามารถแปลงได้หลายขั้นตอนตลอดการเดินทาง ตรรกะทางธุรกิจอยู่ในเครื่องมือที่หลากหลาย
• โอกาส : เครื่องมือข้อมูลสมัยใหม่ช่วยให้ผู้มีส่วนได้ส่วนเสียสามารถเข้าถึงข้อมูลและดำเนินการแปลงไมล์สุดท้ายเพื่อดำเนินการได้เร็วขึ้นและปลดบล็อกตนเอง
• ปัญหา : ตรรกะทางธุรกิจทั่วทั้งสแต็กทำให้ไม่สามารถทำซ้ำได้ การแปลงไมล์สุดท้ายไม่เป็นประโยชน์ต่อผู้ใช้ข้อมูลรายอื่น
• วิธีแก้ไข : ลดพื้นที่ที่สามารถใช้ตรรกะทางธุรกิจได้, สร้างนโยบาย “time to live” ในการแปลงครั้งสุดท้าย, สร้างวัฒนธรรมของการสร้างมาตรฐาน + เฉลิมฉลองการเข้าถึง codebases ข้ามสายงาน

ฤดูร้อน 2019 . การเพิ่มขึ้นของเครื่องดื่มที่มีแอลกอฮอล์ถูกแทงนั้นไม่สามารถหยุดยั้งได้ แต่ก็ยังมีเจ้าของร้านเหล้าแม่และป๊อปบางคนที่ไม่รู้ตัว คุณเป็นวิศวกรวิเคราะห์ที่ตลาดเครื่องดื่มแอลกอฮอล์ B2C ผู้จัดการบัญชีของคุณ (ผู้เชี่ยวชาญด้านการบริโภคแอลกอฮอล์) รู้ว่า Claws จะบินออกจากชั้นวาง หากคุณสามารถหาซื้อได้ในร้านค้า นี่คือตลาดที่เข้าใจยากในการปรับปรุง pareto แบบ win/win/win ซึ่งสินค้าคงคลังที่ดีกว่าจะเป็นประโยชน์ต่อลูกค้า ผู้ค้าปลีก และบริษัท คุณได้รับมอบหมายให้ค้นหาสินค้าขายดีที่ร้านขายเหล้าในเครือข่ายของคุณไม่มีขาย

1. การใช้งานภายใน (เครื่องมือ BI / Looker)

ข้อความค้นหาเริ่มต้นนั้นง่ายต่อการเขียน มีตารางร้านค้า (พร้อมmarket_idSKU ที่ขายดีที่สุดตามตลาด และฟีดสินค้าคงคลังรายวันสำหรับทุกร้านค้า) ทุกร้านค้ามีฟีดสินค้าคงคลังรายวัน สิ่งนี้ทำให้สินค้าขายดีที่แต่ละร้านไม่มี:

select
  s.store_id,
  skus.sku_id,
  skus.market_rank
from dim_stores as s
left join tbl_top_selling_market_skus as skus
  on s.market_id = skus.market_id
left outer join dim_store_inventory as inv
  on s.store_id = inv.store_id
  and inv.sku_id = skus.sku_id
  and inv.remaining_qty > 0
where inv.sku_id is null
order by store_id, skus.market_rank desc
;

…ผู้จัดการบัญชีเริ่มต้นให้ข้อเสนอแนะบนแดชบอร์ดตลอดกระบวนการ

หมายเหตุ:เครื่องมือ BI คือโครงสร้างพื้นฐานของทีมข้อมูล ไม่มีข้อมูลเชิงลึก / กรณีการใช้งาน / ผลิตภัณฑ์ออกจากโดเมนของทีมข้อมูล ความผิดพลาดมีผลกระทบน้อย มีโอกาสได้รับข้อเสนอแนะ + ในทันที

2. การใช้งานภายใน (Internal Tools / Salesforce)

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

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

…ผู้จัดการบัญชีคนหนึ่งสังเกตเห็นว่าร้านขายเบียร์และไวน์มีรายการสินค้าที่มียอดขายสูงสุด AM ใช้บริบททางธุรกิจของตน และข้ามรายการแนะนำที่พวกเขารู้ว่าร้านค้าไม่สามารถดำเนินการตามกฎหมายได้ มีการเพิ่มตรรกะทางธุรกิจเพิ่มเติมผ่านเลเยอร์การตัดสินใจของมนุษย์

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

3. การใช้งานภายนอก (Marketing Automation)

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

จำเป็นต้องมีคอลัมน์อีกสองสามคอลัมน์จากนั้นตารางดิบจะย้อนกลับ ETL เป็น Hubspot / Iterable / Braze ผู้ร่วมงาน CRM ดำเนินการขั้นสุดท้ายให้กับแคมเปญอีเมล และแคมเปญอีเมลที่ชื่อว่า “สิ่งของยอดนิยมที่คุณไม่พกติดตัว” ก็ใช้งานได้

…พนักงาน CRM ที่รับผิดชอบอีเมลแจ้งให้ทราบว่าสินค้าขายดีบางรายการ (ตามจำนวน) เป็นแอลกอฮอล์เพียงเล็กน้อย สิ่งนี้ไม่ตรงกับวิสัยทัศน์ของแบรนด์ของบริษัท / กรณีการใช้งานที่ลูกค้าต้องการ ระบบอีเมลส่วนใหญ่อนุญาตให้มีชั้นตรรกะเพิ่มเติม — ผู้ร่วมงาน CRM ใช้วิจารณญาณในการกรองรายการใด ๆ ที่มีปริมาณ 50 มล. หรือน้อยกว่า

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

4. การใช้งานภายนอก (การใช้งานจริง)

ทีมข้อมูลได้ยินจากทีม AM และ CRM — ร้านขายเหล้าบางแห่งค่อนข้างเก่าและไม่เช็คอีเมล ร้านเหล้าอื่น ๆ เป็นโรงเรียนเปิดใหม่และพวกเขาไม่ต้องการรอทั้งสัปดาห์เพื่อรับอีเมลเกี่ยวกับสิ่งที่กำลังเป็นที่นิยมในตลาดของพวกเขา กลุ่มตัดสินใจที่จะวนซ้ำในทีมแอปพลิเคชันค้าปลีกเพื่อใส่ "รายการยอดนิยมที่คุณไม่พกติดตัว" ลงในแอปที่ใช้งานจริงซึ่งผู้ค้าปลีกทุกรายใช้งาน ทีมข้อมูลจะย้ายเอาต์พุตของตนไปยังบัคเก็ต AWS S3 ซึ่งวิศวกรรมการผลิตจะดึงข้อมูลนั้นขึ้นมา พนักงานร้านขายสุราสามารถดูรายการนี้ได้ทุกวัน โดยไม่ต้องมีผู้จัดการบัญชีหรืออีเมลรบกวน White Claw และ Whispering Angel เข้าฉายในร้านค้าทุกแห่งในอเมริกา

…ผู้ค้าปลีกรายหนึ่งยื่นเรื่องร้องเรียนต่อ Retailer CX — พวกเขาจงใจหยุดจำหน่ายวอดก้า Smirnoff Peppermint หลังจากวันหยุด แท้จริงแล้วมันอาจเป็นสินค้าขายดีอันดับต้น ๆ ของ L90 แต่มันเป็นสินค้าตามฤดูกาลอย่างมาก และพวกเขาไม่ต้องการเห็นมันในรายการแนะนำ ข้อเสนอแนะนี้ส่งไปยังทีมวิศวกรผลิตภัณฑ์ ทีมนั้นได้ทำการปรับแต่งลอจิกในชั้นแอปพลิเคชันเพื่อระบุและลบรายการตามฤดูกาลที่ผ่านมา

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

สมมุติฐานสุดท้าย: ทีมวิศวกรที่รับผิดชอบการใช้ฟีดสินค้าคงคลัง (แตกต่างจากทีมที่รับผิดชอบแอปพลิเคชันผู้ค้าปลีก) ย้ายข้อมูลไปยังสคีมาสินค้าคงคลังใหม่ พวกเขาไม่ทราบถึง ขั้นตอน เดียวของโครงการ "รายการยอดนิยมที่คุณไม่ต้องดำเนินการ" การพึ่งพาที่ทีมข้อมูลสร้างขึ้นอย่างเงียบ ๆ เหนืองานของพวกเขา หรือการพึ่งพาที่คนอื่นสร้างขึ้นเหนืองานของทีมข้อมูล พวกเขาลบตารางเริ่มต้น NULLไหลเข้าสู่ Looker, Salesforce, Hubspot และแอปพลิเคชันผู้ค้าปลีกที่ใช้งานจริง ทีมข้อมูลได้ทำลายผลิตภัณฑ์

เรามาสรุปสิ่งที่เกิดขึ้นทั้งดีและไม่ดีกัน:

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

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

ด้านที่ไม่ดี: ผู้เชี่ยวชาญด้านข้อมูลเมื่อ 10 ปีที่แล้วเคยชินกับข้อความ "เฮ้ ข้อมูลหายไป" สถานการณ์ที่เลวร้ายที่สุดคือการวางเมตริกผิดลงในบอร์ดเด็ค วันนี้ ทีมข้อมูลสามารถตื่นขึ้นมาด้วยการแจ้งเตือนของ Pagerduty ว่าพวกเขาใช้งาน Salesforce, Hubspot และแอปพลิเคชันที่ใช้งานจริงไม่ได้หากตั้งค่า Pagerdutyไว้ การเปิดใช้งานข้อมูลได้เพิ่มเดิมพันของสิ่งที่ทีมข้อมูลสามารถทำลายได้

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

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

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

หากคุณจำตรรกะทางธุรกิจเพิ่มเติมได้:

• ผู้จัดการบัญชีใช้วิจารณญาณและข้ามการแนะนำ SKU สุราไปยังร้านเบียร์/ไวน์
• ผู้ร่วมงาน CRM ลบ SKU <= 50ml เนื่องจากการพิจารณาแบรนด์
• ทีมแอปพลิเคชันผู้ค้าปลีกลบ SKU ตามฤดูกาลสูงเนื่องจากความคิดเห็นของลูกค้า

แล้วเราจะทำอย่างไรเพื่อแก้ไขปัญหาเหล่านี้?

ระบบมีแนวโน้มที่จะผลิต

เรื่องราวสยองขวัญ ปัญหาทั่วไป และวิธีแก้ปัญหาทางเทคนิคสำหรับระบบการผลิตได้ถูกเขียนขึ้นเกี่ยวกับดาต้าทวิตเตอร์และสแต็กย่อย แนวทางแก้ไขส่วนใหญ่เป็นแนวปฏิบัติที่ดีที่สุดที่ SWE รู้จักมานานหลายทศวรรษ (หรืออย่างที่ Zach Kanter พูดอีกอย่างหนึ่ง วิศวกรรม ข้อมูลสถานะที่เป็นอยู่เป็นเพียงวิศวกรรมซอฟต์แวร์ที่ไม่มีแนวทางปฏิบัติที่ดีที่สุด ) หลักการ/บางส่วนที่ได้ผลดีที่สุดสำหรับทีมข้อมูล:

ทีมข้อมูลไม่ได้ควบคุมอินพุตของพวกเขา (h/t Nick Schrock )

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

• ความถูกต้องของแถวเดียว ( intเมื่อคุณคาดหวังint<50 เมื่อคุณคาดหวัง <50)
• ความถูกต้องของแถวรวม (สมมติฐานความละเอียด บริบททางธุรกิจเกี่ยวกับจำนวนแถว จำนวนแถวเทียบกับเมื่อวาน การกระจายของการรวม เช่น ผลรวม ค่าเฉลี่ย p90 ค่ามัธยฐาน)
• การมีอยู่/ความเก่าของข้อมูล (ตารางล่าสุดมีการปรับปรุง)

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

โซลูชันเหล่านี้สามารถนำไปใช้ได้โดยทีมข้อมูลซึ่งเลือกเครื่องมือที่เหมาะสม (เราชอบความคาดหวังที่ยอดเยี่ยม ) และพยายามอย่างเต็มที่ นั่นคือ 20% ของปัญหา ความท้าทายด้านองค์กร + การสื่อสารที่เหลืออีก 80% คือสิ่งที่ทำให้ระบบเสียหาย นี่คือโซลูชันสำหรับทั้งบริษัท:

สร้างการระบายข้อมูลเกรดการผลิต

หรือจงใจสร้างข้อมูล บริษัทที่เชื่อว่าวิทยาศาสตร์ข้อมูลมีประสิทธิภาพควรเชื่อในการสร้างข้อมูลการผลิตอย่างจงใจเพื่อขับเคลื่อนการเรียนรู้ของเครื่องและกรณีการใช้งานการวิเคราะห์ขั้นสูง (h/t Yali Sasoon) สิ่งนี้จำเป็นต้องอาศัยความร่วมมือกับวิศวกร และความร่วมมือทั่วทั้งบริษัทที่ข้อมูลสามารถสร้างขึ้นโดยเจตนา ไม่ใช่การสกัดอย่างเจ็บปวด

สร้างและเฉลิมฉลองเส้นทางสู่การผลิต

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

ระบบมีแนวโน้มไปสู่สหพันธ์คนตาบอด

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

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

Fivetran, dbt และ Hightouch ล้วนมีความสามารถในการกำหนดเวลางานผ่านกำหนดการ cron และ UI สิ่งนี้ทำให้สามารถสร้างการประสานในรูปแบบที่ไม่เปิดเผยการมองเห็นในการพึ่งพาโดยปริยาย ลองนึกภาพว่า Hightouch กำหนดให้เคลื่อนไหวexp_fb_click_idsทุกวันเวลา 8.00 น. ผ่าน UI Fivetran และ dbt ไม่สามารถมองเห็นการพึ่งพานั้น และไม่มีส่วนสนับสนุนโค้ดเบสต้นน้ำของ Hightouch

ให้ใช้เครื่องมือประสาน (Dagster/Prefect/Airflow) เป็นระนาบควบคุมเดียวแทน ผสานการพึ่งพาระหว่างเครื่องมือต่างๆ และสร้าง DAG แบบองค์รวมที่ทำงานตามความสำเร็จของขั้นตอนก่อนหน้า แทนที่จะหวังว่างานอัปสตรีมจะสำเร็จภายในช่วงเวลาหนึ่งของวัน รีบาวด์

สร้างการแมปแบบตัวต่อตัวของการส่งออกข้อมูลของทีมไปยังกรณีการใช้งานขั้นปลาย

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

select * -- Extremely clear this comes from one and only one place
from raw.salesforce.opportunity
;

select * -- Extremely clear this comes from one and only one place
from raw.salesforce.account
;

select * -- Extremely clear this goes to one and only one place
from ml_outputs.model_results.exp_top_items_retailer_app
;

select * -- Extremely clear this goes to one and only one place
from ml_outputs.model_results.exp_top_items_salesfrce
;

แทนที่จะสรุปเรื่องโรคชั้นในอักเสบ ฉันจะแนะนำคุณอีกครั้งที่หัวข้อและคำจำกัดความ ที่ยอดเยี่ยมของ Jean-Michel Lemieux คำแนะนำทั่วไปคือคำแนะนำของเขา พร้อมข้อมูลเฉพาะบางอย่างที่ใช้ได้ผลสำหรับฉัน

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

ลดพื้นที่ที่สามารถฉีดตรรกะทางธุรกิจในช่วงไมล์สุดท้าย:

Hightouch และ Census ช่วยให้สามารถแปลง SQL ได้ Fivetran เคย _ ผู้บริโภคที่เปิดใช้งานข้อมูลส่วนใหญ่ (Sales/CX CRMs, CDP) อนุญาตให้ใช้ SQL หรือเลเยอร์ตรรกะทางธุรกิจที่ต่ำ/ไม่มีโค้ด เมื่อใดก็ตามที่เป็นไปได้ อย่าเขียนตรรกะทางธุรกิจในเครื่องมือเหล่านี้ หากคุณทำตามการจับคู่แบบหนึ่งต่อหนึ่งของทีมข้อมูลส่งออกไปยังกรณีการใช้งานดาวน์สตรีม Reverse ETL ของคุณจะเป็น:

select * from exp_table_for_single_use_case;

ควรใช้การเปลี่ยนแปลงในตรรกะทางธุรกิจกับโมเดล dbt นั้นแทนในไมล์สุดท้าย

สร้างนโยบาย “Time To Live” ในการแปลงไมล์สุดท้าย:

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

โดยทั่วไปแล้ว ผู้มีส่วนได้ส่วนเสียทางธุรกิจของคุณมีบริบทที่คุณไม่มี คุณต้องการดูว่าพวกเขาเปลี่ยนแปลงข้อมูลของคุณอย่างไร คิดย้อนกลับไปที่ SKU ตามฤดูกาล ปริมาณ ตรรกะการจัดหมวดหมู่ร้านค้าที่วิศวกรวิเคราะห์พลาด สร้างโลกที่ผู้มีส่วนได้ส่วนเสียทางธุรกิจของคุณสามารถปรับปรุงงานของคุณได้!

นโยบาย “Time To Live” เป็นแรงดึงดูดที่ดึงกลับไปสู่การรวมศูนย์ อนุญาตให้มีการแปลงไมล์สุดท้าย แต่ตรวจสอบและดึงตรรกะทางธุรกิจกลับเข้าสู่ชั้น dbt / data science ส่วนกลางในจังหวะที่เหมาะกับทีมข้อมูลและผู้มีส่วนได้ส่วนเสียทางธุรกิจของคุณ

สร้างวัฒนธรรมแห่งการสร้างมาตรฐาน + เฉลิมฉลองการเข้าถึงโค้ดเบสข้ามสายงาน

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

นี้อาจจะเป็น️️️เอา. มีเหตุผลมากมายที่ต้องกังวลเกี่ยวกับสมาชิกในทีมที่ไม่มีข้อมูลในการเขียนตรรกะใน SQL และการสร้าง dbt PR สิ่งที่ฉันรับประกันได้ — ตรรกะนี้จะถูกเขียน และถ้าทีมข้อมูลเฝ้าประตู ตรรกะนั้นจะถูกเขียนนอกการมองเห็นของพวกเขา หากทีมข้อมูลสามารถให้ความรู้และสนับสนุนการมีส่วนร่วมใน codebase ของพวกเขาได้ พวกเขาก็จะเชิญชวนให้เขียนโค้ดในที่ที่มันควรจะเป็นที่สุด

ลงจอดเครื่องบิน:

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

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

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

หากคุณสามารถสร้างวัฒนธรรมที่:

• วิศวกรฝ่ายผลิตสร้างการระบายข้อมูลด้วยความตั้งใจและตื่นเต้นว่าข้อมูลจะถูกนำไปใช้อย่างไร
• สมาชิกในทีมข้อมูลมองหากรณีการใช้งาน ขอคำติชม และถามผู้มีส่วนได้ส่วนเสียของพวกเขาว่า "เฮ้ คุณทำอะไรกับข้อมูลที่ฉันส่งให้คุณจริงๆ"
• SWE สามารถให้คำปรึกษาและยกระดับแนวทางปฏิบัติที่ดีที่สุดและมาตรฐานของทีมข้อมูลเพื่อยกระดับการไหลของข้อมูลเฉพาะกิจไปสู่ระดับการผลิต
• สมาชิกในทีมข้อมูลสามารถให้คำปรึกษาและยกระดับผู้มีส่วนได้ส่วนเสียทางธุรกิจเกี่ยวกับวิธีการเพิ่มตรรกะทางธุรกิจ กรอบงานสำหรับตรรกะที่เกี่ยวข้อง
• ทุกทีมเชิญผู้อื่นเข้าสู่ฐานรหัสของพวกเขา และส่งเสริมมุมมองระยะยาวเกี่ยวกับสถาปัตยกรรมของบริษัทโดยรวม

Ian Macomber เป็นหัวหน้าฝ่ายวิทยาศาสตร์ข้อมูลและวิศวกรรมการวิเคราะห์ที่ Ramp ซึ่งเป็นบัตรองค์กรใบแรกและใบเดียวที่ช่วยให้บริษัทใช้จ่ายน้อยลง ก่อนหน้านี้ เขาเป็นรองประธานฝ่ายการวิเคราะห์และวิศวกรรมข้อมูลที่ Drizly

มีแนวโน้มที่สี่เช่นกัน! คอยติดตามสำหรับData Systems Tend Towards Calculationซึ่งมากเกินไปที่จะรวมไว้ในบทความเดียว