Dremio: По-опростен и бърз анализ на данни

Jacques Nadeau е главен технически директор и съосновател на Dremio.

Сега е чудесно време да бъдете разработчик. През последното десетилетие решенията за технологията се преместиха от заседателната зала към иновативни разработчици, които изграждат с отворен код и вземат решения въз основа на достойнствата на основния проект, а не на търговските отношения, предоставени от доставчик. Появиха се нови проекти, които се фокусират върху повишаване на производителността на разработчиците и които са по-лесни за управление и мащабиране. Това важи за почти всеки слой от технологичния стек. Резултатът е, че разработчиците днес имат почти неограничени възможности за изследване на нови технологии, нови архитектури и нови модели за внедряване.

Разглеждайки по-специално слоя данни, NoSQL системи като MongoDB, Elasticsearch и Cassandra прокараха плика по отношение на гъвкавост, мащабируемост и производителност за операционни приложения, всяка с различен модел на данни и подход към схемата. По пътя много екипи за разработки преминаха към модел на микроуслуги, разпространявайки данните от приложенията в много различни основни системи.

По отношение на анализа, старите и новите източници на данни са намерили своето място в комбинация от традиционни хранилища за данни и езера на данни, някои на Hadoop, други на Amazon S3. И възходът на платформата за поточно предаване на данни Kafka създава съвсем различен начин на мислене за движението на данни и анализ на данните в движение.

С данните в толкова много различни технологии и основните формати, анализът на съвременните данни е труден. Инструментите за BI и анализи като Tableau, Power BI, R, Python и моделите за машинно обучение са проектирани за свят, в който данните живеят в една единствена високоефективна релационна база данни. В допълнение, потребителите на тези инструменти - бизнес анализатори, изследователи на данни и модели за машинно обучение - искат възможността да имат достъп до, изследват и анализират данни сами, без каквато и да е зависимост от ИТ.

Представяме данните за Dremio

BI инструментите, системите за наука за данни и моделите за машинно обучение работят най-добре, когато данните живеят в една единствена високоефективна релационна база данни. За съжаление днес не живеят данните. В резултат на това ИТ няма друг избор, освен да преодолее тази празнина чрез комбинация от персонализирана разработка на ETL и собствени продукти. В много компании стекът за анализ включва следните слоеве:

  • Постановка на данни . Данните се преместват от различни оперативни бази данни в една единствена подреждаща област, като клъстер Hadoop или услуга за съхранение в облак (например Amazon S3).
  • Хранилище за данни . Въпреки че е възможно да се изпълняват SQL заявки директно върху Hadoop и облачно съхранение, тези системи просто не са проектирани да осигуряват интерактивна производителност. Следователно подмножество от данни обикновено се зарежда в релационен склад за данни или MPP база данни.
  • Кубчета, агрегиращи таблици и BI екстракти . За да се осигури интерактивно представяне на големи набори от данни, данните трябва да бъдат предварително агрегирани и / или индексирани чрез изграждане на кубчета в OLAP система или материализирани агрегиращи таблици в хранилището на данни.

Тази многослойна архитектура въвежда много предизвикателства. Той е сложен, крехък и бавен и създава среда, в която потребителите на данни са изцяло зависими от ИТ.

Dremio въвежда ново ниво в анализа на данни, което наричаме платформа за данни на самообслужване. Dremio е проект с отворен код, който позволява на бизнес анализаторите и изследователите на данни да изследват и анализират всякакви данни по всяко време, независимо от тяхното местоположение, размер или структура. Dremio комбинира мащабна архитектура с колонно изпълнение и ускорение, за да постигне интерактивно представяне на всеки обем данни, като същевременно дава възможност на ИТ, изследователите на данни и бизнес анализаторите безпроблемно да оформят данните според нуждите на бизнеса.

Изграден върху Apache Arrow, Apache Parquet и Apache Calcite

Dremio използва високоефективно колонно съхранение и изпълнение, задвижвано от Apache Arrow (колонна в памет) и Apache Parquet (колонна на диск). Dremio също използва Apache Calcite за анализ на SQL и оптимизация на заявки, като се основава на същите библиотеки като много други базирани на SQL двигатели, като Apache Hive.

Apache Arrow е проект с отворен код, който позволява колонна обработка и обмен на данни в паметта. Arrow е създаден от Dremio и включва ангажименти от различни компании, включително Cloudera, Databricks, Hortonworks, Intel, MapR и Two Sigma.

Dremio е първият екзекутор, създаден от нулата на Apache Arrow. Вътрешно данните в паметта се поддържат без куп във формат Arrow и скоро ще има API, който връща резултатите от заявките като буфери за памет Arrow.

