فصل بیستوششم — Folder Connector و Combine Files حرفهای؛ ساخت ورودی خودکار فایلهای دورهای
Folder Connector و Combine Files حرفهای؛ ساخت ورودی خودکار فایلهای دورهای
بخشی از آموزش جامع Power BI
محتوای درس Folder Connector و Combine Files حرفهای؛ ساخت ورودی خودکار فایلهای دورهای
مقدمه؛ دیگر فایل ماه بعد را دستی Import نکن
در فصل قبل Append را یاد گرفتیم. حالا یک قدم حرفهایتر میرویم: به جای اینکه هر ماه Query جدید بسازیم، Power Query را به یک Folder وصل میکنیم تا فایلهای معتبر را پیدا کند، یک منطق مشترک روی همه اجرا کند و خروجی یکپارچه بسازد.
این الگو برای فروش شعب، گزارشهای روزانه تولید، لاگ دستگاهها، فایلهای مالی دورهای و خیلی از پروژههای واقعی کاربرد دارد.
۲۶.۱. Folder Connector چه میدهد؟
وقتی به Folder وصل میشوی فقط محتوای فایل را نمیبینی؛ اطلاعاتی مثل Name، Extension، Date modified، Folder Path و Content هم در اختیار Query قرار میگیرد.
۲۶.۲. Content ستون مهم ماست
ستون Content معمولاً Binary فایل را نگه میدارد. Combine Files از همین محتوا برای اجرای Transformation مشترک روی فایلها استفاده میکند.
۲۶.۳. قبل از Combine فیلتر کن
اشتباه رایج این است که سریع روی Combine کلیک کنیم. اول مشخص کن دقیقاً کدام فایلها باید وارد Pipeline شوند.
Extension = ".csv"
Name starts with "Sales_"
Not temporary
Correct folder path
۲۶.۴. Naming Convention
| نام فایل | معنی |
|---|---|
| THR_1405-05-01_Sales.csv | شعبه تهران + تاریخ |
| TBZ_1405-05-01_Sales.csv | شعبه تبریز + تاریخ |
| ~$Sales.xlsx | فایل موقت؛ نامعتبر |
| Sales_Backup.csv | Backup؛ باید فیلتر شود |
هرچه Naming Convention رسمیتر باشد، Automation قابل اعتمادتر میشود.
۲۶.۵. Sample File چیست؟
وقتی Combine Files را اجرا میکنی، Power Query معمولاً یک فایل را به عنوان نمونه در نظر میگیرد تا Transformation مشترک روی آن طراحی شود.
بعد همان منطق به شکل Function روی فایلهای دیگر اجرا میشود.
۲۶.۶. Transform Sample File
Rename، Remove Columns، Promote Headers، Data Type و پاکسازی ساختاری را معمولاً در Query نمونه تنظیم میکنی.
نکته: Ruleهایی که فقط برای یک فایل خاص درستاند نباید وارد Transform Sample شوند.
۲۶.۷. Function خودکار
File Binary
→ Transform Function
→ Standardized Table
Power Query Function تولیدشده را برای هر فایل معتبر صدا میزند و نتیجهها در نهایت زیر هم قرار میگیرند.
۲۶.۸. فایل نمونه خوب انتخاب کن
اگر Sample File ناقص یا غیرعادی باشد، Transformation ممکن است بر اساس Schema اشتباه ساخته شود. بهتر است فایل نمونه نماینده ساختار استاندارد باشد.
۲۶.۹. Promote Headers
در فایلهای Excel/CSV باید مطمئن شوی Header واقعی در ردیف درست قرار دارد. بعضی گزارشها چند ردیف عنوان و توضیح قبل از Header دارند.
۲۶.۱۰. Skip Rows
Report title
Generated at...
----------------
Product | Qty | Amount
در چنین فایلی ممکن است ابتدا چند Row حذف و بعد Promote Headers انجام شود.
۲۶.۱۱. Sheet یا Table درست
در Excel ممکن است چند Sheet وجود داشته باشد. Transform Sample باید Sheet/Table موردنظر را به شکل پایدار انتخاب کند؛ انتخاب صرفاً اولین Sheet میتواند خطرناک باشد.
۲۶.۱۲. Schema Contract
برای ورودی دورهای مشخص کن چه ستونهایی Required، Optional و Forbidden هستند.
۲۶.۱۳. Required Columns
Required:
OrderNo
OrderDate
ProductCode
Quantity
SalesAmount
اگر SalesAmount حذف شده، بهتر است Pipeline هشدار جدی بدهد تا اینکه گزارش ناقص را بیصدا تولید کند.
۲۶.۱۴. Optional Columns
ستونی مثل SalesPersonComment ممکن است اختیاری باشد. نبودنش نباید لزوماً کل Refresh را متوقف کند.
۲۶.۱۵. ستون جدید
اگر سیستم منبع ستون جدیدی اضافه کرد، تصمیم بگیر آن را Ignore میکنی، ثبت میکنی یا Schema Review لازم است. رفتار باید آگاهانه باشد.
۲۶.۱۶. Schema Drift Detection
میتوان لیست نام ستونهای فایل را با Schema مورد انتظار مقایسه کرد و فایلهای ناسازگار را در Query خطاها جدا کرد.
Expected columns
vs
Actual columns
→ Missing / Extra
۲۶.۱۷. Data Type Drift
ممکن است نام ستون ثابت بماند ولی Amount از Number به Text تبدیل شود. بنابراین Schema فقط اسم ستون نیست؛ Type هم مهم است.
۲۶.۱۸. Metadata را نگه دار
نام فایل، تاریخ فایل، Branch و Period را تا مراحل کنترل کیفیت نگه دار. این اطلاعات برای Debug بسیار ارزشمندند.
۲۶.۱۹. استخراج Branch از نام فایل
THR_1405-05-01_Sales.csv
Split '_'
→ BranchCode = THR
این کار فقط وقتی قابل اتکاست که قرارداد نامگذاری رسمی باشد.
۲۶.۲۰. استخراج تاریخ فایل
اگر تاریخ داخل نام فایل منبع رسمی Period است، میتوان آن را استخراج کرد. ولی اگر تاریخ تراکنش داخل خود فایل وجود دارد، این دو مفهوم را با هم قاطی نکن.
۲۶.۲۱. Folder Path
در ساختار پوشه سال/ماه/شعبه، Folder Path خودش Metadata خوبی است و میتواند برای کنترل ورودی استفاده شود.
۲۶.۲۲. Hidden Files
فایلهای Hidden یا System را از Pipeline عملیاتی حذف کن مگر اینکه دلیل مشخصی برای خواندنشان داشته باشی.
۲۶.۲۳. Temporary Files
فایل Excel باز ممکن است فایل موقتی با ~$ بسازد. ورود آن به Combine میتواند Error یا Duplicate ایجاد کند.
۲۶.۲۴. Duplicate File Detection
نام فایل تنها معیار Duplicate نیست. ممکن است دو فایل با نام متفاوت ولی داده یکسان وجود داشته باشند.
برای سیستمهای حساس میتوان File ID، تاریخ، Row Count یا کنترلهای Hash/Business Key را در معماری در نظر گرفت.
۲۶.۲۵. Missing File Detection
اگر هر روز باید یک فایل از هر شعبه برسد، نبودن فایل خودش یک Event مهم Data Quality است.
| Branch | Expected | Received | Status |
|---|---|---|---|
| THR | 1 | 1 | OK |
| TBZ | 1 | 0 | Missing |
| SHZ | 1 | 2 | Duplicate? |
۲۶.۲۶. Quality Gate
قبل از اینکه داده وارد Fact نهایی شود، چند کنترل پایه تعریف کن: Schema، Type، Row Count، Nullهای حیاتی، Duplicate و Total.
Files → Transform → Validate → Accept / Reject
۲۶.۲۷. Reject Query
فایل یا Row نامعتبر را لزوماً حذف نکن. میتوان آن را در Query جداگانه نگه داشت تا تیم عملیات علت را ببیند.
۲۶.۲۸. Error Handling
در Function میتوان بعضی تبدیلها را با منطق کنترل خطا طراحی کرد، اما هدف پنهان کردن Error نیست؛ هدف تولید خطای قابل فهم و قابل پیگیری است.
۲۶.۲۹. try ... otherwise
try Number.FromText([Amount]) otherwise null
این الگو مفید است ولی اگر هر خطا را Null کند ممکن است Data Quality Issue پنهان شود. بهتر است Error Flag یا Exception Log هم داشته باشی.
۲۶.۳۰. فایل خراب
ممکن است یک فایل Corrupt باشد و بقیه سالم. سیاست سازمان باید مشخص کند Refresh کل Dataset متوقف شود یا فایل خراب Reject و Incident ثبت شود.
۲۶.۳۱. CSV و Encoding
فایلهای CSV ممکن است Encoding و Delimiter متفاوت داشته باشند. فارسی بهخصوص باید از نظر نمایش صحیح حروف تست شود.
۲۶.۳۲. Decimal Separator
فایل تولیدشده در Locale متفاوت ممکن است 1,25 یا 1.25 داشته باشد. Using Locale و قرارداد فایل را جدی بگیر.
۲۶.۳۳. Performance
هزاران فایل کوچک معمولاً بدتر از تعداد کمتر فایل بزرگتر هستند. اگر معماری Source دست خودتان است، Consolidation دورهای را بررسی کنید.
۲۶.۳۴. Archive Strategy
پوشه ورودی را با آرشیو قاطی نکن. مثلاً Incoming، Processed، Rejected و Archive میتوانند Lifecycle فایل را شفاف کنند.
۲۶.۳۵. Power BI Service و مسیر فایل
مسیر محلی لپتاپ توسعهدهنده برای Production مناسب نیست. محل فایل و روش دسترسی باید با معماری Refresh، Gateway یا Storage سازمان هماهنگ باشد.
۲۶.۳۶. Gateway
اگر Folder روی شبکه داخلی است، Refresh در Service ممکن است به Gateway و تنظیمات صحیح Data Source نیاز داشته باشد.
مالکیت و Credential آن را سازمانی طراحی کن.
۲۶.۳۷. SharePoint/Cloud Storage
اگر فایلها در SharePoint یا Storage ابری هستند، Connector و معماری دسترسی متفاوت میشود. مفهوم Pipeline مشابه است ولی پیادهسازی باید با منبع واقعی هماهنگ شود.
۲۶.۳۸. مثال شرکت هانا
۲۰ شعبه هر شب فایل Sales ارسال میکنند. سیستم باید ۲۰ فایل مورد انتظار را کنترل کند، فایلهای Duplicate یا Missing را مشخص کند، Schema را Validate کند و فقط داده معتبر را به FactSales ببرد.
۲۶.۳۹. معماری پیشنهادی شرکت هانا
Incoming Folder
→ File Filter
→ Metadata Extraction
→ Transform Function
→ Schema/Quality Checks
→ Valid Rows → FactSales
→ Invalid Files/Rows → Exceptions
۲۶.۴۰. کنترل جمع مبلغ هر فایل
قبل و بعد از Transformation مجموع SalesAmount هر فایل را ثبت کن. این کار برای Reconciliation بسیار ارزشمند است.
۲۶.۴۱. Audit Table
| فیلد | نمونه |
|---|---|
| SourceFile | THR_1405-05-01_Sales.csv |
| Branch | THR |
| Rows | 12,540 |
| SalesTotal | ... |
| Status | Accepted |
| Issue | None |
۲۶.۴۲. خطای رایج؛ Combine قبل از Filter
اگر Backup و Temporary وارد Function شوند، Error و Duplicate میگیری. اول File List را تمیز کن.
۲۶.۴۳. خطای رایج؛ وابستگی به یک Sample عجیب
Sample File باید نماینده قرارداد استاندارد باشد، نه اولین فایل تصادفی پوشه.
۲۶.۴۴. خطای رایج؛ حذف Metadata
اگر Name و Source را خیلی زود حذف کنی، موقع Debug نمیفهمی ردیف خراب از کدام فایل آمده.
۲۶.۴۵. خطای رایج؛ موفقیت Refresh = سلامت داده
Refresh سبز فقط یعنی Pipeline اجرا شده؛ تضمین نمیکند همه فایلهای مورد انتظار آمده یا Total درست است.
۲۶.۴۶. Best Practiceها
قبل از Combine، File List را فیلتر کن.
Naming Convention رسمی داشته باش.
Sample File استاندارد انتخاب کن.
Schema Contract تعریف کن.
Metadata منبع را نگه دار.
Missing/Duplicate File Check بساز.
Invalid Data را قابل مشاهده کن.
Totals را Reconcile کن.
مسیر Production و Gateway را از ابتدا در نظر بگیر.
۲۶.۴۷. تمرین پایه
پوشهای با سه CSV فروش و یک فایل Backup فرض کن. Rule بنویس که فقط فایلهای Sales معتبر وارد Combine شوند.
۲۶.۴۸. تمرین متوسط
از نام THR_1405-05-01_Sales.csv کد شعبه و Period را استخراج کن و به همه Rowهای همان فایل اضافه کن.
۲۶.۴۹. تمرین Schema Drift
فرض کن فایل جدید ستون SalesAmount را ندارد. یک سیاست طراحی کن که فایل را Reject کند و Missing Column را در Exception Report نشان دهد.
۲۶.۵۰. تمرین چالشی
برای ۲۰ شعبه یک Expected File Matrix بساز که Missing، Duplicate و Late File را تشخیص دهد و بگوید کدام فایل اجازه ورود به Fact دارد.
۲۶.۵۱. پروژه نهایی فصل؛ Automated Branch File Ingestion
| لایه | وظیفه |
|---|---|
| Landing | دریافت فایل |
| Discovery | فهرست و فیلتر |
| Metadata | Branch/Period/File |
| Transform | Function مشترک |
| Validation | Schema/Type/Rows/Totals |
| Exceptions | Rejected/Missing/Duplicate |
| Integration | Unified FactSales |
| Audit | File processing log |
هدف این است که ورود فایل ماه بعد نیازمند ساخت Query جدید نباشد و در عین حال Pipeline بتواند ورودی ناقص یا خراب را تشخیص دهد.
جمعبندی فصل بیستوششم
Folder + Combine Files وقتی واقعاً حرفهای میشود که فقط Automation نباشد؛ باید کنترل کیفیت، Metadata، Schema Contract و Audit هم کنارش باشد.
Discover → Filter → Transform → Validate → Integrate → Audit
فصل بیستوهفتم را به Parameters در Power Query اختصاص میدهیم؛ برای حذف Hard-code، مدیریت Dev/Test/Prod، مسیر فایلها، Serverها و ساخت Queryهای قابل تنظیم.