مطالعه بیشتر

مدل‌ها ایجاد کنید تا مجموعه داده‌های خوب شروع برای سؤال‌های جدید به مشتریان بدهید.

ساخت مدل‌ها

مدل‌ها ایجاد کنید تا مجموعه داده‌های خوب شروع برای سؤال‌های جدید به مشتریان بدهید.

باارزش‌ترین کاری که می‌توانید انجام دهید تا پرسیدن سؤال درباره داده برای افراد غیرفنی آسان شود این است که داده خود را در شکلی قرار دهید که پرسیدن سؤال را شهودی کند.

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

مدل‌ها به عنوان بلوک‌های ساختمانی

برای شهودی‌تر کردن داده برای تیم‌های خود، در متابیس می‌توانید مجموعه داده‌های مشتق شده، به نام مدل‌ها، ایجاد کنید که می‌توانند داده از جداول مختلف را با هم جمع کنند. آن‌ها بر اساس نتایج سؤال‌های متابیس ساخته می‌شوند، و می‌توانید ستون‌های محاسبه شده سفارشی اضافه کنید، و همه ستون‌ها را با متادیتا حاشیه‌نویسی کنید تا مشتریان بتوانند با داده در query builder به عنوان نقطه شروع بازی کنند.

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

چرا یک job ETL برای ایجاد یک مدل در پایگاه داده خود اجرا نکنیم؟

مدل‌های متابیس و ETLها متقابلاً منحصر به فرد نیستند. می‌توانید (و باید) از هر دو استفاده کنید. و فقط برای توضیح چرا:

مدل‌ها ابزارهای مدل‌سازی داده را در دست افرادی که دامنه کسب‌وکار را می‌دانند قرار می‌دهند. این یک مسئله بزرگ است. بله، یک مهندس داده بیشتر درباره لوله‌کشی در pipeline داده می‌داند، اما لزوماً مشکلاتی که یک تیم خاص با آن مواجه است و نحوه تعریف بخش‌های آن مشکلات را نمی‌داند (مثلاً، چه چیزی به عنوان یک کاربر فعال واجد شرایط است؟). تیم‌های مختلف در سازمان شما باید کسانی باشند که کسب‌وکار شما را تعریف می‌کنند، و باید قادر به اصلاح آن تعاریف در پاسخ به تغییرات در نحوه کار تیم، پیشنهادات محصول جدید، تغییرات بازار، هر چیزی باشند. با مدل‌ها، مشتریان نیاز به رفتن از طریق تیم داده برای افزودن یک ستون محاسبه شده جدید یا به‌روزرسانی یک تعریف ندارند. و آن و تیم‌های مختلف تعاریف مختلفی خواهند داشت: تیم فروش شما ممکن است یک مدل متفاوت برای یک مشتری نسبت به تیم‌های بازاریابی یا موفقیت شما داشته باشد.
مدل‌ها انعطاف‌پذیر هستند. می‌توانید مدل‌ها را on the fly ایجاد کنید، تغییر دهید، آن‌ها را عوض کنید - آن‌ها اساساً فقط پرس‌وجوها + توضیحات هستند. و آن‌ها یک شهروند درجه یک در متابیس هستند، پس می‌توانید آن‌ها را در مجموعه‌ها سازماندهی کنید، به آن‌ها لینک دهید، و آن‌ها را به عنوان نقطه شروع برای یک سؤال جدید انتخاب کنید، یا آن‌ها را به داشبوردها اضافه کنید. همچنین می‌توانید آن‌ها را archive کنید، یا آن‌ها را به یک سؤال ذخیره شده تغییر دهید (اگرچه متادیتای خود را از دست خواهید داد). ETLها، در مقابل کار بسیار بیشتری هستند، و معمولاً توسط کسی که pipeline داده شما را می‌داند، که می‌داند چگونه کد را بنویسد، job را schedule کند، و غیره gate می‌شوند. ابزارهای عالی برای کمک به نوشتن ETLها وجود دارد، اما آن‌ها اغلب یک راه‌حل heavyweight برای مشکلی هستند که نیاز به راه‌حل‌های انعطاف‌پذیر دارد.
مدل‌ها سنگ‌های پله برای بهبود عملکرد پایگاه داده شما هستند. پس از آزمایش با مدل‌ها در متابیس، می‌توانید محبوب‌ترین مدل‌ها را به viewهای materialized در پایگاه داده خود "ارتقا دهید". Materialize اینجا به معنای نوشتن یک job ETL برای ایجاد و به‌روزرسانی دوره‌ای یک جدول در پایگاه داده که با مدل شما match می‌کند (همان مجموعه ستون‌ها را دارد) است تا نتایج نیاز به محاسبه برای پرس‌وجو هر بار که آن را اجرا می‌کنید نداشته باشند؛ پایگاه داده می‌تواند فقط نتایج را مثل اینکه از یک جدول داده خام می‌آید fetch کند. وقتی جدول را در پایگاه داده خود materialize کردید، می‌توانید یا پرس‌وجوی اصلی را برای مدل در متابیس با یک SELECT * FROM materialized_model ساده عوض کنید، یا فقط مدل را حذف کنید و با جدول materialized مثل هر جدول دیگر در پایگاه داده خود رفتار کنید. (توجه کنید که اگر پرس‌وجوی زیربنایی یک مدل را تغییر دهید، نیاز به به‌روزرسانی متادیتا برای هر ستون دارید).
مدل‌ها می‌توانند رکوردهای فردی را ایندکس کنند و آن‌ها را در جستجوی متابیس در دسترس قرار دهند. می‌توانید رکوردهای فردی را در جستجو ظاهر کنید تا بتوانید رکوردهای فردی، مثل نام مشتریان را lookup کنید.

یک مثال مدل

هنگام فکر کردن به اینکه کدام ستون‌ها را در مدل‌های خود شامل کنید، بهتر است با فهرست کردن انواع سؤال‌هایی که انتظار دارید مشتریان بپرسند شروع کنید، و سپس ستون‌هایی به مدل اضافه کنید که به پاسخ دادن به آن سؤال‌ها کمک می‌کنند. بگویید می‌خواهیم یک مشتری را مدل کنیم. معمولاً، ممکن است بخواهیم چیزی مثل یک مشتری فعال تعریف کنیم، شاید کسی که حداقل یک بار در ماه گذشته از سایت ما بازدید کرده است، یا هر طور که می‌خواهیم مشتری فعال را تعریف کنیم. اما فقط برای ساده نگه داشتن، می‌خواهیم یک مدل برای یک مشتری پایه با پایگاه داده نمونه شامل شده با متابیس تعریف کنیم. و انتظار می‌داریم بخواهیم چند چیز درباره مشتریان خود بدانیم:

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

در یک مدل واقعی، احتمالاً سؤال‌های بسیار بیشتری دارید که می‌خواهید پاسخ دهید، که نیاز به ستون‌های بسیار بیشتری برای پاسخ دارد (مثل چقدر قدیمی یک مشتری است، چقدر در سایت وقت گذرانده، موارد اضافه شده و حذف شده از سبد خرید، یا همه نقاط داده دیگر که فکر می‌کنید تیم‌های شما می‌خواهند درباره آن‌ها سؤال بپرسند). ایده با مدل‌ها این است که همه کد boilerplate که همه این داده را با هم می‌آورد از سر راه بردارید تا مشتریان فقط شروع به بازی با داده‌ای که واقعاً به آن علاقه دارند کنند.

پس در اینجا سؤال ما است، ساخته شده با استفاده از query builder:

برای داده خود، جدول Orders را انتخاب کردیم، آن را به جدول People join کردیم، مجموع کل سفارش‌ها را خلاصه کردیم، ردیف‌ها را شمردیم، و میانگین کل سفارش را با استفاده از یک عبارت سفارشی محاسبه کردیم: = Sum([Total]) / Count. بعد بر اساس: User_ID، People.Created_At، State، Zip، و Source group کردیم.

آن سؤال را ذخیره می‌کنیم، روی عنوان سؤال کلیک می‌کنیم تا sidebar سؤال را باز کنیم (ممکن است نیاز به refresh مرورگر داشته باشید)، و روی آیکون مدل (سه بلوک ساختمانی stacked در یک مثلث) کلیک می‌کنیم تا سؤال را به یک مدل تبدیل کنیم.

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

این superpower مدل است، و به خصوص برای مدل‌های ساخته شده با پرس‌وجوهای SQL مفید است، چون متابیس انواع ستون بازگشتی توسط یک پرس‌وجوی SQL را نمی‌داند.

