Pull to refresh
46
0
Алексей @0x0FFF

Архитектор распределенных систем обработки данных

Send message
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 и портирует функционал их ядра, борясь за серверных пользователей.
Несколько замечаний:
  1. В DAS-кластере 6 рабочих узлов по 8 дисков каждая — итого 48 дисков
    В Isilon-кластере 4 узла x410 по 30 дисков в каждом минимум — итого 120 дисков + SSD
    Серьезно ли сравнивать производительность файловых систем кластеров в такой конфигурации?
  2. Не указана конфигурация дисковой подсистемы для DAS-узлов, т.е. непонятно, сколько из 8 дисков на сервер реально используется для обработки данных. Может быть 2 диска собраны в RAID1 и отданы OS, а под данные используются только 6 дисков на ноду? От этого сильно зависят результаты
  3. Не указан объем данных, на котором тестировался NFS, и количество передаваемых файлов. У Isilon 3.2TB SSD-дисков. В вашем тесте NFS-запись на него длится около 35 секунд. Если до Isilon проброшено 4 кабеля по 10GbE, то их суммарная производительность будет 40 Gbit/sec или 5GB/sec. За 35 секунд через такой канал можно передать 175GB данных, что заведомо меньше объема доступных SSD, то есть данные по большей части лягут на быстрые SSD. Если кабелей 8 картина не меняется — будет 350GB переданных данных
  4. Для terasort не указали объем данных, на котором тестировались, и количество файлов. Результат Teragen на Isilon — 600 секунд. Используя расчеты из п.2, у меня получается что объем данных был около 3TB, что опять же меньше объема SSD, доступного у Isilon.

Итого по teragen и terasort, имея в 3 раза больше дисков в Isilon, производительность по сравнению с DAS-кластером выше в 2.6 и 1.5 раза соответственно. Честно говоря, это не удивительно, но все же хотелось бы, чтобы сравнивали яблоки с яблоками

В целом, Isilon — штука довольно интересная и реально используемая многими крупными компаниями, имеющая свои преимущества для enterprise-заказчиков. Но все же это не повод к публикации подобных спорных бенчмарков
Компаний довольно много, и для примера приведем 8 организаций, изменившихся к лучшему благодаря когнитивной системе
Самого примера так почему-то и не последовало. Не до конца перевели статью?
Полностью согласен, это было бы очень здорово. Если решите такую сделать, поделитесь ссылкой
На самом деле попыток запускать 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 зубцов зафиксированной шестеренки, и завершит оборот ровно на том зубце, с которого начинала. Разве не так?
Задача D — можно ограничиться целыми числами:
Решение
def ispow2(num):
    if num == 1:
        return True
    if num % 2 == 1:
        return False
    return ispow2(num/2)

print ispow2(1024)



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
Задача K
вместо:
            // Шаг рекурсии / рекурсивное условие
            if (n % 2 == 1) {
                System.out.println(n);
                recursion();
            } else {
                recursion();
            }

написать:
            // Шаг рекурсии / рекурсивное условие
            if (n % 2 == 1) {
                System.out.println(n);
            }
            recursion();


Задача 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)

Хорошие задачи на рекурсию:
Задача на BFS/DFS — http://www.careercup.com/question?id=4716965625069568
Задача на аналог qsort — найдите k-ое по величине число в заданной последовательности
Возможно, «Билайн» захантил чересчур много специалистов на позицию «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 и т.д.
Вопрос скорее в том, что некоторые вещи позволительно сказать при живом выступлении — ошибиться в ряде терминов, назвать что-то неправильно и т.д. Это допускается, так как выступление — это зачастую импровизация. Но когда вы пишете статью ожидается, что вы проверите приведенные факты и высказывания перед публикацией, ведь в отличии от живого выступления времени на это у вас достаточно

Information

Rating
Does not participate
Location
Dublin, Dublin, Ирландия
Registered
Activity