۳۰ آذر ۱۴۰۳

Techboy

اخبار و اطلاعات روز تکنولوژی

چرا باید از Presto برای تجزیه و تحلیل موقت استفاده کنید

یک موتور اجرای پرس و جو فدرال SQL که در فیس بوک ایجاد شده است، Presto پرس و جوی تعاملی را برای همه داده های شما - بدون توجه به جایی که در آن قرار دارند، به ارمغان می آورد.

یک موتور اجرای پرس و جو فدرال SQL که در فیس بوک ایجاد شده است، Presto پرس و جوی تعاملی را برای همه داده های شما – بدون توجه به جایی که در آن قرار دارند، به ارمغان می آورد.

پرستو! این نه تنها یک طلسم برای برانگیختن مخاطبان خود پس از یک ترفند جادویی است، بلکه نامی است که بیشتر و بیشتر در هنگام بحث در مورد چگونگی دست زدن به داده های بزرگ استفاده می شود. در حالی که کاربردهای زیادی از Presto در طبیعت وجود دارد، این فناوری – یک موتور جستجوی توزیع شده SQL که از انواع منابع داده پشتیبانی می کند – برای بسیاری از توسعه دهندگان و تحلیلگران داده که می توانند از استفاده از آن سود ببرند ناآشنا است.

در این مقاله، من درباره Presto بحث خواهم کرد: چیست، از کجا آمده است، چگونه است متفاوت از سایر راه حل های انبار داده، و چرا باید آن را برای راه حل های کلان داده خود در نظر بگیرید.

Presto vs. Hive

Presto در سال ۲۰۱۲ در فیس بوک ایجاد شد. منبع باز در سال ۲۰۱۳ و توسط بنیاد Presto (بخشی از بنیاد لینوکس) مدیریت می شود، Presto در طول سال ها محبوبیت ثابتی را تجربه کرده است. امروزه، چندین شرکت یک مدل کسب‌وکار پیرامون Presto ایجاد کرده‌اند، مانند Ahana، با ارائه‌های تجزیه و تحلیل موقت مبتنی بر PrestoDB.

Presto به‌عنوان وسیله‌ای برای دسترسی کاربران نهایی به مجموعه داده‌های عظیم برای انجام تجزیه و تحلیل موقت ساخته شده است. قبل از Presto، فیس بوک از Hive (همچنین توسط فیس بوک ساخته شد و سپس به بنیاد نرم افزار آپاچی اهدا شد) برای انجام این نوع تحلیل استفاده می کرد. همانطور که مجموعه داده های فیس بوک رشد می کرد، مشخص شد که Hive به اندازه کافی تعاملی ندارد (بخوانید: خیلی کند). این تا حد زیادی به این دلیل بود که اساس Hive MapReduce است، که در آن زمان نیاز به تداوم مجموعه داده‌های میانی برای HDFS داشت. این به معنای مقدار زیادی ورودی/خروجی به دیسک برای داده هایی بود که در نهایت دور ریخته شدند.

Presto رویکرد متفاوتی را برای اجرای آن پرس‌و‌جوها اتخاذ می‌کند تا در زمان صرفه‌جویی کند. به‌جای نگهداری داده‌های میانی روی HDFS، Presto به شما اجازه می‌دهد تا داده‌ها را به حافظه بکشید و به‌جای اینکه همه مجموعه‌های داده میانی روی دیسک باقی بمانید، روی داده‌ها در آنجا عملیات انجام دهید. اگر آشنا به نظر می رسد، ممکن است نام آپاچی اسپارک (یا هر فناوری دیگری که در آنجا وجود دارد) را شنیده باشید که همان مفهوم اولیه را برای جایگزینی موثر فناوری های مبتنی بر MapReduce دارند. با استفاده از Presto، داده‌ها را در جایی که در آن زندگی می‌کند (در Hadoop یا، همانطور که خواهیم دید، در هر جایی) نگه می‌دارم و اجراها را در حافظه در سراسر سیستم توزیع‌شده‌مان انجام می‌دهم و در صورت نیاز، داده‌ها را بین سرورها به هم می‌ریزم. من از لمس هر دیسکی اجتناب می کنم و در نهایت زمان اجرای پرس و جو را افزایش می دهم.

چگونه Presto کار می کند

متفاوت از یک انبار داده سنتی، Presto به عنوان موتور اجرای پرس و جو SQL نامیده می شود. انبارهای داده کنترل می کنند که چگونه داده ها نوشته می شوند، آن داده ها کجا هستند و چگونه خوانده می شوند. هنگامی که داده ها را به انبار خود وارد می کنید، بازگرداندن آنها ممکن است دشوار باشد. Presto با جدا کردن ذخیره‌سازی داده‌ها از پردازش، رویکرد دیگری را اتخاذ می‌کند و در عین حال از همان زبان پرس‌وجو ANSI SQL که به آن عادت کرده‌اید، پشتیبانی می‌کند.

نحوه استفاده از پاندا برای تجزیه و تحلیل داده ها در پایتون

در هسته خود، Presto پرس و جوهایی را روی مجموعه داده‌هایی که توسط افزونه‌ها، به‌ویژه اتصال‌کننده‌ها ارائه می‌شوند، اجرا می‌کند. یک رابط ابزاری برای Presto برای خواندن (و حتی نوشتن) داده ها در یک سیستم داده خارجی فراهم می کند. Hive Connector یکی از کانکتورهای استاندارد است که از همان ابرداده ای استفاده می کند که برای تعامل با HDFS یا Amazon S3 استفاده می کنید. به دلیل این اتصال، Presto یک جایگزین برای سازمان‌هایی است که امروزه از Hive استفاده می‌کنند. این می تواند داده ها را از طرحواره ها و جداول یکسان با استفاده از فرمت های داده مشابه – ORC، Avro، Parquet، JSON و غیره بخواند. علاوه بر کانکتور Hive، کانکتورهایی برای Cassandra، Elasticsearch، Kafka، MySQL، MongoDB، PostgreSQL و بسیاری دیگر پیدا خواهید کرد. اتصال دهنده ها همیشه به Presto کمک می کنند و به Presto این امکان را می دهد که بتواند به داده ها در هر جایی که زندگی می کند دسترسی داشته باشد.

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

بیایید نگاهی به نحوه استقرار Presto و نحوه اجرای درخواست‌های شما بیندازیم. Presto به زبان جاوا نوشته شده است و بنابراین برای شروع به JDK یا JRE نیاز دارد. Presto به عنوان دو سرویس اصلی، یک Coordinator و بسیاری Workers مستقر شده است. سرویس Coordinator عملاً مغز عملیات است، درخواست‌های پرس و جو را از مشتریان دریافت می‌کند، پرس و جو را تجزیه می‌کند، یک برنامه اجرا می‌سازد، و سپس زمان‌بندی کار برای انجام بسیاری از خدمات Worker. هر Worker بخشی از پرس و جو کلی را به صورت موازی پردازش می کند، و شما می توانید خدمات Worker را به استقرار Presto خود اضافه کنید تا مطابق با تقاضای شما باشد. هر منبع داده به عنوان یک کاتالوگ پیکربندی شده است، و شما می توانید در هر پرس و جو به تعداد دلخواه کاتالوگ پرس و جو کنید.

معماری پرستو

Presto از طریق درایور JDBC قابل دسترسی است و عملاً با هر ابزاری که می تواند با استفاده از JDBC به پایگاه داده متصل شود، ادغام می شود. رابط خط فرمان Presto یا CLI، اغلب نقطه شروع هنگام شروع به کاوش Presto است. در هر صورت، کلاینت به Coordinator متصل می شود تا یک پرس و جوی SQL صادر کند. این پرس و جو توسط Coordinator تجزیه و تایید می شود و در یک طرح اجرای پرس و جو ساخته می شود. این طرح جزئیات چگونگی اجرای یک پرس و جو توسط کارگران Presto را شرح می دهد. طرح پرس و جو (معمولاً) با یک یا چند اسکن جدول شروع می شود تا داده ها را از فروشگاه های داده خارجی شما خارج کند. سپس یک سری عملگر برای انجام پیش بینی ها، فیلترها، اتصالات، گروه بندی ها، سفارشات و انواع عملیات دیگر وجود دارد. این طرح با تحویل مجموعه نتیجه نهایی از طریق هماهنگ کننده به مشتری به پایان می رسد. این طرح‌های پرس‌وجو برای درک اینکه چگونه Presto پرس‌و‌جوهای شما را اجرا می‌کند، و همچنین توانایی تجزیه و تحلیل عملکرد پرس و جو و یافتن هر گونه تنگنای احتمالی، حیاتی هستند.

موتورهای داده نسل بعدی عملکرد ابرداده را تغییر می دهند

مثال پرس و جو Presto

بیایید به یک پرس و جو و طرح پرس و جو مربوطه نگاهی بیندازیم. من از یک پرس و جو TPC-H استفاده خواهم کرد، یک ابزار محک رایج که برای پایگاه داده های SQL استفاده می شود. به طور خلاصه، TPC-H مجموعه ای استاندارد از جداول و پرس و جوها را به منظور آزمایش کامل بودن زبان SQL و همچنین ابزاری برای محک زدن پایگاه های داده مختلف تعریف می کند. این داده‌ها برای موارد استفاده تجاری طراحی شده‌اند که شامل سفارش‌های فروش اقلامی است که می‌تواند توسط تعداد زیادی از لوازم ارائه شود. Presto یک رابط TPC-H ارائه می دهد که داده ها را در لحظه تولید می کند – ابزاری بسیار مفید هنگام بررسی Presto.

SELECT
  SUM(l.extendedprice*l.discount) AS revenue
FROM lineitem l
WHERE
  l.shipdate >= DATE '1994-01-01'
   AND l.shipdate < DATE '1994-01-01' + INTERVAL '1' YEAR
   AND l.discount BETWEEN .06 - 0.01 AND .06 + 0.01
   AND l.quantity < 24;

این پرس و جو شماره شش است که به عنوان پرس و جو تغییر درآمد پیش بینی شناخته می شود. با استناد به مستندات TPC-H، “این پرس و جو میزان افزایش درآمد را که از حذف برخی موارد منتج می شود، کمیت می کند. تخفیف های سراسری شرکت در محدوده درصد معینی در یک سال معین.”

Presto یک پرس و جو را به یک یا چند مرحله تقسیم می کند که قطعات نیز نامیده می شود، و هر مرحله حاوی عملگر متعدد است. اپراتور یک عملکرد خاص از طرح است که اجرا می شود، یا اسکن، فیلتر، اتصال یا تبادل. مبادلات اغلب مراحل را از هم می پاشند. تبادل بخشی از طرح است که در آن داده ها در سراسر شبکه برای سایر کارگران در خوشه Presto ارسال می شود. اینگونه است که Presto می‌تواند مقیاس‌پذیری و عملکرد خود را ارائه دهد – با تقسیم یک پرس و جو به چندین عملیات کوچک‌تر که می‌توانند به صورت موازی انجام شوند و اجازه می‌دهند داده‌ها در سراسر خوشه توزیع شوند تا پیوندها، گروه‌بندی‌ها و ترتیب مجموعه داده‌ها انجام شود. بیایید به طرح پرس و جو توزیع شده برای این پرس و جو نگاه کنیم. توجه داشته باشید که طرح‌های جستجو از پایین به بالا خوانده می‌شوند.

 Fragment 0 [SINGLE]
     - Output[revenue] => [sum:double]       
             revenue := sum   
         - Aggregate(FINAL) => [sum:double]         
                 sum := "presto.default.sum"((sum_4))          
             - LocalExchange[SINGLE] () => [sum_4:double]  
                 - RemoteSource[1] => [sum_4:double]      
 Fragment 1 
     - Aggregate(PARTIAL) => [sum_4:double]  
             sum_4 := "presto.default.sum"((expr))  
         - ScanFilterProject[table = TableHandle {connectorId='tpch', connectorHandle='lineitem:sf1.0', layout='Optional[lineitem:sf1.0]'}, grouped = false, filterPredicate = ((discount BETWEEN (DOUBLE 0.05) AND (DOUBLE 0.07)) AND ((quantity) < (DOUBLE 24.0))) AND (((shipdate) >= (DATE 1994-01-01)) AND ((shipdate) < (DATE 1995-01-01)))] => [expr:double]
                 expr := (extendedprice) * (discount)   
                 extendedprice := tpch:extendedprice
                 discount := tpch:discount         
                 shipdate := tpch:shipdate 
                 quantity := tpch:quantity  

این طرح دارای دو قطعه است که شامل چندین عملگر است. قطعه ۱ شامل دو عملگر است. ScanFilterProject داده‌ها را اسکن می‌کند، ستون‌های لازم (به نام projecting) را که برای برآورده کردن مقدمات لازم است انتخاب می‌کند، و درآمد از دست رفته به دلیل تخفیف برای هر قلم خط را محاسبه می‌کند. سپس یک عملگر مجموع جزئی، مجموع جزئی را محاسبه می کند. قطعه ۰ شامل یک عملگر LocalExchange است که مجموع جزئی را از قطعه ۱ دریافت می کند و سپس جمع نهایی را برای محاسبه مجموع نهایی دریافت می کند. سپس مجموع به مشتری خروجی می شود.

JSONB در PostgreSQL امروز و فردا

هنگام اجرای پرس و جو، Presto داده ها را از منبع داده خارجی به صورت موازی اسکن می کند، مجموع جزئی را برای هر تقسیم محاسبه می کند، و سپس نتیجه آن مجموع جزئی را برای یک کارگر ارسال می کند تا بتواند جمع بندی نهایی را انجام دهد. با اجرای این پرس و جو، حدود ۱۲۳,۱۴۱,۰۷۸.۲۳ دلار درآمد از دست رفته ناشی از تخفیف دریافت می کنم.

      revenue       
----------------------
 ۱.۲۳۱۴۱۰۷۸۲۲۸۳۰۰۰۵E8

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

همانطور که مجموعه داده‌های شما رشد می‌کند، می‌توانید خوشه Presto خود را به منظور حفظ همان زمان‌های اجرا مورد انتظار رشد دهید. این عملکرد، همراه با انعطاف پذیری برای پرس و جو تقریباً از هر منبع داده، می تواند به کسب و کار شما کمک کند تا ارزش بیشتری از داده های شما نسبت به قبل دریافت کند – همه اینها در عین حفظ داده ها در جایی که هستند و اجتناب از انتقال گران قیمت و زمان مهندسی برای ادغام داده های شما در یک مکان برای تجزیه و تحلیل Presto!

Ashish Tadose یکی از بنیانگذاران و مهندس اصلی نرم افزار در Ahana است. آشیش که علاقه زیادی به سیستم‌های توزیع‌شده داشت، از WalmartLabs به Ahana پیوست، جایی که به عنوان مهندس اصلی، یک سرویس شتاب داده چند ابری را که توسط Presto ارائه می‌شد، ایجاد کرد و در عین حال سایر محصولات مرتبط با کشف داده‌ها، موتورهای جستجوی فدرال و مدیریت داده را رهبری و معماری کرد. پیش از این، Ashish یک معمار ارشد داده در PubMatic بود که در آن پلتفرم داده‌های adtech در مقیاس بزرگ را برای گزارش‌دهی، تجزیه و تحلیل و یادگیری ماشین طراحی و ارائه کرد. او در اوایل کار خود، مهندس داده در VeriSign بود. Ashish همچنین یک committer Apache و مشارکت کننده در پروژه های منبع باز است.

New Tech Forum مکانی برای کاوش و بحث در مورد فناوری سازمانی نوظهور در عمق و وسعت بی سابقه ای فراهم می کند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه سوالات را به newtechforum@infoworld.com ارسال کنید.