Защо трябва да използвате Presto за ad hoc анализ

Presto! Това е не само заклинание да развълнувате аудиторията си след магически трик, но и име, което се използва все повече и повече, когато обсъждате как да прехвърлите през големи данни. Въпреки че има много внедрявания на Presto в природата, технологията - разпределена машина за SQL заявки, която поддържа всички видове източници на данни - остава непозната за много разработчици и анализатори на данни, които биха могли да се възползват от нейното използване.

В тази статия ще обсъждам Presto: какво представлява, откъде идва, как се различава от другите решения за съхранение на данни и защо трябва да го обмислите за вашите решения за големи данни.

Престо срещу кошер

Presto възниква във Facebook още през 2012 г. С отворен код през 2013 г. и управляван от Presto Foundation (част от Linux Foundation), Presto преживява непрекъснат растеж на популярността през годините. Днес няколко компании са изградили бизнес модел около Presto, като Ahana, с Ad-hoc предложения за анализ, базирани на PrestoDB.

Presto е създаден като средство за предоставяне на достъп до крайни потребители до огромни масиви от данни за извършване на ad hoc анализ. Преди Presto, Facebook ще използва Hive (също създаден от Facebook и след това дарен на Apache Software Foundation), за да извърши този вид анализ. Тъй като наборите от данни на Facebook нарастваха, бе установено, че Hive е недостатъчно интерактивен (чете се: твърде бавен). Това до голяма степен се дължи на факта, че основата на Hive е MapReduce, която по това време изискваше междинните набори от данни да се поддържат в HDFS. Това означаваше много I / O на диск за данни, които в крайна сметка бяха изхвърлени. 

Presto възприема различен подход при изпълнението на тези заявки, за да спести време. Вместо да запазва междинни данни на HDFS, Presto ви позволява да изтегляте данните в паметта и да извършвате операции с данните там, вместо да запазвате всички междинни набори от данни на диск. Ако това ви звучи познато, може би сте чували за Apache Spark (или за редица други технологии там), които имат същата основна концепция за ефективно заместване на базираните на MapReduce технологии. Използвайки Presto, ще съхранявам данните там, където живеят (в Hadoop или, както ще видим, навсякъде) и ще изпълнявам изпълненията в паметта в нашата разпределена система, като разбърквам данни между сървърите, ако е необходимо. Избягвам да докосвам диск, като в крайна сметка ускорявам времето за изпълнение на заявката.

Как работи Presto

За разлика от традиционното хранилище за данни, Presto се нарича двигател за изпълнение на SQL заявки. Складовете за данни контролират как се записват данните, къде се намират тези данни и как се четат. След като получите данни в склада си, може да се окаже трудно да ги върнете обратно. Presto възприема друг подход, като отделя съхранението на данни от обработката, като същевременно осигурява поддръжка за същия език за заявки ANSI SQL, с който сте свикнали.

В основата си Presto изпълнява заявки за набори от данни, предоставени от приставки, по-специално Connectors. Конекторът осигурява средство за Presto да чете (и дори записва) данни във външна система за данни. Hive Connector е един от стандартните конектори, използвайки същите метаданни, които бихте използвали за взаимодействие с HDFS или Amazon S3. Поради тази свързаност, Presto е заместител за организации, използващи Hive днес. Той е в състояние да чете данни от едни и същи схеми и таблици, използвайки едни и същи формати за данни - ORC, Avro, Parquet, JSON и др. В допълнение към съединителя Hive, ще намерите конектори за Cassandra, Elasticsearch, Kafka, MySQL, MongoDB, PostgreSQL и много други. Конекторите се допринасят за Presto през цялото време, което дава на Presto потенциала да има достъп до данни навсякъде, където живее.

Предимството на този отделен модел за съхранение е, че Presto може да предостави един обединен изглед на всички ваши данни - независимо къде се намират. Това увеличава възможностите на ad hoc заявките до нива, които никога досега не е достигал, като същевременно осигурява интерактивни времена на заявки за вашите големи масиви от данни (стига да имате инфраструктура за архивиране, локално или в облак).

Нека да разгледаме как е разположена Presto и как става изпълнението на вашите заявки. Presto е написан на Java и следователно изисква JDK или JRE, за да може да стартира. Presto е разположен като две основни услуги, един координатор и много работници . Услугата Координатор е ефективно мозъкът на операцията, получавайки заявки за заявки от клиенти, анализиране на заявката, изграждане на план за изпълнение и след това планиране на работата, която трябва да бъде извършена в много услуги на Worker. Всеки Worker обработва паралелно част от цялостната заявка и можете да добавите услуги на Worker към вашето внедряване на Presto, за да отговарят на вашите нужди. Всеки източник на данни е конфигуриран като каталог и във всяка заявка можете да заявявате толкова каталози, колкото искате.

Ахана

Достъпът до Presto се осъществява чрез JDBC драйвер и се интегрира с практически всеки инструмент, който може да се свърже с бази данни чрез JDBC. Интерфейсът на командния ред на Presto или CLI често е началната точка при започване на изследването на Presto. Така или иначе клиентът се свързва с координатора, за да издаде SQL заявка. Тази заявка се анализира и проверява от координатора и се вгражда в план за изпълнение на заявката. Този план описва подробно как една заявка ще бъде изпълнена от работниците на Presto. Планът за заявки (обикновено) започва с едно или повече сканирания на таблици, за да се извлекат данни от външните ви хранилища за данни. След това има поредица от оператори за извършване на проекции, филтри, обединения, групови байтове, поръчки и всякакви други операции. Планът завършва с крайния набор от резултати, който се доставя на клиента чрез Координатора.Тези планове за заявки са жизненоважни за разбирането на начина, по който Presto изпълнява вашите заявки, както и за възможността да анализира ефективността на заявките и да открие потенциални тесни места.

