Если вы хотите создать или перестроить свое хранилище данных, вы столкнетесь с впечатляющим списком технологий на рынке.
Пробовать каждый из них в поисках подходящего вам – это долго и дорого.
На нашей конференции СмартДанные Ведущий разработчик в Яндексе Максим Стаценко рассказал о плюсах и минусах различных решений для хранения данных: облачных или аппаратных, Hadoop, Vertica, ClickHouse, Exasol, Greenplum, Teradata и других.
Работая в крупных компаниях, Максим пробовал множество решений, сравнивал их на одних и тех же данных и задавал вопросы их разработчикам и поставщикам.
Видео и стенограмма доклада находятся под катом.
Дальше история будет с точки зрения Максима.
Мой доклад ориентирован на людей, которые начинают строить хранилище данных или думают о том, как его переделать, а также на младших разработчиков, которые только планируют стать дата-инженерами.
Я сосредоточусь на том, как я буду выбирать решения и как хранить данные.
О чем этот отчет и почему?
- Говорите о технологиях, о которых говорят меньше, чем о хайповых технологиях.
- Поделитесь опытом, полученным в рамках PoC (проверка концепции) на большом объеме данных
- Поделитесь своим опытом принятия решения, как и где построить хранилище.
Так у меня появилось много друзей, которые любят создавать стартапы или работать в небольших организациях.
Периодически ко мне приходят и говорят: «Макс, мы хотим создать хранилище или хотим переоборудовать свое хранилище, потому что оно не соответствует нашим требованиям».
Общаясь с ними, я понял, что есть популярные универсальные решения, о которых знают все, но я хотел бы вам сказать, что есть хорошие большие решения, о которых мы знаем меньше, и поделиться своим опытом проведения проверки концепции в Mail.ru. .
Мы провели проверку концепции на терабайтах данных о посещениях, с нами активно работали вендоры различного программного обеспечения.
Давайте посмотрим на план моего доклада.
Сначала мы определимся, где развернуть наше хранилище: в облаке или на оборудовании.
Потом выберем технологию хранения данных, потом обсудим, что не вошло в отчет и почему я не постарался вписать это в презентацию.
Что мы строим?
Мы строим аналитическое хранилище данных.Мое видение хранилища аналитических данных — быть ориентированным на людей.
Сотрудники должны иметь доступ к данным 24/7. В любой момент в вашем сервисе что-то может пойти не так.
Аналитики — это люди, которые могут объяснить, почему у вас внезапно упали продажи, почему люди перестали заходить на ваш сайт, почему упали доходы от рекламы.
Если ваш мониторинг работает, аналитик подключится и разберется с проблемой.
Когда вы подрастете (или уже повзрослели), вам придется ограничить доступ к данным.
Вы не хотите, чтобы младший разработчик имел доступ к зарплатам сотрудников, расходам и т. д. Доступ должен быть BI. Я часто привожу пример мобильного телефона.
Если вы хотите узнать, сколько времени осталось на вашем телефоне, вам не нужно писать код на Python, вы просто заходите в меню и смотрите.
В бизнесе ключевые показатели должны быть доступны таким же образом, чтобы люди, у которых нет времени или навыков программирования, могли просматривать ключевые показатели и выполнять простую аналитику.
Еще один важный момент: аналитическое хранилище данных появляется тогда, когда ваш сервис уже вырос из системы SMP. Стандартный процесс создания аналитической системы:
- Мы живем на одной базе с прод.
- Аналитики начинают вмешиваться в работу продукта и делать замечания.
- Реплика не на высоте по производительности.
- Мы начинаем думать о переходе на другое решение.
Специфика современности
То, что я только что сказал, было актуально и 30, и 20 лет назад. Но сейчас 2020 год, и, несмотря на коронавирус и другие проблемы, есть определенные особенности.Ниже приведен контрольный список, на который я обращаю внимание при принятии решений по архитектуре хранилища.
Первое, что я бы посоветовал вам помнить при построении аналитических хранилищ, это то, что с 2000 года объем данных стал расти гораздо быстрее, чем вычислительные мощности.
В результате старые подходы больше не работают. Но системы СМП были изобретены в 70-80-х годах и немного не вписываются в эту парадигму.
Второе, о чем следует помнить, — это угроза безопасности конфиденциальных данных.
Вы собираете много информации о пользователях, и если эти данные попадут в открытый доступ или в руки мошенников, это будет плохо и вам, и пользователям.
В РФ за это предусмотрена уголовная ответственность.
Третий критерий отбора – сложность найма сотрудников.
Де-факто SQL, Python/R являются стандартами доступа к данным.
Если ваша система требует более специфических навыков, найти специалистов будет сложнее.
Например, если вы хотите нанять C++-разработчика, который будет писать ETL, вы пострадаете и предложите много денег.
А разработчики скажут: «Что? Буду ли я «передавать» поля в C++ и обрабатывать логи? Нет, это не интересно.
» Это мой опыт, и я не советую вам его повторять.
Четвертый фактор, влияющий на это решение, — машинное обучение, которое находится на пике популярности.
Это очень популярная технология, и производители тоже присматриваются к ней.
Странно начинать бизнес сейчас и не пытаться спрогнозировать свои доходы, затраты, спрос.
Важно убедиться, что ваше аналитическое хранилище способно предоставлять данные для машинного обучения.
Наконец, нюанс, о котором часто забывают, — это проектирование системы.
Многие не думают, что хороший аналитик сейчас извлекает не только те данные, которые есть в хранилище.
Он может купить данные у других компаний, скачать их в Интернете, пойти к вашему бэкенд-разработчику и попросить получить их из логов.
Неважно как, но как только он собрал данные, которые, по его мнению, решат его проблему, ему нужны эти данные для взаимодействия с данными из хранилища.
Если мы посмотрим на старый конвейер, то для решения этой проблемы он бы попросил дата-инженера загрузить данные в хранилище и расположить их так, чтобы они были в третьей нормальной форме и чтобы каждый мог ими пользоваться.
Это значит, что он поставит в JIRA задачу, которая уходит в бэклог.
Затем аналитик ждет поступления данных.
Когда у вас много хороших аналитиков, отставание растет, инженеры по работе с данными страдают, а процессы продвигаются медленно.
Кажется, все было бы лучше, если бы аналитики могли сами загружать такие «разовые» и так или иначе структурированные данные.
Теперь такие возможности существуют, что упрощает проведение экспериментов, проверку гипотез и внедрение MVP, поскольку вам больше не нужно привлекать дата-инженеров для добавления в хранилище данных, которые, возможно, никогда больше не понадобятся.
Хранение данных в хранилище
На слайде ниже я в общих чертах нарисовал схему аналитического хранилища данных.Шина данных — это интерфейс, через который данные поступают в хранилище, а пользовательский интерфейс и ETL Manager управляют данными и предоставляют доступ к ним.
Схема хранилища аналитических данных Мы сосредоточимся на хранилище.
Схема простая, но если присмотреться, то может оказаться сложнее.
Здесь я нарисовал общую диаграмму лямбда-хранилища, где у вас есть:
- схема реального времени;
- пакетная обработка;
- база данных, в которую вы загружаете предпочитаемые агрегаты;
- облако в S3, куда вы помещаете старые данные.
Варианты, где строить
В глобальном масштабе существует пять вариантов построения нашей СХД.Первые три варианта я объединю в группу «Свой сервер».
- Сервер находится в шкафу, то есть в собственной серверной комнате.
- Аренда стойки в дата-центре
- Аренда сервера
- Аренда виртуальной машины в облаке
- Управляемые услуги в облаке.
Я обнаружил это недавно, около двух лет назад. Управляемые услуги теперь появились как в российских, так и в зарубежных облаках.
Вы заказываете не сервер, а необходимое программное решение.
Например, вас интересует кластер Hadoop с Zeppelin, Spark и всем остальным.
Откройте интерфейс и нажмите, например, 16 узлов Hadoop, каждый узел имеет 1 ТБ данных, определенное количество процессоров.
Нажимаешь кнопку и все появляется.
ClickHouse или любой другой сервис, поддерживаемый выбранным вами поставщиком и облаком, работает таким же образом.
Таким образом, вы получаете систему анализа данных или, по крайней мере, инфраструктуру для нее, точно так же, как вы заказываете еду на свой мобильный телефон.
Дальше у меня будет много слайдов-консультаций.
Я не буду рассматривать всю таблицу, а лишь остановлюсь на некоторых моментах.
В таблице я выделил скрытые затраты знаками доллара, о которых не следует забывать, выбирая, где хранить свои данные.
Первое важное: если вы сами разворачиваете кластерное решение, то вам нужен очень хороший админ.
Например, есть очень неприятная задача — обновление ПО кластера.
Если вы не хотите допускать простоя вашего решения, то вам нужно взять часть узлов и вывести их из ротации.
При этом вы должны убедиться, что у вас осталась хотя бы одна реплика всех данных в ротации.
Далее вы скачиваете новую версию ПО и возвращаете ее в ротацию.
Если случится так, что ваша база данных не будет работать с новой версией, то вам придется откатиться тем же способом.
Это боль, и ваш администратор пострадает. А если у вас open source, то вам нужен разработчик, который будет исправлять ошибки в свободном ПО.
Это очень тяжелая работа, мы довольно долго ею занимались.
Каждый раз обновление Hadoop было эпической историей, несмотря на то, что мы сначала делали обновление на тестовых базах, потом на продакшене, а откатывать всё равно приходилось.
Выбирая решение, не забывайте об экстренном реагировании и мониторинге.
Во-первых, если у вас есть свой сервер, то вам придется задуматься о возможности выхода из строя некоторых аппаратных компонентов.
Например, у вас может выйти из строя диск, но если у вас большой кластер, то диски будут выходить из строя почти каждый день.
Ваша сеть может выйти из строя, что-то может пойти не так с коммутаторами.
Чем больше решение завязано на вас, тем больше этих проблем ляжет на вас.
Вам нужно будет заранее решить это, спрогнозировать, приобрести диски и свитчи, если вы расширяете свои персональные дата-центры или даже небольшую серверную комнату.
Все эти проблемы необходимо решать, и чем больше ответственности вы переложите на облако, тем больше рутинной работы за вас будет выполняться.
Это довольно удобно.
Лично я, поскольку я вырос как разработчик, не люблю настраивать и реагировать на «железные» аварии, поэтому облака мне нравятся.
Еще один важный момент – мониторинг.
Если вы настраиваете свой сервер самостоятельно, то вам придется самостоятельно придумывать систему мониторинга, следить за тем, чтобы загрузка вашего процессора была максимальной, или база данных умерла, или узел Hadoop вышел из строя, писать об этом сообщения в Телеграм, рисуй дашборды.
А если вы устанавливаете виртуальную машину, то, скорее всего, эту работу вам тоже придется проделать самостоятельно.
При использовании управляемых сервисов базовые метрики будут сделаны за вас.
Появится страница, где вы всегда сможете увидеть, что происходит. Самое главное, что за вас кто-то отреагирует и скажет: «Ой, у нас Hadoop-кластер упал, давайте срочно починим».
Скорее всего, вы этого даже не заметите.
Мое мнение Скажу сразу, это всего лишь мое мнение, мой опыт. Возможно, у кого-то из вас другой опыт. Владение собственным оборудованием дает вам душевное спокойствие и спокойствие вашему сотруднику службы безопасности.
По опыту Mail.ru или Минобразования знаю, что адаптировать облачное решение под требования силовика очень сложно.
Напоследок офицер безопасности говорит: «Я хочу, чтобы доступ к серверу был только через решение Cisco, а авторизоваться нужно через СМС и сеанс не должен длиться более 30 минут».
Ни один поставщик облачных услуг не предоставит такого решения «из коробки», и вам придется поговорить с ними отдельно.
Вы можете настроить на своем сервере все, что захотите.
Во-вторых, это конфиденциальность данных в вашей инфраструктуре.
Я немного параноик и очень боюсь, что данные могут утечь.
Когда вы отвечаете за них сами, вам немного спокойнее, ведь вы можете ночью отключить Ethernet-кабель от сервера, и никто не взломает базу данных.
Доступ к серверу имеют только ваши сотрудники, если он правильно настроен.
Такие вещи дают спокойствие, но в то же время современные технологии уже давно изобретены и используются в облачных решениях, обеспечивающих высокий уровень безопасности.
Но психологически иметь свои конфиденциальные данные как-то надежнее и приятнее.
Кроме того, когда вы выбираете продавца, лучше поинтересоваться, все ли ресурсы ваши.
Хотя эта история становится все менее актуальной, перестраховаться все же стоит. Раньше продавцы предполагали, что вы не сможете занять все забронированные вами ресурсы.
Это похоже на овербукинг на рейсах самолетов.
Вендор продает больше мощности, чем имеет на самом деле, надеясь, что ни один из клиентов не будет использовать свои ресурсы на 100%.
А если вам не повезет, ресурсы уйдут к процессам, которые их заняли первыми, а ваши задачи будут работать на остаточной мощности или вообще висеть в очереди.
Например, вам предлагают 128 ГБ оперативной памяти, хотя на самом деле у производителя свободно только 64 ГБ.
Неприятная ситуация, с этим борются современные производители.
Но стоит обсудить, как они гарантируют квоту и всегда ли вы сможете получить доступ ко всем купленным ресурсам.
Что касается аппаратной части, то она более привычна пользователям.
Но к преимуществам виртуальных машин можно отнести их гибкость и простоту.
Я приведу два примера.
Допустим, у вас есть большое хранилище, и вы хотите попробовать преобразовать его в другую технологию, например ClickHouse. Если у вас есть свое оборудование, то вам нужно найти другие серверы.
Если их нет, то купите их, подождите, пока они придут, установите ClickHouse и заполните данные.
А если ClickHouse вам не нравится, что делать с купленными серверами? В облаке можно скачать данные, поиграть недельку, удалить весь этот кластер и быстро разобраться, нужен ли вам ClickHouse. Второй пример — случай моих друзей.
Для своей компании они наняли специалиста по машинному обучению, которого попросили спрогнозировать спрос.
Это была сторонняя компания, она начала активно обучать свои модели и загрузила аналитическую систему «до потолка», чтобы никто, кроме них, не мог работать.
Потом они просто скопировали свой кластер с спросом и все данные в облако и сказали: «Вот вам данные, учитесь, никто туда не пойдет, а аналитика продолжит работать в реальной системе».
Когда модель подрядчика показала хорошие результаты, ее начали интегрировать в общую аналитическую систему и увеличивать системные ресурсы для хорошей модели.
Это дает вам гибкость — вы можете скопировать данные и передать их подрядчику.
И последний бонус виртуальной работы – это перенос рутины на других людей.
За организацию безопасности и реагирование на происшествия будут отвечать специальные сотрудники.
Проблемы с облаками за пределами РФ
В целом они связаны с законодательством и возможными скрытыми сетевыми расходами, если вы загружаете данные из облака или в облако.Согласно Постановлению Правительства РФ № 728 от 26 июня 2018 года мы храним данные пользователей на территории Российской Федерации.
Федеральный закон «О персональных данных» от 27 июля 2006 г.
(№ 152-ФЗ) содержит стандарты безопасного хранения данных.
Трансграничная передача персональных данных на территорию иностранных государств может быть запрещена или ограничена.
Не везде есть русскоязычная поддержка — увеличивается стоимость специалистов, которые будут работать с облаком.
Валютные риски: стоимость услуг зависит от курса рубля.
Стоимость инфраструктуры может удвоиться, как это произошло, когда стоимость доллара удвоилась.
Если вам нужно загружать и скачивать большие объемы данных, вам нужен хороший канал.
Чем больше точек подключения между двумя машинами, тем меньше вероятность, что будет хороший канал.
Стоимость линка к европейскому дата-центру может быть равна стоимости ресурсов проекта СХД в российских облаках.
Выбор программного продукта
Перейдем к системам MPP (массивная параллельная обработка).На какое-то время мне придется побыть Капитаном Очевидностью, но несколько раз мне лично приходилось доказывать нескольким финансовым директорам, что цена продукта — это не вся цена, которую вам придется заплатить.
Я очень люблю Hadoop, но в этом отчете я буду его активно ненавидеть и стыдить.
Hadoop можно получить бесплатно, но вам придется потратить немало усилий, чтобы заставить его работать должным образом.
Вы можете купить коробочное решение, за него придется заплатить, но по сравнению с годом-двумя поддержкой Hadoop оно может оказаться гораздо дешевле.
Еще советую не зацикливаться на тендерах, а провести доказательство концепции.
Тендеры, обзоры, советы экспертов носят предвзятый характер.
У вашего бизнеса есть свои особенности, своя модель использования данных.
Поговорите с продавцом продукта и попросите его позволить вам попробовать продукт. Как правило, можно договориться о триале на месяц-два, вы будете загружать туда данные, запускать запросы и понимать, подходит вам это решение или нет. Может оказаться, что в вашем случае сработает супернепопулярное решение.
Самый простой пример – автомобиль «Жигули», который не нужен нигде за пределами РФ, но здесь «Жигули» – популярный товар, так как его можно отремонтировать с помощью молотка и кувалды.
Все системы, о которых я буду говорить дальше, — это MPP. На схеме ниже они показаны справа, а слева — более архаичные системы SMP (англ.
симметричная многопроцессорность).
Как видите, в системах MPP мы стараемся хранить данные отдельно.
У каждого узла есть фрагмент данных: от A до F, от G до R, от S до Z. При этом каждый узел пытается обработать свой фрагмент данных, не глядя на другие.
В некоторых случаях, например, при неудачных соединениях, происходит обмен данными между узлами, а затем процесс повторяется, где каждый узел пытается обработать только свой кусок.
Это хорошо, потому что его легко масштабировать по ширине.
Это проще и дешевле, чем масштабирование по высоте, поскольку так мы достигаем определенного потолка производительности.
Давайте рассмотрим несколько решений.
Для каждого из них я расскажу о его ЯЗЫКЕ ЗАПРОСОВ, транзакционности, наличии точки отказа и наличии или отсутствии бесплатной версии.
Я также расскажу о том, чем это решение отличается от остальных.
Почему эти четыре пункта
- SQL — не самое современное решение, но это также порог входа.
Курсов по SQL очень много, писать на SQL умеют практически все, и вам гораздо проще найти людей.
Поверьте, это важно.
- Транзакции — это возможность для пользователей не мешать друг другу и сохранять целостность данных.
Допустим, у вас есть операция по переводу денег со счета на счет. При определенном хранилище данных это две операции: списать деньги со счета и записать деньги на другой счет. Если одна из операций не произошла, то вторую также необходимо отменить.
В этом случае операции объединяются в блоки, и такой блок операций называется транзакцией.
- Наличие выделенного узла лично для меня очень важно, потому что это сигнал о том, что в системе есть узкое место.
Если вы станете большим и у вас будет много пользователей, это место может начать давать сбои, и вы ничего не сможете с этим поделать.
- Платно/бесплатно – тут понятно, всех интересуют деньги.
Прежде чем показать вывеску, я расскажу вам о Hadoop. Я очень люблю Hadoop, потому что это комбайн, в нем можно делать все.
В нем есть SQL, транзакции, возможность сохранять данные удобным способом, ML из коробки.
Можно писать низкоуровневое, сохранять в облаке, в общем делать всё, что хочешь.
Но де-факто Hadoop — это боль.
Первое, что вызывает это – безопасность.
За безопасность в Hadoop отвечает Kerberos (есть и другие решения, но это самое популярное).
Для всех, кого я знаю, выкатывание Kerberos на кластер превращается в целый проект, который занимает квартал, полгода, и при этом вы будете решать проблемы, о некоторых из которых даже не пишут на Stack Overflow. В архитектуре Hadoop ваш пользователь записывается в переменную среды.
Если вы хотите стать админом, то просто пишете в консоли: устанавливаете HADOOP_USER="admin" и получаете доступ ко всем данным кластера.
Естественно, ни о какой безопасности здесь не может быть и речи, и вам необходимо установить другие дополнительные системы, например, Kerberos. Во-вторых, Hadoop имеет платные и бесплатные сборки.
Если вы выбрали бесплатный путь сборки Vanilla Hadoop, то, скорее всего, будет много ошибок.
Например, мы обновили Hive, и в нем обнаружилась ошибка: если у вас JOIN типа поля из одной таблицы равен COALESCE поля из другой таблицы, то это просто не работало.
Это условие не было выполнено, и JOIN работал неправильно.
Но мы были крутой командой Java-разработчиков, так чего же нам стоило исправить Java-код Hadoop? Мы потратили месяц на изучение исходного кода Hadoop. В итоге проблему нашли и устранили, но на это ушёл месяц, так как делали это впервые.
Пока мы этим занимались, наши аналитики обнаружили еще одну проблему.
Когда мы представили, что нам придется проходить весь этот путь еще раз, мы сделали вики-страницу, где описали, чего делать не следует. Конечно, кто-то всё равно это сделал, получил неправильные результаты, в общем — это было именно такое решение.
Еще одна боль Hadoop — совместное использование ресурсов, оно существует в очень грубом виде, это очереди YARN или отдельные экземпляры Spark. Это не лучшее решение и имеет множество неприятных нюансов.
БИ с быстрым ответом нет - это думаю все знают. Если вы хотите брать данные в Spark или Hive из базы данных JDBC, загружать их в Hadoop и обрабатывать, то, скорее всего, вам понадобится взять Sqoop или подключить JDBC-коннектор в Spark. NameNode является узким местом.
Расскажу, как Джун устанавливала наш кластер Hadoop. Он прошёл множество курсов и узнал о Hadoop. Там он узнал, что круто раскладывать данные по отдельным сегментам, группируя их по полям.
В рамках запроса он сделал кластеризацию по полю с миллионом уникальных значений, чтобы каждое уникальное значение помещалось в отдельный файл.
Hadoop начал работать очень медленно.
У нас не было никакого мониторинга, который бы свидетельствовал о том, что количество файлов в Hadoop увеличилось.
Мы долго разбирались и только в конце дня поняли, что наш NameNode отвечает медленно, потому что в одном каталоге появились миллионы файлов по 16 КБ.
В Hadoop нет способа защититься от этого.
Многие люди считают Hadoop дьяволом.
Вероятно, Hadoop — самый простой вариант. Я не знаю систем, которые так же легко запустить, но знаю более эффективные.
Teradata (обсуждается ниже) также работает хорошо, она может извлекать неструктурированные и неоптимизированные данные из S3 и далее обрабатывать их с помощью адаптивного оптимизатора.
И это будет как минимум не медленнее, чем в Hadoop. 
В то же время Hadoop и Spark — это круто.
Hadoop — сложный инструмент, который сложно поддерживать, но который открывает большие возможности.
Я бы сравнил Hadoop с языком C, где можно эффективно написать любую сложную программу, но с большой вероятностью допустить ошибки.
Я работал с Hadoop, ClickHouse, Greenplum, Teradata, Exasol, Vertica. В первой таблице представлены преимущественно технические характеристики.
Остановлюсь на особой важности Storage Type. Существует два типа хранилища — столбчатое и строковое.
Столбчатое хранилище в среднем быстрее выбирает данные и лучше сжимает их.
Он больше подходит для длительного хранения.
В то же время помещение данных в столбчатое хранилище — более длительная операция.
Благодаря хранению строк вам не нужно выполнять сложные операции для вставки данных.
Но каждый раз, когда вы читаете строку, вам нужно выполнять операцию поиска, пока не дойдете до нужного столбца.
Если в хранилище столбцов вы делаете это один раз, чтобы добраться до нужного столбца, то в случае хранилища строк вам нужно делать поиск для каждой строки.
Еще одним важным моментом является наличие функций UDF. Здесь нужно посмотреть, насколько широкие возможности предоставляет язык, на котором можно писать свои функции для репозитория.
Многие поддерживают Python, Greenplum имеет PL/SQL, ClickHouse имеет расширенный синтаксис SQL. Exasol может работать с Lua, Vertica — с Python, C++ и другими.
В последнем случае, если вы написали UDF на C++, то он выполняется внутри базы данных, JRE и Python-исполнитель не поднимаются, а просто происходит нативный процесс.
Далее я поделюсь своим опытом работы с системами и своим взглядом на них.
Информацию о пользователях системы я брал не с официальных сайтов вендоров, а из открытых источников, где сами пользователи рассказывают о своих впечатлениях.
Я думаю, так будет более справедливо.
Кликхаус
Пользователи: Яндекс.Метрика
В контакте с Облачное сияние Достаточно новая база данных, публичная версия вышла в 2016 году.Она зародилась в Яндекс.
Метрике и стала бешено популярной.
Откуда такая популярность? 
Человечество тяготело к матрицам и матричным вычислениям, даже когда не было компьютеров.
Математики изучали линейную алгебру.
Так он обзавелся хорошим математическим аппаратом, и в 60-70-х годах его начали изучать только начинающие программисты.
Сейчас любят проводить машинное обучение на процессорах GPU. Почему игрушечная видеокарта подходит для машинного обучения? Дело в том, что рендеринг изображений — это тоже матричные операции, и видеокарта их выполняет хорошо.
В машинном обучении также много матричных операций.
Создатели ClickHouse написали на C++ все операции, которые выполняются векторизованно.
Это позволяет им хорошо распараллеливаться и выполняться очень быстро.
Система немного другая логически и иногда позволяет добиться очень крутых результатов.
И еще одна особенность.
Синтаксис SQL немного урезан по сравнению с классическим для оптимизации матричных векторизованных процессов.
Взамен вам предлагается множество функций, таких как лямбда-функции для массивов, которые являются стандартным типом в ClickHouse. Это уникальная, но очень быстрая система.
Я как-то встречался с руководителем технического отдела одного банка, он сказал: «Мы взяли здесь ClickHouse, но используем его для парсинга JSON, а затем загружаем его в наше хранилище».
Потом мы сами стали использовать ClickHouse при разборе JSON, так как он написан на C++ и все операции в нем происходят очень быстро.
Зеленая слива
Открытый исходный код с 2015 года; предыдущие версии - с 2005 года.
Пользователи: Тинькофф Банк Сбер Лерой Мерлин 
Вероятно, это самая логичная база данных в ее развитии.
Давайте представим, что вам не хватает вашей SMP-системы для хранения данных.
Greenplum решила создать систему MPP, которая будет состоять из группы небольших систем SMP, стоящих рядом друг с другом.
Конкретно в случае с GreenPlum в качестве основы использовался PostgreSQL. По сути, Greenplum — это кучка PostgreSQL, которые под капотом пытаются обрабатывать ваши запросы, разбрасывая данные и обрабатывая задачи между собой.
Почти все, что у вас есть с PostgreSQL, можно адаптировать к Greenplum; и для многих внешних систем Greenplum выглядит как большой PostgreSQL. Трудности известны, их решения тоже существуют, но отметим один неприятный нюанс: Greenplum часто опирается на искусство.
Теги: #Хранение данных #облачные сервисы #Конференции #Большие данные #Hadoop #greenplum #Инжиниринг данных #dwh #облачное хранилище #smartdata #smartdata #Максим Стаценко
-
Карнеад
19 Oct, 24 -
Видеоаналитика: Прагматичный Взгляд
19 Oct, 24 -
Новогодний Анонс Курсов На Портале Мва
19 Oct, 24 -
Google Adsense – Заработок На Видеоклипах.
19 Oct, 24 -
Shoot3D - Макет. Тайна Танцующих Мужчин
19 Oct, 24 -
Docme - Youtube Для Документов
19 Oct, 24
