Meltano Singer bookmark: state trước, sau và bản ghi nạp lại

Meltano Singer bookmark là mốc mà một extractor Singer ghi lại sau mỗi lần chạy, để lần sau chỉ lấy dữ liệu mới kể từ mốc đó. Meltano giữ mốc này trong cơ sở dữ liệu của nó và đưa lại cho tap ở lần chạy tiếp theo. Khi mọi thứ trơn tru, người dùng không cần nghĩ tới bookmark. Khi tap sập giữa chừng hay ai đó chạy full refresh, số bản ghi nạp lại có thể khác xa dự đoán. ProxyVN chạy Meltano 4.4.1 ngày 03/11/2026 với một tap và một target Singer tự viết, qua bảy lần chạy, ghi lại state trước, sau và số dòng nạp lại mỗi lần.

Meltano Singer bookmark: mục tiêu và phạm vi không lặp

Phần này chốt bài toán, đầu ra và ranh giới.

Bài toán

Một nhóm dùng Meltano để kéo dữ liệu giá từ API của đối tác vào kho mỗi giờ. Tap hỗ trợ chế độ tăng dần theo trường updated_at. Nhóm cần biết: sau mỗi lần chạy, bookmark nằm ở đâu, khởi động lại thì nạp lại bao nhiêu bản ghi, tap sập giữa chừng thì sao, và cách đặt lại state mà không làm hỏng dữ liệu.

Đầu ra nghiệm thu

Đầu ra gồm tệp state trước và sau mỗi lần chạy, cùng số bản ghi được nạp lại khi khởi động lại pipeline. Số liệu phải lấy từ cả phía tap, phía target và từ cơ sở dữ liệu của Meltano, để đối chiếu được.

Ranh giới với dlt

dlt là thư viện Python, cursor nằm trong mã nguồn của bạn. Meltano điều phối các plugin Singer chạy như tiến trình riêng, trao đổi qua dòng JSON trên đầu vào và đầu ra chuẩn. Bookmark do tap tạo, target chuyển tiếp, Meltano lưu. Ba bên phải phối hợp đúng thì state mới đúng. Bài tập trung vào sự phối hợp đó.

Không khẳng định mọi tap đều hỗ trợ tăng dần

Mỗi tap Singer tự quyết có hỗ trợ chế độ tăng dần hay không, và tự quyết so mốc bằng lớn hơn hay lớn hơn hoặc bằng. Bài dùng một tap tự viết để biết chính xác nó làm gì. Kết quả về Meltano áp dụng chung, kết quả về số bản ghi gửi lại phụ thuộc từng tap.

Phiên bản đã khóa

Lab dùng meltano 4.4.1, Python 3.12 trên Windows. Tap và target là hai tập lệnh Python ngắn, gọi qua tệp cmd bọc ngoài vì Meltano cần một tệp thực thi. Không tải plugin nào từ kho bên ngoài. Backend state là cơ sở dữ liệu hệ thống mặc định của Meltano, một tệp SQLite.

Vì sao dùng tap tự viết

Tap từ kho plugin thường có hàng nghìn dòng mã và hành vi phụ thuộc phiên bản. Muốn hiểu Meltano xử lý state thế nào, cần một tap mà ta biết chính xác nó gửi gì và khi nào. Tap tự viết trong lab chỉ khoảng ba mươi dòng, đủ để mọi con số trong bài giải thích được bằng mã nguồn.

Ai nên đọc

Người vận hành Meltano đã thấy dữ liệu trùng trong kho mà không rõ từ đâu. Người viết tap Singer riêng cần biết Meltano xử lý state thế nào. Người cần đặt lại state để nạp lại dữ liệu mà không muốn đoán.

Quản lý Singer state trong Meltano cho extractor API được phép với Meltano Singer bookmark

Trước khi chạy, cần nắm cách Singer truyền state.

Ba loại thông điệp

Theo tài liệu Data Integration của Meltano, tap gửi ra các dòng JSON. SCHEMA mô tả cấu trúc một luồng dữ liệu. RECORD chứa một bản ghi. STATE chứa bookmark. Target đọc các dòng này, ghi RECORD vào đích, và khi gặp STATE thì phát lại STATE ra đầu ra của nó sau khi đã ghi xong các bản ghi trước đó.

Vì sao target phát lại STATE

Target xác nhận STATE

Target phát lại STATE như lời xác nhận: mọi bản ghi trước mốc này đã nằm an toàn ở đích. Meltano chỉ lưu STATE mà target phát ra, không lưu STATE của tap trực tiếp. Nhờ vậy, bookmark không vượt trước dữ liệu đã ghi.

Meltano lưu state ở đâu

Với cấu hình mặc định, Meltano lưu state trong bảng state của tệp meltano.db, theo state_id gồm môi trường, tên tap và tên target. Lab đọc bảng này và thấy ba cột: state_id, partial_state và completed_state.

STATE ghi đè, không gộp

Mỗi STATE mới mà target phát ra thay thế STATE trước trong cùng lần chạy. Meltano lưu cái cuối cùng. Tap phải gửi STATE đầy đủ cho mọi luồng mỗi lần, không chỉ gửi phần thay đổi. Với tap nhiều luồng, quên điều này có thể làm mất bookmark của luồng không được nhắc tới trong STATE cuối.

Tap nhận state thế nào

Ở lần chạy sau, Meltano ghi state đã lưu ra một tệp tạm rồi truyền đường dẫn cho tap qua tham số state. Tap đọc bookmark từ tệp đó. Nếu không có state, tap dùng start_date trong cấu hình.

Đầu ra chuẩn là kênh dữ liệu

Tap chỉ được in dòng JSON Singer ra đầu ra chuẩn. Mọi thông điệp gỡ lỗi phải ra đầu ra lỗi. Tap trong lab ghi bookmark đầu vào và số bản ghi ra đầu ra lỗi, Meltano hiện chúng trong log với tên plugin. Một dòng in nhầm ra đầu ra chuẩn sẽ làm target đọc lỗi JSON.

Catalog và chọn luồng

Tap mô tả các luồng nó cung cấp qua chế độ discover, trả về catalog. Catalog cho biết khóa chính, trường replication và phương thức replication của từng luồng. Meltano dùng catalog để biết luồng nào được chọn và có hỗ trợ tăng dần hay không.

Chọn tap/target có hỗ trợ replication cần thiết trong Meltano Singer bookmark

Phần này trình bày tap, target và cấu hình Meltano.

Tap tự viết

Tap đọc tệp items.json mô phỏng phản hồi của API. Nó lấy bookmark từ state, gửi SCHEMA, rồi gửi RECORD cho mọi bản ghi có updated_at lớn hơn hoặc bằng bookmark, sắp theo updated_at và id. Cứ hai bản ghi, tap gửi một STATE với giá trị updated_at lớn nhất đã gửi. Cuối cùng gửi một STATE nữa.

Tap có một tùy chọn crash_after để cố ý sập sau một số bản ghi, dùng cho ca thử lỗi.

Lớn hơn hoặc bằng bookmark

Tap so updated_at lớn hơn hoặc bằng bookmark, không lớn hơn hẳn. Nhiều tap làm vậy để không bỏ sót bản ghi có cùng mốc với bản ghi cuối lần trước. Hệ quả là bản ghi ở đúng mốc được gửi lại mỗi lần. Lab sẽ đếm số bản ghi gửi lại do chuyện này.

Khóa chính đi theo SCHEMA

Tap gửi key_properties cùng thông điệp SCHEMA. Target dùng thông tin này để biết cột nào là khóa khi gộp. Target trong lab bỏ qua khóa để đếm được bản trùng. Target thật nên đọc key_properties và upsert, hoặc ít nhất ghi khóa vào đích để tầng sau khử trùng.

Discover

Ở chế độ discover, tap trả catalog với một luồng items, khóa chính id, replication_key updated_at, phương thức INCREMENTAL, và metadata đánh dấu luồng được chọn. Meltano đọc catalog này trước mỗi lần chạy.

Gửi STATE mỗi hai bản ghi

Tap gửi STATE sau mỗi hai bản ghi để lab thấy rõ ảnh hưởng của tần suất STATE khi có sự cố. Tap thật thường gửi STATE sau mỗi trang API hoặc sau một số bản ghi nhất định. Gửi càng dày, sự cố càng ít bản ghi phải gửi lại, nhưng target phải flush nhiều hơn.

Target tự viết

Target đọc từng dòng. Gặp RECORD thì thêm vào tệp out/items.jsonl. Gặp STATE thì flush tệp rồi in STATE ra đầu ra. Target không khử trùng: mọi RECORD đều được thêm vào. Nhờ vậy, đếm dòng trong tệp là đếm chính xác số bản ghi đã được nạp, kể cả bản trùng.

Cấu hình Meltano

plugins:
  extractors:
  - name: tap-gia
    namespace: tap_gia
    executable: .../tap_gia.cmd
    capabilities: [discover, state, catalog]
    settings:
    - name: data_file
    - name: start_date
    - name: crash_after
      kind: integer
    config:
      data_file: items.json
      start_date: "2026-11-01T00:00:00Z"
  loaders:
  - name: target-jsonl-lab
    namespace: target_jsonl_lab
    executable: .../target_jsonl_lab.cmd

capabilities phải có state, nếu không Meltano không truyền state cho tap. executable trỏ tới tệp cmd vì Meltano chạy thẳng tệp thực thi, không nhận thêm đối số cho trình thông dịch.

Tệp cmd bọc ngoài trên Windows

Meltano chạy plugin bằng đường dẫn executable, không thêm đối số trước tham số của Singer. Để chạy một tập lệnh Python bằng trình thông dịch của môi trường ảo, lab tạo tệp cmd gọi python kèm đường dẫn tập lệnh và chuyển mọi tham số còn lại. Trên Linux, một tập lệnh có dòng shebang làm cùng việc này.

Lệnh chạy

Mỗi lần chạy dùng lệnh meltano run tap-gia target-jsonl-lab. Đọc state bằng meltano state get kèm state_id. Lab chạy bảy lần, giữa các lần thay đổi dữ liệu hoặc cấu hình.

Kiểm catalog, stream selection và replication key cho Meltano Singer bookmark

Phần này chạy lần đầu và đọc state.

Lần 1

Dữ liệu có năm sản phẩm, updated_at từ 08:00 tới 08:20 ngày 02/11. Chưa có state, tap dùng start_date 01/11. Log ghi bookmark đầu vào bằng start_date, tap gửi 5 bản ghi, bookmark mới bằng 08:20 ngày 02/11. Target ghi 5 dòng.

State sau lần 1

meltano state get trả về singer_state với bookmarks, items, updated_at bằng 08:20 ngày 02/11. Đây là STATE cuối cùng mà target phát ra. state_id là dev:tap-gia-to-target-jsonl-lab.

Log hiện bookmark đầu vào

Log của Meltano gắn tên plugin vào mỗi dòng đầu ra lỗi của tap. Nhờ tap ghi bookmark đầu vào, chỉ cần đọc log là biết lần chạy bắt đầu từ đâu. Với tap của bên thứ ba, nên bật mức log chi tiết lần đầu để xem tap có in bookmark hay không.

Tên state_id có ý nghĩa

state_id gồm môi trường, tên tap và tên target. Đổi tên target, hoặc chạy cùng tap với một target khác, sẽ tạo state_id mới và bắt đầu từ start_date. Đây là điều dễ quên khi đổi tên plugin trong meltano.yml: state cũ vẫn còn, nhưng không được dùng nữa.

Replication key phải có trong mọi bản ghi

Tap tính bookmark từ trường updated_at của từng bản ghi. Bản ghi thiếu trường này sẽ làm tap lỗi hoặc bỏ qua tùy cách viết. Với tap của bên thứ ba, nên kiểm trường replication có luôn được API trả về không, trước khi bật chế độ tăng dần.

Đọc trực tiếp meltano.db

