dbt में incremental models कैसे काम करते हैं, और आप full rebuild की जगह उन्हें कब चुनते हैं?

incremental model पहली बार table बनाता है, फिर आगे के runs में सिर्फ नई या बदली हुई rows process करके उन्हें merge कर देता है, और source को छांटने के लिए is_incremental block इस्तेमाल करता है। इसे तब चुनें जब full rebuild बहुत धीमा या महंगा हो, आम तौर पर बड़ी event tables पर। एक unique key रखें ताकि देर से आए updates duplicate होने के बजाय merge हों, और full refresh का रास्ता खुला रखें ताकि logic बदलने पर दोबारा बना सकें।

पहले run पर वह पूरी table बनाता है। उसके बाद is_incremental block एक filter जोड़ देता है ताकि आप सिर्फ हाल की source rows scan करें, और dbt उन्हें unique key पर मौजूदा table में merge कर देता है। मैं इसे तभी उठाता हूं जब full rebuild सचमुच तकलीफदेह हो गया हो, क्योंकि incremental models state ढोते हैं और state खिसकता है। दो आदतें इन्हें ईमानदार रखती हैं। पहली, max timestamp से सख्ती से बड़ा होने के बजाय एक lookback window, क्योंकि sources पुरानी rows भी अपडेट करते हैं। एक orders model पर हमने तीन दिन रखे, यह पाने के बाद कि refunds 48 घंटे तक देर से आते थे और पूरी तरह छूट रहे थे। दूसरी, तय समय पर full refresh, हमारे यहां हफ्ते में एक बार, जो खिसकाव भी पकड़ता है और यह भी साबित करता है कि model अब भी दोबारा बन सकता है। जो गड़बड़ी मैंने देखी है वह है append only strategy पर बिना unique key वाला incremental model, जो हर retry पर चुपचाप दोहरी गिनती करता रहा, और किसी ने तब तक नहीं पकड़ा जब तक महीने का आंकड़ा finance से नहीं भिड़ गया।