थोडक्यात उत्तर: whisky cask warehouse मध्ये बारा किंवा अधिक वर्षे बसू शकतो, आणि त्या काळात तो हलतो, sample होतो, regauge होतो आणि शांतपणे spirit हवेत गमावतो. inventory फक्त cask ची सध्याची position आणि सध्याचे volume साठवत असेल, तर तो बहुतेक इतिहास नाहीसा होतो. हळूहळू बदलणारे attributes (position, मालक, status) type 2 slowly changing dimension म्हणून model करा, cask च्या बाबतीत जे काही घडते ते event म्हणून नोंदवा, आणि angel’s share साठवण्याऐवजी events वरून काढा. मग “हा cask 2019 मध्ये कुठे होता?” आणि “त्याने प्रत्यक्षात किती गमावले?” या प्रत्येकाला एकच उत्तर असते, आणि GenAI assistant अंदाज न लावता ती देऊ शकतो.
warehouse manager ला cask 14-0387 कुठे आहे असे विचारा, आणि तो काही सेकंदांत सांगेल. 2019 च्या उन्हाळ्यात तो कुठे होता असे विचारा, जेव्हा त्या fill मधील काही casks मध्ये अनपेक्षित note आली होती, आणि उत्तरात सहसा कागदी ledger, निवृत्त सहकारी आणि भरपूर सद्भावना यांचा समावेश असतो.
या मालिकेतील मागील पोस्ट्स still house च्या floor वर होत्या. ही पोस्ट warehouse मध्ये जाते, जिथे कालमान तासांऐवजी वर्षांचे असते, आणि जिथे इतिहास टिकतो की नाही हे data model ठरवते.
बदलाचे दोन प्रकार
cask दोन वेगळ्या प्रकारे बदलतो, आणि त्यांना दोन वेगळ्या रचना लागतात.
कधीमधी बदलणारे attributes: warehouse, bay आणि tier; मालक (ग्राहकांसाठी ठेवलेल्या casks साठी); status (maturing, earmarked, disgorged); re-rack नंतरचा cask प्रकार. ही cask बद्दलची तथ्ये आहेत जी काही काळ टिकतात, मग बदलतात.
त्याच्या बाबतीत घडणाऱ्या गोष्टी: भरणे, हलवणे, sampling, regauging, topping up, नव्या cask मध्ये re-rack, disgorging. हे तारीख, प्रमाण आणि व्यक्ती असलेले events आहेत.
बहुतेक cask systems पहिला प्रकार सध्याच्या values म्हणून साठवतात आणि दुसरा, फार तर, comments field म्हणून. दोन्हीमुळे इतिहास हरवतो.
SCD2: प्रत्येक आवृत्ती, तिच्या तारखांसह
type 2 slowly changing dimension attribute ला overwrite करण्याऐवजी त्याची प्रत्येक आवृत्ती ठेवते. प्रत्येक row मध्ये ती कधी खरी झाली आणि कधी थांबली याची तारीख असते:
-- cask_position_scd2: one row per period the cask sat in one place
-- cask_id | warehouse | bay | tier | valid_from | valid_to | is_current
-- 14-0387 | W1 | A | 2 | 2014-05-12 | 2016-09-03 | false
-- 14-0387 | W3 | C | 1 | 2016-09-03 | 2022-04-18 | false
-- 14-0387 | W5 | B | 3 | 2022-04-18 | 9999-12-31 | true
SELECT warehouse, bay, tier
FROM cask_position_scd2
WHERE cask_id = '14-0387'
AND DATE '2019-07-01' >= valid_from
AND DATE '2019-07-01' < valid_to;
ती एक query 2019 च्या प्रश्नाचे उत्तर देते. ती microclimate analysis सुद्धा शक्य करते: कालानुरूप positions warehouse तापमान आणि आर्द्रतेच्या logs शी join करा, आणि प्रत्येक cask ला त्याने प्रत्यक्ष अनुभवलेल्या हवामानाचा स्वतःचा इतिहास मिळतो, आणि rackhouse microclimate पोस्ट ला input म्हणून नेमके हेच हवे असते. SCD2 शिवाय प्रत्येक cask ने बारा वर्षे जिथे तो आज आहे तिथेच घालवली असे दिसते.
ते सांभाळणारा pipeline नेहमीचाच आहे: प्रत्येक वेळी move नोंदवली की सध्याची row बंद करा आणि नवी उघडा. dbt snapshots, Delta MERGE आणि Fabric pipelines हे सगळे काही ओळींच्या configuration ने करतात.
events: cask चा स्वतःचा ledger
cask मधील सामग्री बदलणारी प्रत्येक गोष्ट event आहे, wine cellar ledger movements नोंदवतो त्याच पद्धतीने नोंदवलेली:
- fill: bulk litres, strength, LAA, spirit batch, cask प्रकार
- sample: काढलेले volume, हेतू
- regauge: bulk litres, strength, LAA, पद्धत (dip किंवा weight)
- re-rack: कोणत्या cask मधून, कोणत्या cask मध्ये, volume
- disgorge: vatting कडे बाहेर गेलेले volume आणि strength
regauges बद्दल एक टीप आवश्यक आहे. casks बहुतेकदा dip ऐवजी वजनाने gauge केले जातात: gross weight वजा cask चा tare, भागिले मोजलेल्या strength वरील density, म्हणजे bulk litres. हे गणित 20 degrees C वरील ethanol आणि पाण्याच्या density table वर, आणि भरताना नोंदवलेल्या tare weight वर अवलंबून असते. यापैकी एकही गहाळ किंवा चुकीचे असेल, तर त्या cask चे प्रत्येक regauge एकाच दिशेने चुकते. event वर फक्त निकालातील volume नव्हे तर gross weight, tare आणि strength साठवा, म्हणजे गणित तपासता आणि पुन्हा करता येईल.
काढलेला आकडा म्हणून angel’s share
events जागेवर आल्यावर angel’s share कोणीतरी update करतो असा field राहत नाही आणि गणित बनतो:
loss = भरतानाचे LAA - शेवटच्या regauge वरील LAA - samples आणि withdrawals मध्ये काढलेले LAA
वरील उदाहरणादाखल cask साठी: 63.5% वर 250 litres भरले, म्हणजे 158.75 LAA. बारा वर्षांनंतर तो 205 litres आणि 60.8% वर regauge होतो, म्हणजे 124.64 LAA. साधेपणासाठी 2019 चा छोटा sample बाजूला ठेवला, तर loss साधारण 34 LAA, म्हणजे बारा वर्षांत 21.5%, चक्रवाढीने वर्षाला साधारण 2%. थंड, दमट warehouse मधील Scotch साठी सहसा सांगितल्या जाणाऱ्या श्रेणीत हे आहे. उष्ण हवामानात कितीतरी जास्त loss होतो, आणि जिथे पाणी alcohol पेक्षा वेगाने उडते तिथे strength घसरण्याऐवजी वाढूही शकते.
दोन गोष्टी काढलेल्या आवृत्तीला साठवलेल्यापेक्षा चांगले बनवतात. ती नेहमी अद्ययावत असते: नवा regauge कोणालाही लक्षात ठेवावे न लागता ती update करतो. आणि ती samples बद्दल प्रामाणिक असते: blending team सतत ज्यातून काढत राहिली म्हणून तहानलेला वाटणारा cask त्याचे samples samples म्हणूनच दाखवतो, evaporation म्हणून नाही. angel’s share forecasting पोस्ट loss चे modelling मांडते. ज्या डेटावरून ते model करायला हवे तो हा आहे.
वर GenAI assistant ठेवणे
SCD2 positions आणि cask event ledger असताना लोक प्रत्यक्ष विचारतात ते प्रश्न queries बनतात, आणि queries GenAI assistant साठी tools बनू शकतात:
cask_history(cask_id): प्रत्येक event आणि position, क्रमानेposition_on(cask_id, date): वरील SCD2 lookupalcohol_balance(fill_batch): fill LAA, सध्याचे LAA, samples, प्रत्येक cask चा काढलेला loss
“May 2014 च्या fill मधील कोणत्या casks नी त्यांच्या शेजाऱ्यांपेक्षा जास्त गमावले?” असे विचारल्यावर assistant alcohol_balance call करतो, प्रत्येक cask ची त्याच्या fill आणि warehouse च्या median शी तुलना करतो, आणि outliers त्यांच्या कालानुरूप positions सह यादीत मांडतो. प्रत्येक आकडा query मधून येतो. model चे काम म्हणजे प्रश्न समजून घेणे, योग्य tools call करणे आणि उत्तर साध्या शब्दांत समजावणे. त्याने raw tables का पाहू नयेत याची मांडणी wine मालिकेतील semantic layer पोस्ट करते.
हे कुठे मोडते
बारा वर्षांचा इतिहास क्वचितच स्वच्छ सुरू होतो. बहुतेक cask inventories चे पहिले दशक म्हणजे कागद, जुन्या systems आणि spreadsheets यांचे मिश्रण. जे शक्य आहे ते स्पष्ट स्रोतासह events म्हणून migrate करा, प्रत्येक cask च्या opening position पासून SCD2 सुरू करा, आणि migrate केलेला इतिहास नव्याइतकाच चांगला आहे असे भासवण्याऐवजी त्याला कमी confidence चा म्हणून खूण करा.
regauges क्वचित आणि गोंगाटी असतात. बारा वर्षांत दोनदा regauge झालेला cask त्याच्या loss साठी दोनच data points देतो. casks मधील काही टक्क्यांचे फरक maturation नव्हे तर मोजमापामुळे असू शकतात.
tare weights हरवतात. नोंदवलेला tare नसलेल्या cask चे वजनाने कोणत्याही अचूकतेने regauge करता येत नाही. गहाळ tare ला data quality दोष माना आणि दहाव्या वर्षी नव्हे तर पहिल्याच दिवशी flag करा.
duty नोंदी वेगळ्या असतात. bonded warehouse च्या नोंदी excise प्राधिकरणाला उत्तरदायी असतात आणि त्यांचे स्वतःचे नियम असतात. analytic inventory ने त्यांच्याशी जुळायला हवे, त्यांची जागा घ्यायला नको.
निष्कर्ष
cask म्हणजे बारा वर्षांची नोंद, आणि बहुतेक inventories फक्त तिचे शेवटचे पान ठेवतात. प्रत्येक position तिच्या तारखांसह ठेवा, प्रत्येक event त्याच्या प्रमाणांसह नोंदवा, आणि angel’s share साठवण्याऐवजी काढा. मग हवामान, loss, sampling आणि audits बद्दलच्या महत्त्वाच्या प्रश्नांना प्रत्येकी एकच उत्तर असते, आणि GenAI assistant मनाने रचण्याऐवजी governed tools मार्फत ते शोधू शकतो. spirit धीर धरते. data model नेही धरायला हवा.
मालिकेतील पुढील भाग: गणित code मध्ये करणारा GenAI blending assistant. कोणते casks वापरायचे हे निवडण्यासाठी पाहा AI for Cask Selection and Maturing-Stock Inventory. संपूर्ण यादी The Still and the Model मालिकेच्या पानावर आहे.
वारंवार विचारले जाणारे प्रश्न
SCD2 table म्हणजे काय आणि casks साठी ते का वापरावे? type 2 slowly changing dimension नोंद overwrite करण्याऐवजी तिची प्रत्येक आवृत्ती ती ज्या तारखांना वैध होती त्यांसह ठेवते. casks साठी याचा अर्थ cask ची आजवरची प्रत्येक warehouse position, मालक आणि status त्यांच्या तारखांसह table मध्ये राहतात. March 2019 मध्ये cask कुठे होता असे विचारून तुम्हाला उत्तर मिळू शकते, आणि microclimate analysis, audits आणि ग्राहकांच्या प्रश्नांसाठी हे महत्त्वाचे आहे.
cask inventory मध्ये angel’s share कसा काढावा? काढलेला आकडा म्हणून, साठवलेला कधीच नाही. भरतानाचे litres of absolute alcohol घ्या, त्यातून शेवटच्या regauge मधील alcohol आणि नोंदवलेले samples किंवा withdrawals वजा करा, आणि जे उरते तो loss. field म्हणून साठवलेला angel’s share शिळा होतो आणि sampling लपवतो. events वरून काढलेला तो नेहमी अद्ययावत आणि स्पष्टीकरण देता येण्याजोगा असतो.
GenAI assistant maturing stock बद्दलच्या प्रश्नांची उत्तरे देऊ शकतो का? हो, जर तो raw tables ऐवजी governed queries मार्फत उत्तर देत असेल. त्याला event आणि SCD2 tables वर आधारित cask_history, position_on आणि alcohol_balance सारखे tools द्या, आणि दिलेल्या fill मधील कोणत्या casks नी नेहमीपेक्षा जास्त गमावले यासारख्या प्रश्नांची तो उत्तरे देऊ शकतो, प्रत्येक आकडा query मधून येत.