الگوهای پیشنهادی

تعیین مدیر داده و فضا

برای استفاده‌ی مؤثر از یک انبار داده، صرفاً داشتن زیرساخت تحلیلی کافی نیست و لازم است ساختار مشخصی برای مدیریت و تولید داده در داخل سازمان وجود داشته باشد. کیفیت تحلیل‌ها و خروجی‌ها مستقیماً به کیفیت مدل‌سازی، مالکیت و فرآیندهای مرتبط با داده وابسته است. به‌دلیل الزامات حاکمیت داده (Data Governance)، وجود یک مدیریت متمرکز برای نظارت بر ساختار، کیفیت و دسترسی به داده‌ها ضروری است و از پراکندگی تصمیم‌ها و تفسیرهای متفاوت از داده جلوگیری می‌کند.

توصیه می‌شود حداقل یک نفر با آشنایی فنی مناسب نسبت به مفاهیم داده، مدل‌سازی و پایگاه‌های داده به‌عنوان مسئول اصلی داده در سازمان تعیین شود. این نقش می‌تواند بسته به ساختار سازمان با عناوینی مانند Data Owner، Data Lead، Analytics Lead یا Data Manager تعریف شود و مسئولیت تصمیم‌گیری در خصوص مدل داده، تعاریف تحلیلی، تغییرات اسکیما و هماهنگی بین تیم‌های مختلف را بر عهده داشته باشد. وجود چنین نقشی به شکل‌گیری یک مرجع واحد برای داده کمک می‌کند و اجرای مؤثر سیاست‌های حاکمیت داده را امکان‌پذیر می‌سازد.

پیشنهاد می‌شود این فرد در داده‌لند نیز به‌عنوان مدیر فضا افزوده شود تا مسئولیت‌های مرتبط با انبار داده در سطح ابزار نیز به‌صورت متمرکز مدیریت شود. مدیر فضا در داده‌لند به تمامی بخش‌ها دسترسی دارد و می‌تواند تعریف و نگهداری اسکیماها، مدیریت دسترسی کاربران، نظارت بر کیفیت داده و هماهنگی تغییرات را مستقیماً در محیط انبار داده انجام دهد. هم‌راستاسازی این نقش سازمانی با نقش مدیر فضا در داده‌لند، اجرای تصمیم‌های داده‌ای را ساده‌تر کرده و از بروز ناهماهنگی بین ساختار سازمان و پیاده‌سازی فنی جلوگیری می‌کند.

استفاده از جداول استیجینگ و رویکرد ELT

در داده‌لند، به جای استقرار یک لایه‌ی مجزای Data Lake برای نگهداری داده‌های خام، از جداول استیجینگ (Staging) استفاده می‌شود. در این رویکرد، داده‌های خام مستقیماً و بدون نیاز به پردازش پیشین، طی فرآیند ELT، در جداول استیجینگ به شکل نیمه‌ساختاریافته (تحت ستون جیسون) ذخیره می‌شوند و سپس با قابلیت Transform داده‌لند به جداول نهایی (Fact و Dimension) تبدیل می‌گردند. جداول استیجینگ عملاً نقش Data Lake را در نگهداری نسخه‌ی مرجع و خام داده‌ها ایفا می‌کنند، بدون آنکه نیاز به استقرار و نگهداری یک زیرساخت جداگانه‌ی فایل‌محور با هزینه و پیچیدگی فنی بالا باشد. این معماری یکپارچه به تیم داده اجازه می‌دهد داده‌های خام را با کمترین تأخیر در دسترس داشته و هرگاه نیاز به تغییر منطق تحلیلی یا اضافه‌شدن فیلدهای جدید باشد، تنها با بازنویسی کوئری‌های تبدیل از همان داده‌های ذخیره‌شده به خروجی جدید برسند.

برای پیروی از استانداردهای امروز داده و مزیت‌های ذخیره داده‌های خام، توصیه می‌شود از رویکرد ELT به جای ETL استفاده شود. برای آشنایی بیشتر به مطلب مقایسه ETL و ELT مراجعه کنید.

استفاده از ماژول‌ها

در داده‌لند، علاوه بر امکان ساخت جداول سفارشی، مجموعه‌ای از ماژول‌های آماده نیز در اختیار شما قرار دارد. این ماژول‌ها فراتر از کانکتورهای مرسوم در ابزارهای هوش تجاری عمل کرده و با داشتن اسکیمای داده آماده، تنظیمات اختصاصی و داشبوردهای تحلیلی از پیش‌ساخته، فرآیند تحلیل داده را به شکل چشمگیری تسریع می‌کنند. برخی از این ماژول‌ها (با قابلیت لینکر) فرآیند اتصال و جمع‌آوری داده از منابع مختلف را به صورت خودکار انجام می‌دهند تا شما با کمترین دغدغه فنی، به بینش‌های ارزشمند دست یابید.

