فصل 26 از 50 درس 1 از 1

فصل بیست‌وششم — 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 قرار می‌گیرد.

شکل ۲۶-۱ — معماری کلی Folder + Combine Files
شکل ۲۶-۱ — معماری کلی Folder + Combine Files

۲۶.۲. 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.csvBackup؛ باید فیلتر شود

هرچه 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

شکل ۲۶-۲ — Pipeline مقاوم با کنترل Schema
شکل ۲۶-۲ — Pipeline مقاوم با کنترل Schema

برای ورودی دوره‌ای مشخص کن چه ستون‌هایی 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 است.

BranchExpectedReceivedStatus
THR11OK
TBZ10Missing
SHZ12Duplicate?

۲۶.۲۶. 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

فیلدنمونه
SourceFileTHR_1405-05-01_Sales.csv
BranchTHR
Rows12,540
SalesTotal...
StatusAccepted
IssueNone

۲۶.۴۲. خطای رایج؛ 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فهرست و فیلتر
MetadataBranch/Period/File
TransformFunction مشترک
ValidationSchema/Type/Rows/Totals
ExceptionsRejected/Missing/Duplicate
IntegrationUnified FactSales
AuditFile 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های قابل تنظیم.