Ngoài lệnh state get, có thể mở meltano.db bằng công cụ SQLite và đọc bảng state. Lab thấy cột completed_state chứa singer_state với bookmark, cột partial_state rỗng sau lần chạy thành công. Đọc trực tiếp giúp khi lệnh của Meltano không chạy được, ví dụ cấu hình hỏng.

Chọn luồng

Lab chỉ có một luồng và đánh dấu selected ngay trong catalog. Với tap thật có nhiều luồng, Meltano cho chọn luồng bằng cấu hình select. Luồng không được chọn không được tap gửi, và không có bookmark.

Lưu Singer state/bookmark giữa hai lần chạy với Meltano Singer bookmark

Phần này chạy thêm hai lần, có bản đến muộn và bản trùng mốc.

Dữ liệu lần 2

Sản phẩm 2 đổi giá thành 222.000, updated_at 08:00 ngày 03/11. Sản phẩm 6 mới, updated_at 08:20 ngày 02/11, bằng đúng bookmark. Sản phẩm 7 mới, updated_at 08:12 ngày 02/11, nhỏ hơn bookmark. Sản phẩm 8 mới, updated_at 08:05 ngày 03/11.

Thứ tự gửi theo updated_at

Tap sắp bản ghi theo updated_at rồi theo id trước khi gửi. Nhờ vậy, mỗi STATE gửi giữa chừng đều đúng: mọi bản ghi trước nó có updated_at nhỏ hơn hoặc bằng mốc trong STATE. Tap gửi không theo thứ tự mà vẫn gửi STATE giữa chừng sẽ làm bookmark vượt qua những bản ghi chưa gửi.

Lần 2

Bookmark đầu vào là 08:20 ngày 02/11. Tap gửi 4 bản ghi: sản phẩm 5 và 6 ở đúng mốc, sản phẩm 2 và 8 mới hơn. Bookmark mới là 08:05 ngày 03/11. Target ghi 4 dòng. Tổng tệp có 9 dòng.

Sản phẩm 5 được gửi lại dù không đổi gì, vì nằm ở đúng mốc. Sản phẩm 6 vào được nhờ điều kiện lớn hơn hoặc bằng. Sản phẩm 7 không được gửi, vì cũ hơn bookmark.

Lần 3: không đổi dữ liệu

Gửi lại ở mốc

Bookmark đầu vào là 08:05 ngày 03/11. Tap gửi 1 bản ghi: sản phẩm 8 ở đúng mốc. Target ghi 1 dòng. Tổng tệp có 10 dòng. Mỗi lần chạy không có dữ liệu mới vẫn gửi lại bản ghi ở mốc cuối.

Số bản ghi gửi lại không phụ thuộc lượng dữ liệu mới

Lần 3 không có dữ liệu mới vẫn gửi một bản ghi. Nếu có mười bản ghi cùng mốc cuối, lần chạy không có dữ liệu mới sẽ gửi lại cả mười. Với API mà nhiều bản ghi được cập nhật cùng lúc theo lô, số bản ghi ở mốc cuối có thể lớn. Nên đo số này với dữ liệu thật.

Đích phải khử trùng

Vì tap gửi lại bản ghi ở mốc, đích phải gộp theo khóa chính. Target trong lab cố ý không gộp để đếm được. Target thật ghi vào kho thường dùng khóa chính trong SCHEMA để upsert. Nếu target của bạn chỉ thêm dòng, kho sẽ có bản trùng sau mỗi lần chạy.

Giá cũ của sản phẩm 2 vẫn còn

Tệp có hai dòng sản phẩm 2: giá 102.000 từ lần 1 và 222.000 từ lần 2. Đích gộp theo khóa sẽ giữ dòng nạp sau. Đích chỉ thêm dòng sẽ có cả hai, và người đọc phải chọn dòng có updated_at lớn nhất. Đây là quyết định của tầng biến đổi sau khi nạp.

Bản đến muộn

Sản phẩm 7 không bao giờ được gửi trong các lần chạy tăng dần. Đây không phải lỗi của Meltano mà là giới hạn của mọi cơ chế bookmark theo thời gian. Muốn bắt bản đến muộn, tap phải lùi bookmark một khoảng, hoặc định kỳ chạy full refresh.

Đối soát bản ghi nạp lại và cách reset state an toàn trong Meltano Singer bookmark

Phần này thử tap sập, full refresh và xóa state.

Lần 4: tap sập giữa chừng

Tap sập giữa chừng

Thêm sản phẩm 9, 10, 11 với updated_at 08:00, 08:01, 08:02 ngày 04/11. Đặt crash_after bằng 3. Tap gửi sản phẩm 8, 9, 10 rồi thoát với mã lỗi. Sau hai bản ghi đầu, tap đã gửi một STATE với mốc 08:00 ngày 04/11.

Target ghi 3 dòng và phát lại STATE mốc 08:00 ngày 04/11. Meltano báo Extractor failed. Tổng tệp có 13 dòng.

State được giữ dù lần chạy lỗi

Lần 5, sau khi bỏ crash_after, bookmark đầu vào là 08:00 ngày 04/11, không phải 08:05 ngày 03/11 của lần thành công trước. Meltano đã lưu STATE cuối mà target xác nhận trong lần chạy lỗi. Bảng state có cột partial_state riêng cho trường hợp này.

Tap gửi sản phẩm 9, 10, 11. Bookmark mới là 08:02 ngày 04/11. Target ghi 3 dòng. Tổng tệp có 16 dòng.

Exit code của Meltano khi tap lỗi

Meltano báo Extractor failed và kết thúc với trạng thái lỗi. Lịch chạy nhận mã lỗi và có thể gửi cảnh báo. Điều đáng chú ý là dữ liệu đã ghi trước sự cố vẫn nằm ở đích, và bookmark đã tiến tới STATE cuối được xác nhận. Lần chạy lỗi không phải lần chạy vô ích.

Bản ghi nạp lại sau sự cố

Sản phẩm 9 được nạp hai lần: lần 4 và lần 5. Sản phẩm 10 cũng hai lần. Sản phẩm 10 đã được ghi ở lần 4 sau STATE cuối, nên không nằm trong bookmark, và được gửi lại. Sản phẩm 9 được gửi lại vì nằm ở đúng mốc bookmark.

Đếm bản ghi theo id sau lần 5

Bảng: Đếm bản ghi theo id sau lần 5

id	Số lần trong tệp	Lý do
1, 3, 4	1	chỉ nạp ở lần 1
2	2	lần 1 giá cũ, lần 2 giá mới
5	2	gửi lại ở mốc trong lần 2
6	1	mới ở lần 2
7	0	đến muộn, không bao giờ gửi
8	3	lần 2, gửi lại ở mốc lần 3, lần 4
9, 10	2	lần 4 lỗi, gửi lại lần 5
11	1	lần 5

Giảm bản ghi gửi lại sau sự cố

Sản phẩm 10 bị gửi lại vì nằm sau STATE cuối. Nếu tap gửi STATE sau mỗi bản ghi, sản phẩm 10 đã được xác nhận trước khi tap sập, và chỉ sản phẩm 10 ở mốc mới được gửi lại. Đổi lại, target phải flush sau mỗi bản ghi, chậm hơn với đích như kho dữ liệu đám mây. Cân bằng tùy đích.

Lần 6: full refresh

Chạy meltano run kèm cờ full-refresh. Bookmark đầu vào là start_date 01/11, không đọc state đã lưu. Tap gửi đủ 11 bản ghi, kể cả sản phẩm 7. Bookmark mới là 08:02 ngày 04/11. Tổng tệp có 27 dòng.

Full refresh là cách bắt bản đến muộn. Cái giá là gửi lại toàn bộ dữ liệu, và đích phải gộp đúng theo khóa.

Full refresh không đổi state_id

Lần full refresh dùng cùng state_id. Khi xong, state mới ghi đè state cũ với cùng bookmark 08:02 ngày 04/11. Không có state_id mới, không có dấu vết nào cho biết lần chạy này là full refresh, ngoài log. Nên ghi lại thủ công mỗi lần chạy full refresh.

Lần 7: xóa state

Chạy meltano state clear với state_id, rồi chạy lại bình thường. Bookmark đầu vào là start_date, tap gửi 11 bản ghi, giống full refresh. Tổng tệp có 38 dòng.

Khác biệt giữa hai cách: full refresh không đụng state đã lưu cho tới khi lần chạy xong, còn state clear xóa state ngay. Nếu lần chạy sau state clear thất bại sớm, lần tiếp theo vẫn bắt đầu từ đầu.

Khi nào chọn full refresh, khi nào chọn state clear

Full refresh phù hợp khi muốn nạp lại một lần, giữ state cũ làm lưới an toàn nếu lần chạy lỗi giữa chừng. State clear phù hợp khi state cũ đã hỏng, ví dụ bookmark bị đẩy quá xa do dữ liệu nguồn có mốc sai trong tương lai. Trong cả hai trường hợp, đích phải gộp theo khóa để không nhân đôi dữ liệu.

Reset an toàn

Muốn nạp lại từ một mốc cụ thể thay vì từ đầu, dùng meltano state set để đặt bookmark mong muốn. Lab chưa thử lệnh này. Trước khi đặt hay xóa state, nên lưu state hiện tại ra tệp bằng state get, để quay lại được nếu cần.

Đầu ra nghiệm thu: tệp state trước/sau và số bản ghi nạp lại khi khởi động lại pipeline của Meltano Singer bookmark

Phần cuối gom kết quả thành bộ bàn giao.

Bộ bàn giao

Bộ bàn giao gồm tap_gia.py, target_jsonl_lab.py, hai tệp cmd, meltano.yml, tệp items.json ở trạng thái cuối, out/items.jsonl với 38 dòng và meltano.db. Người nhận chạy lại theo thứ tự bảy lần, phải thấy cùng chuỗi bookmark và cùng số dòng.

Bảng state trước và sau

Bảng: Bảng state trước và sau

Lần	Bookmark trước	Bookmark sau	Bản ghi gửi	Tổng dòng
1	start_date 01/11	02/11 08:20	5	5
2	02/11 08:20	03/11 08:05	4	9
3	03/11 08:05	03/11 08:05	1	10
4, tap sập	03/11 08:05	04/11 08:00	3	13
5	04/11 08:00	04/11 08:02	3	16
6, full refresh	start_date	04/11 08:02	11	27
7, sau state clear	start_date	04/11 08:02	11	38

Tiêu chí đạt

Bookmark tiến đúng theo dữ liệu. Lần chạy lỗi lưu được bookmark đã xác nhận. Số bản ghi gửi lại giải thích được bằng quy tắc lớn hơn hoặc bằng và vị trí STATE cuối. Full refresh và state clear đều bắt đầu từ start_date.

Bookmark ở tương lai

Nếu API trả một bản ghi có updated_at sai, nằm ở năm sau, bookmark sẽ nhảy tới mốc đó. Mọi lần chạy sau chỉ lấy bản ghi mới hơn năm sau, tức không lấy gì cả. Lab chưa cài ca này, nhưng nên kiểm bookmark sau mỗi lần chạy: nếu nó lớn hơn giờ hiện tại, đó là dấu hiệu dữ liệu nguồn lỗi.

Quy tắc vận hành

Đích luôn gộp theo khóa chính. Tap nên gửi STATE thường xuyên để giảm số bản ghi gửi lại sau sự cố. Định kỳ chạy full refresh để bắt bản đến muộn. Lưu state ra tệp trước mọi thao tác đặt lại. Không đổi tên tap hay target trong meltano.yml mà không nghĩ tới state_id.

Khi nào cần proxy với Meltano Singer bookmark

Meltano không gọi mạng, tap mới gọi. Proxy, nếu cần, cấu hình theo cách tap hỗ trợ, thường qua biến môi trường mà thư viện HTTP của tap đọc. Meltano truyền biến môi trường cho tiến trình tap.

Một số API đối tác chỉ cho phép IP đã đăng ký. Khi máy chạy Meltano cần một IP cố định tại Việt Nam, anh em có thể mua proxy tĩnh Việt Nam tại trang chủ ProxyVN. Proxy không sửa bookmark, không tăng quota API và không làm tap hỗ trợ tăng dần nếu nó không hỗ trợ. Vai trò hợp lệ của proxy được giải thích ở bài Web Scraping proxy là gì.

Proxy cấu hình ở đâu

Đặt biến proxy trong phần env của plugin tap trong meltano.yml, không đặt cho cả tiến trình Meltano. Target ghi vào kho nội bộ không nên đi qua proxy dùng cho API bên ngoài. Tách cấu hình theo plugin giúp tránh những lỗi kết nối khó hiểu ở phía target.

Proxy lỗi làm tap sập

Proxy chết giữa chừng có thể làm tap sập giống lần 4 trong lab. Bookmark dừng ở STATE cuối đã xác nhận, lần sau tap gửi lại phần sau mốc đó. Không mất dữ liệu nếu đích gộp theo khóa. Cấu hình chuỗi proxy đúng định dạng cho tap được giải thích trong bài định dạng proxy.

Ghi state ra tệp theo lịch

Lưu state ra tệp sau mỗi lần chạy, kèm thời điểm, tạo thành lịch sử bookmark. Khi phát hiện dữ liệu thiếu, lịch sử này cho biết bookmark đã đi qua những mốc nào và lần chạy nào có thể đã bỏ sót. meltano.db chỉ giữ state mới nhất, không giữ lịch sử.

Những gì lab chưa thử

Lab chưa thử tap và target từ kho plugin của Meltano, chưa thử backend state trên S3 hay Azure, chưa thử meltano state set và merge. Lab cũng chưa thử nhiều luồng trong một tap, nơi mỗi luồng có bookmark riêng trong cùng một state. Hành vi gửi lại ở mốc phụ thuộc từng tap, không phải của Meltano.

Checklist Meltano Singer bookmark

Checklist

• Tap khai báo capability state trong meltano.yml.
• Biết tap so bookmark bằng lớn hơn hay lớn hơn hoặc bằng.
• Target phát lại STATE sau khi ghi xong.
• Đích gộp theo khóa chính.
• Tap gửi STATE thường xuyên để giảm nạp lại sau sự cố.
• Full refresh định kỳ để bắt bản đến muộn.
• Lưu state ra tệp trước khi clear hoặc set.
• Đổi tên plugin là đổi state_id.

Câu hỏi thường gặp về Meltano Singer bookmark

Meltano lưu bookmark ở đâu?

Mặc định trong bảng state của tệp meltano.db, theo state_id gồm môi trường, tap và target.

Vì sao không có dữ liệu mới mà vẫn nạp một bản ghi?

Vì tap gửi lại bản ghi ở đúng mốc bookmark. Lab thấy sản phẩm 8 được gửi lại ở lần 3.

Tap sập thì mất bookmark không?

Không. Lab cho thấy Meltano lưu STATE cuối mà target xác nhận, lần sau tiếp từ mốc 08:00 ngày 04/11.

Full refresh khác state clear thế nào?

Cả hai bắt đầu từ start_date. Full refresh không xóa state trước, state clear xóa ngay.

Bản đến muộn có được nạp không?

Không trong chế độ tăng dần. Lab chỉ nạp sản phẩm 7 ở lần full refresh.

Meltano có cần proxy không?

Không. Chỉ tap gọi API mới có thể cần.

Meltano Singer bookmark và những điều cần nhớ

Meltano Singer bookmark chỉ tiến khi target xác nhận đã ghi, nên dữ liệu không mất, nhưng bản ghi có thể được gửi lại. Lab trên Meltano 4.4.1 cho thấy bản ghi ở mốc được gửi lại mỗi lần chạy, tap sập làm hai bản ghi nạp hai lần, còn bản đến muộn chỉ vào được qua full refresh. Đích gộp theo khóa và full refresh định kỳ là hai việc không nên bỏ. Cần IP tĩnh để tap gọi API đối tác trước khi chạy Meltano Singer bookmark, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.