Bạn đang dùng trình duyệt đã lỗi thời. Trình duyệt có thể không hiển thị đúng trang web này hoặc các trang web khác. Bạn nên nâng cấp hoặc dùng một trình duyệt khác.
Bước đầu tiên là phân tích chi tiết hệ thống, chứ không phải là tìm solutions. Thoạt nghe thì khá là buồn cười, tuy nhiên mình thấy nhiều người vẫn đang nhầm lẫn phần này ở chỗ: Yêu cầu chi tiết đã được liệt kê từ trên rồi (BA, PO...), tại sao còn phân tích làm gì. Tuy nhiên phân tích ở đây là...
Payment hay tax thì nó đều dựa trên lí thuyết chung về thanh toán và chi phí công. Nhưng đúng là mình cũng chưa nghĩ ra business nào mang tính cục bộ đến mức không thể scale được, tự gạch :beat_brick:
Bên mình thì chia core logic giống như bác, có điều dùng thêm support multiple tag build để...
Việc này chỉ xảy ra khi các tính năng tương tự nhau, ko khác nhau nhiều về mặt tham số và vận hành. Còn nếu các tính năng giữa các khu vực có sự khác nhau quá lớn thì lúc đó chỉ có tách source ra thôi
Mạnh dạn dự đoán bên bác đang làm theo mô hình sau:
Source db -> kafka (qua kafka connect) -> parquet file (qua ksql) -> spark stream -> Des db
Mình ko biết bên bạn đang dùng parquet file chung hay mỗi bảng có một file riêng, tuy nhiên về tổng thể thì đang có quá nhiều component trung gian từ db...
Vậy thì quay lại bài toán ban đầu bên thím thôi.
Bên thím có thứ tự ưu tiên như thế nào?
1. Data tại thời điểm đó có cần bắt buộc phải đủ ở 500 bảng hay không? Có cho phép chậm hơn và tổng hợp muộn hơn hay không?
2. Yêu cầu realtime đến mức nào?
3. Bên thím đang tự build cdc, hay sử dụng...