Различни други проекти също обхващат Arrow. Python (Pandas) и R са сред тези проекти, което позволява на учените по данни да работят по-ефективно с данните. Например, Уес Маккини, създател на популярната библиотека на Pandas, наскоро демонстрира как Arrow позволява на потребителите на Python да четат данни в Pandas с над 10 GB / s.

Как Dremio дава възможност за самообслужване на данни

В допълнение към способността да работят интерактивно с техните набори от данни, инженерите на данни, бизнес анализаторите и учените по данни също се нуждаят от начин за подбор на данните, така че да са подходящи за нуждите на конкретен проект. Това е фундаментална промяна от ИТ-ориентирания модел, при който потребителите на данни инициират заявка за набор от данни и чакат ИТ да изпълни заявката си седмици или месеци по-късно. Dremio дава възможност за модел на самообслужване, при който потребителите на данни използват възможностите на Dremio за обработка на данни за съвместно откриване, подреждане, ускоряване и споделяне на данни, без да разчитат на ИТ.

Всички тези възможности са достъпни чрез модерен, интуитивен, уеб-базиран потребителски интерфейс:

  • Открийте . Dremio включва унифициран каталог с данни, където потребителите могат да откриват и изследват физически и виртуални набори от данни. Каталогът с данни се актуализира автоматично, когато се добавят нови източници на данни и с развитието на източниците на данни и виртуалните набори от данни. Всички метаданни се индексират във високоефективен индекс за търсене и са изложени на потребителите през интерфейса на Dremio.
  • Курат . Dremio дава възможност на потребителите да избират данни чрез създаване на виртуални набори от данни. Поддържат се разнообразни трансформации с насочване и щракване и напредналите потребители могат да използват синтаксиса на SQL, за да дефинират по-сложни трансформации. Докато заявките се изпълняват в системата, Dremio научава за данните, позволявайки му да препоръча различни трансформации като обединения и преобразувания на типа данни.
  • Dremio е способен да ускорява наборите от данни до 1000 пъти над производителността на системата източник. Потребителите могат да гласуват за набори от данни, които според тях трябва да бъдат по-бързи, а евристиката на Dremio ще вземе предвид тези гласове при определяне кои набори от данни да се ускорят. По желание системните администратори могат ръчно да определят кои набори от данни да се ускорят.
  • Dremio позволява на потребителите сигурно да споделят данни с други потребители и групи. В този модел група потребители могат да си сътрудничат върху виртуален набор от данни, който ще се използва за определена аналитична работа. Освен това потребителите могат да качват свои собствени данни, като например електронни таблици на Excel, за да се присъединят към други набори от данни от корпоративния каталог. Създателите на виртуални набори от данни могат да определят кои потребители могат да правят заявки или да редактират техните виртуални набори от данни. Това е като Google Docs за вашите данни.

Как работи ускорението на данни на Dremio

Dremio използва силно оптимизирани физически представяния на изходни данни, наречени Data Reflections. Reflection Store може да работи на HDFS, MapR-FS, облачно хранилище като S3 или директно свързано хранилище (DAS). Размерът на Reflection Store може да надвишава този на физическата памет. Тази архитектура позволява на Dremio да ускорява повече данни на по-ниска цена, което води до много по-високо съотношение на удара в кеша в сравнение с традиционните архитектури само с памет. Отраженията на данни се използват автоматично от оптимизатора, базиран на разходите, по време на заявка.

Отраженията на данни са невидими за крайните потребители. За разлика от OLAP кубовете, агрегиращите таблици и екстрактите на BI, потребителят не се свързва изрично с отражение на данни. Вместо това потребителите издават заявки срещу логическия модел, а оптимизаторът на Dremio автоматично ускорява заявката, като се възползва от Data Reflections, които са подходящи за заявката въз основа на анализа на разходите на оптимизатора.

Когато оптимизаторът не може да ускори заявката, Dremio използва своята високопроизводителна разпределена машина за изпълнение, използвайки колонна обработка в паметта (чрез Apache Arrow) и усъвършенствани изтласквания в основните източници на данни (когато се занимава с RDBMS или NoSQL източници).

Как Dremio обработва SQL заявки

Клиентските приложения издават SQL заявки към Dremio през ODBC, JDBC или REST. Заявката може да включва един или повече набори от данни, които потенциално се намират в различни източници на данни. Например, заявката може да бъде свързване между таблица Hive, Elasticsearch и няколко таблици на Oracle.

Dremio използва две основни техники за намаляване на количеството обработка, необходимо за заявка:

  • Натискания в основния източник на данни . Оптимизаторът ще вземе предвид възможностите на основния източник на данни и относителните разходи. След това ще генерира план, който изпълнява етапи на заявката или в източника, или в разпределената среда за изпълнение на Dremio, за да постигне възможно най-ефективния общ план.
  • Ускорение чрез отражения на данни . Оптимизаторът ще използва отражения на данни за части от заявката, когато това създава най-ефективния общ план. В много случаи цялата заявка може да бъде обслужвана от Data Reflections, тъй като те могат да бъдат с порядъци по-ефективни от обработката на заявки в основния източник на данни.

Запитване за натискания

Dremio е в състояние да тласне надолу обработката в релационни и нерелационни източници на данни. Нерелационните източници на данни обикновено не поддържат SQL и имат ограничени възможности за изпълнение. Файлова система, например, не може да прилага предикати или агрегации. MongoDB, от друга страна, може да прилага предикати и агрегации, но не поддържа всички обединения. Оптимизаторът Dremio разбира възможностите на всеки източник на данни. Когато е най-ефективен, Dremio ще изпрати възможно най-голяма част от заявката към основния източник, а останалото изпълнява в собствения си разпределен механизъм за изпълнение.

Разтоварване на оперативни бази данни

Повечето оперативни бази данни са предназначени за оптимизирани за запис натоварвания. Освен това тези внедрявания трябва да адресират строги SLA, тъй като всеки престой или влошена производителност може значително да повлияе на бизнеса. В резултат на това операционните системи често са изолирани от обработката на аналитични заявки. В тези случаи Dremio може да изпълнява аналитични заявки, използвайки Data Reflections, които осигуряват възможно най-ефективната обработка на заявките, като същевременно минимизират въздействието върху операционната система. Отраженията на данни се актуализират периодично въз основа на политики, които могат да бъдат конфигурирани за таблица по таблица.

Фази на изпълнение на заявката

Животът на заявката включва следните фази:

  1. Клиентът изпраща заявка до координатор чрез ODBC / JDBC / REST
  2. Планиране
    1. Координаторът анализира заявката в универсалния релационен модел на Dremio
    2. Координаторът разглежда наличните статистически данни за източниците на данни, за да разработи план за заявки, както и функционалните способности на източника
  3. Координаторът пренаписва плана за заявка, който да използва
    1. наличните отражения на данни, като се обмисли подреждането, разделянето и разпространението на отраженията на данни и
    2. наличните възможности на източника на данни
  4. Екзекуция
  1. Изпълнителите паралелно четат данни в буферите Arrow от източници
    1. Изпълнителите изпълняват пренаписания план за заявки.
    2. Един изпълнител обединява резултатите от един или повече изпълнители и предава крайните резултати на координатора
  1. Клиентът получава резултатите от координатора

Имайте предвид, че данните могат да идват от отражения на данни или от източника (ите) на данните. Когато чете от източник на данни, изпълнителят подава собствените заявки (например MongoDB MQL, Elasticsearch Query DSL, Microsoft Transact-SQL), както е определено от оптимизатора във фазата на планиране.

Всички операции с данни се извършват на изпълнителния възел, което позволява на системата да се мащабира до много едновременни клиенти, използвайки само няколко координационни възела.

Примерно натискане на заявка

За да илюстрираме как Data Fabric се вписва във вашата архитектура на данни, нека разгледаме по-отблизо изпълнението на SQL заявка на източник, който не поддържа SQL.

Един от най-популярните съвременни източници на данни е Elasticsearch. В Elasticsearch има много неща за харесване, но по отношение на аналитиката той не поддържа SQL (включително SQL присъединявания). Това означава, че инструменти като Tableau и Excel не могат да се използват за анализ на данни от приложения, изградени на това хранилище за данни. Има проект за визуализация, наречен Kibana, който е популярен за Elasticsearch, но Kibana е предназначен за разработчици. Това всъщност не е за бизнес потребители.

Dremio улеснява анализирането на данни в Elasticsearch с всеки SQL-базиран инструмент, включително Tableau. Да вземем например следната SQL заявка за бизнес данни на Yelp, която се съхранява в JSON:

ИЗБЕРЕТЕ щат, град, име, преглед_брои

ОТ elastic.yelp.business

КЪДЕТО

  състояние NOT IN ('TX', 'UT', 'NM', 'NJ') И

  review_count> 100

ПОРЪЧАЙТЕ по review_count DESC, щат, град

ГРАНИЦА 10

Dremio компилира заявката в израз, който Elasticsearch може да обработи: