Hệ thống dữ liệu có xu hướng sản xuất

Mười năm qua đã chứng kiến ​​sự thay đổi gần như hoàn toàn trong các công cụ dành cho chuyên gia dữ liệu. Nhìn vào Ngăn xếp dữ liệu hiện đại ngày nay, phần lớn các công cụ (dbt, Looker, Snowflake, Fivetran, Hightouch, Census) không có sẵn trên thị trường vào năm 2012. Toàn bộ danh mục (ELT, Reverse ETL, kho đám mây) và khung (kích hoạt dữ liệu, lưới dữ liệu , kết cấu dữ liệu, hợp đồng dữ liệu) đã được tạo. (Hoặc trong một số trường hợp, các phương pháp SWE hàng chục năm tuổi đã được các nhóm dữ liệu phát hiện lại.) Twitter + Substack theo dõi, dự án nguồn mở, sự nghiệp và công ty đã tăng và giảm. Cơ hội rất nhiều.

Khả năng và diện tích bề mặt để một chuyên gia dữ liệu ảnh hưởng đến hướng đi của công ty lớn hơn đáng kể so với một thập kỷ trước. Thật không may, diện tích bề mặt của những gì có thể xảy ra sai sót cũng tăng nhanh như vậy. Các thách thức bao gồm từ SLA kỹ thuật cấp thấp đến hệ thống cấp cao, văn hóa, tiêu chuẩn và thiết kế tổ chức. Các công cụ mới cực kỳ mạnh mẽ. Các công ty có thể vừa xây dựng vừa phá vỡ hệ thống dữ liệu với tốc độ cao hơn bao giờ hết.

Tôi đã quan sát thấy ba xu hướng đối với hệ thống dữ liệu trong 5 năm qua, trải rộng trên các ngành dọc kỹ thuật trong các nhóm dữ liệu, cũng như trên các ngành dọc kinh doanh được dữ liệu hỗ trợ. Tôi sẽ cố gắng mô tả những xu hướng này thông qua các ví dụ có thể khái quát hóa cho nhiều công ty và hy vọng sẽ mô tả các cơ hội, vấn đề và giải pháp theo cách có thể khái quát hóa cho nhóm của bạn. Xu hướng, cơ hội, vấn đề và giải pháp:

Hệ thống hướng tới sản xuất

• Tóm tắt : công việc và kết quả đầu ra của dữ liệu có giá trị cuối cùng được sử dụng trong các trường hợp sử dụng ngày càng quan trọng hơn/cấp độ sản xuất.
• Cơ hội : kết quả đầu ra của nhóm dữ liệu có thể trải rộng trên một diện tích bề mặt lớn hơn và có tác động mạnh hơn nhiều.
• Vấn đề : vì các đầu ra dữ liệu được sử dụng bởi các trường hợp sử dụng quan trọng hơn, nên không có sự “cứng nhắc” tương ứng cho các quy trình công việc, vốn ban đầu được thiết lập theo cách rất nhẹ.
• Giải pháp : Tạo một lộ trình cho các luồng nhẹ được nâng cấp lên “sản xuất”, kỷ niệm thời gian làm cứng hệ thống khi chúng chuyển sang cấp sản xuất.

• Tóm tắt : kết quả đầu ra dữ liệu ban đầu dành cho một mục đích cụ thể ngày càng được nhiều nhóm và trường hợp sử dụng áp dụng mà không hề hay biết.
• Cơ hội: thông tin chi tiết được thiết kế cho một trường hợp sử dụng cụ thể có thể thúc đẩy quá trình ra quyết định/kết quả tốt hơn giữa nhiều nhóm hơn.
• Vấn đề : không có hai nhóm nào có thông số kỹ thuật giống hệt nhau, các cải tiến cho một trường hợp sử dụng không được sử dụng ở nơi khác.
• Giải pháp : tạo các cam kết của người tiêu dùng/nhà sản xuất + khả năng hiển thị thành các phần phụ thuộc, tập trung hóa logic kinh doanh.

• Tóm tắt : Dữ liệu có thể được chuyển đổi ở nhiều bước trong suốt hành trình của nó, logic nghiệp vụ tồn tại trong nhiều công cụ khác nhau.
• Cơ hội : Các công cụ dữ liệu hiện đại cho phép các bên liên quan truy cập dữ liệu và thực hiện các chuyển đổi chặng cuối để di chuyển nhanh hơn và tự bỏ chặn.
• Vấn đề : Logic nghiệp vụ trên toàn bộ ngăn xếp khiến khả năng tái tạo là không thể, các phép biến đổi chặng cuối không mang lại lợi ích cho những người tiêu dùng dữ liệu khác.
• Giải pháp : Giảm thiểu các lĩnh vực có thể đưa vào logic kinh doanh, tạo chính sách “thời gian tồn tại” đối với các lần chuyển đổi chặng cuối, xây dựng văn hóa tiêu chuẩn hóa + tôn vinh quyền truy cập vào các cơ sở mã đa chức năng.

Mùa hè 2019 . Sự gia tăng của seltzer tăng đột biến là không thể ngăn cản, nhưng vẫn còn một số chủ cửa hàng rượu nhỏ và mẹ không biết. Bạn là kỹ sư phân tích tại thị trường rượu B2C. Người quản lý tài khoản của bạn (chuyên gia về tiêu thụ rượu) BIẾT rằng Claws sẽ bay khỏi kệ, nếu bạn chỉ có thể mua chúng trong cửa hàng. Đây là cải tiến pareto thị trường khó nắm bắt win/win/win, trong đó hàng tồn kho tốt hơn mang lại lợi ích cho khách hàng, nhà bán lẻ và công ty. Bạn đã được giao nhiệm vụ tìm ra những mặt hàng bán chạy nhất mà một cửa hàng rượu trong mạng lưới của bạn không có.

1. Sử dụng nội bộ (BI tool/Looker)

Truy vấn ban đầu rất dễ viết. Có một bảng các cửa hàng (với market_id, SKU bán chạy nhất theo thị trường và nguồn cấp dữ liệu hàng tồn kho hàng ngày cho mọi cửa hàng). Mỗi cửa hàng có nguồn cấp dữ liệu hàng tồn kho hàng ngày. Một cái gì đó như thế này có được những mặt hàng bán chạy nhất mà mỗi cửa hàng không bán:

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
;

…người quản lý tài khoản ban đầu đưa ra phản hồi trên bảng điều khiển trong suốt quá trình.

Lưu ý: Công cụ BI là cơ sở hạ tầng của nhóm dữ liệu. Không có thông tin chi tiết/trường hợp sử dụng/sản phẩm nào rời khỏi miền của nhóm dữ liệu. Một sai lầm có hậu quả thấp, phản hồi có khả năng + ngay lập tức.

2. Sử dụng nội bộ (Công cụ nội bộ / Salesforce)

Tuy nhiên, nhóm bán hàng/thành công của khách hàng/quản lý tài khoản không dành cả ngày cho Looker — họ dành cả ngày cho Salesforce. Có hai trình duyệt mở là một nỗi đau. Đây là một trường hợp sử dụng ETL đảo ngược sách giáo khoa. Đặt dữ liệu ở nơi nó sẽ được sử dụng . Điều này đã khó khăn nhiều năm trước, bây giờ nó không đáng kể - ký một nhà cung cấp ETL đảo ngược, di chuyển các điểm dữ liệu của bạn từ A đến B trong vòng chưa đầy một ngày.