Пример за заявка Presto

Нека да разгледаме заявка и съответния план за заявка. Ще използвам TPC-H заявка, често срещан инструмент за сравнителен анализ, използван за бази данни на SQL. Накратко, TPC-H определя стандартен набор от таблици и заявки, за да се тества пълнотата на езика на SQL, както и средство за бенчмаркиране на различни бази данни. Данните са предназначени за случаи на бизнес употреба, съдържащи поръчки за продажба на артикули, които могат да бъдат предоставени от голям брой доставки. Presto предоставя TPC-H конектор, който генерира данни в движение - много полезен инструмент при проверка на Presto.

ИЗБЕРЕТЕ

  SUM (л. Разширена цена * л. Отстъпка) AS приходи

ОТ lineitem l

КЪДЕТО

  l.shipdate> = DATE '1994-01-01'

   И л. Дата на изпращане <ДАТА '1994-01-01' + ИНТЕРВАЛ '1' ГОДИНА

   И л. Отстъпка МЕЖД .06 - 0,01 И .06 + 0,01

   И л. Количество <24;

Това е заявка номер шест, известна като Прогноза за промяна на приходите. Цитирайки документацията на TPC-H, „тази заявка количествено определя размера на увеличението на приходите, което би довело до елиминиране на определени отстъпки за цялата компания в даден процент от дадена година.“

Presto разбива заявка на един или повече етапи, наричани още фрагменти , и всеки етап съдържа множество оператори . Операторът е определена функция на плана, която се изпълнява, или сканиране, филтър, присъединяване или размяна. Борсите често разбиват етапите. Обменът е частта от плана, при която данните се изпращат през мрежата до други работници в клъстера Presto. Ето как Presto успява да осигури своята мащабируемост и производителност - чрез разделяне на заявка на множество по-малки операции, които могат да се извършват паралелно и позволяват преразпределяне на данни в клъстера за извършване на обединения, групови байтове и подреждане на набори от данни. Нека да разгледаме плана за разпределена заявка за тази заявка. Имайте предвид, че плановете за заявки се четат отдолу нагоре.

 Фрагмент 0 [ЕДИНСТВЕН]

     - продукция [приходи] => [сума: двойно]       

             приходи: = сума   

         - Агрегат (FINAL) => [сума: двойно]         

                 сума: = "presto.default.sum" ((sum_4))          

             - LocalExchange [SINGLE] () => [sum_4: double]  

                 - RemoteSource [1] => [сума_4: двойно]      

 Фрагмент 1 

     - Обобщена (ЧАСТИЧНА) => [сума_4: двойна]  

             sum_4: = "presto.default.sum" ((израз))  

         - ScanFilterProject [table = TableHandle {connectorId = 'tpch', connectorHandle = "lineitem: sf1.0", layout = "Незадължително [lineitem: sf1.0]"}, grouped = false, filterPredicate = ((отстъпка МЕЖДУ ) И (ДВОЙНО 0,07)) И ((количество) = (ДАТА 1994-01-01)) И ((дата на изпращане) [израз: двойно]

                 израз: = (разширена цена) * (отстъпка)   

                 extendedprice := tpch:extendedprice

                 discount := tpch:discount         

                 shipdate := tpch:shipdate 

                 quantity := tpch:quantity  

This plan has two fragments containing several operators. Fragment 1 contains two operators. The ScanFilterProject scans data, selects the necessary columns (called projecting) needed to satisfy the predicates, and calculates the revenue lost due to the discount for each line item. Then a partial Aggregate operator calculates the partial sum. Fragment 0 contains a LocalExchange operator that receives the partial sums from Fragment 1, and then the final aggregate to calculate the final sum. The sum is then output to the client.

When executing the query, Presto scans data from the external data source in parallel, calculates the partial sum for each split, and then ships the result of that partial sum to a single worker so it can perform the final aggregation. Running this query, I get about $123,141,078.23 in lost revenue due to the discounts.

      revenue       

----------------------

 1.2314107822830005E8

As queries grow more complex, such as joins and group-by operators, the query plans can get very long and complicated. With that said, queries break down into a series of operators that can be executed in parallel against data that is held in memory for the lifetime of the query.

As your data set grows, you can grow your Presto cluster in order to maintain the same expected runtimes. This performance, combined with the flexibility to query virtually any data source, can help empower your business to get more value from your data than ever before — all while keeping the data where it is and avoiding expensive transfers and engineering time to consolidate your data into one place for analysis. Presto!

Ashish Tadose is co-founder and principal software engineer at Ahana. Passionate about distributed systems, Ashish joined Ahana from WalmartLabs, where as principal engineer he built a multicloud data acceleration service powered by Presto while leading and architecting other products related to data discovery, federated query engines, and data governance. Previously, Ashish was a senior data architect at PubMatic where he designed and delivered a large-scale adtech data platform for reporting, analytics, and machine learning. Earlier in his career, he was a data engineer at VeriSign. Ashish is also an Apache committer and contributor to open source projects.

Форумът New Tech предоставя място за изследване и обсъждане на нововъзникващите корпоративни технологии в безпрецедентна дълбочина и широчина. Изборът е субективен, базиран на нашия избор на технологиите, които смятаме, че са важни и представляват най-голям интерес за читателите. не приема маркетингово обезпечение за публикуване и си запазва правото да редактира цялото съдържание. Изпращайте всички запитвания на [email protected]