کلیک روی نام مدل sidebar مدل را باز می‌کند، که گزینه Customize metadata را به ما می‌دهد. اینجا می‌توانیم نام‌های دوستانه‌تر به ستون‌ها بدهیم، توضیحات به ستون‌ها اضافه کنیم (که روی hover ظاهر می‌شوند)، و به متابیس بگوییم چه نوع داده‌ای ستون شامل می‌شود.

اگر به جای آن از یک پرس‌وجوی SQL برای ایجاد همان مدل مشتری استفاده می‌کردیم (ببینید یک مثال مدل بالا)، متابیس به طور خودکار قادر به انجام drill-through magic معمول خود نبود.

اما می‌توانیم منوی drill-through و همه magic دیگر متابیس را restore کنیم اگر مقداری متادیتا به ستون‌های مدل (یعنی به فیلدهای بازگشتی توسط تعریف مدل، پرس‌وجوی آن) اضافه کنیم.

به عنوان مثال، اگر این پرس‌وجوی تعریف مدل ما بود:

SELECT
    orders.user_id              AS id,
    people.created_at           AS join_date,
    people.state                AS state,
    people.source               AS source,
    Sum(orders.total)           AS total,
    Count(*)                    AS order_count,
    Sum(orders.total)/Count(*)  AS avg_total
FROM orders
LEFT JOIN people
   ON orders.user_id = people.id
GROUP  BY
    id,
    city,
    state,
    zip,
    source

متابیس به طور خودکار نمی‌دانست چه نوع داده‌ای state یا total یا هر ستون دیگر بود. اگر، با این حال، به صورت دستی نوع را برای هر ستون نتیجه در متادیتای مدل تنظیم کنیم، متابیس سپس قادر به ارائه منوی drill-through روی نمودارها، و همچنین دانستن اینکه چه نوع فیلتری باید برای آن ستون استفاده کند (مثلاً فیلترها برای اعداد گزینه‌های متفاوتی نسبت به تاریخ یا دسته‌ها خواهند داشت) خواهد بود.

مدل‌ها می‌توانند رکوردهای فردی را در جستجو ظاهر کنند

ویژگی متادیتای دیگر با مدل‌ها: می‌توانید انتخاب کنید مقادیر از یک مدل را ایندکس کنید تا در نتایج جستجوی متابیس ظاهر شوند.

اینجا گزینه Surface individual records in search by matching against this column (پایین سمت راست) را toggle می‌کنیم:

به عنوان مثال، می‌توانستید یک ستون در یک مدل با نام‌های مشتری ایندکس کنید تا مشتریان بتوانند یک مشتری مثل Hudson Borer را تایپ کنند و مستقیماً به view جزئیات برای آن مشتری بپرند.

با ایندکس کردن رکوردها در یک مدل، همچنین می‌توانید آن‌ها را X-ray کنید. مستندات درباره مدل‌ها برای جزئیات بیشتر را ببینید.

رد کردن متغیرهای SQL

اینجا یک نکته ظریف است که ارزش اشاره دارد. اگر عادت به ایجاد "مدل‌ها" با سؤال‌های ذخیره شده و متغیرهای SQL (مثل فیلترهای فیلد) دارید تا مشتریان بتوانند آن سؤال‌ها را بگیرند و آن‌ها را به فیلترهای داشبورد متصل کنند، مدل‌ها رویکرد متفاوتی اینجا می‌گیرند. مدل‌ها با متغیرها کار نمی‌کنند، چون نیاز ندارند. وقتی به متابیس انواع ستون مدل را می‌گویید، می‌توانید یک سؤال از آن مدل شروع کنید، آن را ذخیره کنید، و قادر به wire کردن آن به یک فیلتر داشبورد باشید. نیاز به قرار دادن یک متغیر در کد SQL خود ندارید.

اگر یک مدل را به یک داشبورد اضافه کنید، متوجه می‌شوید که نمی‌توانید هیچ یک از ستون‌های آن را به یک فیلتر داشبورد map کنید، حتی پس از تنظیم انواع برای آن فیلترها. برای دریافت همان نتایج با مدل‌ها، می‌توانید:

یک مدل بدون متغیر ایجاد کنید.
یک سؤال بر اساس مدل ذخیره کنید.
آن سؤال را به داشبورد اضافه کنید.
یک فیلتر به داشبورد اضافه کنید.
فیلتر را به ستون مناسب روی سؤال map کنید.

برای بیشتر، فیلترهای داشبورد را ببینید.