Để tăng hiệu quả marketing, các công ty thương mại điện tử có thể áp dụng Machine Learning (học máy) nhằm tối ưu hoá việc hiển thị quảng cáo cho khách hàng.

Có hai phương án phổ biến là xây dựng mô hình tổng quát hoặc mô hình đặc thù, đều sử dụng Supervised Machine Learning để hiểu về khách hàng qua lịch sử dữ liệu. Tuy nhiên, những mô hình kiểu này không thể cung cấp cho ta một phương án tổng thể để tối ưu hoá chiến dịch marketing đa kênh. Hơn nữa, nếu chỉ hiển thị lặp đi lặp lại một mẩu quảng cáo được cho là tốt nhất, khách hàng có thể sẽ thấy nhàm chán, dẫn tới làm giảm hiệu quả của chiến dịch.

Để giải quyết các vấn đề này, công ty Wayfair đã phát triển một nền tảng Machine Learning đa tầng. Nhiệm vụ của hệ thống này là tối ưu hoá các reward gộp từ nhiều chiến dịch marketing. Ví dụ: nền tảng Paid Media ML (WayLift) sử dụng Reinforcement Learning để cân bằng giữa việc khai thác mẩu quảng cáo tốt nhất với việc thử nghiệm các mẩu quảng cáo thay thế.

Nền tảng Machine Learning của Wayfair được cấu thành bởi ba tầng:

Mời các bạn đọc bài viết gốc để có thêm thông tin chi tiết cùng hình ảnh minh họa.

Theo thống kê, Twitter cần xử lý khoảng 400 tỷ event trong thời gian thực và tạo ra dữ liệu có quy mô lên tới hàng petabyte (PB) mỗi ngày. Vì vậy các bài toán về dữ liệu ở đây rất đa dạng, tiêu biểu như xử lý dữ liệu, lưu trữ và sử dụng dữ liệu.

Một trong những bài toán khó mà Twitter đang giải quyết là việc làm sao để thu thập thông tin chi tiết kịp thời, có ý nghĩa. Vấn đề này phát sinh khi các kỹ sư và analyst ở Twitter liên tục phải xử lý từ backroom mỗi khi có yêu cầu dữ liệu cần sử dụng.

Để giải quyết vấn đề này, đội ngũ kỹ sư Twitter đã xây dựng một sản phẩm nội bộ có tên Qurious, cho phép nhân viên trong công ty truy vấn bằng ngôn ngữ tự nhiên (tiếng Anh). Ngay sau đó, họ sẽ nhận được câu trả lời với thông tin chi tiết trong thời gian thực mà không cần tạo bất kỳ một trang dashboard hay report nào cả. Dự án này bao gồm ứng dụng web và chatbot Slack, cả hai đều được tích hợp với các API BigQuery và Data QnA. Công cụ này thực sự “dân chủ hóa” quyền truy cập dữ liệu cho tất cả người dùng trong công ty, bất kể mức độ hiểu biết về dữ liệu của họ.

Dự án này ở Twitter có thể là tương lai của một thế giới “No-SQL”. Để đọc chi tiết, các bạn có thể truy cập đường dẫn sau.

Uber là một nhà cung cấp dịch vụ vận chuyển phạm vi toàn cầu. Theo thời gian, họ có hơn 100 petabyte dữ liệu phân tích cần được lưu trữ và cung cấp thông qua nền tảng dữ liệu lớn (big data) dựa trên Apache Hadoop. Bài viết này mô tả lại hành trình xây dựng nền tảng Hadoop của Uber và thảo luận về những gì đang được xây dựng tiếp theo để mở rộng hệ sinh thái phức tạp và phong phú này.

Giai đoạn 1: Sự khởi đầu của dữ liệu lớn tại Uber

Trước năm 2014, dữ liệu của họ được lưu trữ trong các cơ sở dữ liệu truyền thống (MySQL và PostgreSQL). Để sử dụng các cơ sở dữ liệu này, các kỹ sư phải truy cập từng cơ sở dữ liệu hoặc bảng một cách độc lập và viết mã của riêng nếu họ cần kết hợp dữ liệu từ các cơ sở dữ liệu khác nhau. Vào thời điểm đó, họ chưa có một cơ sở dữ liệu tập trung để phục vụ cho việc phân tích tất cả dữ liệu được lưu trữ của mình. Trên thực tế, dữ liệu của họ nằm rải rác trên các cơ sở dữ liệu OLTP khác nhau, tổng kích thước dữ liệu khoảng vài terabyte và độ trễ để truy cập dữ liệu này là rất cao (thường là vài phút).

Do việc kinh doanh của Uber phát triển nhanh chóng, lượng dữ liệu cũng tăng lên đặt ra yêu cầu cho họ phải xây dựng một kho dữ liệu tập trung. Điều này cũng giúp hình thành thế hệ đầu tiên của kho dữ liệu lớn tại Uber.

Kho dữ liệu này tập trung vào việc tổng hợp tất cả dữ liệu của Uber vào một nơi cũng như hợp lý hóa việc truy cập dữ liệu. Họ quyết định sử dụng Vertica làm phần mềm quản lý dữ liệu của mình do các ưu điểm như thiết kế lưu trữ dữ liệu dạng cột, khả năng mở rộng và tốc độ nhanh.

Giai đoạn 2: Sự xuất hiện của Hadoop

Thế hệ đầu tiên có một số hạn chế đó là dữ liệu thiếu sự nhất quán và khả năng mở rộng còn hạn chế. Để giải quyết những hạn chế này, họ đã tái cấu trúc nền tảng dữ liệu lớn của mình xung quanh hệ sinh thái Hadoop. Cụ thể hơn, họ đã xây dựng một kho dữ liệu Hadoop nơi tất cả dữ liệu thô được trích xuất từ các kho dữ liệu trực tuyến khác nhau một lần duy nhất và không có biến đổi trong quá trình trích xuất.

Để truy cập dữ liệu trong Hadoop, họ sử dụng Presto cho các truy vấn trực tiếp, Apache Spark để hỗ trợ truy cập vào dữ liệu thô (ở cả định dạng SQL và không phải SQL) và Apache Hive để phục vụ cho các truy vấn lớn. Họ cũng tận dụng định dạng File dạng cột tiêu chuẩn của Apache Parquet để giảm dung lượng lưu trữ nhờ tỷ lệ nén được cải thiện.

Giai đoạn 3: Xây dựng lại nền tảng dữ liệu lớn cho mục tiêu dài hạn

Vào đầu năm 2017, nền tảng dữ liệu lớn của họ đã được các team trong toàn công ty sử dụng. Người dùng có thể dễ dàng truy cập dữ liệu trong Hive, Presto, Spark, Vertica, Notebook, … thông qua một cổng giao diện người dùng duy nhất. Với hơn 100 petabyte dữ liệu trong HDFS, 100.000 vcores trong cụm máy chủ, 100.000 truy vấn Presto mỗi ngày, 10.000 công việc Spark mỗi ngày và 20.000 truy vấn Hive mỗi ngày, kiến trúc Hadoop của họ bắt đầu đạt mức giới hạn về khả năng mở rộng và nhiều dịch vụ bắt đầu bị ảnh hưởng bởi độ trễ dữ liệu.

Uber đã bắt đầu nghiên cứu để xây dựng thế hệ kho dữ liệu lớn tiếp theo. Họ tập trung vào bốn yêu cầu sau:

Dựa vào 4 yêu cầu nêu trên, họ đã xây dựng Hudi, một thư viện mã nguồn mở của Spark. Hudi được xây dựng dựa trên HDFS và Parquet để hỗ trợ cho thao tác cập nhật và xóa. Sử dụng thư viện Hudi đã cho phép họ giảm độ trễ truy xuất dữ liệu từ 24 giờ xuống dưới một giờ.

Bài viết còn trình bày những mục tiêu đặt ra để xây dựng thế hệ dữ liệu thứ 4 tiếp theo của Uber. Mời các bạn đọc bài viết gốc để tìm hiểu sâu hơn về nội dung này.

Bạn nghĩ khả năng giải quyết vấn đề của bạn tốt đến đâu? Làm sao bạn đo được chuyện đó?

Giải quyết vấn đề (Problem Solving) là một trong những kỹ năng hàng đầu mà bất kỳ kĩ sư nào cũng cần, và hầu như nhà tuyển dụng nào cũng ghi trong JD của họ. Tuy nhiên khi đi sâu vào, thì ta có thể thấy có những câu hỏi mà ít có câu trả lời hơn: Làm sao đánh giá problem solving skills? Đâu là những phương pháp quy củ để tiếp cận vấn đề?

Đến với Grokking Techtalk #44: Problem Solving lần này, bạn sẽ được giới thiệu một cách bài bản về tư duy giải quyết vấn đề cho software engineers!

Nội dung bài talk:

Ngôn ngữ: Tiếng Việt

Speaker:

Thông tin sự kiện:

Lưu ý: