نکات برجسته از اجلاس داده هوش مصنوعی+ مجلس ملی ۲۰۲۱

منتشر‌شده در: towardsdatascience به تاریخ ۳۱ می ۲۰۲۱
لینک منبع: Highlights from Data + AI Summit NA 2021

یکی از بزرگ‌ترین کنفرانس‌ها در زمینه داده-اجلاس داده A I+ شمال آمریکا ۲۰۲۱ هفته پیش رخ داد و این بار من با صحبت‌های خود شرکت نکردم، بلکه بیشتر از جلسات به عنوان یک شنونده لذت بردم.

در این گزارش کوتاه، می‌خواهم یادداشت‌های خود را در رابطه با ویژگی‌های جدید Spark 3.1 و نسخه 3.2 آینده که در بخش داخلی Apache Spark و بهترین روش‌ها مورد بحث قرار گرفت را خلاصه کنم.

پروژه Zen

پروژه Zen حدود یک سال پیش‌آغاز شد و هدف آن کاربرپسند کردن Spark برای کاربران پیتون بود.

نکات نوع

یکی از این مراحل اضافه کردن اشارات نوع بود که برای مثال امکان تکمیل خودکار در IDE ها و همچنین محیط‌های نوت بوک را فراهم می‌آورد، بنابراین توسعه را کارآمدتر می‌کند. پشتیبانی کامل از اشارات نوع در آخرین نسخه ۳.۱.۱ اضافه شد.

پانداس در Spark

یک ویژگی جدید که برای Spark. ۳ در نظر گرفته شده‌است، ادغام پروژه Koalas با Spark است. Koalas امکان استفاده از Pandas API را فراهم می‌کند در حالی که Spark را به عنوان پشتیبان دارد بنابراین اگر یک دانشمند داده از Pandas برای دستکاری داده خود استفاده می‌کند و به دلیل اندازه بزرگ داده به مسائل عملکردی برخورد می‌کند، تبدیل به Koalas که در آن کد یک‌سان باقی می‌ماند اما تحت سرپوش قرار دارد، اجرای آن در Spark اتفاق می‌افتد. حالا وقتی Koalas در Spark ادغام می‌شود، وضعیت حتی ساده‌تر می‌شود، شما می‌توانید Pandas را از Spark وارد کنید و از Pandas API استفاده کنید در حالی که Spark را در دسترس دارید. ابزارهای طراحی و تجسم Pandas اکنون با اقامت بومی در Spark برای شما در دسترس خواهد بود.

بهبود عملکرد

با هر انتشار Spark، عملکرد موتور بهبود می‌یابد. در این نشست، دو موضوع مربوط به عملکرد مورد بحث قرار گرفت:

اتصال درهم ساز (SHJ)

اتصال درهم ساز یکی از الگوریتم های موجود در Spark برای اتصال داده‌ها است. در عمل، به نفع اتصال Sort-Merge (SMJ) که قوی‌تر است، از آن اجتناب می‌شود. SHJ می‌تواند منجر به خطاهای OOM شود اگر داده‌ها اریب باشند و یکی از پارتیشن‌ها خیلی بزرگ باشد. با این حال، تحت شرایط منطقی، SHJ می‌تواند سریع‌تر از SMJ اجرا شود، زیرا از این نوع جلوگیری می‌کند.

چند پیشرفت در ۳.۱ اجرا شد تا SHJ حتی بهتر و قابل‌استفاده‌تر شود:

• اضافه کردن کد (به Jira مراجعه کنید)
• پشتیبانی از پیوستن کامل بیرونی (به Jira مراجعه کنید)
• پارتیشن‌بندی ذخیره (به Jira مراجعه کنید)

نسخه Vectorization

برداری‌سازی روشی است که در آن چندین ردیف را همزمان پردازش می‌کنیم تا سرعت پردازش را افزایش دهیم. در نسخه فعلی Spark، vectorization هنگام خواندن داده‌ها از قالب پاراکت و orc با استفاده از خواننده vectorشده استفاده می‌شود. به غیر از آن، vectorization در Pandas UDFها در PsPark نیز پشتیبانی می‌شود.

یکی از راه‌های پیاده‌سازی vectorization استفاده از دستورالعمل‌های SIMD (آموزش تکی، داده‌های چندگانه) است که توسط سخت‌افزار مدرن پشتیبانی می‌شود. در حال حاضر نسخه Spark به صراحت از SIMD استفاده نمی‌کند، زیرا کامپایلر هات اسپات در JVM در برخی موارد دستورالعمل‌های SIMD را تولید می‌کند، اما در برخی موارد، این کار را نمی‌کند. با این حال، جاوا ۱۶ جدید وکتورAPI در دسترس دارد و این API می‌تواند اطمینان حاصل کند که دستورالعمل SIMD استفاده خواهد شد. بنابراین با استفاده از این وکتورAPI، می توان به تجزیه و تحلیل صریح برای کد تولید شده در Spark دست یافت. در این نشست vectorization مورد بحث قرار گرفت:

کدک فشرده‌سازی Zاستاندارد

در حقیقت Apache Spark از الگوریتم‌‌های فشرده‌سازی مختلف پشتیبانی می‌کند، به عنوان مثال، اسنپی یک الگوریتم پیش‌فرض است که در زمان ذخیره داده‌ها برای فایل‌های پارکت استفاده می‌شود، از طرف دیگر، از LZ4 برای فایل‌های کشیده استفاده می‌شود و کدک‌های دیگر نیز پشتیبانی می‌شوند. Zstandard یک کدک است که می‌تواند به سرعت تراکم قابل‌مقایسه به صورت snappy و نسبت تراکم قابل‌مقایسه به صورت gzip دست یابد.

از آنجا که Spark ۳.۲، Zاستاندارد در سه موقعیت مفید خواهد بود که در آن می‌تواند منجر به مزایای عملکرد شود (صرفه‌جویی در فضای دیسک محلی و یا ذخیره خارجی و افزایش سرعت اجرای پرس‌وجو) :

• فشرده‌سازی ثبت وقایع (spark.eventLog.compression.codec=zstd)
• فشرده‌سازی I / O در طول شافل (spark.io.compression.codec=zstd)
• فشرده‌سازی فایل‌های پارکت spark.conf.set(“spark.sql.parquet.compression.codec”, “zstd)”

افزایش سرعت

شافل در شغل Spark معمولا گران‌ترین فرآیند است زیرا داده‌ها باید بین گره‌های خوشه جابجا شوند. شافل مرز بین دو مرحله است، بعد از اینکه یک مرحله تمام می‌شود، خروجی بر روی فایل‌ها نوشته می‌شود، و سپس به مرحله بعدی آورده می‌شود. فایل‌ها یا بر روی دیسک‌های محلی مجریان ذخیره می‌شوند و یا هنگامی که از یک سیستم جابه‌جایی خارجی استفاده می‌شود، می‌توانند در یک سیستم ذخیره‌سازی خارجی مانند HDFS ذخیره شوند. تعداد این فایل‌ها به صورت درجه دو با تعداد وظایف رشد می‌کند (به طور خاص‌تر، تعداد وظایف در مرحله بالادست ضرب در تعداد وظایف در مرحله پایین‌دست) و فایل‌ها می‌توانند نسبتا کوچک شوند. یک Jira در حال پیشرفت وجود دارد که هدف از آن پیاده‌سازی یک شافل به اصطلاح مبتنی بر فشار است که شافل I / O را با از پیش ترکیب کردن بلوک‌ها بهینه خواهد کرد. خود موضوع در این نشست مورد بحث قرار گرفت:

سرویس :Magnet Shuffleشافل فشاری در لینکداین

بررسی طرح‌های پیچیده پرس و جو

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

بهینه‌سازی کاتالیزور برای طرح‌های پیچیده

انطباق با SQL ANSI

