Vấn đề kỹ thuật

Trong ngành du lịch, phản hồi tìm kiếm kéo dài hai giây không chỉ là vấn đề trải nghiệm người dùng, mà còn là vấn đề doanh thu. Mỗi giây trễ bổ sung làm giảm tỷ lệ chuyển đổi theo những con số có thể đo lường được. Đặc biệt trong lĩnh vực du lịch, nơi tỷ lệ bỏ phiên cao và các lựa chọn thay thế chỉ cách một cú nhấp chuột, chi phí này tăng lên nhanh chóng. Vấn đề trở nên nghiêm trọng không phải khi ra mắt mà là khi mở rộng quy mô: các nền tảng hoạt động tốt với 100.000 danh mục bắt đầu gặp khó khăn ở mức một triệu, và các quyết định kiến trúc từng được chấp nhận ban đầu trở thành những giới hạn định hình năng lực tối đa của hệ thống.

Hai chế độ lỗi thường xuất hiện cùng lúc. Thứ nhất, phản hồi về tình trạng sẵn có bị lỗi thời khi đến tay người dùng, hiển thị kho hàng đã được đặt 30 giây trước. Thứ hai, các bộ lọc phân loại đếm dựa trên toàn bộ danh mục thay vì chỉ các kết quả thực sự có sẵn, dẫn người mua vào ngõ cụt. Cả hai đều không phải là vấn đề chất lượng dữ liệu. Cả hai đều là vấn đề kiến trúc.

Kiến trúc tìm kiếm

Xương sống của hệ thống tìm kiếm du lịch cấp độ sản xuất là một công cụ tìm kiếm chuyên dụng, không phải là cơ sở dữ liệu quan hệ với các chỉ mục bổ sung. Elasticsearch và OpenSearch là những lựa chọn tiêu chuẩn, nhưng việc lựa chọn công cụ ít quan trọng hơn thiết kế chỉ mục được xây dựng trên chúng. Đối với kho hàng du lịch, một chỉ mục được thiết kế tốt sẽ mã hóa các tài liệu đa thuộc tính bao gồm vị trí, khoảng ngày, sức chứa, các cấp giá, bộ tiện nghi, xếp hạng và các khoảng thời gian khả dụng trong một cấu trúc hỗ trợ các mẫu truy vấn cụ thể của nền tảng. Sự khác biệt giữa một thiết kế chỉ mục tốt và một thiết kế trung bình trở nên rõ ràng ở mức một triệu danh mục và trở nên quan trọng ở mức mười lăm triệu. Việc lựa chọn trường, cấu hình bộ phân tích và chiến lược phân mảnh sẽ quyết định liệu độ trễ P99 dưới 500ms có thể đạt được dưới tải cao điểm hay không.

Khử trùng lặp tài sản và khớp hồ sơ

Một trong những vấn đề kỹ thuật bị đánh giá thấp nhất trong tìm kiếm du lịch là khử trùng lặp: cùng một khách sạn, biệt thự hoặc tài sản xuất hiện nhiều lần trong kết quả tìm kiếm vì nó đến từ các nhà cung cấp khác nhau với các định danh, tên gọi và mô hình dữ liệu khác nhau.

Một tài sản duy nhất có thể xuất hiện trong kho hàng của một nền tảng từ nhiều nguồn khác nhau như quản lý kênh OTA, API khách sạn trực tiếp, nguồn cấp dữ liệu GDS và ngân hàng giường. Mỗi nguồn này lại mang một ID tài sản khác nhau, một địa chỉ hơi khác và một tên có thể không khớp chính xác. Nếu không có lớp khử trùng lặp, người dùng sẽ thấy cùng một tài sản được liệt kê bốn lần với bốn mức giá, mà không có dấu hiệu nào cho thấy họ đang xem cùng một phòng. Điều này dẫn đến giảm tỷ lệ chuyển đổi, giảm niềm tin của nhà cung cấp và khiến nền tảng trông không đáng tin cậy.

Giải pháp tham chiếu tiêu chuẩn trong ngành cho vấn đề này là GIATA - một công ty của Đức duy trì cơ sở dữ liệu tài sản chính bao gồm hơn 750.000 tài sản khách sạn trên toàn thế giới, mỗi tài sản được gán một ID GIATA duy nhất tồn tại trên các kênh phân phối. Việc ánh xạ kho hàng của nhà cung cấp đến các ID GIATA cho phép một nền tảng giải quyết cùng một tài sản trên các nguồn cấp dữ liệu khác nhau thành một bản ghi chuẩn duy nhất, sau đó hiển thị nhiều mức giá của nhà cung cấp đối với bản ghi đó thay vì hiển thị các bản sao. Gradion xây dựng tích hợp GIATA và quy trình khử trùng lặp để chuẩn hóa kho hàng đến thành một biểu đồ tài sản rõ ràng. Quy trình này bao gồm: tạo bản ghi chuẩn, hợp nhất thuộc tính từ nhiều nguồn, giải quyết xung đột khi các nhà cung cấp không đồng ý về số lượng phòng hoặc dữ liệu tiện nghi, và truyền tải cập nhật chỉ mục xuống khi bản ghi chính thay đổi.

Đối với các nền tảng không thể sử dụng GIATA - do chi phí cấp phép hoặc vì loại kho hàng (tài sản cho thuê, biệt thự riêng, địa điểm hoạt động) không được cơ sở dữ liệu này bao phủ tốt - Gradion xây dựng các quy trình khớp xác suất. Các quy trình này nhóm các ứng viên trùng lặp bằng cách sử dụng sự tương đồng về tên, sự gần gũi về tọa độ địa lý và sự trùng lặp thuộc tính, kèm theo một lớp chấm điểm độ tin cậy và một hàng đợi xem xét thủ công cho các kết quả khớp có độ tin cậy thấp. Thách thức kỹ thuật ở đây là khả năng thu hồi: bỏ sót một bản sao thường tệ hơn một kết quả dương tính giả trong hầu hết các trường hợp, bởi vì người dùng sẽ tìm thấy nó và ít tin tưởng nền tảng hơn.

Tình trạng sẵn có theo thời gian thực

Trạng thái tồn kho trong ngành du lịch luôn biến động. Các đặt chỗ diễn ra đồng thời, thời gian giữ chỗ hết hạn, và nguồn cấp dữ liệu từ đối tác cập nhật không đồng bộ. Vấn đề kiến trúc cốt lõi không phải là có nên phản ánh trạng thái thời gian thực hay không, mà là làm thế nào để thực hiện điều đó mà không biến mỗi truy vấn tìm kiếm thành một lệnh gọi đồng bộ gây chậm trễ cho hệ thống bên ngoài.

Đối với các nền tảng lớn, giải pháp thực tế là một mô hình lai: lớp tìm kiếm hoạt động dựa trên chỉ mục khả dụng được duy trì, cập nhật thông qua các luồng sự kiện khi đặt chỗ, hủy bỏ và hết hạn giữ chỗ; trong khi quy trình thanh toán thực hiện kiểm tra xác nhận trực tiếp trước khi hoàn tất đặt chỗ. HomeToGo điều phối khả dụng trên hơn 100 API đối tác và hơn 15 triệu danh sách trên 25 thị trường. Thách thức kỹ thuật nằm ở việc đồng bộ hóa trạng thái từ các nguồn không đồng nhất - mỗi nguồn có tần suất cập nhật, định dạng dữ liệu và đặc điểm độ tin cậy riêng - thành một mô hình nội bộ nhất quán mà các truy vấn tìm kiếm có thể tin cậy. Lớp tích hợp chuẩn hóa dữ liệu này đòi hỏi nỗ lực kỹ thuật không kém gì chính công cụ tìm kiếm.

Chiến lược bộ nhớ đệm

Không phải mọi dữ liệu trong phản hồi tìm kiếm du lịch đều có cùng mức độ biến động. Các thuộc tính tĩnh, danh sách tiện nghi, dữ liệu vị trí và các mẫu giá lịch sử có thể được lưu vào bộ nhớ đệm với thời gian tồn tại (TTL) hợp lý. Tuy nhiên, khả năng khả dụng theo thời gian thực thì không thể. Việc xác định sai ranh giới này sẽ gây ra vấn đề theo cả hai hướng: lưu bộ nhớ đệm quá mức sẽ hiển thị tồn kho không khả dụng và làm mất lòng tin; trong khi lưu bộ nhớ đệm không đủ sẽ làm giảm độ trễ tìm kiếm. Việc vô hiệu hóa bộ nhớ đệm khi có sự kiện đặt chỗ là bắt buộc đối với bất kỳ tồn kho nào đang được giữ hoặc đã xác nhận. Thiết kế về những gì được lưu trong bộ nhớ đệm, với TTL nào và yếu tố nào kích hoạt việc vô hiệu hóa không phải là một chi tiết nhỏ - đó là một ràng buộc về tính đúng đắn của hệ thống.

Tìm kiếm theo khía cạnh và lọc

Các bộ lọc theo khía cạnh (faceted filters) cần phản ánh chính xác tồn kho khả dụng tại thời điểm truy vấn. Điều này đòi hỏi tổng hợp dữ liệu trên tập kết quả đã lọc, thay vì toàn bộ danh mục, để đưa ra số lượng tương ứng với những gì người dùng thực sự có thể đặt. Để đạt được điều này mà không cần quét toàn bộ bảng, cần sử dụng cẩn thận các khả năng tổng hợp của công cụ tìm kiếm và, trong trường hợp độ chính xác của số lượng ít quan trọng hơn tốc độ, có thể áp dụng các kỹ thuật gần đúng. Các khía cạnh động - nơi các phạm vi giá trị và số lượng cập nhật khi các bộ lọc được áp dụng - đặt ra yêu cầu bổ sung về cấu trúc truy vấn và độ trễ. Các yêu cầu lọc chuyên biệt đòi hỏi đầu tư bổ sung vào lớp nội dung: ví dụ, một nền tảng du lịch tập trung vào người Hồi giáo cần các thuộc tính có thể lọc như chứng nhận halal, cơ sở cầu nguyện và chính sách rượu. Điều này có nghĩa là các thuộc tính đó phải luôn hiện diện và được xác minh nhất quán trong tồn kho trước khi chúng có thể được hiển thị dưới dạng các tùy chọn lọc đáng tin cậy. Gradion đã xây dựng các quy trình làm giàu nội dung giúp việc lọc chuyên biệt trở nên đáng tin cậy, không chỉ đơn thuần là có mặt về mặt kỹ thuật.

Xếp hạng mức độ liên quan và tích hợp GDS

Mức độ liên quan của từ khóa chỉ là điểm khởi đầu, không phải giới hạn, trong xếp hạng tìm kiếm du lịch. Xếp hạng đa tín hiệu kết hợp khả năng cạnh tranh về giá, độ tin cậy về khả dụng, tỷ lệ chuyển đổi lịch sử theo thuộc tính và phân khúc thị trường, cùng với sự gần gũi về địa lý với ý định đã nêu. Việc xếp hạng lại bằng máy học, được đào tạo trên dữ liệu chuyển đổi đặt chỗ, bổ sung một lớp cá nhân hóa và cải thiện hiệu quả theo quy mô. Đối với các nền tảng lấy tồn kho từ các hệ thống phân phối toàn cầu (GDS), quy trình khả dụng kết nối với các nguồn cấp dữ liệu của Amadeus, Sabre hoặc Travelport cùng với các API quản lý kênh trực tiếp. Mỗi nguồn mang theo mô hình dữ liệu, tần suất cập nhật và hồ sơ độ tin cậy riêng. Việc chuẩn hóa thành một mô hình khả dụng nội bộ nhất quán là điều kiện tiên quyết để có kết quả tìm kiếm mạch lạc. Lớp ánh xạ chính là nơi nhiều tích hợp tích lũy các vấn đề về tính đúng đắn theo thời gian khi các lược đồ nguồn phát triển.

Tìm kiếm không gian địa lý

Vị trí là một tiêu chí tìm kiếm hàng đầu trong hầu hết các danh mục du lịch. OpenSearch và Elasticsearch cung cấp tính năng truy vấn địa lý tích hợp, hỗ trợ tìm kiếm theo bản đồ (bounding box), lọc theo khoảng cách gần (radius queries) và tìm kiếm khu vực điểm đến (polygon queries). Đối với các nền tảng lưu trú và hoạt động, việc kết hợp lọc địa lý với các bộ lọc về tình trạng sẵn có và thuộc tính trong một truy vấn duy nhất là yêu cầu tiêu chuẩn. Nếu được xử lý đúng cách, điều này sẽ chỉ làm tăng thêm ảnh hưởng không đáng kể đến độ trễ truy vấn.

Minh chứng trong vận hành

KAYAK là nền tảng tìm kiếm du lịch lớn nhất thế giới, xử lý hơn 2 tỷ truy vấn của người dùng hàng năm trên 60 thị trường. NFQ (với sự tham gia của Gradion) đã xây dựng và vận hành một đội ngũ kỹ thuật hiệu suất cao, tích hợp sâu vào quá trình phát triển sản phẩm của KAYAK trong hơn một thập kỷ. Công việc bao gồm cơ sở hạ tầng tìm kiếm và tình trạng sẵn có cốt lõi, hoạt động ở quy mô lớn của KAYAK: tổng hợp đa nhà cung cấp, chuẩn hóa tình trạng sẵn có theo thời gian thực từ các nguồn cấp dữ liệu đa dạng, xếp hạng mức độ liên quan cho hàng tỷ truy vấn mỗi năm, và tối ưu hóa độ trễ mà tìm kiếm tổng hợp chuyến bay và chỗ ở yêu cầu. Năm 2018, KAYAK đã mua lại và tuyển dụng khoảng 40 kỹ sư này trực tiếp vào KAYAK Lithuania - đây là minh chứng rõ ràng nhất cho thấy đội ngũ đã hoạt động theo tiêu chuẩn kỹ thuật nội bộ, chứ không phải tiêu chuẩn của nhà thầu bên ngoài.

HomeToGo là thị trường cho thuê kỳ nghỉ lớn nhất thế giới, với hơn 15 triệu danh sách, hơn 60.000 đối tác đáng tin cậy và hoạt động tại 25 quốc gia. NFQ (với sự tham gia của Gradion) đã cung cấp các đội ngũ kỹ thuật lên đến 150 kỹ sư tại bốn văn phòng: hơn 50 lần triển khai sản phẩm mỗi ngày, hơn 100 thử nghiệm A/B đồng thời, và thời gian hoạt động 99,99% trên một hệ thống tích hợp hơn 100 API đối tác vào một mô hình tình trạng sẵn có thống nhất. Những thách thức về loại bỏ trùng lặp và chuẩn hóa khi tổng hợp 15 triệu danh sách từ các nguồn đa dạng là một minh chứng trực tiếp cho những gì cần thiết để khớp nối tài sản ở quy mô lớn.

roadsurfer: Xây dựng lại toàn bộ nền tảng trong 20 ngày, hỗ trợ 8 ngôn ngữ và 7 loại tiền tệ. Lượng đặt chỗ và doanh thu tăng gấp đôi trong vòng một năm kể từ khi ra mắt.

Kêu gọi hành động

Hãy mô tả quy mô kho dữ liệu, các mẫu truy vấn và những hạn chế về hiệu suất hiện tại của bạn. Chúng tôi sẽ xác định phạm vi kiến trúc tìm kiếm phù hợp.