Các mặt hàng bán chạy nhất mà một cửa hàng không bán hiện đã có trong Salesforce. Nhóm dữ liệu đã thêm ngữ cảnh cho một nhóm khác theo cách ít gây tranh cãi. Đây là tất cả những gì về kích hoạt dữ liệu — trao quyền cho các nhóm khác thực hiện công việc của họ tốt hơn bằng các công cụ mà họ quen thuộc. Nhiều người quản lý tài khoản xem xét nhiều mặt hàng tồn kho bị thiếu hơn, gọi thêm nhiều cửa hàng hơn, nhiều SKU hàng đầu hơn đưa nó vào các cửa hàng rượu, nhiều doanh số bán hàng hơn. Mọi người đều thắng.

…một người quản lý tài khoản nhận thấy rằng một cửa hàng bia và rượu có các mặt hàng rượu trong danh sách các mặt hàng bán chạy nhất của họ. AM sử dụng bối cảnh kinh doanh của họ và bỏ qua các mặt hàng đề xuất mà họ biết rằng cửa hàng không thể mang theo một cách hợp pháp. Logic kinh doanh bổ sung đã được thêm thông qua lớp quyết định của con người.

Lưu ý: Salesforce KHÔNG phải là cơ sở hạ tầng của nhóm dữ liệu. Thông tin chi tiết và trường hợp sử dụng đã rời khỏi miền của nhóm dữ liệu chứ không phải của công ty. Không có gì là khách hàng phải đối mặt. Một sai lầm có hậu quả thấp, nhưng thông tin phản hồi không được đảm bảo. Logic bổ sung đã được thêm vào (thông qua phán đoán của con người).

3. Sử dụng bên ngoài (Marketing Automation)

Việc triển khai Salesforce rất hữu ích nhưng về bản chất vẫn còn khá thủ công. Người quản lý tài khoản và chủ cửa hàng rượu dành quá nhiều thời gian cho điện thoại. Hầu hết các cửa hàng rượu đặt hàng tồn kho mỗi tuần một lần. AM sử dụng sự trợ giúp từ dữ liệu và các hoạt động tiếp thị để hợp lý hóa việc liên lạc qua email tự động theo nhịp hàng tuần.

Một vài cột nữa là cần thiết, sau đó bảng thô được đảo ngược ETL'd thành Hubspot/Iterable/braze. Một cộng tác viên CRM hoàn tất các bước hoàn thiện cho chiến dịch email và chiến dịch email có tiêu đề "Những mặt hàng hàng đầu bạn không mang theo" sẽ được triển khai.

…nhân viên CRM phụ trách email thông báo rằng một số mặt hàng bán chạy nhất (theo số lượng) là một chút rượu. Điều này không phù hợp với tầm nhìn thương hiệu/trường hợp sử dụng mong muốn của khách hàng. Hầu hết các hệ thống email đều cho phép thêm một lớp logic — cộng tác viên CRM sử dụng phán đoán của họ để lọc ra bất kỳ mục nào có thể tích 50ml trở xuống.

Lưu ý: Thông tin chi tiết và trường hợp sử dụng đã rời khỏi miền của nhóm dữ liệu và công ty. Đầu ra của nhóm dữ liệu hiện đang đối mặt với khách hàng. Một sai lầm có hậu quả cao hơn, phản hồi ít có khả năng được gửi chính xác đến đúng bên liên quan. Logic kinh doanh bổ sung đã được thêm vào (thông qua chuyển đổi chặng cuối trong lớp CRM).

4. Sử dụng bên ngoài (Ứng dụng sản xuất)

Nhóm dữ liệu nhận phản hồi từ nhóm AM và CRM — một số cửa hàng rượu khá cũ và họ không kiểm tra email. Các cửa hàng rượu khác là trường học mới và họ không muốn đợi cả tuần để nhận email về những gì đang thịnh hành trên thị trường của họ. Nhóm quyết định lặp lại trong nhóm ứng dụng bán lẻ để đưa “Những mặt hàng hàng đầu bạn không mang theo” vào ứng dụng sản xuất mà tất cả các nhà bán lẻ chạy trên đó. Nhóm dữ liệu di chuyển đầu ra của họ vào một bộ chứa AWS S3, nơi đầu ra được kỹ thuật sản xuất chọn. Giờ đây, nhân viên cửa hàng rượu có thể xem danh sách này hàng ngày mà không cần người quản lý tài khoản hoặc email. White Claw và Whispering Angel lọt vào mọi cửa hàng ở Mỹ.

…một nhà bán lẻ đã gửi đơn khiếu nại tới Nhà bán lẻ CX — họ đã cố tình ngừng cung cấp rượu Vodka Smirnoff Peppermint sau kỳ nghỉ lễ. Nó thực sự có thể là mặt hàng bán chạy nhất của L90, nhưng nó cực kỳ theo mùa và họ không muốn thấy nó trong danh sách được đề xuất của mình. Phản hồi này được gửi tới nhóm kỹ sư sản xuất, nhóm đó thực hiện một tinh chỉnh logic trong lớp ứng dụng để xác định và xóa các mặt hàng theo mùa trong quá khứ.

Lưu ý: Thông tin chi tiết và trường hợp sử dụng đã rời khỏi miền của nhóm dữ liệu và công ty. Đầu ra của nhóm dữ liệu là khách hàng phải đối mặt. Một sai lầm có hậu quả cao hơn, phản hồi ít có khả năng được chuyển đến đúng bên liên quan. Logic bổ sung đã được thêm vào (thông qua logic nghiệp vụ trong lớp ứng dụng sản xuất).

Một giả thuyết cuối cùng: nhóm kỹ thuật phụ trách tiêu thụ nguồn cấp dữ liệu hàng tồn kho (khác với nhóm phụ trách ứng dụng nhà bán lẻ) chuyển sang một lược đồ hàng tồn kho mới. Họ không biết về một bước duy nhất của dự án “Những mặt hàng hàng đầu mà bạn không mang theo”, những phụ thuộc mà nhóm dữ liệu đã âm thầm xây dựng dựa trên công việc của họ hoặc những phụ thuộc mà những người khác đã xây dựng dựa trên công việc của nhóm dữ liệu. Họ xóa bảng ban đầu. NULLs chảy vào Looker, Salesforce, Hubspot và ứng dụng bán lẻ sản xuất. Nhóm dữ liệu đã bị hỏng prod.

Hãy tóm tắt lại những gì đã xảy ra, cả tốt và xấu:

Từ quan điểm của một chuyên gia dữ liệu đã bắt đầu sự nghiệp của họ trước khi “kích hoạt dữ liệu”, mọi thứ vừa xảy ra (ngoại trừ đoạn kết) đều thật khó tin! Những gì bắt đầu như một bảng điều khiển Looker đã nhanh chóng trở thành một ứng dụng sản xuất, với giá trị kinh doanh được chứng minh ở mọi bước. Không cần tài nguyên SWE cho đến phút cuối cùng— khi sản phẩm được đề xuất đã được người dùng xác thực.

Tác động và quỹ đạo nghề nghiệp của một chuyên gia dữ liệu bị giới hạn bởi diện tích bề mặt mà họ có thể ảnh hưởng. Nhà phân tích kinh doanh thông minh của năm 2012 được giới hạn ở Tableau + các bài thuyết trình nội bộ. Chuyên gia dữ liệu ngày nay CÓ THỂ đưa các hàng vào Salesforce, kích hoạt email tiếp thị và xây dựng các sản phẩm dữ liệu để sử dụng trong các dịch vụ và ứng dụng sản xuất. Đây là một tin tuyệt vời!

Mặt xấu: chuyên gia dữ liệu của mười năm trước đã quen với các thông báo “Này, dữ liệu bị lỗi”. Trường hợp xấu nhất là đưa các số liệu sai vào bảng. Ngày nay, nhóm dữ liệu có thể nhận được thông báo Pager Duty rằng họ đã phá vỡ Salesforce, Hubspot và ứng dụng sản xuất, nếu Pager Duty thậm chí còn được thiết lập . Kích hoạt dữ liệu đã nâng cao khả năng mà một nhóm dữ liệu có thể phá vỡ.