توصیه داده‌لند این است که اگر برای ماهیت داده مدنظر شما ماژولی وجود دارد، از آن استفاده کرده و از ساخت جدول سفارشی پرهیز کنید. دلیل این توصیه، اتصال و یکپارچگی ماژول‌ها با یکدیگر است. ماژول‌ها، با اتصال به یکدیگر، یک ساختار یکپارچه را تشکیل می‌دهند و به شما اجازه می‌دهد تا دیدگاه‌های ترکیبی و عمیق‌تری از سازمان خود به دست آورید؛ قابلیتی که در جداول سفارشی مجزا به سادگی قابل دستیابی نیست. استفاده از ماژول‌ها به معنای بهره‌مندی از یک اکوسیستم تحلیلی هوشمند و از پیش‌آماده است که پیچیدگی‌ها را کاهش داده و شما را مستقیماً به نتیجه می‌رساند.

استفاده از الگوی کیمبال

همانطور که در بخش معماری داده‌ها اشاره شده است، داده‌لند بر اساس اصول مدل‌سازی کیمبال طراحی شده و از آن پشتیبانی می‌کند. بر همین اساس، برای دستیابی به بهینه‌ترین عملکرد، ساختار و قابلیت تحلیل، توصیه می‌شود که مدل‌سازی داده‌های خود را با استفاده از دو نوع جدول اصلی انجام دهید: جدول وقایع (Fact) و جدول وصف (Dimension). استفاده از این الگو به شما کمک می‌کند تا داده‌ها را برای گزارش‌گیری و تحلیل‌های کسب‌وکار به شکلی استاندارد و کارآمد سازماندهی کنید.

نوع سوم جدول، یعنی جدول خام (Raw)، نیز در دسترس است. این نوع جدول برای ذخیره‌سازی داده‌های خام استیجینگ (Staging) یا داده‌های فاقد شناسه واقعه مشخص کاربرد دارد. از نمونه‌های مناسب برای این نوع جدول می‌توان به داده‌های سری زمانی (Time-Series) و لاگ‌های رویدادمحور اشاره کرد. در صورتی که نوع داده شما می‌تواند در ردیف جدول وقایع (Fact) قرار بگیرد، بهتر است به جای جدول خام از جدول وقایع استفاده شود.

یکی از اصول مدل کیمبال، نرمال‌سازی (Normalized) جداول وقایع است. بهتر است داده‌های Dimension و Fact در جداول مجزا ثبت و به کمک شناسه (ID) به یکدیگر مرتبط شوند. با این کار به کمک یک اتصال (JOIN) در کوئری تمامی داده‌های توصیفی به راحتی در دسترس خواهند بود و نگهداری داده‌ها و مدل‌ها با سهولت و خطای کمتری همراه خواهد بود.

در زمینه مدل‌سازی هر چند کیمبال مدل ستاره‌ای (Star Schema) را پیشنهاد می‌دهد اما در محصول داده‌لند محدودیتی در ایجاد جداول وصف تودرتو (Snowflake Schema) وجود ندارد و عملکرد مطلوب داده‌لند در اتصال (JOIN) امکان بهره‌برداری از مدل Snowflake در لایه تحلیل را فراهم می‌کند.

لود Micro-batch

داده‌لند به طور کامل از ارسال داده به صورت گروهی (Bulk) و در حجم بالا پشتیبانی می‌کند. با این حال، از آنجایی که زیرساخت داده‌لند برای پردازش جریان‌های داده (Data Streams) بهینه شده است، توصیه ما برای بهره‌برداری حداکثری از پتانسیل تحلیلی، استفاده از الگوی میکرو-بچ (Micro-batch) و ارسال داده‌ها به صورت نزدیک به آنی (Near Real-time) است. در این رویکرد، داده‌ها در دسته‌های کوچک و به‌صورت دوره‌ای به داده‌لند ارسال می‌شوند؛ توصیه می‌شود بازه‌ی ارسال (Interval) میکرو-بچ‌ها حداقل ۵ دقیقه یا بیشتر در نظر گرفته شود.

این الگو تضمین‌کننده تازگی اطلاعات (Data Freshness) در داشبوردهاست، امکان مانیتورینگ شاخص‌ها را در زمان نزدیک به لحظه فراهم می‌کند و زیرساخت لازم برای پیاده‌سازی قابلیت‌های پیشرفته‌ای مانند اتوماسیون و سیستم‌های هشداردهی در آینده را مهیا می‌سازد.

در جدول زیر، الگوهای پیشنهادی برای بازه ارسال و لود داده به جداول ماژول‌های مختلف ارائه شده است:

استفاده از Flat JSON

ابزار هوش تجاری (BI) داده‌لند، قابلیت تحلیل داده‌های با فرمت JSON را مستقیماً در واسط کاربری خود فراهم می‌کند. با این حال، برای اطمینان از سازگاری کامل و عملکرد بهینه، این قابلیت صرفاً بر تحلیل ساختارهای JSON مسطح (Flat JSON) و کلیدهای تعریف‌شده در سطح ریشه (Root) متمرکز است.

