سازمانهای بزرگ داده کم ندارند؛ مشکل آنها دسترسی به داده است. هر واحد گزارش خود را از پایگاهدادهٔ خود میگیرد، تیم تحلیل برای هر پرسش جدید باید از چند مالک داده اجازه بگیرد و خروجی بگیرد، و وقتی دو گزارش عدد متفاوتی برای یک شاخص نشان میدهند، هفتهها صرف پیدا کردن دلیل میشود. انبار دادهٔ سنتی بخشی از این مسئله را حل کرده، اما برای دادهٔ نیمهساختیافته، رویدادهای حسگر، تصاویر و متن، یا برای بارهای کاری یادگیری ماشین، ساختار سخت و هزینهٔ آن مانع میشود.
اهمیت این موضوع با ورود هوش مصنوعی به سازمان چند برابر شده است. مدلها به دادهٔ تاریخی، متنوع و با کیفیت مشخص نیاز دارند و باید بتوانند به دادهٔ خام، نه فقط خلاصههای گزارشی، دسترسی داشته باشند. علاوه بر این، الزامات حسابرسی و پاسخگویی ایجاب میکند سازمان بتواند بگوید یک عدد در یک گزارش از کدام منبع، با کدام تبدیل و در چه زمانی به دست آمده است. دریاچهٔ داده، اگر درست ساخته شود، هر دو نیاز را پاسخ میدهد: دسترسی وسیع برای تحلیل و مدلسازی، و تبار مشخص برای اعتماد.
معماری مدرن دریاچهٔ داده معمولاً بهصورت چند ناحیه یا لایهٔ متوالی طراحی میشود. ناحیهٔ خام، داده را دقیقاً همانطور که از منبع رسیده نگه میدارد؛ چه از طریق بارگذاری دستهای و چه از طریق جریان رویداد. ناحیهٔ پاکسازیشده، داده را با طرحوارهٔ مشخص، نوعهای استاندارد و کلیدهای مرجع، مثل شناسهٔ طلایی شخص، بازسازی میکند. و ناحیهٔ آماده، مدلهای دادهای موضوعی مثل مشتری، تراکنش یا مزرعه را برای مصرف تحلیل، داشبورد و مدل میسازد. در کنار اینها، یک کاتالوگ داده، فهرست مجموعهدادهها، مالکان، کیفیت و تبار را نگه میدارد و لایهٔ دسترسی، مجوزها را بر اساس نقش اعمال میکند.
نخستین ملاحظهٔ عملی، مالکیت و کیفیت است. هر مجموعهداده در دریاچه باید مالک مشخصی در کسبوکار داشته باشد که مسئول تعریف، کیفیت و چرخهٔ حیات آن است. قواعد کیفیت، مثل کامل بودن، یکتایی و بازهٔ مجاز، باید بهصورت خودکار در هر بارگذاری اجرا شوند و نتیجه در کاتالوگ منتشر شود. برای مثال، اگر بارگذاری روزانهٔ تراکنشها ناگهان نیمی از حجم معمول را داشته باشد، سیستم باید پیش از آنکه داشبوردها بهروزرسانی شوند هشدار دهد، نه اینکه مدیران صبح با عددی نادرست روبهرو شوند.
دومین ملاحظه، پیوند با مرجع اشخاص و رویدادها است. دریاچهای که داده را با شناسههای محلی هر سامانه نگه میدارد، فقط پراکندگی را در یک مکان جمع کرده است. ارزش واقعی زمانی پدید میآید که در ناحیهٔ پاکسازیشده، همهٔ رکوردها به شناسهٔ مشترک شخص، محصول یا مکان پیوند بخورند. همچنین، تغذیهٔ دریاچه از طریق پلتفرم رویداد، بهجای استخراج مستقیم از پایگاهدادهها، هم بار سامانههای عملیاتی را کم میکند و هم تازگی داده را از شبانه به نزدیک بلادرنگ میرساند.
سومین ملاحظه، مصرف است. دریاچهٔ دادهای که فقط تیم داده از آن استفاده میکند، شکست خورده است. لایهٔ سرویسدهی باید داشبورد و گزارش را برای مدیران، پرسوجوی تعاملی را برای تحلیلگران، و دسترسی برنامهنویسی را برای دانشمندان داده و مدلها فراهم کند؛ همه بر یک تعریف مشترک از شاخصها. یک لایهٔ معنایی که تعریف رسمی هر شاخص را نگه میدارد، از تکرار محاسبات متفاوت برای یک مفهوم جلوگیری میکند و اختلاف اعداد میان گزارشها را از ریشه حذف میکند.
دامهای رایج آشنا هستند. نخست، «باتلاق داده»: ریختن همهچیز بدون کاتالوگ، مالک و قاعدهٔ کیفیت، تا جایی که کسی نمیداند چه چیزی کجاست و به چه چیزی میتوان اعتماد کرد. دوم، ساختن دریاچه بهعنوان پروژهٔ فناوری اطلاعات بدون مورد استفادهٔ کسبوکاری مشخص، که پس از یک سال با انبوهی از داده و هیچ مصرفکنندهای پایان مییابد. سوم، بیتوجهی به کنترل دسترسی در سطح ستون و ردیف، که دریاچه را به نقطهٔ نشت دادهٔ حساس تبدیل میکند. و چهارم، نادیده گرفتن هزینهٔ ذخیرهسازی و پردازش که بدون سیاست نگهداری، بهطور خطی رشد میکند.
در نیاداد، پلتفرم «دریا» دریاچهٔ دادهٔ سازمانی است: نواحی خام، پاکسازیشده و آماده، کاتالوگ داده با مالک و تبار، قواعد کیفیت خودکار و اتصال به پلتفرم رویداد برای تغذیهٔ نزدیک به بلادرنگ. «بینش» لایهٔ هوش تجاری است که بر روی «دریا» داشبورد، گزارش و تحلیل تعاملی را با تعریف مشترک شاخصها فراهم میکند. این دو در پروژهٔ کشاورزی هوشمند نیاداد برای ترکیب خوانش حسگرها، دادهٔ هواشناسی و سوابق زراعی به کار رفتهاند و همان معماری در پروژههای بانکی و شهری نیاداد تکرار میشود.
دریاچهٔ داده زمانی به دارایی تبدیل میشود که سه چیز را همزمان داشته باشد: حاکمیت، پیوند به هویت مشترک و مصرفکنندگان واقعی. بدون حاکمیت، باتلاق است؛ بدون هویت مشترک، انبار پراکندگی؛ و بدون مصرفکننده، هزینه. با هر سه، پایهای است که تحلیل، هوش مصنوعی و پاسخگویی سازمان بر آن بنا میشود.