انواع داده ها و انواع معنایی

وقتی یک رابط انجمن می‌سازید، هر فیلدی که در طرح تعریف می‌کنید به یک نوع داده نیاز دارد. نوع داده، نوع اولیه فیلد مانند BOOLEAN ، STRING ، NUMBER و غیره را تعریف می‌کند.

علاوه بر انواع داده، Looker Studio از انواع معنایی نیز استفاده می‌کند. انواع معنایی به توصیف نوع اطلاعاتی که داده‌ها نشان می‌دهند کمک می‌کنند. به عنوان مثال، فیلدی با نوع داده NUMBER ممکن است از نظر معنایی نشان‌دهنده مقدار یا درصد ارز باشد و فیلدی با نوع داده STRING ممکن است از نظر معنایی نشان‌دهنده یک شهر باشد. برای مشاهده انواع معنایی موجود، لطفاً به مستندات انواع معنایی مراجعه کنید.

طرحواره رابط جامعه و فیلدهای استودیوی Looker

وقتی طرحواره (schema) را برای رابط انجمن خود تعریف می‌کنید، برای هر فیلد ویژگی‌های مختلفی وجود دارد که نحوه نمایش و استفاده از فیلد در Looker Studio را تعیین می‌کند. به عنوان مثال:

  • conceptType در طرحواره اتصال شما با استفاده از ویژگی conceptType تعریف می‌شود. این ویژگی تعیین می‌کند که آیا فیلد به عنوان یک بُعد یا متریک در نظر گرفته شود. توضیحی در مورد تفاوت بین متریک‌ها و ابعاد را می‌توانید در Dimensions and metrics بیابید.
  • نوع معنایی می‌تواند یا در طرحواره کانکتور تعریف شود، یا می‌تواند به طور خودکار توسط Looker Studio بر اساس ویژگی نوع داده تعریف شده در کانکتور شما و مقادیر داده‌ای که توسط کانکتور شما بازگردانده می‌شود، شناسایی شود. برای جزئیات بیشتر در مورد نحوه عملکرد این روش ، به تشخیص خودکار نوع معنایی مراجعه کنید.
  • نوع تجمیع تعیین می‌کند که آیا مقادیر معیار (ابعاد نادیده گرفته می‌شوند) می‌توانند دوباره تجمیع شوند یا خیر. تنظیم ویژگی semantics.isReaggregatable روی true ، تجمیع پیش‌فرض SUM را فعال می‌کند، در غیر این صورت روی Auto تنظیم می‌شود. همچنین می‌توانید با استفاده از ویژگی defaultAggregationType ، نوع تجمیع پیش‌فرض را برای فیلدهای قابل تجمیع به صورت دستی تنظیم کنید.

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

تنظیم اطلاعات معنایی

دو راه برای تنظیم اطلاعات معنایی وجود دارد. می‌توانید یا به صورت دستی معنای فیلد را تنظیم کنید یا به Looker Studio برای تشخیص خودکار تکیه کنید.

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

تنظیم دستی انواع معنایی (توصیه می‌شود)

اگر انواع معنایی خود را می‌دانید، می‌توانید به صورت دستی برای هر فیلد طرحواره، semantics تعریف کنید. جزئیات کامل در مورد ویژگی‌های موجود برای شما را می‌توانید در صفحه مرجع فیلد پیدا کنید. اگر تصمیم به تعریف دستی انواع معنایی دارید، توصیه می‌شود semanticType و semanticGroup را برای هر فیلد تعریف کنید. با ارائه دستی این ویژگی‌ها، فرآیند تشخیص خودکار نوع معنایی اجرا نخواهد شد. اگر برخی از فیلدهای خود را به صورت دستی تنظیم کنید، اما نه همه آنها، آنهایی که مشخص نکرده‌اید، بسته به dataType مشخص شده برای فیلد، به صورت پیش‌فرض روی Text ، Number یا Boolean تنظیم می‌شوند.

در ادامه مثالی از یک طرحواره ساده که به صورت دستی انواع معنایی را تنظیم می‌کند، آورده شده است. Income به عنوان واحد پول و Filing Year به عنوان تاریخ تنظیم شده است.

data-studio/semantics.gs
const schema = [
  {
    name: "Income",
    label: "Income (in USD)",
    dataType: "NUMBER",
    semantics: {
      conceptType: "METRIC",
      semanticGroup: "CURRENCY",
      semanticType: "CURRENCY_USD",
    },
  },
  {
    name: "Filing Year",
    label: "Year in which you filed the taxes.",
    dataType: "STRING",
    semantics: {
      conceptType: "METRIC",
      semanticGroup: "DATE_OR_TIME",
      semanticType: "YEAR",
    },
  },
];

عیب‌یابی دستی انواع معنایی

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

  1. به جای کل داده‌ها، ۲ یا ۳ ردیف از آن‌ها را برگردانید، سپس به صورت دستی آن‌ها را بررسی کنید.
  2. در Looker Studio جدولی ایجاد کنید که فقط از فیلدی که می‌خواهید بررسی کنید استفاده کند.
  3. به فیلدهای Geo و Date توجه زیادی داشته باشید زیرا دقیق‌ترین قالب‌بندی را دارند.

تشخیص خودکار نوع معنایی

اگر هیچ نوع معنایی در طرحواره خود تعریف نکرده باشید، Looker Studio تلاش می‌کند تا بر اساس ویژگی نوع داده و قالب مقادیر داده‌ای که توسط کانکتور شما بازگردانده می‌شود، به طور خودکار آنها را تشخیص دهد.

مراحل فرآیند تشخیص خودکار به شرح زیر است:

  1. با اجرای تابع getSchema از کانکتور community خود، طرحواره را درخواست کنید.
  2. دسته‌هایی از فیلدهای تعریف‌شده در طرحواره کانکتور را پیمایش کنید و درخواست‌های getData را برای فیلدها صادر کنید. درخواست‌های getData با پارامتر sampleExtraction که روی true تنظیم شده است، اجرا می‌شوند تا نشان دهند که درخواست‌های داده برای اهداف تشخیص معنایی هستند.
  3. بر اساس نوع داده فیلد و قالب مقدار برگردانده شده از درخواست getData ، نوع معنایی فیلد را شناسایی کنید.

گزینه‌هایی برای مدیریت تشخیص خودکار نوع معنایی

وقتی Looker Studio تابع getData یک کانکتور community را به منظور تشخیص معنایی اجرا می‌کند، درخواست ورودی شامل یک ویژگی sampleExtraction خواهد بود که روی true تنظیم می‌شود. داده‌های برگردانده شده توسط کانکتور شما فقط توسط Looker Studio برای شناسایی نوع معنایی فیلد استفاده می‌شود. از آنجایی که این مقدار برای هیچ هدف دیگری استفاده نخواهد شد، نیازی به داده‌های واقعی از منبع خارجی شما ندارد.

چندین روش برای بهبود تشخیص نوع معنایی در کد شما وجود دارد:

  • توصیه می‌شود: مقادیر از پیش تعریف‌شده را ارسال کنید
    برای هر فیلد، یک مقدار از پیش تعریف‌شده که به بهترین شکل نوع معنایی فیلد را نشان می‌دهد و توسط Looker Studio به درستی شناسایی می‌شود، برگردانید. برای مثال، اگر نوع معنایی یک فیلد Country باشد، مقداری مانند IT برای ایتالیا برگردانید. مزیت دیگر این رویکرد این است که بسیار سریع‌تر است زیرا نیازی به ارسال درخواست HTTP به سرویس شخص ثالث برای داده‌ها ندارد.

  • فقط n تعداد رکورد را برمی‌گرداند
    اگر سرویس شخص ثالثی که از آن داده‌ها را دریافت می‌کنید، هنگام درخواست داده، از محدودیت‌های ردیف پشتیبانی می‌کند، به جای کل مجموعه داده‌ها، زیرمجموعه کوچکی از ردیف‌ها را به Looker Studio برگردانید. این کار میزان داده‌هایی را که باید برای هر درخواست تشخیص معنایی به Looker Studio ارسال کنید، محدود می‌کند.

  • درخواست همه ستون‌ها و ذخیره پاسخ
    اگر امکان درخواست همه ستون‌ها برای سرویس شخص ثالثی که از آن داده‌ها را دریافت می‌کنید وجود دارد، در اولین درخواست تشخیص معنایی دریافتی از Looker Studio، همه ستون‌ها را دریافت کرده و نتایج را ذخیره کنید. برای درخواست‌های تشخیص معنایی بعدی، به جای ارسال درخواست‌های HTTP اضافی به سرویس شخص ثالث، مقادیر ستون‌ها را از حافظه پنهان دریافت کنید.

  • هیچ کار متفاوتی انجام نده
    شما می‌توانید انتخاب کنید که هیچ تطبیق خاصی برای درخواست‌هایی که sampleExtraction روی true تنظیم شده است، پیاده‌سازی نشود. این امر باعث می‌شود فرآیند تشخیص معنایی کندتر شود زیرا Looker Studio باید تمام داده‌ها را برای فرآیند تشخیص معنایی واکشی کند. علاوه بر این، این امر بر نرخ درخواست به منبع داده خارجی شما تأثیر می‌گذارد زیرا بسیاری از درخواست‌های تشخیص معنایی به صورت موازی اجرا می‌شوند.

قالب‌های شناخته‌شده برای تشخیص خودکار نوع معنایی

تاریخ و زمان
  • YYYY/MM/DD-HH:MM:SS
  • YYYY-MM-DD [HH:MM:SS[.uuuuuu]]
  • YYYY/MM/DD [HH:MM:SS[.uuuuuu]]
  • YYYYMMDD [HH:MM:SS[.uuuuuu]]
  • Sat, 24 May 2008 20:09:47 GMT
  • 2008-05-24T20:09:47Z
  • زمان: دوره برای ثانیه، میکرو، میلی و نانو.
ژئو