Tài liệu này là tài liệu đầu tiên trong loạt bài gồm hai phần khám phá chủ đề kỹ thuật dữ liệu và kỹ thuật tính năng cho máy học (ML), tập trung vào các nhiệm vụ học tập có giám sát. Phần đầu tiên này thảo luận về các phương pháp hay nhất để xử lý trước dữ liệu trong quy trình ML trên Google Cloud. Tài liệu tập trung vào việc sử dụng TensorFlow và thư viện TensorFlow Transform ( tf.Transform ) mã nguồn mở để chuẩn bị dữ liệu, huấn luyện mô hình và phục vụ mô hình cho việc dự đoán. Tài liệu này nêu bật những thách thức trong quá trình tiền xử lý dữ liệu cho ML, đồng thời mô tả các tùy chọn và kịch bản để thực hiện chuyển đổi dữ liệu trên Google Cloud một cách hiệu quả.
Tài liệu này giả định rằng bạn đã quen thuộc với BigQuery , Dataflow , Vertex AI và API TensorFlow Keras .
Tài liệu thứ hai, Xử lý trước dữ liệu cho ML với Google Cloud , cung cấp hướng dẫn từng bước về cách triển khai quy trình tf.Transform .
Giới thiệu
ML giúp bạn tự động tìm các mẫu phức tạp và có thể hữu ích trong dữ liệu. Các mẫu này được cô đọng trong mô hình ML, sau đó có thể được sử dụng trên các điểm dữ liệu mới—một quá trình được gọi là đưa ra dự đoán hoặc thực hiện suy luận .
Xây dựng mô hình ML là một quá trình gồm nhiều bước. Mỗi bước trình bày những thách thức về mặt kỹ thuật và khái niệm riêng. Loạt bài gồm hai phần này tập trung vào các nhiệm vụ học tập có giám sát và quá trình lựa chọn, chuyển đổi và tăng cường dữ liệu nguồn để tạo ra các tín hiệu dự đoán mạnh mẽ cho biến mục tiêu. Các hoạt động này kết hợp kiến thức miền với các kỹ thuật khoa học dữ liệu. Các hoạt động là bản chất của kỹ thuật tính năng .
Kích thước của tập dữ liệu huấn luyện cho các mô hình ML trong thế giới thực có thể dễ dàng bằng hoặc lớn hơn một terabyte (TB). Do đó, bạn cần các khung xử lý dữ liệu quy mô lớn để xử lý các bộ dữ liệu này một cách hiệu quả và phân tán. Khi sử dụng mô hình ML để đưa ra dự đoán, bạn phải áp dụng các phép biến đổi tương tự mà bạn đã sử dụng cho dữ liệu huấn luyện trên các điểm dữ liệu mới. Bằng cách áp dụng các phép biến đổi tương tự, bạn trình bày tập dữ liệu trực tiếp cho mô hình ML theo cách mà mô hình mong đợi.
Tài liệu này thảo luận về những thách thức này đối với các mức độ chi tiết khác nhau của hoạt động kỹ thuật tính năng: tập hợp cấp phiên bản, toàn bộ và thời gian. Tài liệu này cũng mô tả các tùy chọn và kịch bản để thực hiện chuyển đổi dữ liệu cho ML trên Google Cloud.
Tài liệu này cũng cung cấp thông tin tổng quan về TensorFlow Transform ( tf.Transform ), một thư viện dành cho TensorFlow cho phép bạn xác định cả chuyển đổi dữ liệu ở cấp phiên bản và chuyển đổi dữ liệu đầy đủ thông qua quy trình tiền xử lý dữ liệu. Các quy trình này được thực thi bằng Apache Beam và chúng tạo ra các tạo phẩm cho phép bạn áp dụng các phép biến đổi tương tự trong quá trình dự đoán cũng như khi mô hình được phân phối.
Dữ liệu tiền xử lý cho ML
Phần này giới thiệu các hoạt động tiền xử lý dữ liệu và các giai đoạn sẵn sàng của dữ liệu. Nó cũng thảo luận về các loại hoạt động tiền xử lý và mức độ chi tiết của chúng.
Kỹ thuật dữ liệu so với kỹ thuật tính năng
Quá trình tiền xử lý dữ liệu cho ML bao gồm cả kỹ thuật dữ liệu và kỹ thuật tính năng. Kỹ thuật dữ liệu là quá trình chuyển đổi dữ liệu thô thành dữ liệu đã chuẩn bị sẵn . Sau đó, kỹ thuật tính năng sẽ điều chỉnh dữ liệu đã chuẩn bị để tạo ra các tính năng mà mô hình ML mong đợi. Những thuật ngữ này có ý nghĩa như sau:
- Dữ liệu thô (hoặc chỉ data )
- Dữ liệu ở dạng nguồn mà không cần chuẩn bị trước cho ML. Trong ngữ cảnh này, dữ liệu có thể ở dạng thô (trong hồ dữ liệu) hoặc ở dạng chuyển đổi (trong kho dữ liệu). Dữ liệu đã chuyển đổi trong kho dữ liệu có thể đã được chuyển đổi từ dạng thô ban đầu để sử dụng cho phân tích. Tuy nhiên, trong ngữ cảnh này, dữ liệu thô có nghĩa là dữ liệu chưa được chuẩn bị cụ thể cho tác vụ ML của bạn. Dữ liệu cũng được coi là dữ liệu thô nếu nó được gửi từ các hệ thống phát trực tuyến mà cuối cùng gọi các mô hình ML để dự đoán.
- Dữ liệu đã chuẩn bị
- Tập dữ liệu ở dạng sẵn sàng cho nhiệm vụ ML của bạn: nguồn dữ liệu đã được phân tích cú pháp, nối và đưa vào dạng bảng. Dữ liệu đã chuẩn bị sẽ được tổng hợp và tóm tắt theo mức độ chi tiết phù hợp—ví dụ: mỗi hàng trong tập dữ liệu đại diện cho một khách hàng duy nhất và mỗi cột thể hiện thông tin tóm tắt về khách hàng đó, chẳng hạn như tổng số tiền đã chi tiêu trong sáu tuần qua. Trong bảng dữ liệu đã chuẩn bị sẵn, các cột không liên quan đã bị loại bỏ và các bản ghi không hợp lệ đã được lọc ra. Đối với các nhiệm vụ học có giám sát, tính năng mục tiêu sẽ xuất hiện.
- Tính năng thiết kế
- Tập dữ liệu có các tính năng đã điều chỉnh mà mô hình mong đợi—nghĩa là các tính năng được tạo bằng cách thực hiện một số thao tác cụ thể ML trên các cột trong tập dữ liệu đã chuẩn bị và tạo các tính năng mới cho mô hình của bạn trong quá trình đào tạo và dự đoán, như được mô tả sau trong các hoạt động tiền xử lý . Ví dụ về các thao tác này bao gồm chia tỷ lệ các cột số thành giá trị từ 0 đến 1, cắt bớt các giá trị và các tính năng phân loại mã hóa một nóng .
Sơ đồ sau, hình 1, hiển thị các bước liên quan đến việc chuẩn bị dữ liệu được xử lý trước:
Trong thực tế, dữ liệu từ cùng một nguồn thường ở các mức độ sẵn sàng khác nhau. Ví dụ: một trường từ một bảng trong kho dữ liệu của bạn có thể được sử dụng trực tiếp làm tính năng được thiết kế. Đồng thời, một trường khác trong cùng một bảng có thể cần phải trải qua quá trình biến đổi trước khi trở thành một tính năng được thiết kế. Tương tự, các hoạt động kỹ thuật dữ liệu và kỹ thuật tính năng có thể được kết hợp trong cùng một bước tiền xử lý dữ liệu.
Hoạt động tiền xử lý
Quá trình tiền xử lý dữ liệu bao gồm một số thao tác. Mỗi thao tác được thiết kế để giúp ML xây dựng các mô hình dự đoán tốt hơn. Chi tiết về các thao tác tiền xử lý này nằm ngoài phạm vi của tài liệu này, nhưng một số thao tác được mô tả ngắn gọn trong phần này.
Đối với dữ liệu có cấu trúc, các hoạt động tiền xử lý dữ liệu bao gồm:
- Làm sạch dữ liệu: xóa hoặc sửa các bản ghi có giá trị bị hỏng hoặc không hợp lệ khỏi dữ liệu thô và xóa các bản ghi bị thiếu một số lượng lớn cột.
- Lựa chọn và phân vùng phiên bản: chọn các điểm dữ liệu từ tập dữ liệu đầu vào để tạo tập huấn luyện, đánh giá (xác thực) và tập kiểm tra . Quá trình này bao gồm các kỹ thuật lấy mẫu ngẫu nhiên lặp lại, lấy mẫu quá mức các lớp thiểu số và phân vùng phân tầng.
- Điều chỉnh tính năng: cải thiện chất lượng của một tính năng cho ML, bao gồm chia tỷ lệ và chuẩn hóa các giá trị số, đưa ra các giá trị bị thiếu, cắt bớt các giá trị ngoại lệ và điều chỉnh các giá trị có phân bố sai lệch.
- Chuyển đổi tính năng: chuyển đổi tính năng số thành tính năng phân loại (thông qua nhóm ) và chuyển đổi tính năng phân loại thành biểu diễn số (thông qua mã hóa một lần, học với số lượng , nhúng tính năng thưa thớt, v.v.). Một số mô hình chỉ hoạt động với các tính năng số hoặc phân loại, trong khi những mô hình khác có thể xử lý các tính năng loại hỗn hợp. Ngay cả khi các mô hình xử lý cả hai loại, chúng vẫn có thể hưởng lợi từ các cách biểu diễn khác nhau (số và phân loại) của cùng một tính năng.
- Trích xuất tính năng: giảm số lượng tính năng bằng cách tạo các biểu diễn dữ liệu có kích thước thấp hơn, mạnh mẽ hơn bằng cách sử dụng các kỹ thuật như PCA , trích xuất nhúng và băm .
- Lựa chọn tính năng: chọn một tập hợp con các tính năng đầu vào để huấn luyện mô hình và bỏ qua những tính năng không liên quan hoặc dư thừa, sử dụng các phương pháp lọc hoặc trình bao bọc . Việc lựa chọn tính năng cũng có thể chỉ đơn giản là loại bỏ các tính năng nếu các tính năng đó thiếu một số lượng lớn giá trị.
- Xây dựng tính năng: tạo các tính năng mới bằng cách sử dụng các kỹ thuật điển hình, chẳng hạn như mở rộng đa thức (bằng cách sử dụng các hàm toán học đơn biến) hoặc chéo tính năng (để nắm bắt các tương tác tính năng). Các tính năng cũng có thể được xây dựng bằng cách sử dụng logic nghiệp vụ từ miền của trường hợp sử dụng ML.
Khi bạn làm việc với dữ liệu phi cấu trúc (ví dụ: hình ảnh, âm thanh hoặc tài liệu văn bản), học sâu sẽ thay thế kỹ thuật tính năng dựa trên kiến thức miền bằng cách đưa nó vào kiến trúc mô hình. Lớp tích chập là một bộ tiền xử lý tính năng tự động. Việc xây dựng kiến trúc mô hình phù hợp đòi hỏi một số kiến thức thực nghiệm về dữ liệu. Ngoài ra, cần có một số lượng tiền xử lý, chẳng hạn như sau:
- Đối với tài liệu văn bản: từ gốc và từ vựng , tính toán TF-IDF và trích xuất n-gram , tra cứu nhúng.
- Đối với hình ảnh: cắt, thay đổi kích thước, cắt xén, làm mờ Gaussian và bộ lọc canary.
- Đối với tất cả các loại dữ liệu (bao gồm văn bản và hình ảnh): học chuyển , xử lý tất cả các lớp trừ lớp cuối cùng của mô hình được đào tạo đầy đủ như một bước kỹ thuật tính năng.
Độ chi tiết tiền xử lý
Phần này thảo luận về mức độ chi tiết của các loại chuyển đổi dữ liệu. Nó cho thấy lý do tại sao quan điểm này lại quan trọng khi chuẩn bị các điểm dữ liệu mới cho dự đoán bằng cách sử dụng các phép biến đổi được áp dụng trên dữ liệu huấn luyện.
Các hoạt động tiền xử lý và chuyển đổi có thể được phân loại như sau, dựa trên mức độ chi tiết của hoạt động:
Các chuyển đổi cấp độ cá thể trong quá trình đào tạo và dự đoán . Đây là những phép biến đổi đơn giản, trong đó chỉ cần các giá trị từ cùng một thể hiện cho phép chuyển đổi. Ví dụ: các phép biến đổi cấp phiên bản có thể bao gồm việc cắt bớt giá trị của một đối tượng đến một ngưỡng nào đó, mở rộng đa thức một đối tượng khác, nhân hai đối tượng hoặc so sánh hai đối tượng để tạo cờ Boolean.
Những phép biến đổi này phải được áp dụng giống hệt nhau trong quá trình huấn luyện và dự đoán, bởi vì mô hình sẽ được huấn luyện dựa trên các tính năng được biến đổi chứ không phải trên các giá trị đầu vào thô. Nếu dữ liệu không được chuyển đổi giống hệt nhau thì mô hình hoạt động kém vì nó được trình bày với dữ liệu có sự phân bổ các giá trị mà nó không được đào tạo. Để biết thêm thông tin, hãy xem phần thảo luận về độ lệch phục vụ đào tạo trong phần Thử thách tiền xử lý .
Các phép biến đổi hoàn toàn trong quá trình đào tạo, nhưng các phép biến đổi cấp độ phiên bản trong quá trình dự đoán . Trong trường hợp này, các phép biến đổi có trạng thái vì chúng sử dụng một số thống kê được tính toán trước để thực hiện phép biến đổi. Trong quá trình đào tạo, bạn phân tích toàn bộ dữ liệu đào tạo để tính toán các số lượng như tối thiểu, tối đa, trung bình và phương sai nhằm chuyển đổi dữ liệu đào tạo, dữ liệu đánh giá và dữ liệu mới tại thời điểm dự đoán.
Ví dụ: để chuẩn hóa một đặc điểm số cho việc huấn luyện, bạn tính giá trị trung bình (μ) và độ lệch chuẩn (σ) của nó trên toàn bộ dữ liệu huấn luyện. Tính toán này được gọi là thao tác full-pass (hoặc analyze ). Khi bạn phân phối mô hình để dự đoán, giá trị của điểm dữ liệu mới sẽ được chuẩn hóa để tránh độ lệch phân phối đào tạo. Do đó, các giá trị μ và σ được tính toán trong quá trình đào tạo được sử dụng để điều chỉnh giá trị tính năng, đây là thao tác cấp phiên bản đơn giản sau:
$$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$Các phép biến đổi toàn phần bao gồm:
- Các tính năng số chia tỷ lệ MinMax bằng cách sử dụng tính toán tối thiểu và tối đa từ tập dữ liệu huấn luyện.
- Các tính năng số tỷ lệ tiêu chuẩn (chuẩn hóa điểm z) sử dụng μ và σ được tính toán trên tập dữ liệu huấn luyện.
- Bucketizing các tính năng số bằng cách sử dụng lượng tử.
- Gán các giá trị bị thiếu bằng cách sử dụng trung vị (tính năng số) hoặc chế độ (tính năng phân loại).
- Chuyển đổi chuỗi (giá trị danh nghĩa) thành số nguyên (chỉ mục) bằng cách trích xuất tất cả các giá trị riêng biệt (từ vựng) của tính năng phân loại đầu vào.
- Đếm sự xuất hiện của một thuật ngữ (giá trị đặc trưng) trong tất cả các tài liệu (thể hiện) để tính toán cho TF-IDF.
- Tính toán PCA của các tính năng đầu vào để chiếu dữ liệu vào không gian có chiều thấp hơn (với các tính năng phụ thuộc tuyến tính).
Bạn chỉ nên sử dụng dữ liệu huấn luyện để tính toán các số liệu thống kê như μ, σ, min và max . Nếu bạn thêm dữ liệu kiểm tra và đánh giá cho các hoạt động này, bạn đang rò rỉ thông tin từ dữ liệu đánh giá và kiểm tra để huấn luyện mô hình. Làm như vậy sẽ ảnh hưởng đến độ tin cậy của kết quả kiểm tra, đánh giá. Để đảm bảo rằng bạn áp dụng phép chuyển đổi nhất quán cho tất cả các tập dữ liệu, bạn sử dụng cùng số liệu thống kê được tính toán từ dữ liệu huấn luyện để chuyển đổi dữ liệu kiểm tra và đánh giá.
Tổng hợp lịch sử trong quá trình đào tạo và dự đoán . Điều này liên quan đến việc tạo các tập hợp kinh doanh, dẫn xuất và gắn cờ làm tín hiệu đầu vào cho nhiệm vụ dự đoán—ví dụ: tạo số liệu về lần truy cập gần đây, tần suất và tiền tệ (RFM) cho khách hàng để xây dựng mô hình xu hướng. Các loại tính năng này có thể được tính toán trước và lưu trữ trong kho tính năng để sử dụng trong quá trình đào tạo mô hình, chấm điểm hàng loạt và cung cấp dự đoán trực tuyến. Bạn cũng có thể thực hiện kỹ thuật tính năng bổ sung (ví dụ: chuyển đổi và điều chỉnh) cho các tập hợp này trước khi đào tạo và dự đoán.
Tổng hợp lịch sử trong quá trình đào tạo, nhưng tổng hợp thời gian thực trong quá trình dự đoán . Cách tiếp cận này liên quan đến việc tạo ra một tính năng bằng cách tóm tắt các giá trị thời gian thực theo thời gian. Trong cách tiếp cận này, các trường hợp được tổng hợp được xác định thông qua các mệnh đề cửa sổ thời gian. Ví dụ: bạn có thể sử dụng phương pháp này nếu bạn muốn đào tạo một mô hình ước tính thời gian chuyến đi taxi dựa trên số liệu giao thông cho tuyến đường trong 5 phút qua, trong 10 phút qua, trong 30 phút qua và các thời điểm khác. khoảng thời gian. Bạn cũng có thể sử dụng phương pháp này để dự đoán lỗi của một bộ phận động cơ dựa trên giá trị trung bình chuyển động của nhiệt độ và độ rung được tính toán trong 3 phút qua. Mặc dù những tập hợp này có thể được chuẩn bị ngoại tuyến để đào tạo nhưng chúng được tính toán theo thời gian thực từ luồng dữ liệu trong quá trình phân phối.
Chính xác hơn, khi bạn chuẩn bị dữ liệu huấn luyện, nếu giá trị tổng hợp không có trong dữ liệu thô thì giá trị đó sẽ được tạo trong giai đoạn kỹ thuật dữ liệu. Dữ liệu thô thường được lưu trữ trong cơ sở dữ liệu có định dạng
(entity, timestamp, value). Trong các ví dụ trước,entitylà mã định danh đoạn tuyến đường cho các tuyến taxi và mã định danh bộ phận động cơ cho lỗi động cơ. Bạn có thể sử dụng các thao tác cửa sổ để tính toán(entity, time_index, aggregated_value_over_time_window)và sử dụng các tính năng tổng hợp làm đầu vào cho quá trình đào tạo mô hình của mình.Khi mô hình dự đoán theo thời gian thực (trực tuyến) được cung cấp, mô hình sẽ mong đợi các tính năng bắt nguồn từ các giá trị tổng hợp làm đầu vào. Do đó, bạn có thể sử dụng công nghệ xử lý luồng như Apache Beam để tính toán tổng hợp từ các điểm dữ liệu thời gian thực được truyền vào hệ thống của bạn. Công nghệ xử lý luồng tổng hợp dữ liệu thời gian thực dựa trên các khoảng thời gian khi có điểm dữ liệu mới. Bạn cũng có thể thực hiện kỹ thuật tính năng bổ sung (ví dụ: chuyển đổi và điều chỉnh) cho các tập hợp này trước khi đào tạo và dự đoán.
Đường dẫn ML trên Google Cloud
Phần này thảo luận về các thành phần cốt lõi của quy trình từ đầu đến cuối điển hình để đào tạo và phục vụ các mô hình TensorFlow ML trên Google Cloud bằng cách sử dụng các dịch vụ được quản lý. Nó cũng thảo luận về nơi bạn có thể triển khai các danh mục khác nhau của hoạt động tiền xử lý dữ liệu và những thách thức chung mà bạn có thể gặp phải khi triển khai các chuyển đổi đó. Phần Cách thức hoạt động của tf.Transform cho thấy cách thư viện TensorFlow Transform giúp giải quyết những thách thức này.
Kiến trúc cấp cao
Sơ đồ sau đây, hình 2, cho thấy kiến trúc cấp cao của quy trình ML điển hình để đào tạo và phục vụ các mô hình TensorFlow. Các nhãn A, B và C trong sơ đồ đề cập đến các vị trí khác nhau trong quy trình nơi có thể diễn ra quá trình xử lý trước dữ liệu. Chi tiết về các bước này được cung cấp trong phần sau.
Đường ống bao gồm các bước sau:
- Sau khi nhập dữ liệu thô, dữ liệu dạng bảng sẽ được lưu trữ trong BigQuery và các dữ liệu khác như hình ảnh, âm thanh và video sẽ được lưu trữ trong Cloud Storage. Phần thứ hai của loạt bài này sử dụng dữ liệu dạng bảng được lưu trữ trong BigQuery làm ví dụ.
- Kỹ thuật dữ liệu (chuẩn bị) và kỹ thuật tính năng được thực hiện trên quy mô lớn bằng Dataflow. Quá trình thực thi này tạo ra các tập huấn luyện, đánh giá và kiểm tra sẵn sàng ML được lưu trữ trong Cloud Storage. Lý tưởng nhất là các bộ dữ liệu này được lưu trữ dưới dạng tệp TFRecord , đây là định dạng được tối ưu hóa cho các tính toán TensorFlow.
- Gói huấn luyện mô hình TensorFlow được gửi tới Vertex AI Training, gói này sử dụng dữ liệu được xử lý trước từ các bước trước để huấn luyện mô hình. Đầu ra của bước này là TensorFlow SavingModel đã được huấn luyện và xuất sang Cloud Storage.
- Mô hình TensorFlow đã đào tạo được triển khai cho Vertex AI Prediction dưới dạng dịch vụ có API REST để có thể sử dụng cho các dự đoán trực tuyến. Mô hình tương tự cũng có thể được sử dụng cho công việc dự đoán hàng loạt.
- Sau khi mô hình được triển khai dưới dạng API REST, ứng dụng khách và hệ thống nội bộ có thể gọi API bằng cách gửi yêu cầu kèm theo một số điểm dữ liệu và nhận phản hồi từ mô hình kèm theo dự đoán.
- Để điều phối và tự động hóa quy trình này, bạn có thể sử dụng Quy trình AI của Vertex làm công cụ lập lịch để thực hiện các bước chuẩn bị dữ liệu, đào tạo mô hình và triển khai mô hình.
Bạn cũng có thể sử dụng Vertex AI Feature Store để lưu trữ các tính năng đầu vào nhằm đưa ra dự đoán. Ví dụ: bạn có thể định kỳ tạo các tính năng được thiết kế từ dữ liệu thô mới nhất và lưu trữ chúng trong Vertex AI Feature Store. Ứng dụng khách tìm nạp các tính năng đầu vào cần thiết từ Vertex AI Feature Store và gửi chúng đến mô hình để nhận dự đoán.
Thực hiện tiền xử lý ở đâu
Trong hình 2, các nhãn A, B và C cho thấy các hoạt động tiền xử lý dữ liệu có thể diễn ra trong BigQuery, Dataflow hoặc TensorFlow. Các phần sau đây mô tả cách hoạt động của từng tùy chọn này.
Tùy chọn A: BigQuery
Thông thường, logic được triển khai trong BigQuery cho các hoạt động sau:
- Lấy mẫu: chọn ngẫu nhiên một tập hợp con từ dữ liệu.
- Lọc: loại bỏ các trường hợp không liên quan hoặc không hợp lệ.
- Phân vùng: phân chia dữ liệu để tạo ra các tập huấn luyện, đánh giá và kiểm tra.
Bạn có thể sử dụng tập lệnh BigQuery SQL làm truy vấn nguồn cho quy trình tiền xử lý Dataflow, đây là bước xử lý dữ liệu trong hình 2. Ví dụ: nếu một hệ thống được sử dụng ở Canada và kho dữ liệu có các giao dịch từ khắp nơi trên thế giới, hãy lọc theo việc lấy dữ liệu đào tạo chỉ dành cho Canada được thực hiện tốt nhất trong BigQuery. Kỹ thuật tính năng trong BigQuery rất đơn giản và có thể mở rộng, đồng thời hỗ trợ triển khai các chuyển đổi tính năng tổng hợp lịch sử và cấp phiên bản.
Tuy nhiên, chúng tôi khuyên bạn chỉ nên sử dụng BigQuery cho kỹ thuật tính năng nếu bạn sử dụng mô hình của mình để dự đoán hàng loạt (chấm điểm) hoặc nếu các tính năng được tính toán trước trong BigQuery nhưng được lưu trữ trong Vertex AI Feature Store để sử dụng trong quá trình dự đoán trực tuyến. Nếu bạn dự định triển khai mô hình cho các dự đoán trực tuyến và nếu bạn không có tính năng được thiết kế trong cửa hàng tính năng trực tuyến thì bạn phải sao chép các hoạt động tiền xử lý SQL để chuyển đổi các điểm dữ liệu thô mà các hệ thống khác tạo ra. Nói cách khác, bạn cần triển khai logic hai lần: một lần trong SQL để xử lý trước dữ liệu đào tạo trong BigQuery và lần thứ hai trong logic của ứng dụng sử dụng mô hình để xử lý trước các điểm dữ liệu trực tuyến để dự đoán.
Ví dụ: nếu ứng dụng khách của bạn được viết bằng Java, bạn cần triển khai lại logic trong Java. Điều này có thể gây ra lỗi do sự khác biệt trong quá trình triển khai, như được mô tả trong phần sai lệch phục vụ đào tạo của các thách thức Tiền xử lý ở phần sau của tài liệu này. Việc duy trì hai cách triển khai khác nhau cũng tốn thêm chi phí. Bất cứ khi nào bạn thay đổi logic trong SQL để xử lý trước dữ liệu huấn luyện, bạn cần thay đổi cách triển khai Java cho phù hợp để xử lý trước dữ liệu tại thời điểm cung cấp.
Nếu bạn chỉ sử dụng mô hình của mình để dự đoán hàng loạt (ví dụ: sử dụng dự đoán hàng loạt Vertex AI) và nếu dữ liệu để tính điểm của bạn có nguồn gốc từ BigQuery, thì bạn có thể triển khai các hoạt động tiền xử lý này như một phần của tập lệnh BigQuery SQL. Trong trường hợp đó, bạn có thể sử dụng cùng một tập lệnh SQL tiền xử lý để chuẩn bị cả dữ liệu huấn luyện và dữ liệu chấm điểm.
Các phép biến đổi trạng thái đầy đủ không phù hợp để triển khai trong BigQuery. Nếu sử dụng BigQuery cho các phép biến đổi toàn phần, bạn cần có các bảng phụ trợ để lưu trữ số lượng cần thiết cho các phép biến đổi trạng thái, chẳng hạn như giá trị trung bình và phương sai để chia tỷ lệ cho các đặc tính số. Hơn nữa, việc triển khai các phép biến đổi toàn phần bằng cách sử dụng SQL trên BigQuery sẽ làm tăng độ phức tạp trong các tập lệnh SQL và tạo ra sự phụ thuộc phức tạp giữa quá trình đào tạo và tập lệnh SQL tính điểm.
Tùy chọn B: Luồng dữ liệu
Như được hiển thị trong hình 2, bạn có thể triển khai các hoạt động tiền xử lý tốn kém về mặt tính toán trong Apache Beam và chạy chúng trên quy mô lớn bằng Dataflow. Dataflow là dịch vụ tự động tính toán quy mô được quản lý hoàn toàn để xử lý dữ liệu theo luồng và hàng loạt. Khi sử dụng Dataflow, bạn cũng có thể sử dụng các thư viện chuyên dụng bên ngoài để xử lý dữ liệu, không giống như BigQuery.
Luồng dữ liệu có thể thực hiện các chuyển đổi cấp phiên bản cũng như các chuyển đổi tính năng tổng hợp lịch sử và thời gian thực. Đặc biệt, nếu mô hình ML của bạn mong đợi một tính năng đầu vào như total_number_of_clicks_last_90sec , thì các hàm cửa sổ Apache Beam có thể tính toán các tính năng này dựa trên việc tổng hợp các giá trị của cửa sổ thời gian của dữ liệu sự kiện (phát trực tuyến) thời gian thực (ví dụ: sự kiện nhấp chuột). Trong cuộc thảo luận trước đó về mức độ chi tiết của các phép biến đổi , điều này được gọi là "Tập hợp lịch sử trong quá trình đào tạo, nhưng tập hợp thời gian thực trong quá trình dự đoán".
Sơ đồ sau, hình 3, cho thấy vai trò của Dataflow trong việc xử lý dữ liệu luồng để dự đoán gần thời gian thực.
Như được hiển thị trong hình 3, trong quá trình xử lý, các sự kiện được gọi là điểm dữ liệu sẽ được nhập vào Pub/Sub . Luồng dữ liệu sử dụng các điểm dữ liệu này, tính toán các tính năng dựa trên tổng hợp theo thời gian và sau đó gọi API mô hình ML đã triển khai để đưa ra dự đoán. Sau đó, các dự đoán sẽ được gửi đến hàng đợi Pub/Sub gửi đi. Từ Pub/Sub, các dự đoán có thể được sử dụng bởi các hệ thống hạ nguồn như giám sát hoặc kiểm soát hoặc chúng có thể bị đẩy lùi (ví dụ: dưới dạng thông báo) tới ứng dụng khách yêu cầu ban đầu. Các dự đoán cũng có thể được lưu trữ trong kho dữ liệu có độ trễ thấp như Cloud Bigtable để tìm nạp theo thời gian thực. Cloud Bigtable cũng có thể được sử dụng để tích lũy và lưu trữ các tập hợp thời gian thực này để có thể tra cứu khi cần để dự đoán.
Việc triển khai Apache Beam tương tự có thể được sử dụng để xử lý hàng loạt dữ liệu đào tạo đến từ kho dữ liệu ngoại tuyến như BigQuery và xử lý luồng dữ liệu thời gian thực để phân phát các dự đoán trực tuyến.
Trong các kiến trúc điển hình khác, chẳng hạn như kiến trúc được hiển thị trong Hình 2, ứng dụng khách gọi trực tiếp API mô hình đã triển khai để dự đoán trực tuyến. Trong trường hợp đó, nếu các hoạt động tiền xử lý được triển khai trong Dataflow để chuẩn bị dữ liệu huấn luyện thì các hoạt động đó sẽ không được áp dụng cho dữ liệu dự đoán đi thẳng vào mô hình. Do đó, các phép biến đổi như thế này nên được tích hợp vào mô hình trong quá trình phục vụ các dự đoán trực tuyến.
Luồng dữ liệu có thể được sử dụng để thực hiện chuyển đổi toàn phần bằng cách tính toán số liệu thống kê cần thiết trên quy mô lớn. Tuy nhiên, những số liệu thống kê này cần được lưu trữ ở đâu đó để sử dụng trong quá trình dự đoán nhằm chuyển đổi các điểm dữ liệu dự đoán. Bằng cách sử dụng thư viện TensorFlow Transform ( tf.Transform ), bạn có thể nhúng trực tiếp các số liệu thống kê này vào mô hình thay vì lưu trữ chúng ở nơi khác. Cách tiếp cận này sẽ được giải thích sau trong phần Cách thức hoạt động của tf.Transform .
Tùy chọn C: TensorFlow
Như được hiển thị trong Hình 2, bạn có thể triển khai các hoạt động tiền xử lý và chuyển đổi dữ liệu trong chính mô hình TensorFlow. Như được hiển thị trong hình, quá trình tiền xử lý mà bạn triển khai để huấn luyện mô hình TensorFlow sẽ trở thành một phần không thể thiếu của mô hình khi mô hình được xuất và triển khai để dự đoán. Các chuyển đổi trong mô hình TensorFlow có thể được thực hiện theo một trong các cách sau:
- Triển khai tất cả logic chuyển đổi cấp phiên bản trong hàm
input_fnvà trong hàmserving_fn. Hàminput_fnchuẩn bị một tập dữ liệu bằng APItf.data.Datasetđể đào tạo mô hình. Hàmserving_fnnhận và chuẩn bị dữ liệu cho dự đoán. - Đặt mã chuyển đổi trực tiếp vào mô hình TensorFlow của bạn bằng cách sử dụng các lớp tiền xử lý Keras hoặc tạo các lớp tùy chỉnh .
Mã logic chuyển đổi trong hàm serving_fn xác định giao diện cung cấp của SavingModel của bạn để dự đoán trực tuyến. Nếu bạn triển khai các phép biến đổi tương tự đã được sử dụng để chuẩn bị dữ liệu huấn luyện trong mã logic chuyển đổi của hàm serving_fn thì điều đó sẽ đảm bảo rằng các phép biến đổi tương tự được áp dụng cho các điểm dữ liệu dự đoán mới khi chúng được phân phối.
Tuy nhiên, do mô hình TensorFlow xử lý từng điểm dữ liệu một cách độc lập hoặc theo một đợt nhỏ nên bạn không thể tính toán tổng hợp từ tất cả các điểm dữ liệu. Do đó, các phép biến đổi toàn phần không thể được triển khai trong mô hình TensorFlow của bạn.
Những thách thức tiền xử lý
Sau đây là những thách thức chính của việc triển khai tiền xử lý dữ liệu:
Đào tạo-phục vụ nghiêng . Độ lệch đào tạo-phục vụ đề cập đến sự khác biệt giữa hiệu quả (hiệu suất dự đoán) trong quá trình đào tạo và trong quá trình phục vụ. Sự sai lệch này có thể do sự khác biệt giữa cách bạn xử lý dữ liệu trong quá trình đào tạo và quy trình phân phối. Ví dụ: nếu mô hình của bạn được huấn luyện về tính năng được biến đổi theo logarit nhưng lại hiển thị tính năng thô trong quá trình phân phối thì kết quả dự đoán có thể không chính xác.
Nếu các phép biến đổi trở thành một phần của chính mô hình thì việc xử lý các phép biến đổi cấp phiên bản có thể đơn giản, như được mô tả trước đó trong Tùy chọn C: TensorFlow . Trong trường hợp đó, giao diện phục vụ mô hình (hàm
serving_fn) mong đợi dữ liệu thô, trong khi mô hình sẽ chuyển đổi nội bộ dữ liệu này trước khi tính toán đầu ra. Các phép biến đổi giống như các phép biến đổi được áp dụng trên các điểm dữ liệu dự đoán và huấn luyện thô.Chuyển đổi đầy đủ . Bạn không thể triển khai các phép biến đổi toàn phần chẳng hạn như các phép biến đổi tỷ lệ và chuẩn hóa trong mô hình TensorFlow của mình. Trong các phép biến đổi toàn phần, một số thống kê (ví dụ: giá trị
maxvàminđể chia tỷ lệ các đối tượng số) phải được tính toán trước trên dữ liệu huấn luyện, như được mô tả trong Tùy chọn B: Luồng dữ liệu . Sau đó, các giá trị này phải được lưu trữ ở đâu đó để sử dụng trong quá trình phân phối mô hình nhằm dự đoán nhằm chuyển đổi các điểm dữ liệu thô mới dưới dạng các phép biến đổi cấp phiên bản, giúp tránh sai lệch phân phối đào tạo. Bạn có thể sử dụng thư viện TensorFlow Transform (tf.Transform) để nhúng trực tiếp số liệu thống kê vào mô hình TensorFlow của mình. Cách tiếp cận này sẽ được giải thích sau trong phần Cách thức hoạt động của tf.Transform .Chuẩn bị trước dữ liệu để đạt hiệu quả đào tạo tốt hơn . Việc triển khai các chuyển đổi cấp phiên bản như một phần của mô hình có thể làm giảm hiệu quả của quá trình đào tạo. Sự xuống cấp này xảy ra do các phép biến đổi giống nhau được áp dụng lặp đi lặp lại cho cùng một dữ liệu huấn luyện trên mỗi kỷ nguyên. Hãy tưởng tượng rằng bạn có dữ liệu đào tạo thô với 1.000 tính năng và bạn áp dụng kết hợp các phép biến đổi cấp phiên bản để tạo ra 10.000 tính năng. Nếu bạn triển khai các phép biến đổi này như một phần của mô hình của mình và sau đó nếu bạn cung cấp cho mô hình dữ liệu huấn luyện thô thì 10.000 thao tác này sẽ được áp dụng N lần trên mỗi phiên bản, trong đó N là số kỷ nguyên. Ngoài ra, nếu bạn đang sử dụng bộ tăng tốc (GPU hoặc TPU), chúng sẽ không hoạt động trong khi CPU thực hiện những chuyển đổi đó, đây không phải là cách sử dụng hiệu quả các bộ tăng tốc đắt tiền của bạn.
Lý tưởng nhất là dữ liệu huấn luyện được chuyển đổi trước khi huấn luyện, sử dụng kỹ thuật được mô tả trong Tùy chọn B: Luồng dữ liệu , trong đó 10.000 thao tác chuyển đổi chỉ được áp dụng một lần trên mỗi phiên bản huấn luyện. Dữ liệu đào tạo được chuyển đổi sau đó được trình bày cho mô hình. Không có phép biến đổi nào nữa được áp dụng và máy gia tốc luôn bận rộn. Ngoài ra, việc sử dụng Dataflow giúp bạn xử lý trước lượng lớn dữ liệu trên quy mô lớn bằng cách sử dụng dịch vụ được quản lý hoàn toàn.
Việc chuẩn bị trước dữ liệu đào tạo có thể cải thiện hiệu quả đào tạo. Tuy nhiên, việc triển khai logic chuyển đổi bên ngoài mô hình (các phương pháp được mô tả trong Tùy chọn A: BigQuery hoặc Tùy chọn B: Dataflow ) không giải quyết được vấn đề sai lệch phục vụ đào tạo. Trừ khi bạn lưu trữ tính năng được thiết kế trong kho tính năng để sử dụng cho cả quá trình đào tạo và dự đoán, logic chuyển đổi phải được triển khai ở đâu đó để áp dụng cho các điểm dữ liệu mới sắp được dự đoán, vì giao diện mô hình mong đợi dữ liệu được chuyển đổi. Thư viện TensorFlow Transform (
tf.Transform) có thể giúp bạn giải quyết vấn đề này, như được mô tả trong phần sau.
Cách hoạt động của tf.Transform
Thư viện tf.Transform rất hữu ích cho các phép biến đổi yêu cầu phải vượt qua đầy đủ. Đầu ra của thư viện tf.Transform được xuất dưới dạng biểu đồ TensorFlow biểu thị logic chuyển đổi cấp phiên bản và số liệu thống kê được tính toán từ các phép biến đổi toàn phần, được sử dụng cho mục đích đào tạo và phục vụ. Việc sử dụng cùng một biểu đồ cho cả quá trình huấn luyện và phân phát có thể tránh được tình trạng sai lệch vì các phép biến đổi giống nhau được áp dụng trong cả hai giai đoạn. Ngoài ra, thư viện tf.Transform có thể chạy trên quy mô lớn trong quy trình xử lý hàng loạt trên Dataflow để chuẩn bị trước dữ liệu đào tạo và cải thiện hiệu quả đào tạo.
Sơ đồ sau, hình 4, cho thấy cách thư viện tf.Transform xử lý trước và chuyển đổi dữ liệu để huấn luyện và dự đoán. Quá trình này được mô tả trong các phần sau.
tf.Transform để xử lý trước và chuyển đổi dữ liệu. Chuyển đổi dữ liệu đào tạo và đánh giá
Bạn xử lý trước dữ liệu huấn luyện thô bằng cách sử dụng phép chuyển đổi được triển khai trong API tf.Transform Apache Beam và chạy nó trên quy mô lớn trên Dataflow. Quá trình tiền xử lý diễn ra theo các giai đoạn sau:
- Giai đoạn phân tích: Trong giai đoạn phân tích, các số liệu thống kê cần thiết (như phương tiện, phương sai và lượng tử) cho các phép biến đổi trạng thái được tính toán trên dữ liệu huấn luyện bằng các thao tác vượt qua đầy đủ. Giai đoạn này tạo ra một tập hợp các tạo phẩm chuyển đổi, bao gồm biểu đồ
transform_fn. Biểu đồtransform_fnlà biểu đồ TensorFlow có logic chuyển đổi dưới dạng các phép toán cấp phiên bản. Nó bao gồm các số liệu thống kê được tính toán trong giai đoạn phân tích dưới dạng hằng số. - Giai đoạn biến đổi: Trong giai đoạn biến đổi, biểu đồ
transform_fnđược áp dụng cho dữ liệu huấn luyện thô, trong đó số liệu thống kê được tính toán được sử dụng để xử lý các bản ghi dữ liệu (ví dụ: để chia tỷ lệ các cột số) theo kiểu cấp phiên bản.
Cách tiếp cận hai giai đoạn như thế này giải quyết thách thức tiền xử lý khi thực hiện các phép biến đổi toàn phần.
Khi dữ liệu đánh giá được xử lý trước, chỉ các thao tác cấp phiên bản mới được áp dụng, sử dụng logic trong biểu đồ transform_fn và số liệu thống kê được tính toán từ giai đoạn phân tích trong dữ liệu huấn luyện. Nói cách khác, bạn không phân tích dữ liệu đánh giá theo kiểu toàn diện để tính toán số liệu thống kê mới, chẳng hạn như μ và σ, để chuẩn hóa các đặc điểm số trong dữ liệu đánh giá. Thay vào đó, bạn sử dụng số liệu thống kê được tính toán từ dữ liệu huấn luyện để chuyển đổi dữ liệu đánh giá theo kiểu cấp độ phiên bản.
Dữ liệu đánh giá và đào tạo đã chuyển đổi được chuẩn bị trên quy mô lớn bằng Dataflow trước khi chúng được sử dụng để huấn luyện mô hình. Quá trình chuẩn bị dữ liệu hàng loạt này giải quyết thách thức tiền xử lý của việc chuẩn bị dữ liệu lên phía trước để cải thiện hiệu quả đào tạo. Như được hiển thị trong Hình 4, giao diện nội bộ mô hình mong đợi các tính năng biến đổi.
Đính kèm các biến đổi vào mô hình xuất
Như đã lưu ý, biểu đồ transform_fn được tạo bởi đường ống tf.Transform được lưu trữ dưới dạng biểu đồ TensorFlow được xuất. Biểu đồ được xuất bao gồm logic chuyển đổi dưới dạng các hoạt động ở cấp độ thể hiện và tất cả các số liệu thống kê được tính toán trong các phép biến đổi toàn bộ dưới dạng hằng số đồ thị. Khi mô hình được đào tạo được xuất để phục vụ, biểu đồ transform_fn được gắn vào SavingModel như là một phần của hàm serving_fn của nó.
Mặc dù nó phục vụ mô hình để dự đoán, giao diện phục vụ mô hình mong đợi các điểm dữ liệu ở định dạng thô (nghĩa là trước bất kỳ phép biến đổi nào). Tuy nhiên, giao diện nội bộ mô hình mong đợi dữ liệu ở định dạng được chuyển đổi.
Biểu đồ transform_fn , hiện là một phần của mô hình, áp dụng tất cả logic tiền xử lý trên điểm dữ liệu đến. Nó sử dụng các hằng số được lưu trữ (như μ và σ để bình thường hóa các tính năng số) trong hoạt động cấp độ thể hiện trong quá trình dự đoán. Do đó, biểu đồ transform_fn chuyển đổi điểm dữ liệu thô thành định dạng được chuyển đổi. Định dạng biến đổi là những gì được mong đợi bởi giao diện bên trong mô hình để tạo ra dự đoán, như trong Hình 4.
Cơ chế này giải quyết thách thức tiền xử lý của độ lệch phục vụ đào tạo, bởi vì cùng một logic (triển khai) được sử dụng để chuyển đổi dữ liệu đào tạo và đánh giá được áp dụng để chuyển đổi các điểm dữ liệu mới trong quá trình phục vụ dự đoán.
Tóm tắt tùy chọn tiền xử lý
Bảng sau đây tóm tắt các tùy chọn tiền xử lý dữ liệu mà tài liệu này đã thảo luận. Trong bảng, "N/A" là viết tắt của "không áp dụng".
| Tùy chọn tiền xử lý dữ liệu | Cấp độ ví dụ (biến đổi không quốc tịch) | Thông số hoàn toàn trong quá trình đào tạo và cấp độ thể hiện trong quá trình phục vụ (các phép biến đổi trạng thái) | Các tập hợp thời gian thực (cửa sổ) trong quá trình đào tạo và phục vụ (biến đổi phát trực tuyến) |
|---|---|---|---|
BigQuery (SQL) | Ghi điểm hàng loạt: OK , việc thực hiện chuyển đổi tương tự được áp dụng trên dữ liệu trong quá trình đào tạo và ghi điểm hàng loạt. Dự đoán trực tuyến: Không được khuyến nghị , bạn có thể xử lý dữ liệu đào tạo, nhưng nó dẫn đến việc phục vụ đào tạo vì bạn xử lý phục vụ dữ liệu bằng các công cụ khác nhau. | Ghi điểm hàng loạt: Không được khuyến nghị . Dự đoán trực tuyến: Không được khuyến nghị . Mặc dù bạn có thể sử dụng các số liệu thống kê được tính toán bằng cách sử dụng BigQuery cho các phép biến đổi hàng loạt/trực tuyến cấp độ, nhưng điều đó không dễ dàng vì bạn phải duy trì một cửa hàng thống kê để được đào tạo và sử dụng trong quá trình dự đoán. | Ghi điểm hàng loạt: N/A , như thế này được tính toán dựa trên các sự kiện thời gian thực. Dự đoán trực tuyến: Không được khuyến nghị , bạn có thể xử lý dữ liệu đào tạo, nhưng nó dẫn đến việc phục vụ đào tạo vì bạn xử lý phục vụ dữ liệu bằng các công cụ khác nhau. |
DataFlow (Apache Beam) | Ghi điểm hàng loạt: OK , việc thực hiện chuyển đổi tương tự được áp dụng trên dữ liệu trong quá trình đào tạo và ghi điểm hàng loạt. Dự đoán trực tuyến: Dữ liệu OK trong thời gian phục vụ đến từ Pub/Sub để được tiêu thụ bởi DataFlow. Mặt khác, kết quả trong việc phục vụ đào tạo. | Ghi điểm hàng loạt: Không được khuyến nghị . Dự đoán trực tuyến: Không được khuyến nghị . Mặc dù bạn có thể sử dụng các số liệu thống kê được tính toán bằng cách sử dụng DataFlow theo các phép biến đổi hàng loạt/trực tuyến cấp độ, nhưng điều đó không dễ dàng vì bạn phải duy trì một cửa hàng thống kê để được đào tạo và sử dụng trong quá trình dự đoán. | Ghi điểm hàng loạt: N/A , như thế này được tính toán dựa trên các sự kiện thời gian thực. Dự đoán trực tuyến: OK , tương tự như vậy, chuyển đổi chùm tia Apache được áp dụng trên dữ liệu trong quá trình đào tạo (Batch) và phục vụ (luồng). |
DataFlow (Apache Beam + TFT) | Ghi điểm hàng loạt: OK , thực hiện chuyển đổi tương tự được áp dụng cho dữ liệu trong quá trình đào tạo và ghi điểm hàng loạt. Dự đoán trực tuyến: Khuyến nghị , hãy tránh các độ lệch phục vụ đào tạo và chuẩn bị dữ liệu đào tạo lên phía trước. | Ghi điểm hàng loạt: Khuyến nghị . Dự đoán trực tuyến: Khuyến nghị . Cả hai cách sử dụng được khuyến nghị vì logic chuyển đổi và thống kê được tính toán trong quá trình đào tạo được lưu trữ dưới dạng biểu đồ tenorflow được gắn vào mô hình xuất khẩu để phục vụ. | Ghi điểm hàng loạt: N/A , như thế này được tính toán dựa trên các sự kiện thời gian thực. Dự đoán trực tuyến: OK , tương tự như vậy, chuyển đổi chùm tia Apache được áp dụng trên dữ liệu trong quá trình đào tạo (Batch) và phục vụ (luồng). |
Tenorflow * | Ghi điểm hàng loạt: Không được khuyến nghị . Dự đoán trực tuyến: Không được khuyến nghị . Đối với hiệu quả đào tạo trong cả hai trường hợp, tốt hơn là chuẩn bị dữ liệu đào tạo lên phía trước. | Ghi điểm hàng loạt: Không thể . Dự đoán trực tuyến: Không thể . | Ghi điểm hàng loạt: N/A , như thế này được tính toán dựa trên các sự kiện thời gian thực. Dự đoán trực tuyến: Không thể . |
* Với tenorflow, các phép biến đổi như giao cắt, nhúng và mã hóa một lần nóng nên được thực hiện khai báo dưới dạng các cột feature_columns .
Điều gì tiếp theo
- Để triển khai đường ống
tf.Transformvà chạy nó bằng DataFlow, hãy đọc Phần hai của loạt bài này, tiền xử lý dữ liệu cho ML bằng cách sử dụng Transform TensorFlow . - Lấy chuyên môn Coursera trên ML với TensorFlow trên Google Cloud .
- Tìm hiểu về thực tiễn tốt nhất cho kỹ thuật ML trong các quy tắc của ML .
- Để biết thêm kiến trúc tham chiếu, sơ đồ và thực tiễn tốt nhất, khám phá các giải pháp đám mây TFX .
Tài liệu này là tài liệu đầu tiên trong loạt hai phần khám phá chủ đề kỹ thuật dữ liệu và kỹ thuật tính năng cho máy học (ML), tập trung vào các nhiệm vụ học tập được giám sát. Phần đầu tiên này thảo luận về các thực tiễn tốt nhất để xử lý dữ liệu trong một đường ống ML trên Google Cloud. Tài liệu tập trung vào việc sử dụng thư viện TensorFlow và Transformflow Transform ( tf.Transform ) để chuẩn bị dữ liệu, đào tạo mô hình và phục vụ mô hình để dự đoán. Tài liệu này nêu bật các thách thức của việc tiền xử lý dữ liệu cho ML và nó mô tả các tùy chọn và kịch bản để thực hiện chuyển đổi dữ liệu trên Google Cloud một cách hiệu quả.
Tài liệu này giả định rằng bạn quen thuộc với BigQuery , DataFlow , Vertex AI và API TensorFlow Keras .
Tài liệu thứ hai, tiền xử lý dữ liệu cho ML với Google Cloud , cung cấp một hướng dẫn từng bước về cách thực hiện đường ống tf.Transform .
Giới thiệu
ML giúp bạn tự động tìm các mẫu phức tạp và có khả năng hữu ích trong dữ liệu. Các mẫu này được cô đọng trong một mô hình ML mà sau đó có thể được sử dụng trên các điểm dữ liệu mới, một quy trình gọi là dự đoán hoặc thực hiện suy luận .
Xây dựng một mô hình ML là một quá trình nhiều người. Mỗi bước trình bày các thách thức kỹ thuật và khái niệm của riêng mình. Sê-ri hai phần này tập trung vào các nhiệm vụ học tập có giám sát và quá trình lựa chọn, chuyển đổi và tăng cường dữ liệu nguồn để tạo ra các tín hiệu dự đoán mạnh mẽ cho biến mục tiêu. Các hoạt động này kết hợp kiến thức miền với các kỹ thuật khoa học dữ liệu. Các hoạt động là bản chất của kỹ thuật tính năng .
Kích thước của các bộ dữ liệu đào tạo cho các mô hình ML trong thế giới thực có thể dễ dàng bằng hoặc lớn hơn một terabyte (TB). Do đó, bạn cần các khung xử lý dữ liệu quy mô lớn để xử lý các bộ dữ liệu này một cách hiệu quả và phân phối. Khi bạn sử dụng mô hình ML để đưa ra dự đoán, bạn phải áp dụng các phép biến đổi tương tự mà bạn đã sử dụng cho dữ liệu đào tạo trên các điểm dữ liệu mới. Bằng cách áp dụng các phép biến đổi tương tự, bạn trình bày bộ dữ liệu trực tiếp cho mô hình ML theo cách mà mô hình mong đợi.
Tài liệu này thảo luận về những thách thức này đối với các mức độ chi tiết khác nhau của các hoạt động kỹ thuật tính năng: tập hợp cấp độ, toàn bộ thông thường và cửa sổ thời gian. Tài liệu này cũng mô tả các tùy chọn và kịch bản để thực hiện chuyển đổi dữ liệu cho ML trên Google Cloud.
Tài liệu này cũng cung cấp một cái nhìn tổng quan về biến đổi TensorFlow ( tf.Transform ), một thư viện cho TensorFlow cho phép bạn xác định cả chuyển đổi dữ liệu cấp độ thể hiện và toàn bộ thông qua các đường ống tiền xử lý dữ liệu. Các đường ống này được thực hiện với Apache Beam và chúng tạo ra các tạo tác cho phép bạn áp dụng các phép biến đổi tương tự trong quá trình dự đoán như khi mô hình được phục vụ.
Tiền xử lý dữ liệu cho ML
Phần này giới thiệu các hoạt động tiền xử lý dữ liệu và các giai đoạn sẵn sàng dữ liệu. Nó cũng thảo luận về các loại hoạt động tiền xử lý và độ chi tiết của chúng.
Kỹ thuật dữ liệu so với kỹ thuật tính năng
Tiền xử lý dữ liệu cho ML bao gồm cả kỹ thuật dữ liệu và kỹ thuật tính năng. Kỹ thuật dữ liệu là quá trình chuyển đổi dữ liệu thô thành dữ liệu đã chuẩn bị . Kỹ thuật tính năng sau đó điều chỉnh dữ liệu đã chuẩn bị để tạo các tính năng được mô hình ML dự kiến. Các thuật ngữ này có ý nghĩa sau:
- Dữ liệu thô (hoặc chỉ là dữ liệu )
- Dữ liệu ở dạng nguồn của nó, mà không có bất kỳ sự chuẩn bị trước cho ML. Trong bối cảnh này, dữ liệu có thể ở dạng thô (trong hồ dữ liệu) hoặc ở dạng biến đổi (trong kho dữ liệu). Dữ liệu được chuyển đổi trong kho dữ liệu có thể đã được chuyển đổi từ dạng thô ban đầu của nó để được sử dụng để phân tích. Tuy nhiên, trong bối cảnh này, dữ liệu thô có nghĩa là dữ liệu chưa được chuẩn bị cụ thể cho tác vụ ML của bạn. Dữ liệu cũng được coi là dữ liệu thô nếu nó được gửi từ các hệ thống phát trực tuyến mà cuối cùng gọi các mô hình ML cho các dự đoán.
- Dữ liệu chuẩn bị
- Bộ dữ liệu trong biểu mẫu đã sẵn sàng cho tác vụ ML của bạn: Nguồn dữ liệu đã được phân tích cú pháp, tham gia và đưa vào một dạng bảng. Ví dụ, dữ liệu được chuẩn bị được tổng hợp và tóm tắt theo độ chi tiết bên phải, mỗi hàng trong bộ dữ liệu đại diện cho một khách hàng duy nhất và mỗi cột đại diện cho thông tin tóm tắt cho khách hàng, như tổng số chi tiêu trong sáu tuần qua. Trong một bảng dữ liệu đã chuẩn bị, các cột không liên quan đã bị loại bỏ và các bản ghi không hợp lệ đã được lọc ra. Đối với các nhiệm vụ học tập có giám sát, tính năng mục tiêu có mặt.
- Các tính năng kỹ thuật
- Bộ dữ liệu với các tính năng được điều chỉnh được mong đợi bởi mô hình, nghĩa là các tính năng được tạo bằng cách thực hiện các hoạt động dành riêng cho ML nhất định trên các cột trong bộ dữ liệu đã chuẩn bị và tạo các tính năng mới cho mô hình của bạn trong quá trình đào tạo và dự đoán, như được mô tả sau Trong các hoạt động tiền xử lý . Ví dụ về các hoạt động này bao gồm chia tỷ lệ các cột số thành giá trị từ 0 đến 1, các giá trị cắt và các tính năng phân loại mã hóa một Hot .
Sơ đồ sau, Hình 1, cho thấy các bước có liên quan đến việc chuẩn bị dữ liệu được xử lý trước:
Trong thực tế, dữ liệu từ cùng một nguồn thường ở các giai đoạn sẵn sàng khác nhau. Ví dụ: một trường từ bảng trong kho dữ liệu của bạn có thể được sử dụng trực tiếp làm tính năng được thiết kế. Đồng thời, một trường khác trong cùng một bảng có thể cần phải trải qua các phép biến đổi trước khi nó trở thành một tính năng được thiết kế. Tương tự, kỹ thuật dữ liệu và hoạt động kỹ thuật tính năng có thể được kết hợp trong cùng một bước tiền xử lý dữ liệu.
Hoạt động tiền xử lý
Tiền xử lý dữ liệu bao gồm một số hoạt động. Mỗi hoạt động được thiết kế để giúp ML xây dựng các mô hình dự đoán tốt hơn. Các chi tiết của các hoạt động tiền xử lý này nằm ngoài phạm vi của tài liệu này, nhưng một số hoạt động được mô tả ngắn gọn trong phần này.
Đối với dữ liệu có cấu trúc, các hoạt động tiền xử lý dữ liệu bao gồm các hoạt động sau:
- Làm sạch dữ liệu: Loại bỏ hoặc sửa các bản ghi đã bị hỏng hoặc không hợp lệ các giá trị ra khỏi dữ liệu thô và xóa các bản ghi thiếu một số lượng lớn các cột.
- Lựa chọn và phân vùng phiên bản: Chọn các điểm dữ liệu từ bộ dữ liệu đầu vào để tạo đào tạo, đánh giá (xác thực) và các bộ kiểm tra . Quá trình này bao gồm các kỹ thuật để lấy mẫu ngẫu nhiên có thể lặp lại, các lớp thiểu số quá mức và phân vùng phân tầng.
- Điều chỉnh tính năng: Cải thiện chất lượng của một tính năng cho ML, bao gồm tỷ lệ và bình thường hóa các giá trị số, buộc các giá trị bị thiếu, các ngoại lệ cắt và điều chỉnh các giá trị có phân phối sai lệch.
- Chuyển đổi tính năng: Chuyển đổi một tính năng số thành một tính năng phân loại (thông qua nhóm hóa ) và chuyển đổi các tính năng phân loại thành biểu diễn số (thông qua mã hóa một lần, học với số lượng , tính năng thưa thớt, v.v.). Một số mô hình chỉ hoạt động với các tính năng số hoặc phân loại, trong khi các mô hình khác có thể xử lý các tính năng loại hỗn hợp. Ngay cả khi các mô hình xử lý cả hai loại, chúng có thể được hưởng lợi từ các biểu diễn khác nhau (số và phân loại) của cùng một tính năng.
- Khai thác tính năng: Giảm số lượng các tính năng bằng cách tạo các biểu diễn dữ liệu mạnh hơn, mạnh hơn bằng cách sử dụng các kỹ thuật như PCA , trích xuất nhúng và băm .
- Lựa chọn tính năng: Chọn một tập hợp con của các tính năng đầu vào để đào tạo mô hình và bỏ qua các tính năng không liên quan hoặc dự phòng, sử dụng các phương thức bộ lọc hoặc trình bao bọc . Lựa chọn tính năng cũng có thể liên quan chỉ đơn giản là bỏ các tính năng nếu các tính năng bị thiếu một số lượng lớn các giá trị.
- Xây dựng tính năng: Tạo các tính năng mới bằng cách sử dụng các kỹ thuật điển hình, chẳng hạn như mở rộng đa thức (bằng cách sử dụng các chức năng toán học đơn biến) hoặc giao nhau tính năng (để nắm bắt các tương tác tính năng). Các tính năng cũng có thể được xây dựng bằng cách sử dụng logic kinh doanh từ miền của trường hợp sử dụng ML.
Khi bạn làm việc với dữ liệu phi cấu trúc (ví dụ: hình ảnh, âm thanh hoặc tài liệu văn bản), Deep Learning thay thế kỹ thuật tính năng dựa trên kiến thức miền bằng cách gấp nó vào kiến trúc mô hình. Một lớp tích chập là một bộ tiền xử lý tính năng tự động. Xây dựng kiến trúc mô hình phù hợp đòi hỏi một số kiến thức thực nghiệm về dữ liệu. Ngoài ra, một số lượng tiền xử lý là cần thiết, chẳng hạn như sau:
- Đối với các tài liệu văn bản: Xuất thân và lemmat hóa , tính toán TF-idf và trích xuất N-gram , tra cứu nhúng.
- Đối với hình ảnh: cắt, thay đổi kích thước, cắt xén, mờ Gaussian và các bộ lọc Canary.
- Đối với tất cả các loại dữ liệu (bao gồm cả văn bản và hình ảnh): Chuyển giao học tập , xử lý các lớp hoàn toàn nhưng của mô hình được đào tạo đầy đủ như một bước kỹ thuật tính năng.
Tiền xử lý hạt
Phần này thảo luận về độ chi tiết của các loại chuyển đổi dữ liệu. Nó cho thấy lý do tại sao quan điểm này là rất quan trọng khi chuẩn bị các điểm dữ liệu mới cho các dự đoán bằng cách sử dụng các phép biến đổi được áp dụng trên dữ liệu đào tạo.
Các hoạt động tiền xử lý và chuyển đổi có thể được phân loại như sau, dựa trên hoạt động chi tiết:
Chuyển đổi cấp độ thể hiện trong quá trình đào tạo và dự đoán . Đây là những biến đổi đơn giản, trong đó chỉ cần các giá trị từ cùng một trường hợp cho phép biến đổi. Ví dụ: các phép biến đổi cấp độ thể hiện có thể bao gồm việc cắt giá trị của một tính năng vào một số ngưỡng, mở rộng đa thức một tính năng khác, nhân hai tính năng hoặc so sánh hai tính năng để tạo cờ Boolean.
Các phép biến đổi này phải được áp dụng giống hệt nhau trong quá trình đào tạo và dự đoán, bởi vì mô hình sẽ được đào tạo về các tính năng được chuyển đổi, không phải trên các giá trị đầu vào thô. Nếu dữ liệu không được chuyển đổi giống hệt nhau, thì mô hình hoạt động kém vì nó được trình bày với dữ liệu có phân phối các giá trị mà nó không được đào tạo. Để biết thêm thông tin, hãy xem các cuộc thảo luận về độ lệch phục vụ đào tạo trong phần Thử thách tiền xử lý .
Các phép biến đổi toàn bộ trong quá trình đào tạo, nhưng các phép biến đổi cấp độ trong quá trình dự đoán . Trong kịch bản này, các phép biến đổi là trạng thái, bởi vì chúng sử dụng một số thống kê được tính toán trước để thực hiện chuyển đổi. Trong quá trình đào tạo, bạn phân tích toàn bộ dữ liệu đào tạo để tính toán các số lượng như tối thiểu, tối đa, trung bình và phương sai để chuyển đổi dữ liệu đào tạo, dữ liệu đánh giá và dữ liệu mới tại thời điểm dự đoán.
Ví dụ, để bình thường hóa một tính năng số để đào tạo, bạn tính toán giá trị trung bình của nó (μ) và độ lệch chuẩn () trên toàn bộ dữ liệu đào tạo. Tính toán này được gọi là hoạt động toàn bộ (hoặc phân tích ). Khi bạn phục vụ mô hình để dự đoán, giá trị của một điểm dữ liệu mới được chuẩn hóa để tránh độ lệch phục vụ đào tạo. Do đó, các giá trị μ và σ được tính toán trong quá trình đào tạo được sử dụng để điều chỉnh giá trị tính năng, đây là thao tác cấp độ đơn giản sau đây:
$$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$Các phép biến đổi hoàn toàn thông tin bao gồm:
- Minmax chia tỷ lệ các tính năng số bằng Min và Max được tính toán từ bộ dữ liệu đào tạo.
- Tỷ lệ tiêu chuẩn (chuẩn hóa điểm Z) Các tính năng bằng cách sử dụng μ và σ được tính toán trên bộ dữ liệu đào tạo.
- Xô các tính năng số bằng cách sử dụng lượng tử.
- Cắt bỏ các giá trị bị thiếu bằng cách sử dụng các tính năng trung bình (tính năng số) hoặc chế độ (các tính năng phân loại).
- Chuyển đổi chuỗi (giá trị danh nghĩa) thành các số nguyên (chỉ mục) bằng cách trích xuất tất cả các giá trị riêng biệt (từ vựng) của một tính năng phân loại đầu vào.
- Đếm sự xuất hiện của một thuật ngữ (giá trị tính năng) trong tất cả các tài liệu (trường hợp) để tính toán cho TF-IDF.
- Tính toán PCA của các tính năng đầu vào để chiếu dữ liệu vào không gian chiều thấp hơn (với các tính năng phụ thuộc tuyến tính).
Bạn chỉ nên sử dụng dữ liệu đào tạo để tính toán số liệu thống kê như μ,, tối thiểu và tối đa . Nếu bạn thêm dữ liệu kiểm tra và đánh giá cho các hoạt động này, bạn sẽ rò rỉ thông tin từ dữ liệu đánh giá và kiểm tra để đào tạo mô hình. Làm như vậy ảnh hưởng đến độ tin cậy của kết quả kiểm tra và đánh giá. Để đảm bảo rằng bạn áp dụng chuyển đổi nhất quán cho tất cả các bộ dữ liệu, bạn sử dụng cùng một số liệu thống kê được tính toán từ dữ liệu đào tạo để chuyển đổi dữ liệu kiểm tra và đánh giá.
Tập hợp lịch sử trong quá trình đào tạo và dự đoán . Điều này liên quan đến việc tạo ra các tập hợp kinh doanh, dẫn xuất và cờ làm tín hiệu đầu vào cho nhiệm vụ dự đoán, ví dụ, tạo ra các số liệu hồi quy, tần suất và tiền tệ (RFM) để khách hàng xây dựng các mô hình xu hướng. Các loại tính năng này có thể được tính toán trước và lưu trữ trong một cửa hàng tính năng được sử dụng trong quá trình đào tạo mô hình, ghi điểm hàng loạt và phục vụ dự đoán trực tuyến. Bạn cũng có thể thực hiện thêm kỹ thuật tính năng (ví dụ: chuyển đổi và điều chỉnh) sang các tập hợp này trước khi đào tạo và dự đoán.
Các tập hợp lịch sử trong quá trình đào tạo, nhưng tập hợp thời gian thực trong quá trình dự đoán . Cách tiếp cận này liên quan đến việc tạo ra một tính năng bằng cách tóm tắt các giá trị thời gian thực theo thời gian. Trong phương pháp này, các trường hợp được tổng hợp được xác định thông qua các mệnh đề cửa sổ tạm thời. Ví dụ: bạn có thể sử dụng phương pháp này nếu bạn muốn đào tạo một mô hình ước tính thời gian chuyến đi taxi dựa trên các số liệu giao thông cho tuyến đường trong 5 phút cuối, trong 10 phút cuối cùng, trong 30 phút cuối cùng và tại các số khác khoảng thời gian. Bạn cũng có thể sử dụng phương pháp này để dự đoán sự thất bại của bộ phận động cơ dựa trên mức trung bình di chuyển của nhiệt độ và giá trị rung được tính toán trong 3 phút cuối. Mặc dù các tập hợp này có thể được chuẩn bị ngoại tuyến để đào tạo, nhưng chúng được tính toán trong thời gian thực từ luồng dữ liệu trong quá trình phục vụ.
Chính xác hơn, khi bạn chuẩn bị dữ liệu đào tạo, nếu giá trị tổng hợp không có trong dữ liệu thô, giá trị được tạo trong giai đoạn kỹ thuật dữ liệu. Dữ liệu thô thường được lưu trữ trong cơ sở dữ liệu có định dạng
(entity, timestamp, value). Trong các ví dụ trước,entitylà mã định danh phân đoạn tuyến đường cho các tuyến taxi và định danh phần động cơ cho lỗi động cơ. Bạn có thể sử dụng các hoạt động gió để tính toán(entity, time_index, aggregated_value_over_time_window)và sử dụng các tính năng tổng hợp làm đầu vào cho đào tạo mô hình của bạn.Khi mô hình dự đoán thời gian thực (trực tuyến) được phục vụ, mô hình mong đợi các tính năng có nguồn gốc từ các giá trị tổng hợp dưới dạng đầu vào. Do đó, bạn có thể sử dụng công nghệ xử lý luồng như Apache Beam để tính toán các tập hợp từ các điểm dữ liệu thời gian thực được truyền vào hệ thống của bạn. Công nghệ xử lý luồng tổng hợp dữ liệu thời gian thực dựa trên các cửa sổ thời gian khi các điểm dữ liệu mới đến. Bạn cũng có thể thực hiện thêm kỹ thuật tính năng (ví dụ: chuyển đổi và điều chỉnh) sang các tập hợp này trước khi đào tạo và dự đoán.
ML đường ống trên Google Cloud
Phần này thảo luận về các thành phần cốt lõi của một đường ống từ đầu đến cuối điển hình để đào tạo và phục vụ các mô hình ML Tensorflow trên Google Cloud bằng các dịch vụ được quản lý. Nó cũng thảo luận về nơi bạn có thể thực hiện các loại khác nhau của các hoạt động tiền xử lý dữ liệu và những thách thức chung mà bạn có thể gặp phải khi thực hiện các phép biến đổi đó. Phần TF.Transform Works cho thấy thư viện biến đổi TensorFlow giúp giải quyết các thách thức này như thế nào.
Kiến trúc cấp cao
Biểu đồ sau, Hình 2, cho thấy một kiến trúc cấp cao của một đường ống ML điển hình để đào tạo và phục vụ các mô hình Tensorflow. Các nhãn A, B và C trong sơ đồ đề cập đến các địa điểm khác nhau trong đường ống nơi có thể xử lý trước dữ liệu. Chi tiết về các bước này được cung cấp trong phần sau.
Đường ống bao gồm các bước sau:
- Sau khi dữ liệu thô được nhập, dữ liệu bảng được lưu trữ trong BigQuery và các dữ liệu khác như hình ảnh, âm thanh và video, được lưu trữ trong lưu trữ đám mây. Phần thứ hai của loạt bài này sử dụng dữ liệu bảng được lưu trữ trong BigQuery làm ví dụ.
- Kỹ thuật dữ liệu (chuẩn bị) và kỹ thuật tính năng được thực hiện ở quy mô bằng DataFlow. Việc thực hiện này tạo ra các bộ đào tạo, đánh giá và thử nghiệm sẵn sàng cho ML được lưu trữ trong lưu trữ đám mây. Lý tưởng nhất, các bộ dữ liệu này được lưu trữ dưới dạng các tệp TFRecord , là định dạng được tối ưu hóa cho các tính toán TensorFlow.
- Gói Trainer Model TensorFlow được gửi đến đào tạo AI của Vertex, sử dụng dữ liệu được xử lý trước từ các bước trước để đào tạo mô hình. Đầu ra của bước này là một mô -đun lưu lượng tenorflow được đào tạo được xuất sang lưu trữ đám mây.
- Mô hình TensorFlow được đào tạo được triển khai để dự đoán AI của Vertex như một dịch vụ có API REST để có thể sử dụng cho các dự đoán trực tuyến. Mô hình tương tự cũng có thể được sử dụng cho các công việc dự đoán hàng loạt.
- Sau khi mô hình được triển khai dưới dạng API REST, các ứng dụng máy khách và hệ thống nội bộ có thể gọi API bằng cách gửi các yêu cầu với một số điểm dữ liệu và nhận phản hồi từ mô hình với dự đoán.
- Để dàn dựng và tự động hóa đường ống này, bạn có thể sử dụng các đường ống AI của Vertex như một trình lập lịch để gọi việc chuẩn bị dữ liệu, đào tạo mô hình và các bước triển khai mô hình.
Bạn cũng có thể sử dụng cửa hàng tính năng AI của Vertex để lưu trữ các tính năng đầu vào để đưa ra dự đoán. Ví dụ: bạn có thể định kỳ tạo các tính năng được thiết kế từ dữ liệu thô mới nhất và lưu trữ chúng trong cửa hàng tính năng AI của Vertex. Các ứng dụng khách hàng tìm nạp các tính năng đầu vào cần thiết từ cửa hàng tính năng AI của Vertex và gửi chúng đến mô hình để nhận dự đoán.
Làm tiền xử lý trước ở đâu
Trong Hình 2, các nhãn A, B và C cho thấy các hoạt động tiền xử lý dữ liệu có thể diễn ra trong BigQuery, DataFlow hoặc TensorFlow. Các phần sau đây mô tả cách mỗi tùy chọn này hoạt động.
Tùy chọn A: BigQuery
Thông thường, logic được triển khai trong BigQuery cho các hoạt động sau:
- Lấy mẫu: Chọn ngẫu nhiên một tập hợp con từ dữ liệu.
- Lọc: Loại bỏ các trường hợp không liên quan hoặc không hợp lệ.
- Phân vùng: Tách dữ liệu để tạo ra các bộ đào tạo, đánh giá và kiểm tra.
Các tập lệnh BigQuery SQL có thể được sử dụng làm truy vấn nguồn cho đường ống tiền xử lý DataFlow, đó là bước xử lý dữ liệu trong Hình 2. Ví dụ: nếu một hệ thống được sử dụng ở Canada và kho dữ liệu có các giao dịch từ khắp nơi trên thế giới, lọc đến Nhận dữ liệu đào tạo chỉ dành cho Canada được thực hiện tốt nhất trong BigQuery. Kỹ thuật tính năng trong BigQuery rất đơn giản và có thể mở rộng, và hỗ trợ thực hiện các phép biến đổi tính năng tập hợp cấp độ và lịch sử.
Tuy nhiên, chúng tôi khuyên bạn nên sử dụng BigQuery cho kỹ thuật tính năng chỉ khi bạn sử dụng mô hình của mình để dự đoán hàng loạt (tính điểm) hoặc nếu các tính năng được tính toán trước trong BigQuery, nhưng được lưu trữ trong cửa hàng tính năng AI của Vertex được sử dụng trong dự đoán trực tuyến. Nếu bạn có kế hoạch triển khai mô hình cho các dự đoán trực tuyến và nếu bạn không có tính năng được thiết kế trong một cửa hàng tính năng trực tuyến, bạn phải sao chép các hoạt động xử lý tiền xử lý SQL để chuyển đổi các điểm dữ liệu thô mà các hệ thống khác tạo ra. Nói cách khác, bạn cần triển khai logic hai lần: một lần trong SQL để xử lý dữ liệu đào tạo trong BigQuery và lần thứ hai trong logic của ứng dụng tiêu thụ mô hình để xử lý các điểm dữ liệu trực tuyến để dự đoán.
Ví dụ: nếu ứng dụng khách hàng của bạn được viết bằng Java, bạn cần phải thực hiện lại logic trong Java. Điều này có thể đưa ra các lỗi do sự khác biệt về thực hiện, như được mô tả trong phần SKEW phục vụ đào tạo của các thách thức tiền xử lý sau này trong tài liệu này. Nó cũng là chi phí thêm để duy trì hai triển khai khác nhau. Bất cứ khi nào bạn thay đổi logic trong SQL để xử lý dữ liệu đào tạo, bạn cần thay đổi triển khai Java phù hợp để xử lý dữ liệu vào thời gian phục vụ.
Nếu bạn chỉ sử dụng mô hình của mình để dự đoán hàng loạt (ví dụ: sử dụng dự đoán hàng loạt AI của Vertex AI) và nếu dữ liệu của bạn để ghi điểm có nguồn gốc từ BigQuery, bạn có thể thực hiện các hoạt động tiền xử lý này như là một phần của tập lệnh SQL BigQuery. Trong trường hợp đó, bạn có thể sử dụng cùng một tập lệnh SQL tiền xử lý để chuẩn bị cả dữ liệu đào tạo và ghi điểm.
Các phép biến đổi trạng thái toàn bộ không phù hợp để thực hiện trong BigQuery. Nếu bạn sử dụng BigQuery cho các phép biến đổi toàn bộ, bạn cần các bảng phụ trợ để lưu trữ số lượng cần thiết cho các phép biến đổi trạng thái, chẳng hạn như phương tiện và phương sai để mở rộng các tính năng số. Hơn nữa, việc thực hiện các phép biến đổi toàn bộ bằng cách sử dụng SQL trên BigQuery tạo ra sự phức tạp tăng lên trong các tập lệnh SQL và tạo ra sự phụ thuộc phức tạp giữa đào tạo và các tập lệnh SQL ghi điểm.
Tùy chọn B: DataFlow
Như được hiển thị trong Hình 2, bạn có thể thực hiện các hoạt động tiền xử lý đắt tiền tính toán trong Apache Beam và chạy chúng ở quy mô bằng DataFlow. DataFlow là một dịch vụ tự động được quản lý đầy đủ để xử lý dữ liệu hàng loạt và phát trực tuyến. Khi bạn sử dụng DataFlow, bạn cũng có thể sử dụng các thư viện chuyên dụng bên ngoài để xử lý dữ liệu, không giống như BigQuery.
DataFlow có thể thực hiện các phép biến đổi cấp độ thể hiện, và các phép biến đổi tính năng tổng hợp lịch sử và thời gian thực. Cụ thể, nếu các mô hình ML của bạn mong đợi một tính năng đầu vào như total_number_of_clicks_last_90sec , các chức năng cửa sổ Apache chùm có thể tính toán các tính năng này dựa trên việc tổng hợp các giá trị của các cửa sổ thời gian của dữ liệu sự kiện thời gian thực (phát trực tuyến) (ví dụ: nhấp vào các sự kiện). Trong các cuộc thảo luận trước đây về độ chi tiết của các biến đổi , điều này được gọi là "các tập hợp lịch sử trong quá trình đào tạo, nhưng các tập hợp thời gian thực trong dự đoán."
Sơ đồ sau, Hình 3, cho thấy vai trò của DataFlow trong việc xử lý dữ liệu luồng cho các dự đoán gần thời gian thực.
Như được hiển thị trong Hình 3, trong quá trình xử lý, các sự kiện được gọi là điểm dữ liệu được nhập vào PUB/SUB . DataFlow tiêu thụ các điểm dữ liệu này, tính toán các tính năng dựa trên các tập hợp theo thời gian và sau đó gọi API mô hình ML được triển khai để dự đoán. Dự đoán sau đó được gửi đến một hàng đợi quán rượu/phụ. Từ Pub/Sub, dự đoán có thể được tiêu thụ bởi các hệ thống hạ nguồn như giám sát hoặc kiểm soát, hoặc chúng có thể được đẩy lùi (ví dụ, dưới dạng thông báo) cho máy khách yêu cầu ban đầu. Dự đoán cũng có thể được lưu trữ trong một kho lưu trữ dữ liệu có độ trễ thấp như Cloud Bigtable để tìm nạp thời gian thực. Cloud Bigtable cũng có thể được sử dụng để tích lũy và lưu trữ các tập hợp thời gian thực này để chúng có thể được tra cứu khi cần thiết để dự đoán.
Việc triển khai chùm tia Apache tương tự có thể được sử dụng để dữ liệu đào tạo xử lý hàng loạt đến từ một kho dữ liệu ngoại tuyến như BigQuery và dữ liệu thời gian thực xử lý luồng để phục vụ dự đoán trực tuyến.
Trong các kiến trúc điển hình khác, chẳng hạn như kiến trúc được hiển thị trong Hình 2, ứng dụng máy khách trực tiếp gọi API mô hình được triển khai để dự đoán trực tuyến. Trong trường hợp đó, nếu các hoạt động tiền xử lý được triển khai trong DataFlow để chuẩn bị dữ liệu đào tạo, các hoạt động không được áp dụng cho dữ liệu dự đoán trực tiếp vào mô hình. Do đó, các biến đổi như thế này nên được tích hợp trong mô hình trong quá trình phục vụ cho các dự đoán trực tuyến.
DataFlow có thể được sử dụng để thực hiện chuyển đổi toàn bộ, bằng cách tính toán các số liệu thống kê cần thiết ở quy mô. Tuy nhiên, những thống kê này cần được lưu trữ ở đâu đó sẽ được sử dụng trong quá trình dự đoán để chuyển đổi các điểm dữ liệu dự đoán. Bằng cách sử dụng thư viện TensorFlow Transform ( tf.Transform ), bạn có thể trực tiếp nhúng các số liệu thống kê này vào mô hình thay vì lưu trữ chúng ở nơi khác. Cách tiếp cận này được giải thích sau đó trong cách hoạt động của tf.transform .
Tùy chọn C: Tensorflow
Như được hiển thị trong Hình 2, bạn có thể thực hiện các hoạt động chuyển đổi và chuyển đổi dữ liệu trong chính mô hình TensorFlow. Như được hiển thị trong hình, tiền xử lý mà bạn triển khai để đào tạo mô hình TensorFlow trở thành một phần không thể thiếu của mô hình khi mô hình được xuất và triển khai để dự đoán. Các phép biến đổi trong mô hình TensorFlow có thể được thực hiện theo một trong những cách sau:
- Thực hiện tất cả các logic chuyển đổi cấp độ thể hiện trong hàm
input_fnvà trong hàmserving_fn. Hàminput_fnchuẩn bị một bộ dữ liệu bằng APItf.data.Datasetđể đào tạo mô hình. Hàm phụcserving_fnnhận và chuẩn bị dữ liệu cho các dự đoán. - Đặt mã chuyển đổi trực tiếp vào mô hình TensorFlow của bạn bằng cách sử dụng các lớp tiền xử lý Keras hoặc tạo các lớp tùy chỉnh .
Mã logic chuyển đổi trong hàm serving_fn xác định giao diện phục vụ của SavingModel của bạn để dự đoán trực tuyến. Nếu bạn thực hiện các phép biến đổi tương tự được sử dụng để chuẩn bị dữ liệu đào tạo trong mã logic chuyển đổi của hàm serving_fn , nó đảm bảo rằng các phép biến đổi tương tự được áp dụng cho các điểm dữ liệu dự đoán mới khi chúng được phục vụ.
Tuy nhiên, vì mô hình TensorFlow xử lý từng điểm dữ liệu một cách độc lập hoặc trong một lô nhỏ, bạn không thể tính toán các tập hợp từ tất cả các điểm dữ liệu. Do đó, các phép biến đổi toàn bộ không thể được triển khai trong mô hình TensorFlow của bạn.
Những thách thức tiền xử lý
Sau đây là những thách thức chính trong việc thực hiện tiền xử lý dữ liệu:
Phục vụ đào tạo . Độ lệch phục vụ đào tạo đề cập đến sự khác biệt giữa hiệu quả (hiệu suất dự đoán) trong quá trình đào tạo và trong quá trình phục vụ. Độ lệch này có thể được gây ra bởi sự khác biệt giữa cách bạn xử lý dữ liệu trong đào tạo và các đường ống phục vụ. Ví dụ: nếu mô hình của bạn được đào tạo trên một tính năng được chuyển đổi logarit, nhưng nó được trình bày với tính năng thô trong quá trình phục vụ, đầu ra dự đoán có thể không chính xác.
Nếu các phép biến đổi trở thành một phần của chính mô hình, có thể đơn giản để xử lý các phép biến đổi cấp độ thể hiện, như được mô tả trước đó trong tùy chọn C: TensorFlow . Trong trường hợp đó, giao diện phục vụ mô hình (hàm
serving_fn) mong đợi dữ liệu thô, trong khi mô hình chuyển đổi nội bộ dữ liệu này trước khi tính toán đầu ra. Các phép biến đổi giống như các biến đổi được áp dụng trên các điểm dữ liệu đào tạo và dự đoán thô.Biến đổi hoàn toàn thông . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example,
maxandminvalues to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform (tf.Transform) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. In addition, if you're using accelerators (GPUs or TPUs), they sit idle while the CPU performs those transformations, which isn't an efficient use of your costly accelerators.
Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.
Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform (
tf.Transform) library can help you to address this issue, as described in the following section.
How tf.Transform works
The tf.Transform library is useful for transformations that require a full pass. The output of the tf.Transform library is exported as a TensorFlow graph that represents the instance-level transformation logic and the statistics computed from full-pass transformations, to be used for training and serving. Using the same graph for both training and serving can prevent skew, because the same transformations are applied in both stages. In addition, the tf.Transform library can run at scale in a batch processing pipeline on Dataflow to prepare the training data up front and improve training efficiency.
The following diagram, figure 4, shows how the tf.Transform library preprocesses and transforms data for training and prediction. The process is described in the following sections.
tf.Transform for preprocessing and transforming data. Transform training and evaluation data
You preprocess the raw training data using the transformation implemented in the tf.Transform Apache Beam APIs, and run it at scale on Dataflow. The preprocessing occurs in the following phases:
- Analyze phase: During the analyze phase, the required statistics (like means, variances, and quantiles) for stateful transformations are computed on the training data with full-pass operations. This phase produces a set of transformation artifacts, including the
transform_fngraph. Thetransform_fngraph is a TensorFlow graph that has the transformation logic as instance-level operations. It includes the statistics computed in the analyze phase as constants. - Transform phase: During the transform phase, the
transform_fngraph is applied to the raw training data, where the computed statistics are used to process the data records (for example, to scale numerical columns) in an instance-level fashion.
A two-phase approach like this addresses the preprocessing challenge of performing full-pass transformations.
When the evaluation data is preprocessed, only instance-level operations are applied, using the logic in the transform_fn graph and the statistics computed from the analyze phase in the training data. In other words, you don't analyze the evaluation data in a full-pass fashion to compute new statistics, such as μ and σ, to normalize numeric features in evaluation data. Instead, you use the computed statistics from the training data to transform the evaluation data in an instance-level fashion.
The transformed training and evaluation data are prepared at scale using Dataflow, before they are used to train the model. This batch data-preparation process addresses the preprocessing challenge of preparing the data up front to improve training efficiency. As shown in figure 4, the model internal interface expects transformed features.
Attach transformations to the exported model
As noted, the transform_fn graph that's produced by the tf.Transform pipeline is stored as an exported TensorFlow graph. The exported graph consists of the transformation logic as instance-level operations, and all of the statistics computed in the full-pass transformations as graph constants. When the trained model is exported for serving, the transform_fn graph is attached to the SavedModel as part of its serving_fn function.
While it's serving the model for prediction, the model serving interface expects data points in the raw format (that is, before any transformations). However, the model internal interface expects the data in the transformed format.
The transform_fn graph, which is now part of the model, applies all the preprocessing logic on the incoming data point. It uses the stored constants (like μ and σ to normalize the numeric features) in the instance-level operation during prediction. Therefore, the transform_fn graph converts the raw data point into the transformed format. The transformed format is what is expected by the model internal interface in order to produce prediction, as shown in figure 4.
This mechanism resolves the preprocessing challenge of the training-serving skew, because the same logic (implementation) that is used to transform the training and evaluation data is applied to transform the new data points during prediction serving.
Preprocessing options summary
The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."
| Data preprocessing option | Instance-level (stateless transformations) | Full-pass during training and instance-level during serving (stateful transformations) | Real-time (window) aggregations during training and serving (streaming transformations) |
|---|---|---|---|
BigQuery (SQL) | Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools. | Batch scoring: Not recommended . Online prediction: Not recommended . Although you can use statistics computed using BigQuery for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction. | Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools. |
Dataflow (Apache Beam) | Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: OK —if data at serving time comes from Pub/Sub to be consumed by Dataflow. Otherwise, results in training-serving skew. | Batch scoring: Not recommended . Online predictions: Not recommended . Although you can use statistics computed using Dataflow for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction. | Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream). |
Dataflow (Apache Beam + TFT) | Batch scoring: OK —the same transformation implementation is applied to data during training and batch scoring. Online prediction: Recommended —it avoids training-serving skew and prepares training data up front. | Batch scoring: Recommended . Online prediction: Recommended . Both uses are recommended because transformation logic and computed statistics during training are stored as a TensorFlow graph that's attached to the exported model for serving. | Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream). |
TensorFlow * | Batch scoring: Not recommended . Online prediction: Not recommended . For training efficiency in both cases, it's better to prepare the training data up front. | Batch scoring: Not Possible . Online prediction: Not Possible . | Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not Possible . |
* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.
What's next
- To implement a
tf.Transformpipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform . - Take the Coursera specialization on ML with TensorFlow on Google Cloud .
- Learn about best practices for ML engineering in Rules of ML .
- For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .
This document is the first in a two-part series that explores the topic of data engineering and feature engineering for machine learning (ML), with a focus on supervised learning tasks. This first part discusses the best practices for preprocessing data in an ML pipeline on Google Cloud. The document focuses on using TensorFlow and the open source TensorFlow Transform ( tf.Transform ) library to prepare data, train the model, and serve the model for prediction. This document highlights the challenges of preprocessing data for ML, and it describes the options and scenarios for performing data transformation on Google Cloud effectively.
This document assumes that you're familiar with BigQuery , Dataflow , Vertex AI , and the TensorFlow Keras API.
The second document, Data preprocessing for ML with Google Cloud , provides a step-by-step tutorial for how to implement a tf.Transform pipeline.
Giới thiệu
ML helps you automatically find complex and potentially useful patterns in data. These patterns are condensed in an ML model that can then be used on new data points—a process called making predictions or performing inference .
Building an ML model is a multistep process. Each step presents its own technical and conceptual challenges. This two-part series focuses on supervised learning tasks and the process of selecting, transforming, and augmenting the source data to create powerful predictive signals to the target variable. These operations combine domain knowledge with data science techniques. The operations are the essence of feature engineering .
The size of training datasets for real-world ML models can easily be equal to or greater than one terabyte (TB). Therefore, you need large-scale data processing frameworks in order to process these datasets efficiently and distributedly. When you use an ML model to make predictions, you have to apply the same transformations that you used for the training data on the new data points. By applying the same transformations, you present the live dataset to the ML model the way that the model expects.
This document discusses these challenges for different levels of granularity of feature engineering operations: instance-level, full-pass, and time-window aggregations. This document also describes the options and scenarios to perform data transformation for ML on Google Cloud.
This document also provides an overview of TensorFlow Transform ( tf.Transform ), a library for TensorFlow that lets you define both instance-level and full-pass data transformation through data preprocessing pipelines. These pipelines are executed with Apache Beam , and they create artifacts that let you apply the same transformations during prediction as when the model is served.
Preprocessing data for ML
This section introduces data preprocessing operations and stages of data readiness. It also discusses the types of the preprocessing operations and their granularity.
Data engineering compared to feature engineering
Preprocessing the data for ML involves both data engineering and feature engineering. Data engineering is the process of converting raw data into prepared data . Feature engineering then tunes the prepared data to create the features that are expected by the ML model. These terms have the following meanings:
- Raw data (or just data )
- The data in its source form, without any prior preparation for ML. In this context, the data might be in its raw form (in a data lake) or in a transformed form (in a data warehouse). Transformed data that's in a data warehouse might have been converted from its original raw form to be used for analytics. However, in this context, raw data means that the data hasn't been prepared specifically for your ML task. Data is also considered raw data if it's sent from streaming systems that eventually call ML models for predictions.
- Prepared data
- The dataset in the form ready for your ML task: data sources have been parsed, joined, and put into a tabular form. Prepared data is aggregated and summarized to the right granularity—for example, each row in the dataset represents a unique customer, and each column represents summary information for the customer, like the total spent in the last six weeks. In a prepared data table, irrelevant columns have been dropped, and invalid records have been filtered out. For supervised learning tasks, the target feature is present.
- Engineered features
- The dataset with the tuned features that are expected by the model—that is, features that are created by performing certain ML-specific operations on the columns in the prepared dataset, and creating new features for your model during training and prediction, as described later in Preprocessing operations . Examples of these operations include scaling numerical columns to a value between 0 and 1, clipping values, and one-hot-encoding categorical features.
The following diagram, figure 1, shows the steps that are involved in preparing preprocessed data:
In practice, data from the same source is often at different stages of readiness. For example, a field from a table in your data warehouse might be used directly as an engineered feature. At the same time, another field in the same table might need to go through transformations before it becomes an engineered feature. Similarly, data engineering and feature engineering operations might be combined in the same data preprocessing step.
Preprocessing operations
Data preprocessing includes several operations. Each operation is designed to help ML build better predictive models. The details of these preprocessing operations are outside the scope of this document, but some operations are briefly described in this section.
For structured data, data preprocessing operations include the following:
- Data cleansing: removing or correcting records that have corrupted or invalid values from raw data, and removing records that are missing a large number of columns.
- Instances selection and partitioning: selecting data points from the input dataset to create training, evaluation (validation), and test sets . This process includes techniques for repeatable random sampling, minority classes oversampling, and stratified partitioning.
- Feature tuning: improving the quality of a feature for ML, which includes scaling and normalizing numeric values, imputing missing values, clipping outliers, and adjusting values that have skewed distributions.
- Feature transformation: converting a numeric feature to a categorical feature (through bucketization ), and converting categorical features to a numeric representation (through one-hot encoding, learning with counts , sparse feature embeddings, etc.). Some models work only with numeric or categorical features, while others can handle mixed type features. Even when models handle both types, they can benefit from different representations (numeric and categorical) of the same feature.
- Feature extraction: reducing the number of features by creating lower-dimension, more powerful data representations using techniques such as PCA , embedding extraction, and hashing .
- Feature selection: selecting a subset of the input features for training the model, and ignoring the irrelevant or redundant ones, using filter or wrapper methods . Feature selection can also involve simply dropping features if the features are missing a large number of values.
- Feature construction: creating new features by using typical techniques, such as polynomial expansion (by using univariate mathematical functions) or feature crossing (to capture feature interactions). Features can also be constructed by using business logic from the domain of the ML use case.
When you work with unstructured data (for example, images, audio, or text documents), deep learning replaces domain-knowledge-based feature engineering by folding it into the model architecture. A convolutional layer is an automatic feature preprocessor. Constructing the right model architecture requires some empirical knowledge of the data. In addition, some amount of preprocessing is needed, such as the following:
- For text documents: stemming and lemmatization , TF-IDF calculation, and n-gram extraction, embedding lookup.
- For images: clipping, resizing, cropping, Gaussian blur, and canary filters.
- For all types of data (including text and images): transfer learning , which treats all-but-last layers of the fully trained model as a feature engineering step.
Preprocessing granularity
This section discusses the granularity of types of data transformations. It shows why this perspective is critical when preparing new data points for predictions using transformations that are applied on training data.
Preprocessing and transformation operations can be categorized as follows, based on operation granularity:
Instance-level transformations during training and prediction . These are straightforward transformations, where only values from the same instance are needed for the transformation. For example, instance-level transformations might include clipping the value of a feature to some threshold, polynomially expanding another feature, multiplying two features, or comparing two features to create a Boolean flag.
These transformations must be applied identically during training and prediction, because the model will be trained on the transformed features, not on the raw input values. If the data isn't transformed identically, then the model behaves poorly because it is presented with data that has a distribution of values that it wasn't trained with. For more information, see the discussion of training-serving skew in the Preprocessing challenges section.
Full-pass transformations during training, but instance-level transformations during prediction . In this scenario, transformations are stateful, because they use some precomputed statistics to perform the transformation. During training, you analyze the whole body of training data to compute quantities such as minimum, maximum, mean, and variance for transforming training data, evaluation data, and new data at prediction time.
For example, to normalize a numeric feature for training, you compute its mean (μ) and its standard deviation (σ) across the whole of the training data. This computation is called a full-pass (or analyze ) operation. When you serve the model for prediction, the value of a new data point is normalized to avoid training-serving skew. Therefore, μ and σ values that are computed during training are used to adjust the feature value, which is the following simple instance-level operation:
$$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$Full-pass transformations include the following:
- MinMax scaling numerical features using min and max computed from the training dataset.
- Standard scaling (z-score normalization) numerical features using μ and σ computed on the training dataset.
- Bucketizing numerical features using quantiles.
- Imputing missing values using the median (numerical features) or the mode (categorical features).
- Converting strings (nominal values) to integers (indexes) by extracting all the distinct values (vocabulary) of an input categorical feature.
- Counting the occurrence of a term (feature value) in all the documents (instances) to calculate for TF-IDF.
- Computing the PCA of the input features to project the data into a lower dimensional space (with linearly dependent features).
You should use only the training data to compute statistics like μ, σ, min , and max . If you add the test and evaluation data for these operations, you are leaking information from the evaluation and test data to train the model. Doing so affects the reliability of the test and evaluation results. To ensure that you apply a consistent transformation to all datasets, you use the same statistics computed from the training data to transform the test and evaluation data.
Historical aggregations during training and prediction . This involves creating business aggregations, derivations, and flags as input signals to the prediction task—for example, creating recency, frequency, and monetary (RFM) metrics for customers to build propensity models. These types of features can be precomputed and stored in a feature store to be used during model training, batch scoring, and online prediction serving. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.
Historical aggregations during training, but real-time aggregations during prediction . This approach involves creating a feature by summarizing real-time values over time. In this approach, the instances to be aggregated are defined through temporal window clauses. For example, you can use this approach if you want to train a model that estimates the taxi trip time based on the traffic metrics for the route in the last 5 minutes, in the last 10 minutes, in the last 30 minutes, and at other intervals. You can also use this approach to predict the failure of an engine part based on the moving average of temperature and vibration values computed over the last 3 minutes. Although these aggregations can be prepared offline for training, they are computed in real time from a data stream during serving.
More precisely, when you prepare training data, if the aggregated value isn't in the raw data, the value is created during the data engineering phase. The raw data is usually stored in a database with a format of
(entity, timestamp, value). In the previous examples,entityis the route segment identifier for the taxi routes and the engine part identifier for the engine failure. You can use windowing operations to compute(entity, time_index, aggregated_value_over_time_window)and use the aggregation features as an input for your model training.When the model for real-time (online) prediction is served, the model expects features derived from the aggregated values as an input. Therefore, you can use a stream-processing technology like Apache Beam to compute the aggregations from the real-time data points streamed into your system. Stream-processing technology aggregates real-time data based on time windows as new data points arrive. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.
ML pipeline on Google Cloud
This section discusses the core components of a typical end-to-end pipeline to train and serve TensorFlow ML models on Google Cloud using managed services. It also discusses where you can implement different categories of the data preprocessing operations, and common challenges that you might face when you implement such transformations. The How tf.Transform works section shows how the TensorFlow Transform library helps to address these challenges.
High-level architecture
The following diagram, figure 2, shows a high-level architecture of a typical ML pipeline for training and serving TensorFlow models. The labels A, B, and C in the diagram refer to the different places in the pipeline where data preprocessing can take place. Details about these steps are provided in the following section.
The pipeline consists of the following steps:
- After raw data is imported, tabular data is stored in BigQuery, and other data like images, audio, and video, is stored in Cloud Storage. The second part of this series uses tabular data stored in BigQuery as an example.
- Data engineering (preparation) and feature engineering are executed at scale using Dataflow. This execution produces ML-ready training, evaluation, and test sets that are stored in Cloud Storage. Ideally, these datasets are stored as TFRecord files, which is the optimized format for TensorFlow computations.
- A TensorFlow model trainer package is submitted to Vertex AI Training, which uses the preprocessed data from the previous steps to train the model. The output of this step is a trained TensorFlow SavedModel that is exported to Cloud Storage.
- The trained TensorFlow model is deployed to Vertex AI Prediction as a service that has a REST API so that it can be used for online predictions. The same model can also be used for batch prediction jobs.
- After the model is deployed as a REST API, client apps and internal systems can invoke the API by sending requests with some data points, and receiving responses from the model with predictions.
- For orchestrating and automating this pipeline, you can use Vertex AI Pipelines as a scheduler to invoke the data preparation, model training, and model deployment steps.
You can also use Vertex AI Feature Store to store input features to make predictions. For example, you can periodically create engineered features from the latest raw data and store them in Vertex AI Feature Store. Client apps fetch the required input features from Vertex AI Feature Store and send them to the model to receive predictions.
Where to do preprocessing
In figure 2, the labels A, B, and C show that data preprocessing operations can take place in BigQuery, Dataflow, or TensorFlow. The following sections describe how each of these options work.
Option A: BigQuery
Typically, logic is implemented in BigQuery for the following operations:
- Sampling: randomly selecting a subset from the data.
- Filtering: removing irrelevant or invalid instances.
- Partitioning: splitting the data to produce training, evaluation, and test sets.
BigQuery SQL scripts can be used as a source query for the Dataflow preprocessing pipeline, which is the data processing step in figure 2. For example, if a system is used in Canada, and the data warehouse has transactions from around the world, filtering to get Canada-only training data is best done in BigQuery. Feature engineering in BigQuery is simple and scalable, and supports implementing instance-level and historical aggregations feature transformations.
However, we recommend that you use BigQuery for feature engineering only if you use your model for batch prediction (scoring), or if the features are precomputed in BigQuery, but stored in Vertex AI Feature Store to be used during online prediction. If you plan to deploy the model for online predictions, and if you don't have the engineered feature in an online feature store, you have to replicate the SQL preprocessing operations to transform the raw data points that other systems generate. In other words, you need to implement the logic twice: one time in SQL to preprocess training data in BigQuery, and a second time in the logic of the app that consumes the model to preprocess online data points for prediction.
For example, if your client app is written in Java, you need to reimplement the logic in Java. This can introduce errors due to implementation discrepancies, as described in the training-serving skew section of Preprocessing challenges later in this document. It's also extra overhead to maintain two different implementations. Whenever you change the logic in SQL to preprocess the training data, you need to change the Java implementation accordingly to preprocess data at serving time.
If you are using your model only for batch prediction (for example, using Vertex AI batch prediction ), and if your data for scoring is sourced from BigQuery, you can implement these preprocessing operations as part of the BigQuery SQL script. In that case, you can use the same preprocessing SQL script to prepare both training and scoring data.
Full-pass stateful transformations aren't suitable for implementation in BigQuery. If you use BigQuery for full-pass transformations, you need auxiliary tables to store quantities needed by stateful transformations, such as means and variances to scale numerical features. Further, implementation of full-pass transformations using SQL on BigQuery creates increased complexity in the SQL scripts, and creates intricate dependency between training and the scoring SQL scripts.
Option B: Dataflow
As shown in figure 2, you can implement computationally expensive preprocessing operations in Apache Beam, and run them at scale using Dataflow. Dataflow is a fully managed autoscaling service for batch and stream data processing. When you use Dataflow, you can also use external specialized libraries for data processing, unlike BigQuery.
Dataflow can perform instance-level transformations, and historical and real-time aggregation feature transformations. In particular, if your ML models expect an input feature like total_number_of_clicks_last_90sec , Apache Beam windowing functions can compute these features based on aggregating the values of time windows of real-time (streaming) events data (for example, click events). In the earlier discussion of granularity of transformations , this was referred to as "Historical aggregations during training, but real-time aggregations during prediction."
The following diagram, figure 3, shows the role of Dataflow in processing stream data for near real-time predictions.
As shown in figure 3, during processing, events called data points are ingested into Pub/Sub . Dataflow consumes these data points, computes features based on aggregates over time, and then calls the deployed ML model API for predictions. Predictions are then sent to an outbound Pub/Sub queue. From Pub/Sub, predictions can be consumed by downstream systems like monitoring or control, or they can be pushed back (for example, as notifications) to the original requesting client. Predictions can also be stored in a low-latency data store like Cloud Bigtable for real-time fetching. Cloud Bigtable can also be used to accumulate and store these real-time aggregations so they can be looked up when needed for prediction.
The same Apache Beam implementation can be used to batch-process training data that comes from an offline datastore like BigQuery and stream-process real-time data for serving online predictions.
In other typical architectures, such as the architecture shown in figure 2, the client app directly calls the deployed model API for online predictions. In that case, if preprocessing operations are implemented in Dataflow to prepare the training data, the operations aren't applied to the prediction data that goes directly to the model. Therefore, transformations like these should be integrated in the model during serving for online predictions.
Dataflow can be used to perform full-pass transformation, by computing the required statistics at scale. However, these statistics need to be stored somewhere to be used during prediction to transform prediction data points. By using the TensorFlow Transform ( tf.Transform ) library, you can directly embed these statistics in the model instead of storing them elsewhere. This approach is explained later in How tf.Transform works .
Option C: TensorFlow
As shown in figure 2, you can implement data preprocessing and transformation operations in the TensorFlow model itself. As shown in the figure, the preprocessing that you implement for training the TensorFlow model becomes an integral part of the model when the model is exported and deployed for predictions. Transformations in the TensorFlow model can be accomplished in one of the following ways:
- Implementing all of the instance-level transformation logic in the
input_fnfunction and in theserving_fnfunction. Theinput_fnfunction prepares a dataset using thetf.data.DatasetAPI for training a model. Theserving_fnfunction receives and prepares the data for predictions. - Putting the transformation code directly in your TensorFlow model by using Keras preprocessing layers or creating custom layers .
The transformation logic code in the serving_fn function defines the serving interface of your SavedModel for online prediction. If you implement the same transformations that were used for preparing training data in the transformation logic code of the serving_fn function, it ensures that the same transformations are applied to new prediction data points when they're served.
However, because the TensorFlow model processes each data point independently or in a small batch, you can't calculate aggregations from all data points. As a result, full-pass transformations can't be implemented in your TensorFlow model.
Preprocessing challenges
The following are the primary challenges of implementing data preprocessing:
Training-serving skew . Training-serving skew refers to a difference between effectiveness (predictive performance) during training and during serving. This skew can be caused by a discrepancy between how you handle data in the training and the serving pipelines. For example, if your model is trained on a logarithmically transformed feature, but it's presented with the raw feature during serving, the prediction output might not be accurate.
If the transformations become part of the model itself, it can be straightforward to handle instance-level transformations, as described earlier in Option C: TensorFlow . In that case, the model serving interface (the
serving_fnfunction) expects raw data, while the model internally transforms this data before computing the output. The transformations are the same as those that were applied on the raw training and prediction data points.Full-pass transformations . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example,
maxandminvalues to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform (tf.Transform) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. In addition, if you're using accelerators (GPUs or TPUs), they sit idle while the CPU performs those transformations, which isn't an efficient use of your costly accelerators.
Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.
Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform (
tf.Transform) library can help you to address this issue, as described in the following section.
How tf.Transform works
The tf.Transform library is useful for transformations that require a full pass. The output of the tf.Transform library is exported as a TensorFlow graph that represents the instance-level transformation logic and the statistics computed from full-pass transformations, to be used for training and serving. Using the same graph for both training and serving can prevent skew, because the same transformations are applied in both stages. In addition, the tf.Transform library can run at scale in a batch processing pipeline on Dataflow to prepare the training data up front and improve training efficiency.
The following diagram, figure 4, shows how the tf.Transform library preprocesses and transforms data for training and prediction. The process is described in the following sections.
tf.Transform for preprocessing and transforming data. Transform training and evaluation data
You preprocess the raw training data using the transformation implemented in the tf.Transform Apache Beam APIs, and run it at scale on Dataflow. The preprocessing occurs in the following phases:
- Analyze phase: During the analyze phase, the required statistics (like means, variances, and quantiles) for stateful transformations are computed on the training data with full-pass operations. This phase produces a set of transformation artifacts, including the
transform_fngraph. Thetransform_fngraph is a TensorFlow graph that has the transformation logic as instance-level operations. It includes the statistics computed in the analyze phase as constants. - Transform phase: During the transform phase, the
transform_fngraph is applied to the raw training data, where the computed statistics are used to process the data records (for example, to scale numerical columns) in an instance-level fashion.
A two-phase approach like this addresses the preprocessing challenge of performing full-pass transformations.
When the evaluation data is preprocessed, only instance-level operations are applied, using the logic in the transform_fn graph and the statistics computed from the analyze phase in the training data. In other words, you don't analyze the evaluation data in a full-pass fashion to compute new statistics, such as μ and σ, to normalize numeric features in evaluation data. Instead, you use the computed statistics from the training data to transform the evaluation data in an instance-level fashion.
The transformed training and evaluation data are prepared at scale using Dataflow, before they are used to train the model. This batch data-preparation process addresses the preprocessing challenge of preparing the data up front to improve training efficiency. As shown in figure 4, the model internal interface expects transformed features.
Attach transformations to the exported model
As noted, the transform_fn graph that's produced by the tf.Transform pipeline is stored as an exported TensorFlow graph. The exported graph consists of the transformation logic as instance-level operations, and all of the statistics computed in the full-pass transformations as graph constants. When the trained model is exported for serving, the transform_fn graph is attached to the SavedModel as part of its serving_fn function.
While it's serving the model for prediction, the model serving interface expects data points in the raw format (that is, before any transformations). However, the model internal interface expects the data in the transformed format.
The transform_fn graph, which is now part of the model, applies all the preprocessing logic on the incoming data point. It uses the stored constants (like μ and σ to normalize the numeric features) in the instance-level operation during prediction. Therefore, the transform_fn graph converts the raw data point into the transformed format. The transformed format is what is expected by the model internal interface in order to produce prediction, as shown in figure 4.
This mechanism resolves the preprocessing challenge of the training-serving skew, because the same logic (implementation) that is used to transform the training and evaluation data is applied to transform the new data points during prediction serving.
Preprocessing options summary
The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."
| Data preprocessing option | Instance-level (stateless transformations) | Full-pass during training and instance-level during serving (stateful transformations) | Real-time (window) aggregations during training and serving (streaming transformations) |
|---|---|---|---|
BigQuery (SQL) | Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools. | Batch scoring: Not recommended . Online prediction: Not recommended . Although you can use statistics computed using BigQuery for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction. | Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools. |
Dataflow (Apache Beam) | Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: OK —if data at serving time comes from Pub/Sub to be consumed by Dataflow. Otherwise, results in training-serving skew. | Batch scoring: Not recommended . Online predictions: Not recommended . Although you can use statistics computed using Dataflow for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction. | Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream). |
Dataflow (Apache Beam + TFT) | Batch scoring: OK —the same transformation implementation is applied to data during training and batch scoring. Online prediction: Recommended —it avoids training-serving skew and prepares training data up front. | Batch scoring: Recommended . Online prediction: Recommended . Both uses are recommended because transformation logic and computed statistics during training are stored as a TensorFlow graph that's attached to the exported model for serving. | Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream). |
TensorFlow * | Batch scoring: Not recommended . Online prediction: Not recommended . For training efficiency in both cases, it's better to prepare the training data up front. | Batch scoring: Not Possible . Online prediction: Not Possible . | Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not Possible . |
* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.
What's next
- To implement a
tf.Transformpipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform . - Take the Coursera specialization on ML with TensorFlow on Google Cloud .
- Learn about best practices for ML engineering in Rules of ML .
- For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .
This document is the first in a two-part series that explores the topic of data engineering and feature engineering for machine learning (ML), with a focus on supervised learning tasks. This first part discusses the best practices for preprocessing data in an ML pipeline on Google Cloud. The document focuses on using TensorFlow and the open source TensorFlow Transform ( tf.Transform ) library to prepare data, train the model, and serve the model for prediction. This document highlights the challenges of preprocessing data for ML, and it describes the options and scenarios for performing data transformation on Google Cloud effectively.
This document assumes that you're familiar with BigQuery , Dataflow , Vertex AI , and the TensorFlow Keras API.
The second document, Data preprocessing for ML with Google Cloud , provides a step-by-step tutorial for how to implement a tf.Transform pipeline.
Giới thiệu
ML helps you automatically find complex and potentially useful patterns in data. These patterns are condensed in an ML model that can then be used on new data points—a process called making predictions or performing inference .
Building an ML model is a multistep process. Each step presents its own technical and conceptual challenges. This two-part series focuses on supervised learning tasks and the process of selecting, transforming, and augmenting the source data to create powerful predictive signals to the target variable. These operations combine domain knowledge with data science techniques. The operations are the essence of feature engineering .
The size of training datasets for real-world ML models can easily be equal to or greater than one terabyte (TB). Therefore, you need large-scale data processing frameworks in order to process these datasets efficiently and distributedly. When you use an ML model to make predictions, you have to apply the same transformations that you used for the training data on the new data points. By applying the same transformations, you present the live dataset to the ML model the way that the model expects.
This document discusses these challenges for different levels of granularity of feature engineering operations: instance-level, full-pass, and time-window aggregations. This document also describes the options and scenarios to perform data transformation for ML on Google Cloud.
This document also provides an overview of TensorFlow Transform ( tf.Transform ), a library for TensorFlow that lets you define both instance-level and full-pass data transformation through data preprocessing pipelines. These pipelines are executed with Apache Beam , and they create artifacts that let you apply the same transformations during prediction as when the model is served.
Preprocessing data for ML
This section introduces data preprocessing operations and stages of data readiness. It also discusses the types of the preprocessing operations and their granularity.
Data engineering compared to feature engineering
Preprocessing the data for ML involves both data engineering and feature engineering. Data engineering is the process of converting raw data into prepared data . Feature engineering then tunes the prepared data to create the features that are expected by the ML model. These terms have the following meanings:
- Raw data (or just data )
- The data in its source form, without any prior preparation for ML. In this context, the data might be in its raw form (in a data lake) or in a transformed form (in a data warehouse). Transformed data that's in a data warehouse might have been converted from its original raw form to be used for analytics. However, in this context, raw data means that the data hasn't been prepared specifically for your ML task. Data is also considered raw data if it's sent from streaming systems that eventually call ML models for predictions.
- Prepared data
- The dataset in the form ready for your ML task: data sources have been parsed, joined, and put into a tabular form. Prepared data is aggregated and summarized to the right granularity—for example, each row in the dataset represents a unique customer, and each column represents summary information for the customer, like the total spent in the last six weeks. In a prepared data table, irrelevant columns have been dropped, and invalid records have been filtered out. For supervised learning tasks, the target feature is present.
- Engineered features
- The dataset with the tuned features that are expected by the model—that is, features that are created by performing certain ML-specific operations on the columns in the prepared dataset, and creating new features for your model during training and prediction, as described later in Preprocessing operations . Examples of these operations include scaling numerical columns to a value between 0 and 1, clipping values, and one-hot-encoding categorical features.
The following diagram, figure 1, shows the steps that are involved in preparing preprocessed data:
In practice, data from the same source is often at different stages of readiness. For example, a field from a table in your data warehouse might be used directly as an engineered feature. At the same time, another field in the same table might need to go through transformations before it becomes an engineered feature. Similarly, data engineering and feature engineering operations might be combined in the same data preprocessing step.
Preprocessing operations
Data preprocessing includes several operations. Each operation is designed to help ML build better predictive models. The details of these preprocessing operations are outside the scope of this document, but some operations are briefly described in this section.
For structured data, data preprocessing operations include the following:
- Data cleansing: removing or correcting records that have corrupted or invalid values from raw data, and removing records that are missing a large number of columns.
- Instances selection and partitioning: selecting data points from the input dataset to create training, evaluation (validation), and test sets . This process includes techniques for repeatable random sampling, minority classes oversampling, and stratified partitioning.
- Feature tuning: improving the quality of a feature for ML, which includes scaling and normalizing numeric values, imputing missing values, clipping outliers, and adjusting values that have skewed distributions.
- Feature transformation: converting a numeric feature to a categorical feature (through bucketization ), and converting categorical features to a numeric representation (through one-hot encoding, learning with counts , sparse feature embeddings, etc.). Some models work only with numeric or categorical features, while others can handle mixed type features. Even when models handle both types, they can benefit from different representations (numeric and categorical) of the same feature.
- Feature extraction: reducing the number of features by creating lower-dimension, more powerful data representations using techniques such as PCA , embedding extraction, and hashing .
- Feature selection: selecting a subset of the input features for training the model, and ignoring the irrelevant or redundant ones, using filter or wrapper methods . Feature selection can also involve simply dropping features if the features are missing a large number of values.
- Feature construction: creating new features by using typical techniques, such as polynomial expansion (by using univariate mathematical functions) or feature crossing (to capture feature interactions). Features can also be constructed by using business logic from the domain of the ML use case.
When you work with unstructured data (for example, images, audio, or text documents), deep learning replaces domain-knowledge-based feature engineering by folding it into the model architecture. A convolutional layer is an automatic feature preprocessor. Constructing the right model architecture requires some empirical knowledge of the data. In addition, some amount of preprocessing is needed, such as the following:
- For text documents: stemming and lemmatization , TF-IDF calculation, and n-gram extraction, embedding lookup.
- For images: clipping, resizing, cropping, Gaussian blur, and canary filters.
- For all types of data (including text and images): transfer learning , which treats all-but-last layers of the fully trained model as a feature engineering step.
Preprocessing granularity
This section discusses the granularity of types of data transformations. It shows why this perspective is critical when preparing new data points for predictions using transformations that are applied on training data.
Preprocessing and transformation operations can be categorized as follows, based on operation granularity:
Instance-level transformations during training and prediction . These are straightforward transformations, where only values from the same instance are needed for the transformation. For example, instance-level transformations might include clipping the value of a feature to some threshold, polynomially expanding another feature, multiplying two features, or comparing two features to create a Boolean flag.
These transformations must be applied identically during training and prediction, because the model will be trained on the transformed features, not on the raw input values. If the data isn't transformed identically, then the model behaves poorly because it is presented with data that has a distribution of values that it wasn't trained with. For more information, see the discussion of training-serving skew in the Preprocessing challenges section.
Full-pass transformations during training, but instance-level transformations during prediction . In this scenario, transformations are stateful, because they use some precomputed statistics to perform the transformation. During training, you analyze the whole body of training data to compute quantities such as minimum, maximum, mean, and variance for transforming training data, evaluation data, and new data at prediction time.
For example, to normalize a numeric feature for training, you compute its mean (μ) and its standard deviation (σ) across the whole of the training data. This computation is called a full-pass (or analyze ) operation. When you serve the model for prediction, the value of a new data point is normalized to avoid training-serving skew. Therefore, μ and σ values that are computed during training are used to adjust the feature value, which is the following simple instance-level operation:
$$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$Full-pass transformations include the following:
- MinMax scaling numerical features using min and max computed from the training dataset.
- Standard scaling (z-score normalization) numerical features using μ and σ computed on the training dataset.
- Bucketizing numerical features using quantiles.
- Imputing missing values using the median (numerical features) or the mode (categorical features).
- Converting strings (nominal values) to integers (indexes) by extracting all the distinct values (vocabulary) of an input categorical feature.
- Counting the occurrence of a term (feature value) in all the documents (instances) to calculate for TF-IDF.
- Computing the PCA of the input features to project the data into a lower dimensional space (with linearly dependent features).
You should use only the training data to compute statistics like μ, σ, min , and max . If you add the test and evaluation data for these operations, you are leaking information from the evaluation and test data to train the model. Doing so affects the reliability of the test and evaluation results. To ensure that you apply a consistent transformation to all datasets, you use the same statistics computed from the training data to transform the test and evaluation data.
Historical aggregations during training and prediction . This involves creating business aggregations, derivations, and flags as input signals to the prediction task—for example, creating recency, frequency, and monetary (RFM) metrics for customers to build propensity models. These types of features can be precomputed and stored in a feature store to be used during model training, batch scoring, and online prediction serving. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.
Historical aggregations during training, but real-time aggregations during prediction . This approach involves creating a feature by summarizing real-time values over time. In this approach, the instances to be aggregated are defined through temporal window clauses. For example, you can use this approach if you want to train a model that estimates the taxi trip time based on the traffic metrics for the route in the last 5 minutes, in the last 10 minutes, in the last 30 minutes, and at other intervals. You can also use this approach to predict the failure of an engine part based on the moving average of temperature and vibration values computed over the last 3 minutes. Although these aggregations can be prepared offline for training, they are computed in real time from a data stream during serving.
More precisely, when you prepare training data, if the aggregated value isn't in the raw data, the value is created during the data engineering phase. The raw data is usually stored in a database with a format of
(entity, timestamp, value). In the previous examples,entityis the route segment identifier for the taxi routes and the engine part identifier for the engine failure. You can use windowing operations to compute(entity, time_index, aggregated_value_over_time_window)and use the aggregation features as an input for your model training.When the model for real-time (online) prediction is served, the model expects features derived from the aggregated values as an input. Therefore, you can use a stream-processing technology like Apache Beam to compute the aggregations from the real-time data points streamed into your system. Stream-processing technology aggregates real-time data based on time windows as new data points arrive. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.
ML pipeline on Google Cloud
This section discusses the core components of a typical end-to-end pipeline to train and serve TensorFlow ML models on Google Cloud using managed services. It also discusses where you can implement different categories of the data preprocessing operations, and common challenges that you might face when you implement such transformations. The How tf.Transform works section shows how the TensorFlow Transform library helps to address these challenges.
High-level architecture
The following diagram, figure 2, shows a high-level architecture of a typical ML pipeline for training and serving TensorFlow models. The labels A, B, and C in the diagram refer to the different places in the pipeline where data preprocessing can take place. Details about these steps are provided in the following section.
The pipeline consists of the following steps:
- After raw data is imported, tabular data is stored in BigQuery, and other data like images, audio, and video, is stored in Cloud Storage. The second part of this series uses tabular data stored in BigQuery as an example.
- Data engineering (preparation) and feature engineering are executed at scale using Dataflow. This execution produces ML-ready training, evaluation, and test sets that are stored in Cloud Storage. Ideally, these datasets are stored as TFRecord files, which is the optimized format for TensorFlow computations.
- A TensorFlow model trainer package is submitted to Vertex AI Training, which uses the preprocessed data from the previous steps to train the model. The output of this step is a trained TensorFlow SavedModel that is exported to Cloud Storage.
- The trained TensorFlow model is deployed to Vertex AI Prediction as a service that has a REST API so that it can be used for online predictions. The same model can also be used for batch prediction jobs.
- After the model is deployed as a REST API, client apps and internal systems can invoke the API by sending requests with some data points, and receiving responses from the model with predictions.
- For orchestrating and automating this pipeline, you can use Vertex AI Pipelines as a scheduler to invoke the data preparation, model training, and model deployment steps.
You can also use Vertex AI Feature Store to store input features to make predictions. For example, you can periodically create engineered features from the latest raw data and store them in Vertex AI Feature Store. Client apps fetch the required input features from Vertex AI Feature Store and send them to the model to receive predictions.
Where to do preprocessing
In figure 2, the labels A, B, and C show that data preprocessing operations can take place in BigQuery, Dataflow, or TensorFlow. The following sections describe how each of these options work.
Option A: BigQuery
Typically, logic is implemented in BigQuery for the following operations:
- Sampling: randomly selecting a subset from the data.
- Filtering: removing irrelevant or invalid instances.
- Partitioning: splitting the data to produce training, evaluation, and test sets.
BigQuery SQL scripts can be used as a source query for the Dataflow preprocessing pipeline, which is the data processing step in figure 2. For example, if a system is used in Canada, and the data warehouse has transactions from around the world, filtering to get Canada-only training data is best done in BigQuery. Feature engineering in BigQuery is simple and scalable, and supports implementing instance-level and historical aggregations feature transformations.
However, we recommend that you use BigQuery for feature engineering only if you use your model for batch prediction (scoring), or if the features are precomputed in BigQuery, but stored in Vertex AI Feature Store to be used during online prediction. If you plan to deploy the model for online predictions, and if you don't have the engineered feature in an online feature store, you have to replicate the SQL preprocessing operations to transform the raw data points that other systems generate. In other words, you need to implement the logic twice: one time in SQL to preprocess training data in BigQuery, and a second time in the logic of the app that consumes the model to preprocess online data points for prediction.
For example, if your client app is written in Java, you need to reimplement the logic in Java. This can introduce errors due to implementation discrepancies, as described in the training-serving skew section of Preprocessing challenges later in this document. It's also extra overhead to maintain two different implementations. Whenever you change the logic in SQL to preprocess the training data, you need to change the Java implementation accordingly to preprocess data at serving time.
If you are using your model only for batch prediction (for example, using Vertex AI batch prediction ), and if your data for scoring is sourced from BigQuery, you can implement these preprocessing operations as part of the BigQuery SQL script. In that case, you can use the same preprocessing SQL script to prepare both training and scoring data.
Full-pass stateful transformations aren't suitable for implementation in BigQuery. If you use BigQuery for full-pass transformations, you need auxiliary tables to store quantities needed by stateful transformations, such as means and variances to scale numerical features. Further, implementation of full-pass transformations using SQL on BigQuery creates increased complexity in the SQL scripts, and creates intricate dependency between training and the scoring SQL scripts.
Option B: Dataflow
As shown in figure 2, you can implement computationally expensive preprocessing operations in Apache Beam, and run them at scale using Dataflow. Dataflow is a fully managed autoscaling service for batch and stream data processing. When you use Dataflow, you can also use external specialized libraries for data processing, unlike BigQuery.
Dataflow can perform instance-level transformations, and historical and real-time aggregation feature transformations. In particular, if your ML models expect an input feature like total_number_of_clicks_last_90sec , Apache Beam windowing functions can compute these features based on aggregating the values of time windows of real-time (streaming) events data (for example, click events). In the earlier discussion of granularity of transformations , this was referred to as "Historical aggregations during training, but real-time aggregations during prediction."
The following diagram, figure 3, shows the role of Dataflow in processing stream data for near real-time predictions.
As shown in figure 3, during processing, events called data points are ingested into Pub/Sub . Dataflow consumes these data points, computes features based on aggregates over time, and then calls the deployed ML model API for predictions. Predictions are then sent to an outbound Pub/Sub queue. From Pub/Sub, predictions can be consumed by downstream systems like monitoring or control, or they can be pushed back (for example, as notifications) to the original requesting client. Predictions can also be stored in a low-latency data store like Cloud Bigtable for real-time fetching. Cloud Bigtable can also be used to accumulate and store these real-time aggregations so they can be looked up when needed for prediction.
The same Apache Beam implementation can be used to batch-process training data that comes from an offline datastore like BigQuery and stream-process real-time data for serving online predictions.
In other typical architectures, such as the architecture shown in figure 2, the client app directly calls the deployed model API for online predictions. In that case, if preprocessing operations are implemented in Dataflow to prepare the training data, the operations aren't applied to the prediction data that goes directly to the model. Therefore, transformations like these should be integrated in the model during serving for online predictions.
Dataflow can be used to perform full-pass transformation, by computing the required statistics at scale. However, these statistics need to be stored somewhere to be used during prediction to transform prediction data points. By using the TensorFlow Transform ( tf.Transform ) library, you can directly embed these statistics in the model instead of storing them elsewhere. This approach is explained later in How tf.Transform works .
Option C: TensorFlow
As shown in figure 2, you can implement data preprocessing and transformation operations in the TensorFlow model itself. As shown in the figure, the preprocessing that you implement for training the TensorFlow model becomes an integral part of the model when the model is exported and deployed for predictions. Transformations in the TensorFlow model can be accomplished in one of the following ways:
- Implementing all of the instance-level transformation logic in the
input_fnfunction and in theserving_fnfunction. Theinput_fnfunction prepares a dataset using thetf.data.DatasetAPI for training a model. Theserving_fnfunction receives and prepares the data for predictions. - Putting the transformation code directly in your TensorFlow model by using Keras preprocessing layers or creating custom layers .
The transformation logic code in the serving_fn function defines the serving interface of your SavedModel for online prediction. If you implement the same transformations that were used for preparing training data in the transformation logic code of the serving_fn function, it ensures that the same transformations are applied to new prediction data points when they're served.
However, because the TensorFlow model processes each data point independently or in a small batch, you can't calculate aggregations from all data points. As a result, full-pass transformations can't be implemented in your TensorFlow model.
Preprocessing challenges
The following are the primary challenges of implementing data preprocessing:
Training-serving skew . Training-serving skew refers to a difference between effectiveness (predictive performance) during training and during serving. This skew can be caused by a discrepancy between how you handle data in the training and the serving pipelines. For example, if your model is trained on a logarithmically transformed feature, but it's presented with the raw feature during serving, the prediction output might not be accurate.
If the transformations become part of the model itself, it can be straightforward to handle instance-level transformations, as described earlier in Option C: TensorFlow . In that case, the model serving interface (the
serving_fnfunction) expects raw data, while the model internally transforms this data before computing the output. The transformations are the same as those that were applied on the raw training and prediction data points.Full-pass transformations . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example,
maxandminvalues to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform (tf.Transform) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. In addition, if you're using accelerators (GPUs or TPUs), they sit idle while the CPU performs those transformations, which isn't an efficient use of your costly accelerators.
Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.
Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform (
tf.Transform) library can help you to address this issue, as described in the following section.
How tf.Transform works
The tf.Transform library is useful for transformations that require a full pass. The output of the tf.Transform library is exported as a TensorFlow graph that represents the instance-level transformation logic and the statistics computed from full-pass transformations, to be used for training and serving. Using the same graph for both training and serving can prevent skew, because the same transformations are applied in both stages. In addition, the tf.Transform library can run at scale in a batch processing pipeline on Dataflow to prepare the training data up front and improve training efficiency.
The following diagram, figure 4, shows how the tf.Transform library preprocesses and transforms data for training and prediction. The process is described in the following sections.
tf.Transform for preprocessing and transforming data. Transform training and evaluation data
You preprocess the raw training data using the transformation implemented in the tf.Transform Apache Beam APIs, and run it at scale on Dataflow. The preprocessing occurs in the following phases:
- Analyze phase: During the analyze phase, the required statistics (like means, variances, and quantiles) for stateful transformations are computed on the training data with full-pass operations. This phase produces a set of transformation artifacts, including the
transform_fngraph. Thetransform_fngraph is a TensorFlow graph that has the transformation logic as instance-level operations. It includes the statistics computed in the analyze phase as constants. - Transform phase: During the transform phase, the
transform_fngraph is applied to the raw training data, where the computed statistics are used to process the data records (for example, to scale numerical columns) in an instance-level fashion.
A two-phase approach like this addresses the preprocessing challenge of performing full-pass transformations.
When the evaluation data is preprocessed, only instance-level operations are applied, using the logic in the transform_fn graph and the statistics computed from the analyze phase in the training data. In other words, you don't analyze the evaluation data in a full-pass fashion to compute new statistics, such as μ and σ, to normalize numeric features in evaluation data. Instead, you use the computed statistics from the training data to transform the evaluation data in an instance-level fashion.
The transformed training and evaluation data are prepared at scale using Dataflow, before they are used to train the model. This batch data-preparation process addresses the preprocessing challenge of preparing the data up front to improve training efficiency. As shown in figure 4, the model internal interface expects transformed features.
Attach transformations to the exported model
As noted, the transform_fn graph that's produced by the tf.Transform pipeline is stored as an exported TensorFlow graph. The exported graph consists of the transformation logic as instance-level operations, and all of the statistics computed in the full-pass transformations as graph constants. When the trained model is exported for serving, the transform_fn graph is attached to the SavedModel as part of its serving_fn function.
While it's serving the model for prediction, the model serving interface expects data points in the raw format (that is, before any transformations). However, the model internal interface expects the data in the transformed format.
The transform_fn graph, which is now part of the model, applies all the preprocessing logic on the incoming data point. It uses the stored constants (like μ and σ to normalize the numeric features) in the instance-level operation during prediction. Therefore, the transform_fn graph converts the raw data point into the transformed format. The transformed format is what is expected by the model internal interface in order to produce prediction, as shown in figure 4.
This mechanism resolves the preprocessing challenge of the training-serving skew, because the same logic (implementation) that is used to transform the training and evaluation data is applied to transform the new data points during prediction serving.
Preprocessing options summary
The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."
| Data preprocessing option | Instance-level (stateless transformations) | Full-pass during training and instance-level during serving (stateful transformations) | Real-time (window) aggregations during training and serving (streaming transformations) |
|---|---|---|---|
BigQuery (SQL) | Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools. | Batch scoring: Not recommended . Online prediction: Not recommended . Although you can use statistics computed using BigQuery for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction. | Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools. |
Dataflow (Apache Beam) | Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: OK —if data at serving time comes from Pub/Sub to be consumed by Dataflow. Otherwise, results in training-serving skew. | Batch scoring: Not recommended . Online predictions: Not recommended . Although you can use statistics computed using Dataflow for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction. | Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream). |
Dataflow (Apache Beam + TFT) | Batch scoring: OK —the same transformation implementation is applied to data during training and batch scoring. Online prediction: Recommended —it avoids training-serving skew and prepares training data up front. | Batch scoring: Recommended . Online prediction: Recommended . Both uses are recommended because transformation logic and computed statistics during training are stored as a TensorFlow graph that's attached to the exported model for serving. | Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream). |
TensorFlow * | Batch scoring: Not recommended . Online prediction: Not recommended . For training efficiency in both cases, it's better to prepare the training data up front. | Batch scoring: Not Possible . Online prediction: Not Possible . | Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not Possible . |
* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.
What's next
- To implement a
tf.Transformpipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform . - Take the Coursera specialization on ML with TensorFlow on Google Cloud .
- Learn about best practices for ML engineering in Rules of ML .
- For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .