یک نهاد دولتی مانند استانداری، همزمان با دادههای مالی دستگاهها، اطلاعات پروژههای عمرانی، آمار جمعیتی، وضعیت روستاها و شهرها، دادههای مکانی، گزارشهای متنی، تصاویر، اطلاعات منابع طبیعی، شاخصهای خدمات عمومی و دهها مجموعه داده دیگر سروکار دارد. در چنین موقعیتی وقتی صحبت از ذخیرهسازی اطلاعات میشود، مسئله فقط حجم این اطلاعات نیست؛ مسئله اصلی این است که ماهیت آنها یکسان نیست.
گزارش بودجه یک جدول منظم و ساختاریافته است، اما تصویر ماهوارهای، نقشه GIS، گزارش کارشناسی یا متن درخواستهای مردمی چنین ساختاری ندارند. اگر قرار باشد همه این دادهها در یک معماری واحد جمعآوری و برای گزارشگیری، تحلیل مدیریتی و در آینده هوش مصنوعی آماده شوند، یک پرسش اساسی مطرح میشود: دادههای استان دقیقاً کجا باید قرار بگیرند؟
سالها پاسخ رایج، «Data Warehouse» یا انبار داده بود. با افزایش حجم و تنوع اطلاعات، Data Lake یا دریاچه داده مطرح شد. امروز نیز معماریهای جدیدتر مانند Lakehouse تلاش میکنند مزایای هر دو را کنار یکدیگر قرار دهند.
برای مدیریت استانی، انتخاب میان این مدلها صرفاً یک تصمیم فنی نیست؛ معماری داده استانی تعیین میکند مدیران چه اطلاعاتی را بتوانند کنار هم ببینند، با چه سرعتی گزارش بگیرند و تا چه اندازه برای تحلیلهای آینده آماده باشند.
Data Warehouse چیست و چرا هنوز اهمیت دارد؟
Data Warehouse را میتوان یک مخزن سازمانیافته برای دادههایی دانست که قرار است مرتب تحلیل و گزارش شوند. اطلاعات پیش از ورود به انبار داده پاکسازی، استاندارد و در قالب ساختار مشخصی قرار میگیرند.
برای مثال اگر قرار باشد وضعیت پروژههای عمرانی تمام شهرستانهای یک استان مقایسه شود، Data Warehouse میتواند دادههایی مانند اعتبار مصوب، میزان تخصیص، پیشرفت فیزیکی، تاریخ شروع و وضعیت پروژه را از سامانههای مختلف دریافت و در یک مدل مشترک قرار دهد.
مزیت بزرگ این معماری، نظم است.
وقتی مدیر سؤالهایی مشخص و پرتکرار دارد، انبار داده محیط بسیار مناسبی فراهم میکند. گزارشهای رسمی، داشبوردهای مدیریتی، مقایسه دورهای عملکرد و شاخصهای استاندارد معمولاً در چنین ساختاری عملکرد خوبی دارند.
وب سرویس آمازون (AWS) نیز Data Warehouse را برای تحلیل سریع حجم بزرگی از داده و استفاده از ابزارهای Business Intelligence مناسب میداند.
اما همین نظم، یک محدودیت نیز ایجاد میکند: معمولاً قبل از ورود اطلاعات باید بدانیم قرار است با آن چه کنیم.
وقتی داده دیگر فقط جدول نیست؛ Data Lake وارد میشود
فرض کنیم علاوه بر اطلاعات مالی و پروژهها، استانداری بخواهد این موارد را نیز نگهداری و تحلیل کند:
تصاویر پروژهها، فایلهای GIS، دادههای سنجش از دور، مکاتبات، PDFها، دادههای هواشناسی، اطلاعات حسگرها، نظرات مردم یا حتی دادههایی که هنوز کاربرد تحلیلی دقیق آنها مشخص نشده است.
وارد کردن تمام این اطلاعات به ساختار سختگیرانه یک Data Warehouse دشوار و گاهی غیرمنطقی است.
Data Lake برای حل همین مسئله شکل گرفته است. دریاچه داده میتواند حجم بزرگی از اطلاعات ساختاریافته، نیمهساختاریافته و بدون ساختار را در قالب اولیه یا نزدیک به قالب اولیه آنها نگهداری کند. AWS نیز یکی از مزیتهای اصلی Data Lake را امکان جمعآوری داده از سامانههای جزیرهای و فراهم کردن بستری برای تحلیل پیشرفته و یادگیری ماشین میداند.
به زبان ساده، Data Warehouse میگوید:
ابتدا مشخص کنیم این داده چیست و چگونه قرار است استفاده شود؛ بعد آن را ذخیره کنیم.
Data Lake بیشتر میگوید:
داده را در قالب اولیه یا نزدیک به قالب اولیه نگهداری کنیم تا بتوانیم امروز یا در آینده کاربردهای متفاوتی برای آن تعریف کنیم.
تفاوتهای اصلی در یک نگاه
موضوع |
Data Warehouse |
Data Lake |
| نوع داده | عمدتاً ساختاریافته | ساختاریافته، نیمهساختاریافته و بدون ساختار |
| هدف اصلی | گزارش و تحلیل مشخص | نگهداری گسترده و تحلیلهای متنوع |
| زمان تعریف ساختار | قبل از ورود داده | هنگام پردازش و استفاده نیز امکانپذیر است |
| مناسب برای | داشبورد، KPI، گزارش رسمی | AI، تحلیل پیشرفته، GIS، فایل و داده خام |
| انعطاف | کمتر | بیشتر |
| کنترل و استانداردسازی | معمولاً قویتر | نیازمند Data Governance جدیتر |
| ریسک اصلی | محدود شدن به ساختارهای از پیش تعریفشده | تبدیل شدن به «Data Swamp» در صورت مدیریت ضعیف |
این جدول یک نکته مهم را آشکار میکند: هیچکدام از این دو روش ذاتاً «بهتر» نیستند بلکه هر یک، مسئله متفاوتی را حل میکنند.
مسئله مدیریت استانی دقیقاً چیست؟
در مدیریت استانی، داده فقط از یک سازمان یا یک سطح مدیریتی نمیآید. ساختار خود مدیریت محلی نیز چندلایه است:
استان | شهرستان | بخش | روستا
و در کنار آن، دهیاریها، شهرداریها و دستگاههای مختلف نیز مجموعه اطلاعات خود را تولید میکنند.
از طرف دیگر، یک مدیر استانی دو نیاز کاملاً متفاوت دارد. نیاز اول، گزارش رسمی و قابل اتکاست؛ مثلاً:
- میزان اعتبار عمرانی شهرستانها چقدر است؟
- کدام پروژهها عقب هستند؟
- عملکرد مالی واحدهای مشابه چه تفاوتی دارد؟
در چنین شرایطی Data Warehouse بسیار مناسب است.
اما نیاز دوم، کشف ارتباطهای جدید میان دادههایی است که الزاماً از قبل برای یک گزارش مشخص طراحی نشدهاند؛ مثلاً ترکیب اطلاعات مکانی، جمعیتی، منابع آب، پروژههای عمرانی و دادههای اقتصادی برای پیدا کردن مناطق نیازمند مداخله.
اینجا Data Lake ظرفیت بیشتری دارد.
بنابراین سؤال درست برای یک استان این نیست که:
Data Warehouse یا Data Lake؟
سؤال بهتر این است:
کدام نوع داده و کدام نیاز مدیریتی باید در کدام لایه قرار گیرد؟
خطر Data Lake؛ وقتی دریاچه داده به باتلاق داده تبدیل میشود
نباید دور از نظر داشت که انعطافپذیری Data Lake گاه میتواند به نقطه ضعف آن هم تبدیل شود.
اگر هر دستگاه فایلها و دادههای خود را بدون استاندارد مشخص وارد کند، بعد از مدتی ممکن است سازمان با هزاران مجموعه داده مواجه شود که معلوم نیست چه کسی تولیدشان کرده، آخرین بار چه زمانی بهروزرسانی شدهاند یا نسخه معتبر کدام است.
در ادبیات مدیریت داده برای این وضعیت اصطلاح Data Swamp یا «باتلاق داده» به کار میرود.
جلوگیری از این وضعیت نیازمند مدیریت Metadata، شناسنامه داده، Data Catalog، ثبت منشأ اطلاعات، کنترل کیفیت و تعیین سطح دسترسی است. معماریهای مدرن داده نیز دقیقاً بر Metadata Management، Data Lineage و حکمرانی یکپارچه تأکید دارند.
یعنی ساخت Data Lake بدون Data Governance، میتواند مسئله پراکندگی داده را حل نکند و فقط آن را به مخزن بزرگتری منتقل کند.
Lakehouse؛ چرا مجبور به انتخاب یکی از دو مدل نیستیم؟
طی سالهای اخیر، معماری دیگری با عنوان Data Lakehouse گسترش پیدا کرده است. ایده اصلی ساده است: چرا باید میان انعطاف Data Lake و نظم Data Warehouse یکی را انتخاب کنیم؟
Lakehouse تلاش میکند دادههای متنوع را در یک زیرساخت گسترده نگهداری کند، اما قابلیتهایی مانند ساختار جدولی، تراکنش قابل اتکا، کنترل کیفیت، مدیریت نسخه و گزارشگیری سریع را نیز به آن اضافه کند.
مایکروسافت و آمازون هر دو معماری Lakehouse را راهی برای ترکیب ویژگیهای Data Lake و Data Warehouse معرفی میکنند. در این مدل میتوان داده خام و متنوع را حفظ کرد و همزمان یک لایه ساختاریافته برای گزارشهای رسمی و Business Intelligence ایجاد کرد.
برای مدیریت استانی، این مدل اهمیت خاصی دارد؛ چون قرار نیست همه دادههای استان یک شکل داشته باشند.
میتوان دادههای ساختاریافته و تأییدشده را برای گزارشهای رسمی آماده کرد، بدون آن که مجبور باشیم دادههای خام، مکانی، متنی یا تصویری را کنار بگذاریم.
برای مدیریت استانی ایران کدام مدل منطقیتر است؟
اگر قرار باشد معماری یک استان را از صفر طراحی کنیم، یک Data Warehouse سنتی و مستقل را بهتنهایی توصیه نمیکنیم، زیرا داده استانی بسیار متنوعتر از آن است که همه چیز از ابتدا در جدولهای ثابت خلاصه شود.
از سوی دیگر، ساخت یک Data Lake بزرگ بدون لایه حکمرانی و ساختار گزارش نیز تصمیم پرخطری است چون مدیران برای بسیاری از وظایف روزمره به دادههای استاندارد و رسمی نیاز دارند.
مدل منطقیتر، یک معماری ترکیبی یا Lakehouse است:
- Data Lake / Lakehouse برای نگهداری مجموعه گسترده دادهها؛
- لایههای استاندارد و کنترلشده برای دادههای معتبر؛
- Data Warehouse یا Data Mart برای گزارشهای ثابت و رسمی؛
- و یک لایه تحلیل برای داشبورد، هوش مصنوعی و پرسشهای مدیریتی.
به این ترتیب، مدیر استانی مجبور نیست میان «انعطاف» و «اعتمادپذیری» یکی را انتخاب کند.
چه دادهای کجا قرار بگیرد؟
برای ملموستر شدن موضوع، معماری یک استان میتواند تقریباً چنین تفکیکی داشته باشد:
این تفکیک یک اصل اساسی دارد:
هر دادهای قرار نیست در یک پایگاه واحد ریخته شود؛ هدف، ایجاد معماری واحد برای مدیریت چند نوع مخزن داده است.
نقش سماد در این نوع معماری چیست؟
سماد در حال حاضر بخش مهمی از دادههای ساختاریافته مدیریت روستایی را در حوزههایی مانند امور مالی، بودجه، منابع انسانی، پروژهها، مصوبات، ساختوساز و ارزیابی عملکرد تولید و یکپارچه میکند.
اگر در آینده یک زیرساخت داده استانی طراحی شود، چنین سامانههایی میتوانند به جای ایجاد فایلهای پراکنده، یکی از منابع معتبر داده آن باشند.
اما ارزش اصلی زمانی ایجاد میشود که داده سماد بتواند در کنار دادههای دیگر قرار گیرد؛ مثلاً اطلاعات جمعیتی، منابع طبیعی، کشاورزی، آب، زیرساخت، سلامت یا سایر دادههای دستگاههای استانی.
آن زمان پرسش مدیریتی نیز از محدوده یک سیستم فراتر میرود: کدام مناطق همزمان با کاهش جمعیت، محدودیت منابع آب و ضعف سرمایهگذاری عمرانی روبهرو هستند؟
یا: کدام روستاها با وجود ظرفیت گردشگری بالا، زیرساخت خدماتی کمتری نسبت به مناطق مشابه دارند؟
اینجا دیگر موضوع فقط گزارشگیری سماد نیست؛ صحبت از یک معماری داده استانی است که سامانههای تخصصی، از جمله سماد، اجزای آن را تشکیل میدهند.
سماد، تجربهای منحصر بفرد
سامانه یکپارچه و هوشمند مدیریت امور دهیاریها، برای تغییر رویکرد از مدیریت سنتی به یک سیستم شفاف و منسجم.
قبل از انتخاب فناوری، این سؤالها را پاسخ دهید
بحث Data Warehouse، Data Lake یا Lakehouse خیلی سریع میتواند به بحث برند نرمافزار، فضای ابری و فناوری ذخیرهسازی تبدیل شود؛ در حالی که این نقطه شروع درستی نیست.
ابتدا باید روشن شود:
پاسخ به این سؤالهاست که معماری مناسب را تعیین میکند، نه محبوبیت یک فناوری.
جمعبندی؛ پاسخ درست معمولاً «هر دو» است
Data Warehouse هنوز یکی از بهترین ابزارها برای گزارشهای ساختاریافته، شاخصهای رسمی و تحلیلهای تکرارشونده است. Data Lake نیز انعطاف لازم برای نگهداری حجم بزرگی از دادههای متنوع را فراهم میکند.
اما مدیریت استانی برای استانداری، به هر دو نوع نیاز دارد.
یک استان هم باید بتواند گزارش رسمی تولید کند و هم دادههایی را نگهداری کند که هنوز کاربرد آینده آنها کاملاً مشخص نیست. هم به داشبوردهای ثابت نیاز دارد و هم به هوش مصنوعی، GIS، تحلیل متون و مدلهای پیشبینی.
به همین دلیل، معماریهای مدرن به سمت ترکیب این دو جهان حرکت کردهاند. Lakehouse یا معماری ترکیبی میتواند برای یک استان منطقیتر باشد؛ به شرطی که حکمرانی داده، کیفیت، امنیت و چرخه عمر اطلاعات از ابتدا در طراحی آن دیده شوند.
هدف نهایی نیز نباید ساخت بزرگترین مخزن داده استان باشد. ایدهآل این است که دادههای پراکنده دستگاهها بتوانند در زمان مناسب، با سطح دسترسی مناسب و کیفیت قابل اعتماد، کنار هم قرار گیرند و به مدیر برای شناخت بهتر استان کمک کنند.
در چنین مدلی، داده از یک محصول جانبی فعالیت اداری به بخشی از زیرساخت حکمرانی تبدیل میشود.
شرکت دانشبنیان تدبیرنگر، توسعهدهنده راهکارهای هوشمند، سامانههای اتوماسیون و خدمات یکپارچه دیجیتال در مسیر تحول و توانمندسازی سازمانی کارآمد.
آدرس
ارومیه – خیابان برق از سمت بلوار شهید بهشتی، کوچه ۳، پلاک ۱۲
ایمیل
hello@tadbirnegar.ir
tadbirnegar.com@gmail.com
