هزینههای پنهان پشته داده
تیم متابیس
ما در اینجا یک فهرست ناقص از هزینههای پنهان مرتبط با نگهداری یک پشته داده را ارائه میدهیم. و با پشته داده، ما به طور سست درباره یک پشته داده مدرن متشکل از تقریباً یک:
- لایه منبع داده (یک پایگاه داده عملیاتی/تولید و منابع داده شخص ثالث)
- یک لایه ETL که تمام آن داده منبع را به یک انبار داده تبدیل میکند
- یک لایه ذخیرهسازی (انبار داده)
- یک لایه پرسوجو (ابزار BI)
این مقاله به معنای تحریک FUD (ترس، عدم اطمینان، و تردید) نیست؛ ما فقط فکر کردیم که برجسته کردن برخی فرصتها برای مدیریت هزینهها مفید خواهد بود. ما این هزینهها را به هیچ ترتیبی فهرست نمیکنیم، زیرا بزرگی هزینهها از سازمانی به سازمان دیگر متفاوت است، بنابراین ممکن است انتخاب کنید که برخی هزینهها را اما نه دیگران را برطرف کنید. ما ابتدا فضای مشکل را پوشش میدهیم، سپس راههای مختلفی را که میتوانید این هزینهها را کاهش دهید کاوش میکنیم.
هزینههای پنهان
آموزش و منحنیهای یادگیری
یک هزینه اغلب نادیده گرفته شده این است که ابزارهای موجود در پشته شما برخی سربارهای آموزشی را متحمل میشوند. آن، یا شما حقوق بالاتری برای افرادی که قبلاً یک ابزار یا لایه پشته را تسلط یافتهاند میپردازید. این سربار به ویژه برای ابزار BI شما مرتبط است، زیرا ابزار BI—پنجره به پشته داده شما—بزرگترین استخر افراد استفاده کننده از آن را خواهد داشت، هر کدام با سطوح مختلف تجربه.
چیز دیگر برای اشاره در اینجا این است که منحنیهای یادگیری دو نوع مختلف هزینه را تحمیل میکنند. هزینه اول زمان مورد نیاز برای آموزش کارکنان در این ابزارها است، یا از طریق آموزش فعال (شما جلسات آموزشی با مشتریان میزبانی میکنید)، یا آموزش خودهدایتشده، جایی که انتظار دارید مشتریان مستندات را بخوانند، چیزها را بفهمند، و یادگیری-با-انجام دادن.
هزینه دوم، شکست پذیرش، میتواند ظریفتر باشد: اگر ابزار یادگیری دشوار باشد، مشتریان زحمت یادگیری محصول را به روشی که آنها را مولد میکند نمیکشند. یا، بدتر، آنها اصلاً زحمت یادگیری محصول را نمیکشند، و شما در نهایت برای مجوزی که ارزش صفر برای سازمان شما تولید میکند پول میپردازید.
تأخیر تکرار
چقدر سریع تیمها میتوانند روی گزارشهای خود تکرار کنند؟ یعنی، چقدر سریع میتوانید گزارشها را بر اساس اطلاعات جدید بهروزرسانی کنید (خواه آن اطلاعات جدید از تغییر در بازار ناشی شود، یا یک رویداد تازه ابزارسازی شده در محصول شما)؟
به طور مشخص آنچه منظور ما است این است که، اگر برای هر "ساخت" از پشته داده شما (و در اینجا ما درباره لایه ETL که انبار داده شما را "میسازد" صحبت میکنیم)، نیاز به پردازش کل جدول دارید، هزینه تکرار روی ایجاد تغییرات در آن ساخت غیرقابل توجه نیست.
اگر، پس از ایجاد تغییر، بازخورد از افرادی که آن داده را تحلیل میکنند دریافت میکنید که برخی دادهها به نظر اشتباه میرسند، یا که نیاز به گنجاندن بیشتر داده دارید، افزودن یا تغییر چند ستون به یک مدل میتواند مقدار قابل توجهی پول در حقوق و هزینههای ابری برای شما هزینه کند.
کارهای ETL و گزارشهای زامبی
مشتریان گزارشها را ایجاد و برنامهریزی میکنند. سپس آنها به ایجاد گزارشهای جدید میروند و آنها را برنامهریزی میکنند. آنها بررسی گزارشهای قدیمی را متوقف میکنند، و با این حال گزارشهای قدیمی به اجرا ادامه میدهند، حتی همانطور که افراد بیشتری استخدام میکنید، که گزارشهای بیشتری ایجاد و برنامهریزی میکنند... مشکل این است که بیشتر ارائهدهندگان پایگاه داده ابری به ازای هر پرسوجو شارژ میکنند، بنابراین شما در نهایت برای تحلیلی که از آن استفاده نمیکنید پول میپردازید.
عوامل اتوبوس
در حالی که خاص تیمهای داده نیست، داده و سیلوهای تیم مستعد "بازنشانی دانش" هستند زمانی که متخصصان در آن تیمها شرکت را ترک میکنند.
هزینههای کش
کش عمدتاً یک صرفهجویی هزینه است، اما برخی راهحلها نیاز به کش کردن دادههای شما در یک پایگاه داده جداگانه دارند، و سپس برای آن از شما شارژ میکنند. شاید آن هزینه ارزش داشته باشد، شاید نه.
عدم گسترشپذیری
ابزارهای BI باید بتوانند به خوبی با ابزارهایی که تیم شما قبلاً با آنها آشنا هستند کار کنند. به عنوان مثال، میتوانید فقط از Metabase برای مدل کردن دادههای خود استفاده کنید، و سپس به مشتریان اجازه دهید هر چیزی که میخواهند برای ایجاد گزارش استفاده کنند. اگر برخی افراد با نرمافزار صفحه گسترده راحتتر هستند، میتوانند فقط داده را از Metabase صادر کنند و آن را در نرمافزار صفحه گسترده انتخابی تحلیل کنند، و این کاملاً خوب است. مشکل زمانی است که ابزارها شما را مجبور به استفاده از آنها میکنند.
نگهداری چندین منبع حقیقت
ذخیره دادههای مشابه در مکانهای متعدد میتواند دو مشکل ایجاد کند: مشکل اول این است که میتوانید در نهایت وقت را برای فهمیدن اینکه کدام داده میتوانید به آن اعتماد کنید تلف کنید. مشکل دوم، مرتبط، و مخربتر این است که میتوانید در نهایت تصمیمات را بر اساس داده اشتباه یا نادرست (اشتباه به معنای اینکه باید از دادههای دیگر، مرتبطتر استفاده کنید، و نادرست به معنای اینکه خود داده نادرست یا ناقص است) بگیرید.
دست و پا زدن سطح حساب
جزئی، اما با این حال یک دردسر. چون برخی برنامهها انواع مختلف حسابها را با تواناییهای مختلف در نقاط قیمت مختلف ارائه میدهند، باید با نحوه توزیع آن تواناییها سروکار داشته باشید. برخی مجوزهای سازنده میتوانند ۱۰ برابر یک حساب پایه باشند، بنابراین باید وقت را برای فهمیدن اینکه چه کسی مجوز دریافت میکند و چرا، و چه زمانی تعداد مجوز را با تغییر کسبوکار شما افزایش یا کاهش دهید بسوزانید.
چیز دیگر با این حسابهای سطحبندی شده این است که، چون فقط برخی انواع حساب مجاز به ایجاد گزارش یا ایجاد تغییرات هستند، آنها تضمین میکنند که شما گلوگاهها را در گردش کار خود میسازید (فکر کنید: صفهای درخواست موردی).
نحوه پایین نگه داشتن هزینههای پشته داده
در اینجا فهرست غیرجامعی از اقداماتی که میتوانید برای کاهش مسائل ذکر شده در بالا انجام دهید وجود دارد. هر پیشنهاد میتواند به کاهش یک یا بیشتر از هزینههای ذکر شده در بالا کمک کند.
از یک ابزار استفاده کنید که برای پرسوجوی دادههای شما نیاز به SQL ندارد
شما قطعاً یک ابزار میخواهید که بتوانید از SQL استفاده کنید، اما همچنین نیاز به راهی برای وادار کردن مشتریان به تعامل با داده که SQL نمیدانند دارید. و هرچه سازنده پرسوجو بصریتر باشد، مشتریان سریعتر میتوانند روی ابزار BI بالا بیایند، و این به معنای این است که افراد بیشتری واقعاً از نرمافزاری که برای آن پول میپردازید استفاده میکنند.
جلسات آموزشی و اشتراکگذاری داده میزبانی کنید
این جلسات آموزشی نیازی به رسمی بودن ندارند. فقط مشتریان را با هم جمع کنید و آنها را با ساخت داشبوردهای مرتبط با خودشان یاد بگیرید. پس از اینکه مشتریان دست ابزار را گرفتند، و فهمیدند که داده کجاست، فقط باید جلسات آموزشی را برای استخدامهای جدید برگزار کنید.
و شما نمیتوانید فقط روی ابزار آموزش دهید؛ باید به مشتریان نشان دهید که چه دادهای در دسترس آنها است و کجاست. اگر ابزار خوبی باشد، باید مستندات و منابع یادگیری زیادی داشته باشد. اما اگر مشتریان نمیدانند کجا داده مرتبط با دامنه خود را پیدا کنند، آن دانش هدر میرود.
دادههای خود را مستند کنید
صحبت از آموزش: مستندسازی داده بخشی از زیرساخت اصلی شرکت شما است، اما، بله، خوب، موفق باشید با این. دادههای شما احتمالاً فقط مستند میشوند اگر افراد را برای انجام آن اختصاص دهید؛ یعنی، باید کار را تیکت کنید و واقعاً آن را به خط برسانید. اگر هنوز منابع برای انجام این کار ندارید، میتوانید برخی توابع اجباری را امتحان کنید که ممکن است حداقل برخی از دادهها را مستند کند. به عنوان مثال، میتوانید برجسته کردن مدلها یا گزارشهای خاص در جلسات تیم یا شرکت را چرخش دهید، که میتواند مشتریان را به نوشتن چیزها (به عنوان مثال، پر کردن توضیحات ستون، افزودن زمینه به داشبوردها و غیره) انگیزه دهد. مستندسازی دادههای شما ممکن است سیزیفی به نظر برسد، اما هر کمی کمک میکند، و آن مستندات از نظر اشتراکگذاری دانش، onboarding، و تصمیمگیری سود میدهد.
به طور دورهای گزارشهای برنامهریزی شده را هرس کنید
برخی ابزارها با ابزارهای ممیزی همراه هستند که میتوانند به شما بگویند گزارشهای برنامهریزی شده چقدر اغلب اجرا میشوند. اگر مشکوک هستید که مشتریان برخی گزارشها را بررسی نمیکنند، آنها را بایگانی کنید و ببینید آیا کسی شکایت میکند. و حتی اگر شکایت کنند، با آنها درباره اجرای گزارش کمتر مکرر، یا خاموش کردن گزارش به طور کامل و فقط داشتن مشتریان برای اجرای آن در صورت نیاز صحبت کنید.
ساخت، نگهداری و تغییر مدلها را آسانتر کنید
برای هر تیم آسان کنید که مجموعه دادههای خود را مدیریت کنند. این تیمها دامنهای را که داده توصیف میکند میدانند، بنابراین در موقعیت خوبی برای شناسایی اینکه کدام داده مرتبط است در مقابل کدام نیست هستند.
یک تمایز مفید در اینجا تفاوت بین مدلهای بنیادی و مدلهای گزارشدهی است.
ایدهآل شما یک مجموعه از مدلهای بنیادی دارید: دادههای تمیز شده، نسبتاً خام شما که توسط یک تیم داده یا تحلیلگر یا مهندس مدیریت میشود. داده در این مدلها تمیز و صحیح است، اما هنوز برای دامنههای خاص مدیریت نشده است. تغییرات در این مدلها باید نادر باشند، زیرا احتمالاً گران هستند.
مدلهای گزارشدهی مدلهای پاییندست هستند که تیمها میتوانند برای پاسخ به سوالاتی که نیاز به پاسخ دارند بسازند و بهروزرسانی کنند. این مدلها سبکوزن و انعطافپذیر هستند. ساخت آنها ارزانتر است، و در حالی که میتوانند توسط تحلیلگران تأیید شوند، توسط آنها مسدود نمیشوند.
این بخش شایسته یک مقاله کامل است، بنابراین ما فقط در اینجا متوقف میشویم.
از ابزارهایی با حسابهای سطحبندی شده خودداری کنید
اگر میخواهید کنترل را بر اینکه چه کسی چه کاری میتواند انجام دهد سفت کنید، این باید یک مسئله مجوز باشد، نه یک مسئله قیمتگذاری. یکی از دلایلی که ما (Metabase) مدل محصول سطحبندی شده (رایگان در مقابل Enterprise/Pro) را اتخاذ کردهایم این است که ما معتقدیم که مدل سطح حساب آزاردهنده است. Metabase در اینجا منحصر به فرد نیست، اما به طور کلی، اگر از نرمافزاری که شما را مجبور به فهمیدن اینکه میخواهید برای چه کسانی بیشتر پول بپردازید دوری کنید، سربار کمتری متحمل میشوید.
تیم داده خود را توزیع کنید
اگر یک نیمکت داده عمیق دارید، تحلیلگران را با تیمها جاسازی کنید تا تخصص دامنه را توسعه دهند، و به تیمها کمک کنند یاد بگیرند چگونه گزارشهای خود را ایجاد کنند. ایدهآل، تحلیلگران داده باید به اندازه نوشتن گزارشهای خود، گزارشهای دیگران را آموزش و بررسی کنند.
با احتیاط ارتقا دهید (یا بگذارید شخص دیگری این کار را برای شما انجام دهد)
فقط ابزارها را ارتقا دهید اگر از ویژگیهای جدید بهرهمند میشوید. یا (بهتر) ریسک را کاهش دهید و زمان را با برونسپاری ارتقاها به یک سرویس صرفهجویی کنید. اگر چیزی اشتباه پیش رود، مشکل شما نیست.