این یک پروژه جاری در Spark و در نسخه ۳.۰ یک تنظیمات پیکربندی تجربی معرفی شده‌است که spark.sql.ansi.enabled را فعال می‌کند و زمانی که روی درست تنظیم می‌شود، Spark سعی خواهد کرد تا با مشخصات ANSI SQL مطابقت کند، به این معنی که یک پرس و جو می‌تواند در زمان اجرا شکست بخورد اگر ورودی نامعتبر باشد در حالی که می‌تواند مقادیر صفر را برگرداند. یک مثال خاص از این مورد، دسته‌بندی انواع داده‌هایی است که نمی توان آن‌ها را با اطمینان ترسیم کرد یا این که گیج‌کننده هستند. برخی توابع جدید مربوط به این در ۳.۲ منتشر خواهند شد، به عنوان مثال، TRY_CAST, TRY_ADD, TRY_DIVIDE که می‌تواند مفید باشد اگر کاربر بخواهد از حالت ANSI استفاده کند، اما ترجیح می‌دهد مقادیر صفر داشته باشد اگر ورودی به جای شکست در پرس و جو نامعتبر باشد.

در Spark 3.2 دو نوع تاریخ بازه جدید ، ماه و روز منتشر می شود که برخی از مشکلات CalendarIntervalType فعلی را حل می کند. یک Jira در حال پیشرفت وجود دارد که چتری برای کارهای فرعی مربوطه است. مشکل نوع فاصله فعلی این است که قابل‌مقایسه نیست و از مرتب‌سازی پشتیبانی نمی‌کند، بنابراین با داشتن دو فاصله نمی‌توانیم آن‌ها را مقایسه کنیم و بگوییم کدام یک بزرگ‌تر است. مشکل دیگر این است که ما نمی‌توانیم نوع فاصله را در فرمت های فایلی مانند parquet/orc یا حتی json ذخیره کنیم. از سوی دیگر، دو نوع جدید YearMonthIntervalType و Day TimeIntervalType که در ۳.۲ آزاد خواهند شد قابل‌مقایسه و قابل سفارش خواهند بود و با استانداردهای SQL هم خوانی خواهند داشت.

برای اطلاعات بیشتر و جزئیات بیشتر در مورد انطباق با SQL ANSI، مستندات را ببینید و یا جلسات زیر را از اجلاس بررسی کنید که در آن این موضوعات مورد بحث قرار گرفتند:

تفحص عمیق در ویژگی‌های جدید Apache Spark ۳.۱

نمایش جامع در مورد جشنواره‌ها در Apache Spark ۳.۲

تکنولوژی DataSourceV2 API

در اصل DataSourceV2 API در چند سال اخیر تحت توسعه بوده‌است، هدف آن حل مشکلات مختلف مربوط به V1 API است، به عنوان مثال، رفتار متناقض متصل‌کننده‌ها برای برخی از حالت‌های Datateter، عدم اعتبار طرح قبل از نوشتن به جداول، وابستگی به API های داخلی دیگر مانند SQL LContext و عدم توسعه آسان برای ویژگی‌های جدید.

همچنین V2 API از کاتالوگ تحت کاپوت برای بررسی این که آیا یک جدول وجود دارد یا نه استفاده می‌کند و از قوانین اعتبارسنجی سازگار به طور مستقل از اجرای رابط استفاده می‌کند. یک Jira در حال پیشرفت وجود دارد که هدف آن حمایت از کنترل بهتر اتصالات بر روی توزیع و سفارش در V2 API است که باید انعطاف‌پذیری بهتری را فراهم کند و برنامه‌ریزی شده‌است که در Spark. ۲ منتشر شود.

نتیجه‌گیری

جلسات جالب زیادی در اجلاس Data + AI در مجلس ملی ۲۰۲۱ برگزار شد. در این گزارش کوتاه، یادداشت‌های خود را از برخی جلسات درونی Spark و بهترین تجارب خلاصه کردم. این یادداشت‌ها به هیچ وجه کامل نیستند، من عمدتا بر بحث ویژگی‌های جدیدی تمرکز کردم که در ۳.۱.۱ منتشر شدند یا برای انتشار آتی برنامه‌ریزی شده‌اند.

این متن با استفاده از ربات ترجمه مقاله دیتاساینس ترجمه شده و به صورت محدود مورد بازبینی انسانی قرار گرفته است.در نتیجه می‌تواند دارای برخی اشکالات ترجمه باشد.

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