HAWQ 2.0 нативно поддерживает чтение таблиц, объявленных в Hive Metastore, без плясок с бубном вроде внешних таблиц. А скоро будет поддерживать и их создание
Да, вы правы, GPDB уже умеет многое. В то же время HAWQ работает поверх Hadoop и интегрируется с YARN, что позволяет ему более удачно вписаться в Hadoop-кластер, а вот GPDB требует для своей работы отдельный кластер и немного другую организацию дисков
На официальном сайте есть этому объяснение: https://www.mongodb.com/big-data-explained
Вся эта статья про аналитические системы, а MongoDB — это т.н. «operational» система. Обычно она всплывает в контексте обсуждения Cassandra, HBase и подобных систем этого класса
Хорошая статья, спасибо! Приятно, что есть еще специалисты, способные разделять реальность и маркетинг
В целом направление мысли верное, но есть некоторые фактические ошибки:
если, например, маперы уже прекратили свою работу, то ресурсы редьюсерам уже не освободятся — на самом деле освободятся. Даже если у вас YARN настроен на возможность выполнения только одного таска единовременно (один маппер или один редюсер), вы сможете выполнить задачу в 1000 мапперов и столько же редюсеров. Конечно, работать они при этом будут последовательно
Spark не понимает, как данные лежат в HDFS. Это хоть и MPP-система — Spark не MPP, это тот же Batch Processing, что и MapReduce. Задача обработки данных разбивается на таски и они выполняются асинхронно, промежуточные данные сбрасываются на диск
Spark Streaming и, возможно, это будет действительно таким «долгоиграющим» решением — Как раз у Spark Streaming наиболее сильные конкуренты — Apache Storm, Apache Heron, Apache Flink, да и та же Kafka c Kafka Streams. Конкурировать micro-batch подходу Spark Streaming с «честным» streaming в вышеназванных системах будет очень проблематично
Impala, Drill и Kudu… это такие же МРР-движки поверх HDFS как Spark и MR — Kudu не имеет зависимости от HDFS, это как раз более быстрая замена HDFS для обработки табличных данных с поддержкой update (в отличии от HDFS). И, конечно, она не имеет отношения к MPP
Apache HAWQ… они взяли традиционный Greenplum и натянули его на HDFS… какой-то практической целесообразности в этом мало. — по сути это ответ рынку. MPP over Hadoop востребована (посмотрите на те же Hive и Impala), вот Pivotal и выпустил этот продукт. К слову сказать, среди решений его класса он является наиболее быстрым и продвинутым в плане поддержки SQL, но как и любое связанное с Hadoop решение является сложным в сопровождении
Появятся первые дистрибутивы CDH уже с частичным отказом от использования HDFS — уже появились, ведь Kudu — это не HDFS
Greenpum сделает свой аналог Flex Zone, путем слияния кода с HAWQ, либо сам станет non-HDFS частью HAWQ, в конце концов, кого-то мы потеряем — на самом деле я поднимал этот вопрос перед руководством практически сразу после форка HAWQ от GPDB, но такой цели нет. Сейчас же их ветки ушли чересчур далеко друг от друга и я не вижу возможности их слияния в будущем. Скорее GPDB расширит функционал для нативной поддержки HDFS таблиц, да и только.
В свое время я тоже писал и про Kudu, и про неструктурированные данные, и про перспективы Big Data, и про перспективы Spark. В целом же я рекомендую вам писать статьи на английском — это даст охват аудитории в 10 раз выше и возможность дискуссии с интересными специалистами (как, например, мой спор с одним из создателей Spark в комментариях к этой статье)
Что примечательно, практически вся СУБД была создана одним человеком
В целом же молодцы, что открыли исходники! Очень интересно посмотреть, как оно работает изнутри
Правильное направление — признание лидерства Linux в области серверных ОС и работа в сторону лучшей с ним интеграции (нативный запуск Linux-приложений в Windows, версия MSSQL для Linux, портирование Docker и Hadoop, и т.д.)
Проприетарно — это не хорошо и не плохо, это по-другому. Но проприетарность серверной ОС — это то, с чем многие разрабатывающие софт компании не хотят мириться, т.к. для них разработка под такую платформу является более высоким риском, чем разработка под открытую платформу.
Мобильные ОС (смартфоны) — пример рынка, на который MS также опоздала, и так и не сумела выйти в лидеры
Intel: 107'300, Red Hat: 8'300, Samsung: 307'000, Google: 57'100, IBM: 377'757, TI: 31'003 — мне продолжать по остальным 1294 компаниям?
К тому же из 118,584 человек в Microsoft только 43,860 инженеры. Из них, например, над Windows 7 работали 2'000 разработчиков. По другой информации всего над Windows работает около 5'000 человек
Лично я считаю, что Microsoft движется в правильном направлении, но они сильно опоздали на этот рынок. Я профессионально занимаюсь кластерными системами, и по моему опыту серверные инсталляции Windows популярны только в Израиле (из всего региона EMEA). Так же, например, Microsoft опоздали на рынок мобильных ОС
Пока ядро Windows проприетарно, добиться успеха в области серверных приложений у них не получится. Кто делает вклад в ядро Linux: Intel, Red Hat, Samsung, IBM, SUSE, Texas Instruments, Google, всего более 1200 компаний. Кто делает вклад в ядро Windows: Microsoft. У них просто нет такого количества квалифицированных ресурсов, чтобы конкурировать с таким большим open source сообществом
Сообщество Linux в течении более чем 10 лет разрабатывало функционал ядра Linux для поддержки приложений вроде LXC и Docker — это и cgroups для контроля потребления ресурсов, и различные namespace для изоляции процессов, и различные union fs вроде aufs для поддержки файловой системы контейнера, и виртуальные сетевые адаптеры. Это всё в ядре Linux, и что-то уже очень давно.
Похоже, Microsoft желает сделать то же самое за год-другой. Конечно, ни о каком запуске контейнеров Linux в Windows речи не идет — для этого Windows должен поддерживать чересчур много системных вызовов Linux, от чего они пока весьма далеко. Но прогресс идет в этом направлении, что весьма интересно — сначала Linux пытался догнать Windows, улучшая GUI и борясь за десктопных пользователей, а теперь Microsoft эмулирует системные вызовы Linux и портирует функционал их ядра, борясь за серверных пользователей.
В DAS-кластере 6 рабочих узлов по 8 дисков каждая — итого 48 дисков
В Isilon-кластере 4 узла x410 по 30 дисков в каждом минимум — итого 120 дисков + SSD
Серьезно ли сравнивать производительность файловых систем кластеров в такой конфигурации?
Не указана конфигурация дисковой подсистемы для DAS-узлов, т.е. непонятно, сколько из 8 дисков на сервер реально используется для обработки данных. Может быть 2 диска собраны в RAID1 и отданы OS, а под данные используются только 6 дисков на ноду? От этого сильно зависят результаты
Не указан объем данных, на котором тестировался NFS, и количество передаваемых файлов. У Isilon 3.2TB SSD-дисков. В вашем тесте NFS-запись на него длится около 35 секунд. Если до Isilon проброшено 4 кабеля по 10GbE, то их суммарная производительность будет 40 Gbit/sec или 5GB/sec. За 35 секунд через такой канал можно передать 175GB данных, что заведомо меньше объема доступных SSD, то есть данные по большей части лягут на быстрые SSD. Если кабелей 8 картина не меняется — будет 350GB переданных данных
Для terasort не указали объем данных, на котором тестировались, и количество файлов. Результат Teragen на Isilon — 600 секунд. Используя расчеты из п.2, у меня получается что объем данных был около 3TB, что опять же меньше объема SSD, доступного у Isilon.
Итого по teragen и terasort, имея в 3 раза больше дисков в Isilon, производительность по сравнению с DAS-кластером выше в 2.6 и 1.5 раза соответственно. Честно говоря, это не удивительно, но все же хотелось бы, чтобы сравнивали яблоки с яблоками
В целом, Isilon — штука довольно интересная и реально используемая многими крупными компаниями, имеющая свои преимущества для enterprise-заказчиков. Но все же это не повод к публикации подобных спорных бенчмарков
На самом деле попыток запускать Hadoop поверх СХД предпринималось уже довольно много, практически все вендоры СХД имеют своё решение для этого. В пику этому по сети гуляет множество статей вроде Never, ever do this to Hadoop, осуждающих такой дизайн. Даже я как-то написал одну.
На самом деле тут все довольно просто. Подобные системы имеют смысл только при сильном дизбалансе требований к объему хранимых данных и вычислительной мощности. Например, большой кластер Apache Spark для обработки пары десятков терабайт данных в MLlib, или же хранение нескольких петабайт данных и периодические запросы к ним в Hive.
Рациональная же составляющая тут следующая — не верьте маркетингу. Если у вас есть N процессоров и M жестких дисков, то добавив между ними сеть вы никак не получите +30% в производительности чтения (да и откуда, жестких дисков-то ровно столько же). Затем, при использовании приведенной архитектуры нужно не забывать про стоимость лицензий на софт, поставляемый HPE (те же СХД — это не просто кучка железа, это проприетарный софт на них). Масштабировать такой кластер в будущем можно будет только компонентами HP, то есть вендор lock-in гарантирован. К тому же требования к сети у таких решений по сравнению с традиционными кластерами Hadoop сильно выше — если на текущий момент множество кластеров Hadoop спокойно живет с 1GbE ввиду парадигмы вычислений MR, то тут без 10GbE не обойтись, а желательно еще и по нескольку кабелей к каждой из нод подвести (20 LFF дисков на вычислительную ноду смогут отдать ей около 1200MB/sec, а это уже больше возможностей одного 10GbE порта).
Как показывает практика, чаще всего подобные системы внедряются крупными банками и подобными им корпорациями, в которых нет своей экспертизы по Hadoop, но которые хотят показать всему миру что "мы тоже умеем Hadoop". Зачастую внедренные таким образом системы либо практически не используются, либо заменяются нормальными кластерами с ростом нагрузки на них и экспертизы на стороне заказчика.
Если у нас две шестеренки по 50 зубцов в каждой, то как возможно, чтобы за один оборот вокруг зафиксированной шестеренки движущаяся совершила два оборота? Ведь она пройдет ровно 50 зубцов зафиксированной шестеренки, и завершит оборот ровно на том зубце, с которого начинала. Разве не так?
Задача S — вот оба варианта, реализованные на Python. Рекурсивный начинает тормозить уже при вычислении суммы для 9 символов, а вариант с меморизацией выводит результат и для 50 символов за миллисекунды:
Задача S
# Recursive version
def findrec(target, length):
res = 0
if length == 1 and target < 10:
res = 1
elif length > 1:
for i in range(min(10,target)):
res += findrec(target-i, length-1)
return res
# Memorization version
def findmem(target, length, mem):
if mem[target][length] > -1:
return mem[target][length]
res = 0
if length == 1 and target < 10:
res = 1
elif length > 1:
for i in range(min(10,target)):
r = findmem(target-i, length-1, mem)
mem[target-i][length-1] = r
res += r
return res
def find(target, length):
mem = [[-1]*(length+1) for _ in range(target+1)]
return findmem(target, length, mem)
A: От 1 до n — склеивать числа в строку крайне неэффективно, почему бы их прямо из функции не печатать? B: От A до B — аналогично D: Точная степень двойки — решение через числа с плавающей точкой просто режет глаза, неужели нельзя было просто делить пополам и проверять остаток от деления? H: Проверка числа на простоту — в условии решение должно быть за O(logN), ваше же решение O(N) по вычислениям и O(N) по памяти засчет стека рекурсии I: Разложение на множители — FYI, даже решето Эратосфена не дает O(logN). Ваше решение O(N) по вычислениям и O(N) по памяти K: Вывести нечетные числа последовательности — пример вообще дикий, при этом зачем-то два рекурсивных вызова вместо одного S: Заданная сумма цифр — тут хорошо добавить условия ранней остановки рекурсии (sum > s) и меморизацию по (len,sum) чтобы тысячи раз не считать одно и то же U: Разворот числа — как уже заметили, решение с логарифмами и степенями весьма дико. Код будет такой:
def rev(num,tmp):
res = tmp*10 + num%10
if num > 10:
res = rev(num/10, res)
return res
print rev(123456789,0)
Возможно, «Билайн» захантил чересчур много специалистов на позицию «Data Scientist», а так как задач для них особенно нет, должны же они как-то отрабатывать свой хлеб? 50 человек по 100к с каждого пару раз в год — вот и бюджет команды из 4х специалистов
В целом согласен с замечанием: мероприятие непродолжительное (12 занятий по 2 часа) и после программы ШАД (бесплатной, кстати) выглядит немного смешно, наподобие вечерних курсов программистов. Похоже, что оно 100% нацелено на хантинг
Печально. Похоже, что инвестиция в $300m делается не в Apache Spark как таковой, а в интеграцию Apache Spark с проприетарными продуктами IBM и портирование решений IBM на платформу Apache Spark. Переписать 40 миллионов строк DataWorks — не проблема, а вот сделать достаточный вклад в Apache Spark (около 400к строк кода всего), чтобы у IBM появился хоть один коммитер — уже намного сложнее.
В целом же статья чисто маркетинговая, порадовали «распознавание естественных языков» (имелось в виду наверное NLP?), «технологию обработки изображений» (а вот тут уже нужно «распознавание», плюс такой технологии нет в Spark), «компания считает свой инструмент весьма надежным» (ага, свой).
Даже не так — нужна большая база кода, в которой разные программисты решали одну и ту же задачу, в противном случае их решение работать не будет
Плюс тут еще много тонкостей — в GCJ почти у всех участников есть свои «шаблоны» решений, в которых для ответа на поставленную задачу чаще всего достаточно дописать только одну функцию. Отсюда и такое качество классификации, т.к. шаблоны чаще всего индивидуальны
Спасибо за развернутый ответ.
Я знаком с архитектурами современных MPP решений. Поэтому и интересно узнать вашу архитектуру, т.к. если ваше собственное решение, написанное за 2 года, обгоняет коммерческий продукт c 10-летней историей, спроектированный небезызвестным Стоунбрейкером, у вас однозначно должны быть какие-то ноу-хау в плане компрессии, обработки сжатых данных, индексов/bloom filters и т.д.
Вопрос скорее в том, что некоторые вещи позволительно сказать при живом выступлении — ошибиться в ряде терминов, назвать что-то неправильно и т.д. Это допускается, так как выступление — это зачастую импровизация. Но когда вы пишете статью ожидается, что вы проверите приведенные факты и высказывания перед публикацией, ведь в отличии от живого выступления времени на это у вас достаточно
Да, вы правы, GPDB уже умеет многое. В то же время HAWQ работает поверх Hadoop и интегрируется с YARN, что позволяет ему более удачно вписаться в Hadoop-кластер, а вот GPDB требует для своей работы отдельный кластер и немного другую организацию дисков
Вся эта статья про аналитические системы, а MongoDB — это т.н. «operational» система. Обычно она всплывает в контексте обсуждения Cassandra, HBase и подобных систем этого класса
В целом направление мысли верное, но есть некоторые фактические ошибки:
Greenpum сделает свой аналог Flex Zone, путем слияния кода с HAWQ, либо сам станет non-HDFS частью HAWQ, в конце концов, кого-то мы потеряем — на самом деле я поднимал этот вопрос перед руководством практически сразу после форка HAWQ от GPDB, но такой цели нет. Сейчас же их ветки ушли чересчур далеко друг от друга и я не вижу возможности их слияния в будущем. Скорее GPDB расширит функционал для нативной поддержки HDFS таблиц, да и только.
В свое время я тоже писал и про Kudu, и про неструктурированные данные, и про перспективы Big Data, и про перспективы Spark. В целом же я рекомендую вам писать статьи на английском — это даст охват аудитории в 10 раз выше и возможность дискуссии с интересными специалистами (как, например, мой спор с одним из создателей Spark в комментариях к этой статье)
В целом же молодцы, что открыли исходники! Очень интересно посмотреть, как оно работает изнутри
Проприетарно — это не хорошо и не плохо, это по-другому. Но проприетарность серверной ОС — это то, с чем многие разрабатывающие софт компании не хотят мириться, т.к. для них разработка под такую платформу является более высоким риском, чем разработка под открытую платформу.
Мобильные ОС (смартфоны) — пример рынка, на который MS также опоздала, и так и не сумела выйти в лидеры
К тому же из 118,584 человек в Microsoft только 43,860 инженеры. Из них, например, над Windows 7 работали 2'000 разработчиков. По другой информации всего над Windows работает около 5'000 человек
Лично я считаю, что Microsoft движется в правильном направлении, но они сильно опоздали на этот рынок. Я профессионально занимаюсь кластерными системами, и по моему опыту серверные инсталляции Windows популярны только в Израиле (из всего региона EMEA). Так же, например, Microsoft опоздали на рынок мобильных ОС
Похоже, Microsoft желает сделать то же самое за год-другой. Конечно, ни о каком запуске контейнеров Linux в Windows речи не идет — для этого Windows должен поддерживать чересчур много системных вызовов Linux, от чего они пока весьма далеко. Но прогресс идет в этом направлении, что весьма интересно — сначала Linux пытался догнать Windows, улучшая GUI и борясь за десктопных пользователей, а теперь Microsoft эмулирует системные вызовы Linux и портирует функционал их ядра, борясь за серверных пользователей.
В Isilon-кластере 4 узла x410 по 30 дисков в каждом минимум — итого 120 дисков + SSD
Серьезно ли сравнивать производительность файловых систем кластеров в такой конфигурации?
Итого по teragen и terasort, имея в 3 раза больше дисков в Isilon, производительность по сравнению с DAS-кластером выше в 2.6 и 1.5 раза соответственно. Честно говоря, это не удивительно, но все же хотелось бы, чтобы сравнивали яблоки с яблоками
В целом, Isilon — штука довольно интересная и реально используемая многими крупными компаниями, имеющая свои преимущества для enterprise-заказчиков. Но все же это не повод к публикации подобных спорных бенчмарков
На самом деле тут все довольно просто. Подобные системы имеют смысл только при сильном дизбалансе требований к объему хранимых данных и вычислительной мощности. Например, большой кластер Apache Spark для обработки пары десятков терабайт данных в MLlib, или же хранение нескольких петабайт данных и периодические запросы к ним в Hive.
Рациональная же составляющая тут следующая — не верьте маркетингу. Если у вас есть N процессоров и M жестких дисков, то добавив между ними сеть вы никак не получите +30% в производительности чтения (да и откуда, жестких дисков-то ровно столько же). Затем, при использовании приведенной архитектуры нужно не забывать про стоимость лицензий на софт, поставляемый HPE (те же СХД — это не просто кучка железа, это проприетарный софт на них). Масштабировать такой кластер в будущем можно будет только компонентами HP, то есть вендор lock-in гарантирован. К тому же требования к сети у таких решений по сравнению с традиционными кластерами Hadoop сильно выше — если на текущий момент множество кластеров Hadoop спокойно живет с 1GbE ввиду парадигмы вычислений MR, то тут без 10GbE не обойтись, а желательно еще и по нескольку кабелей к каждой из нод подвести (20 LFF дисков на вычислительную ноду смогут отдать ей около 1200MB/sec, а это уже больше возможностей одного 10GbE порта).
Как показывает практика, чаще всего подобные системы внедряются крупными банками и подобными им корпорациями, в которых нет своей экспертизы по Hadoop, но которые хотят показать всему миру что "мы тоже умеем Hadoop". Зачастую внедренные таким образом системы либо практически не используются, либо заменяются нормальными кластерами с ростом нагрузки на них и экспертизы на стороне заказчика.
H — самая очевидная оптимизация — это проверять делимость не до N/2, а до sqrt(N), сложность уже будет O(sqrt(N)). Есть еще вот такой вариант: en.wikipedia.org/wiki/AKS_primality_test, а вообще это сложная проблема: www.math.uni-bonn.de/people/saxena/talks/May2007-Turku.pdf
написать:
Задача S — вот оба варианта, реализованные на Python. Рекурсивный начинает тормозить уже при вычислении суммы для 9 символов, а вариант с меморизацией выводит результат и для 50 символов за миллисекунды:
B: От A до B — аналогично
D: Точная степень двойки — решение через числа с плавающей точкой просто режет глаза, неужели нельзя было просто делить пополам и проверять остаток от деления?
H: Проверка числа на простоту — в условии решение должно быть за O(logN), ваше же решение O(N) по вычислениям и O(N) по памяти засчет стека рекурсии
I: Разложение на множители — FYI, даже решето Эратосфена не дает O(logN). Ваше решение O(N) по вычислениям и O(N) по памяти
K: Вывести нечетные числа последовательности — пример вообще дикий, при этом зачем-то два рекурсивных вызова вместо одного
S: Заданная сумма цифр — тут хорошо добавить условия ранней остановки рекурсии (sum > s) и меморизацию по (len,sum) чтобы тысячи раз не считать одно и то же
U: Разворот числа — как уже заметили, решение с логарифмами и степенями весьма дико. Код будет такой:
Хорошие задачи на рекурсию:
Задача на BFS/DFS — http://www.careercup.com/question?id=4716965625069568
Задача на аналог qsort — найдите k-ое по величине число в заданной последовательности
В целом согласен с замечанием: мероприятие непродолжительное (12 занятий по 2 часа) и после программы ШАД (бесплатной, кстати) выглядит немного смешно, наподобие вечерних курсов программистов. Похоже, что оно 100% нацелено на хантинг
В целом же статья чисто маркетинговая, порадовали «распознавание естественных языков» (имелось в виду наверное NLP?), «технологию обработки изображений» (а вот тут уже нужно «распознавание», плюс такой технологии нет в Spark), «компания считает свой инструмент весьма надежным» (ага, свой).
Плюс тут еще много тонкостей — в GCJ почти у всех участников есть свои «шаблоны» решений, в которых для ответа на поставленную задачу чаще всего достаточно дописать только одну функцию. Отсюда и такое качество классификации, т.к. шаблоны чаще всего индивидуальны
Я знаком с архитектурами современных MPP решений. Поэтому и интересно узнать вашу архитектуру, т.к. если ваше собственное решение, написанное за 2 года, обгоняет коммерческий продукт c 10-летней историей, спроектированный небезызвестным Стоунбрейкером, у вас однозначно должны быть какие-то ноу-хау в плане компрессии, обработки сжатых данных, индексов/bloom filters и т.д.