بر همین اساس، توصیه می‌شود ستون‌هایی که حاوی داده‌های JSON هستند، همواره از یک ساختار مسطح پیروی کنند و از ایجاد آبجکت‌های تودرتو (Nested Objects) خودداری شود. در یک JSON مسطح، تمام زوج‌های کلید-مقدار (key-value pairs) در یک سطح قرار دارند. رعایت این الگو تضمین می‌کند که تمام ابزارهای تحلیلی و بصری‌سازی داده‌لند بتوانند به درستی داده‌های شما را پردازش و نمایش دهند.

{
  "order_id": 1001,
  "customer_name": "Ali Ahmadi",
  "total_amount": 150000,
  "city": "Tehran",
  "status": "delivered"
}

{
  "order_id": 1001,
  "customer": {
    "name": "Ali Ahmadi",
    "address": {
      "city": "Tehran"
    }
  },
  "total_amount": 150000,
  "status": "delivered"
}

استانداردسازی تاریخ و زمان

در راستای یکپارچگی داده‌ها و انطباق با اصول حاکمیت داده (Data Governance)، استفاده از فرمت زمانی واحد ضروری است. رعایت این استاندارد، پیچیدگی‌ها و خطاهای ناشی از تبدیل زمان در کوئری‌ها و عملیات JOIN را کاهش می‌دهد. استفاده از استانداردهای زیر در تمامی ستون‌های تاریخ و تاریخ و ساعت الزامی است.

لازم به ذکر است که قابلیتی در نوع مقدار دو ستون فوق برای تبدیل خودکار انواع فرمت‌های زمانی (شامل تاریخ شمسی و UTC) به استاندارد مورد نیاز دیده شده است. بنابراین در مواردی که امکان تبدیل در سمت منبع وجود ندارد، این عملیات به صورت سیستمی در مسیر لود داده توسط داده‌لند قابل انجام است.

همچنین در رابط کاربری (UI) داده‌لند، تمامی امکانات لازم برای کار با تاریخ شمسی فراهم شده است. تقویم‌ها و فرمت‌های نمایشی به گونه‌ای طراحی شده‌اند که کاربر نهایی می‌تواند تاریخ‌های میلادی ذخیره‌شده را به صورت شمسی مشاهده و استفاده کند. وجود مبدل‌های داخلی و پشتیبانی کامل از تاریخ شمسی در سطح رابط کاربری، نگرانی‌ها بابت تعامل کاربران با تاریخ میلادی را برطرف می‌سازد.

ساخت استوری‌های اختصاصی

در محیط داشبورد داده‌لند، ویجت‌ها و چارت‌ها در فضایی به نام استوری چیدمان می‌شوند. برای حفظ وضوح و انتقال سریع اطلاعات، توصیه می‌شود از قرار دادن تعداد زیادی ویجت در یک استوری خودداری کنید. به عنوان یک قاعده کلی و بهینه، بهتر است تعداد ویجت‌ها در هر استوری بین ۵ تا ۹ عدد محدود نگه داشته شود. هر استوری باید به مجموعه‌ای از داده‌های مرتبط و یک هدف تحلیلی مشخص اختصاص یابد. بنابراین، به جای ایجاد یک استوری جامع و پیچیده، بهتر است چندین استوری متمرکز و موضوعی طراحی کنید که هر یک به یک جنبه یا سوال مشخص از کسب‌وکار پاسخ دهد.

تنظیمات امنیتی فضا و جدول

برای برقراری اصل امنیت داده‌ها می‌توانید از قابلیت‌های امنیتی در سطح فضا و جدول بهره‌مند شوید. استفاده همزمان از این دو لایه امنیتی، یک چارچوب حفاظتی جامع و قدرتمند برای داده‌های شما از لحظه ورود تا زمان مشاهده ایجاد می‌کند.

به عنوان یک راهکار امنیتی مؤثر، توصیه می‌شود دسترسی به فضا را با استفاده از قابلیت آی‌پی مجاز محدود کنید. با فعال‌سازی این ویژگی، می‌توانید اطمینان حاصل کنید که تنها کاربرانی با آدرس‌های IP تأیید شده، مانند شبکه داخلی سازمان، قادر به دسترسی به فضا هستند. این اقدام، گامی مهم برای جلوگیری از دسترسی‌های غیرمجاز به کل محیط کاری شماست.

در لایه دوم، امنیت بر روی نقطه ورود داده به هر جدول متمرکز است. برای هر جدول به صورت مجزا، می‌توانید مشخص کنید که داده‌ها از چه منابعی (IPهای مجاز یا غیرمجاز) و با چه نرخی مجاز به ارسال هستند. فعال‌سازی این تنظیمات از یکپارچگی داده‌های شما محافظت کرده و از ارسال داده‌های ناخواسته یا مخرب به جداول جلوگیری می‌کند.