Xuất sang lưu trữ đối tượng
Một đối tượng JSON cho mỗi mục tiêu hoàn thành, trong bucket do bạn sở hữu. Đây là đường vào mọi kho dữ liệu ngoài BigQuery.
1. Khoảng trống được lấp đầy
Trước đây chỉ có đúng một cách đi từ MousePlayer vào kho dữ liệu và cách đó dẫn đến Google. Nếu dùng Snowflake, Redshift hoặc ClickHouse, bạn không có cách nào - dù cả ba đều đọc tốt từ lưu trữ đối tượng.
Vì vậy cầu nối ghi vào lưu trữ đối tượng thay vì lần lượt vào từng kho dữ liệu. Snowflake nhập từ S3, Redshift nhập từ S3, ClickHouse nhập từ S3 và BigQuery nhập từ Google Cloud Storage. Một lần xuất đến được tất cả.
| Nơi lưu | Cách truy cập |
|---|---|
| Amazon S3 | Signature Version 4, bucket trong tên máy chủ |
| Cloudflare R2 | Signature Version 4 với điểm cuối tài khoản của bạn |
| Google Cloud Storage | qua API tương thích S3 với khóa HMAC |
| MinIO, Wasabi, Backblaze B2 và các dịch vụ khác | Signature Version 4 với điểm cuối của bạn |
| Azure Blob Storage | liên kết SAS của container - phía chúng tôi hoàn toàn không ký |
2. Vì sao Azure khác biệt và vì sao tốt hơn
Azure Blob không dùng Signature Version 4 mà ký bằng SharedKey. Chúng tôi có thể xây dựng cơ chế ký thứ hai. Thay vào đó, cầu nối nhận liên kết SAS của container - URL bạn tạo trong tài khoản lưu trữ với chữ ký đã có sẵn.
Phía chúng tôi ít mã hơn và phía bạn cần đặt ít niềm tin hơn. Chúng tôi hoàn toàn không thấy khóa tài khoản: bạn giao quyền do chính bạn giới hạn cho một container, với ngày hết hạn bạn chọn, có thể thu hồi bất cứ lúc nào mà không tác động phần khác.
Nên áp dụng cùng mức hạn chế cho phía S3: cấp khóa truy cập quyền ghi vào đúng tiền tố này và không gì khác. Khóa chỉ có thể thêm vào mouseplayer/goals/ không thể đọc các bucket khác dù bị lộ.
3. Một đối tượng cho mỗi mục tiêu và khóa là ngày
Lưu trữ đối tượng không hỗ trợ nối thêm. Tệp hằng ngày sẽ phải được ghi lại toàn bộ mỗi lần và hai mục tiêu đến cùng lúc sẽ ghi đè nhau. Vì vậy mỗi mục tiêu hoàn thành trở thành đối tượng riêng.
Đổi lại là nhiều đối tượng nhỏ; bố cục khóa giúp cách này khả thi:
prefix/YYYY/MM/DD/channel/session-goal.json
Kho dữ liệu đọc một ngày thành một phân vùng và việc bổ sung dữ liệu quá khứ là quét tiền tố thay vì truy vấn. Nếu muốn phân vùng theo dự án thay vì ngày, hãy đưa ID kênh vào tiền tố.
Mỗi đối tượng là một dòng JSON
Chủ động không thụt lề để đọc toàn bộ tiền tố thành NDJSON mà không cần mở từng đối tượng. Dấu thời gian, dự án, phiên, ID khách hàng, mục tiêu, giá trị, loại tiền tệ và liên kết phát lại bản ghi.
Giá trị trống là null, không phải số không
Mục tiêu không có giá trị tiền tệ ghi null. Trong kho dữ liệu, số không sẽ được cộng vào tổng chưa từng tồn tại - khác biệt giữa “chưa thỏa thuận số tiền” và “số tiền bằng không” được giữ qua lần xuất.
4. Nếu trả 403, hãy đọc phần này trước
Yêu cầu S3 bị từ chối hầu như không nói lên điều gì và có lý do thông báo trong nhật ký của chúng tôi cho biết nhiều hơn S3: khu vực được đưa vào chữ ký. Khu vực sai và khóa sai tạo cùng lỗi 403, nên nghi ngờ hiển nhiên - khóa - chỉ đúng một nửa số lần.
Ba thứ cần kiểm tra theo thứ tự này:
- Khu vực đúng như bucket báo cáo. R2 và Google Cloud Storage dùng
autovà không kiểm tra; mọi dịch vụ khác đều kiểm tra. - Quyền theo tiền tố. Khóa được giới hạn cho
mouseplayer/không thể ghi vàomouseplayer-goals/- dấu gạch chéo cuối có ý nghĩa trong ARN tài nguyên. - Điểm cuối cho R2 và dịch vụ tương thích S3. Dán tên máy chủ không có
https://; chúng tôi đều loại bỏ phần đó nhưng đường dẫn nối thêm vào sẽ là bucket khác.
ID khóa truy cập được chủ động lưu dạng rõ. Theo thiết kế, ID có trong mọi yêu cầu đã ký, nên mã hóa chỉ tốn công mà không tăng bảo vệ. Khóa bí mật được mã hóa, không hiển thị lại và không bao giờ vào hàng đợi nội bộ mang tác vụ.
Mọi nhãn hiệu nêu ở đây thuộc chủ sở hữu tương ứng. MousePlayer không có quan hệ kinh doanh với các nhà cung cấp này.