Trong trường hợp giả định này, người quản lý cửa hàng và tài khoản sẽ khó chịu trong một hoặc hai ngày cho đến khi lỗi được khắc phục. Tất cả mọi thứ được xem xét - lỗi này là tương đối tốn kém.

Điều đó không có nghĩa là nó không thể tốn kém! Hãy tưởng tượng một kết quả khoa học dữ liệu dự đoán tỷ lệ rời bỏ của khách hàng và mã khuyến mãi $5 được gửi khi xác suất đó vượt qua một ngưỡng nhất định. Bây giờ, hãy tưởng tượng mô hình được đào tạo lại, hoặc hiệu chỉnh lại không đúng cách, hoặc thực sự là bất cứ điều gì. Các đường dẫn kích hoạt dữ liệu tương tự có thể được sử dụng để vô tình gửi hàng triệu đô la mã khuyến mãi.

Ngăn xếp dữ liệu hiện đại giúp việc sản xuất đầu ra dữ liệu cực kỳ dễ dàng — bất kể chúng có nên được sản xuất hay nhóm xây dựng đầu vào biết đầu ra đang được tiêu thụ như thế nào. Các công cụ này không yêu cầu truy vấn ban đầu hoặc quy trình được làm cứng vì chúng được nâng lên thành các trường hợp sử dụng quan trọng hơn. Chúng không yêu cầu sự đồng ý hoặc khả năng hiển thị của những người đã xây dựng đầu ra ban đầu.

Nếu bạn nhớ logic kinh doanh bổ sung:

• Người quản lý tài khoản đã sử dụng phán đoán của họ và bỏ qua việc giới thiệu SKU rượu cho các cửa hàng bia/rượu
• Cộng tác viên CRM đã xóa SKU <= 50ml do cân nhắc thương hiệu
• Nhóm ứng dụng của nhà bán lẻ đã xóa các SKU có tính thời vụ cao do phản hồi của khách hàng

Vậy chúng ta có thể làm gì để khắc phục những vấn đề này?

Hệ thống có xu hướng sản xuất

Những câu chuyện kinh dị, các vấn đề tổng quát và các giải pháp kỹ thuật cho các hệ thống sản xuất đã được viết một cách hùng hồn trên data twitter và substack. Phần lớn, các giải pháp là các phương pháp hay nhất mà SWE đã biết trong nhiều thập kỷ (hoặc, như Zach Kanter đã nói theo một cách khác , kỹ thuật dữ liệu hiện trạng chỉ là kỹ thuật phần mềm không có các phương pháp hay nhất ). Một số phần/nguyên tắc đã gắn bó nhất với tôi đối với các nhóm dữ liệu:

Nhóm dữ liệu không kiểm soát đầu vào của họ (h/t Nick Schrock )

Đầu ra dữ liệu là cơ sở của nhiều quyết định trong các tổ chức, bất kể con người hay thuật toán chịu trách nhiệm. Tuy nhiên, các nhóm dữ liệu không kiểm soát đầu vào của họ theo cách mà các kỹ sư phần mềm làm. Các nhóm dữ liệu phải phòng thủ trong các tính toán của họ bằng cách đầu tư vào QA; cho các vấn đề trong quá khứ cũng như cho các vấn đề chưa xảy ra. Thử nghiệm này nên bao gồm:

• Hiệu lực của các hàng đơn lẻ ( intkhi bạn mong đợi một int, <50 khi bạn mong đợi <50)
• Tính hợp lệ của các hàng tổng hợp (giả định về mức độ chi tiết, bối cảnh kinh doanh xung quanh số lượng hàng, số lượng hàng so với ngày hôm qua, phân phối của các tổng hợp như tổng, trung bình, p90, trung vị)
• Sự tồn tại / ổn định của dữ liệu (bảng lần cuối được cập nhật)

Chi phí của một lỗi trong một hệ thống sản xuất cao hơn theo cấp số nhân so với trong dàn dựng. Tạo các đường ống kiểm tra dữ liệu và các mẫu triển khai + phát triển để phát hiện lỗi và kiểm tra các giả định càng sớm càng tốt.

Đây là những giải pháp có thể được thực hiện bởi các nhóm dữ liệu, những người chọn đúng công cụ (chúng tôi thích Kỳ vọng lớn ) và nỗ lực. Đó là 20% của vấn đề. 80% thách thức còn lại về tổ chức + giao tiếp là nguyên nhân khiến hệ thống bị hỏng. Dưới đây là các giải pháp toàn công ty:

Tạo dữ liệu cấp độ sản xuất

Hoặc, cố tình tạo dữ liệu . Các công ty tin rằng khoa học dữ liệu có sức mạnh cũng nên tin tưởng vào việc cố ý tạo dữ liệu sản xuất để cung cấp năng lượng cho các trường hợp sử dụng máy học và phân tích nâng cao (h/t Yali Sasoon). Điều này đòi hỏi sự hợp tác với các kỹ sư và sự liên kết trong toàn công ty để dữ liệu có thể được tạo ra một cách có chủ ý chứ không phải trích xuất một cách đau đớn.

Tạo và kỷ niệm một lộ trình sản xuất

Các công ty thường ăn mừng những bước lặp lại nhanh chóng trong môi trường phát triển mà không đưa ra hướng dẫn hoặc thời gian để củng cố hoạt động hướng tới cấp độ sản xuất. Kỷ niệm công việc này và tạo ra thời gian và quyền sở hữu đa chức năng rõ ràng cho các hệ thống cứng.

Hệ thống có xu hướng hướng tới liên đoàn mù

Một lần nữa - hãy ăn mừng vấn đề này! Nếu nhiều người tìm thấy các trường hợp sử dụng kinh doanh khác nhau cho kết quả đầu ra của nhóm dữ liệu, thì bạn đang làm đúng. Tuy nhiên, giống như cách mà một số bảng điều khiển đặc biệt có thể biến nó thành một bảng điều khiển cách đây 10 năm, truy vấn đặc biệt đó có thể biến nó thành một ứng dụng sản xuất mà bạn không hề hay biết.

Tận dụng một mặt phẳng điều khiển duy nhất để điều phối theo hướng sự kiện

Fivetran, dbt và Hightouch đều có khả năng lên lịch công việc thông qua lịch trình cron và giao diện người dùng. Điều này cho phép việc điều phối được xây dựng theo những cách không hiển thị thành các phụ thuộc ngầm. Hãy tưởng tượng rằng Hightouch được lên lịch di chuyển exp_fb_click_idshàng ngày vào lúc 8 giờ sáng thông qua giao diện người dùng. Fivetran và dbt không có tầm nhìn về sự phụ thuộc đó, cũng như những người đóng góp vào cơ sở mã ngược dòng của Hightouch.

Thay vào đó, hãy sử dụng công cụ điều phối (Dagster/Prefect/Airflow) làm mặt phẳng điều khiển duy nhất. Hợp nhất các phần phụ thuộc giữa các công cụ và tạo DAG toàn diện chạy dựa trên thành công của bước trước thay vì hy vọng các tác vụ ngược dòng thành công vào một thời điểm nhất định trong ngày. Trả lại .

Tạo ánh xạ một đối một của nhóm dữ liệu xuất sang các trường hợp sử dụng xuôi dòng

Các nhóm dữ liệu nên làm quen với cách dbt đề xuất để cấu trúc các dự án . Thông thường, lớp dàn dựng được tổ chức và đặt tên theo cách làm cho mối quan hệ một đối một với đầu vào nguồn cực kỳ rõ ràng. Sử dụng một mẫu tương tự cho đầu ra. Ở mức độ tương tự, rõ ràng đối tượng Cơ hội và Tài khoản Salesforce đại diện cho một bảng dbt trong giai đoạn, rõ ràng là xuất dữ liệu được sử dụng cho một và chỉ một trường hợp sử dụng.

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
;

Thay vì tóm tắt bệnh viêm lớp, tôi sẽ hướng bạn một lần nữa đến chủ đề và định nghĩa tuyệt vời của Jean-Michel Lemieux. Lời khuyên chung là của anh ấy, với một số dữ liệu cụ thể phù hợp với tôi.

Định nghĩa kỹ thuật cho bệnh viêm lớp là các nhóm đặt mã ở nơi họ cảm thấy thoải mái nhất trong khi tối ưu hóa tốc độ so với đặt mã ở nơi thuộc về nó khi xem xét viễn cảnh dài hạn hơn trên toàn bộ hệ thống phần mềm.

Giảm các lĩnh vực mà logic kinh doanh có thể được đưa vào ở dặm cuối cùng:

Hightouch và Census cho phép chuyển đổi SQL. Fivetran đã từng . Hầu hết người tiêu dùng kích hoạt dữ liệu (Sales/CX CRM, CDP) cho phép lớp logic kinh doanh SQL hoặc thấp/không có mã. Bất cứ khi nào có thể, đừng viết logic kinh doanh trong các công cụ này. Nếu bạn tuân theo ánh xạ một đối một của nhóm dữ liệu xuất sang các trường hợp sử dụng xuôi dòng, Reverse ETL của bạn luôn có thể là:

select * from exp_table_for_single_use_case;

Những thay đổi trong logic kinh doanh nên được áp dụng cho mô hình dbt đó, thay vì ở dặm cuối cùng.

Tạo các chính sách “Thời gian để sống” trên các biến đổi ở dặm cuối cùng:

Nhóm dữ liệu không thể loại bỏ hoàn toàn các biến đổi dặm cuối. Bạn không muốn các bên liên quan của mình cảm thấy như họ bị chặn bởi nhóm dữ liệu. Sẽ luôn có nhu cầu giới thiệu các bản sửa lỗi nóng hoặc lặp lại logic kinh doanh nhanh hơn so với làm mới dbt PR + Snowflake.

Tổng quát hơn, các bên liên quan trong kinh doanh của bạn có bối cảnh mà bạn không có. Bạn muốn xem họ đang thay đổi dữ liệu của bạn như thế nào. Hãy nhớ lại logic SKU, khối lượng, phân loại cửa hàng theo mùa mà kỹ sư phân tích đã bỏ qua. Tạo một thế giới nơi các bên liên quan trong doanh nghiệp của bạn có thể cải thiện công việc của bạn!

Chính sách “Thời gian để sống” là một lực hấp dẫn quay trở lại tập trung hóa. Cho phép chuyển đổi dặm cuối, nhưng xem xét chúng và kéo logic kinh doanh trở lại lớp dbt / khoa học dữ liệu trung tâm theo nhịp phù hợp với nhóm dữ liệu của bạn và các bên liên quan trong kinh doanh

Xây dựng văn hóa tiêu chuẩn hóa + tôn vinh quyền truy cập vào các cơ sở mã chức năng chéo

Mọi người mặc định viết logic nghiệp vụ bằng công cụ mà họ cảm thấy thoải mái nhất. Đối với một cộng tác viên CRM, đó có thể là Hubspot / Iterable / Braze. Cách tốt nhất để các nhóm dữ liệu ngăn chặn logic kinh doanh mở rộng không chỉ là hạn chế các chuyển đổi chặng cuối trong các công cụ khác mà còn mời những người khác tham gia vào công cụ của họ .

Đây có thể là một ️️️ mất. Có nhiều lý do để lo lắng về việc các thành viên nhóm không có dữ liệu viết logic bằng SQL và tạo PR dbt. Điều tôi có thể đảm bảo — logic này sẽ được viết và nếu nhóm dữ liệu giữ cổng, nó sẽ được viết ngoài tầm nhìn của họ. Nếu một nhóm dữ liệu có thể giáo dục và khuyến khích đóng góp cho cơ sở mã của họ, thì họ mời mã được viết ở nơi phù hợp nhất.

Hạ cánh máy bay:

Đây là thời điểm tuyệt vời để trở thành một nhà lãnh đạo dữ liệu. Thập kỷ phát triển hệ sinh thái dữ liệu vừa qua đã biến việc di chuyển và thao tác dữ liệu thành hàng hóa thông qua các công cụ của bên thứ nhất và bên thứ ba. Một chuyên gia phân tích tài năng với ước mơ và thẻ tín dụng có thể hỗ trợ báo cáo nội bộ, công cụ nội bộ, tự động hóa tiếp thị và ứng dụng sản xuất. Đây là một tin tức khách quan không thể tin được đối với các công ty và chuyên gia dữ liệu.

• Ngăn xếp dữ liệu hiện đại cho phép nhóm dữ liệu sản xuất bất kỳ thứ gì, bất kể chúng có phải như vậy hay không và không có sự cho phép hoặc khả năng hiển thị của kỹ thuật sản xuất.
• Ngăn xếp dữ liệu hiện đại cho phép các bên liên quan trong doanh nghiệp thêm logic kinh doanh dặm cuối để cung cấp năng lượng cho quy trình sản xuất, bất kể họ có nên như vậy hay không và không có sự cho phép hoặc khả năng hiển thị của nhóm dữ liệu.

Tại một số điểm, các sản phẩm dữ liệu của bạn sẽ phá vỡ ứng dụng sản xuất. Email tiếp thị sẽ được gửi đi mà lẽ ra không nên gửi. Nhóm CRM sẽ đổ lỗi cho nhóm dữ liệu, nhóm dữ liệu sẽ đổ lỗi cho nhóm kỹ thuật sản xuất. Một trong những bài học quan trọng nhất mà tôi đã học được nhưng vẫn phải vật lộn hàng ngày: Khả năng bước vào một căn phòng căng thẳng/Phóng to và nhắc nhở mọi người rằng tất cả chúng ta cùng một đội là một siêu năng lực. Đó là bản tóm tắt thực sự về cách đưa hệ thống dữ liệu vào sản xuất.

Nếu bạn có thể tạo ra một nền văn hóa nơi:

• Các kỹ sư sản xuất tạo ra dữ liệu cạn kiệt với mục đích và hứng thú về cách dữ liệu sẽ được sử dụng
• Các thành viên nhóm dữ liệu tìm kiếm các trường hợp sử dụng, yêu cầu phản hồi và hỏi các bên liên quan của họ, "Này, bạn thực sự làm gì với dữ liệu tôi gửi cho bạn?"
• SWE có thể cố vấn và nâng cấp các phương pháp và tiêu chuẩn tốt nhất của nhóm dữ liệu để nâng các luồng dữ liệu đặc biệt lên cấp độ sản xuất
• Các thành viên nhóm dữ liệu có thể cố vấn và nâng cấp các bên liên quan trong kinh doanh về cách thêm logic nghiệp vụ, khuôn khổ cho nơi logic thuộc về
• Mọi nhóm đều mời những người khác tham gia vào cơ sở mã của họ và khuyến khích tầm nhìn dài hạn về kiến ​​trúc tổng thể của công ty

Ian Macomber là Trưởng phòng Khoa học Dữ liệu và Kỹ thuật Phân tích tại Ramp, thẻ công ty đầu tiên và duy nhất giúp các công ty chi tiêu ít hơn. Trước đây, ông là Phó Giám đốc Phân tích và Kỹ thuật Dữ liệu tại Drizly.

Có một xu hướng thứ tư là tốt! Hãy tiếp tục theo dõi Xu hướng Tính toán của Hệ thống Dữ liệu , hơi quá nhiều để có thể đưa vào một bài viết.