Vertica оставила бы и Spark, и Impala глотать пыль на сопоставимых мощностях в структурированной задаче на таких крошечных размерах. Oracle сравнивать с ними совсем не стоит, это решение под транзакционные нагрузки, его используют под DWH либо как легаси, либо по неграмотности.
Аналитические ad-hoc запросы на Spark нужно запускать в уже проинициализированном контексте, опционально, с динамическим аллоцированием. Из коробки в CDH это умеет Hive-on-Spark через CLI или Hue. Не из коробки после небольшой магии можно поднять Spark SQL Thrift Server или Hive LLAP + Spark. Самый кастомный вариант — можно держать контекст в отдельном приложении и сделать свой собственный интерфейс.
"Что-то Lamborghini дороговата… Сравнил её с комбайном Ростсельмаш Дон без переднего колеса, так вот он больше картошки за раз везёт. Правда, в лесу борона за сосны цепляется, могли бы предусмотреть… Да, надо Lamborghini подумать о ценовой политике!"
Несопоставимые вычислительные мощности, use case заведомо проигрышный для Oracle, неоптимальный способ запуска Spark (spark-submit для SQL, серьёзно?), однобокий запрос — методология абсолютно кустарна.
Если хотите сравнивать производительность аналитических запросов — сравнивайте Spark SQL, Teradata, Vertica, GreenPlum, HANA, ClickHouse и т.п. Причем у каждого из этих решений есть своя оптимальная ниша и свои условия работы. Зачем сравнивать с Oracle, который играет в совсем другие игры?
Это аналогично уменьшению числа бинов в гистограмме. Чем меньше число бинов (С), тем больше соотношение B/C, тем хуже видно артефакты дискретного пространства.
В изначальных графиках я брал 1000 бинов, на них всё отлично видно. Для 100 бинов самые сильные выбросы ещё заметны, но уже сливаются с шумом.
На картинке видно пики на дробных явках. Сделайте побольше разрешение и добавьте линии на дробных значениях, и выбросы будут еще отчетливее.
Как вот тут: https://habrahabr.ru/post/352424/#comment_10737414
Спасибо, что провели моделирование! К сожалению, вы не уловили суть эксперимента и где-то ошиблись. Вот что должно было у вас получиться:
График явки с распределенями от @Sabubu
А если взять данные, похожие на настоящие выборы, получается вот что:
График явки с распределениями, приближенными к натуральным
Как видите, пиковые выбросы присутствуют. Я нарисовал полосы для дробей от 1/2 до n/10, так что отлично видно, что пики присутствуют именно в этих значениях.
Объясню еще раз, почему это получается. У вас есть случайно распределенное целое число A. Вы делите его на другое случайно распределенное целое число B. Вы получаете дискретное вероятностное пространство A/B. Далее вы пытаетесь отобразить его на канвас с целым числом пикселов C, т.е. в другое дискретное пространство. При недостаточно большом соотношении B/C A/B мапится на C неравномерно и искажает изначальное распределение A/B.
Ни один из ваших графиков напрямую не применим к президентским выборам.
Мои рассуждения — про дроби. Они подходят вообще под любые распределения шансов. Наверняка можно обобщить их в строгое доказательство, но это потребует массу времени, а читать его никто не будет.
Омг, да это не принципиально, размер участка. Чем больше размер, тем более редкими и выраженными будут пики.
Можете проверить сами. Нагенерируйте случайных участков с правдоподобным распределением размеров (гамма вокруг 1220?), нагенерируйте правдоподобной явки (гаусс вокруг 70%?), а потом загоните результат все в бакеты с шагом по 1%.
Если размеры участков распределены равномерно на интервале от 1 до 104, то получить 75 из 103 можно только в одном случае (75/103), то 75% достигается 26 способами (3/4, 6/8, ..., 75/100, 78/104). В этом модельном случае пик на 75% будет в 26 раз больше, чем на 75/103.
Обратите внимание, что это за участки. Высокая явка — нормальное явление для высокоорганизованных УИКов типа традиционных общин, режимных учреждений, военных частей. Дух конформизма в таких местах весьма силен, этим может объясняться традиционно высокий процент за действующую власть.
В моей статье числа по порядку довольно близко соответствуют выборам, как число точек (около 100к), так и порядок делимых чисел (от 1 до нескольких тысяч). Это совпадение, не специально.
Высокая явка — нормальное явление для высокоорганизованных УИКов типа традиционных общин, режимных учреждений, военных частей. Дух конформизма в таких местах весьма силен, этим может объясняться традиционно высокий процент за действующую власть.
На моем изображении реальные данные, около ста тысяч точек, числитель и знаменатель варьировались от 1 до нескольких тысяч, примерно по гамма-распределениям. Масштабы чисел достаточно близки к данным по УИКам, но это не специально. На изображении увеличен фрагмент от 0.0 до 1.0 по обоим осям.
95 тысяч точек недостаточно, чтобы получить гладкую картинку на холсте в миллион пикселов, тем более, что голоса и размеры УИКов распределены неслучайно.
Такие полосы постоянно появляются на графиках распределения дробей. Посмотрите, например, графики с выборов про политические партии или снос домов в Москве — эти полоски много раз давали диванным политологам повод обвинять всех подряд в коррупции.
Похожие ситуации как раз и возникают, когда отделы в компании друг к другу никак не относятся.
А ещё так появляется десяток лабораторий больших данных, каждая из которых всех бигдатей и пишет что-то своё. Часто на одну и ту же тему, зато все эксперименты очень удачные.
А если вдруг доходит до внедрения, сберджайл заканчивается, и начинаются подковёрные шахматы.
Сама по себе Presto, без QueryGrid, имеет схожую функциональность и изначально разрабатывалась в Facebook для тех же целей и, рискну, предположить, еще больших объемов и производительности. Что забавно, Presto умеет использовать Teradata как источник данных, пробрасывать туда предикаты и распараллеливать вычисления.
Vertica оставила бы и Spark, и Impala глотать пыль на сопоставимых мощностях в структурированной задаче на таких крошечных размерах. Oracle сравнивать с ними совсем не стоит, это решение под транзакционные нагрузки, его используют под DWH либо как легаси, либо по неграмотности.
Аналитические ad-hoc запросы на Spark нужно запускать в уже проинициализированном контексте, опционально, с динамическим аллоцированием. Из коробки в CDH это умеет Hive-on-Spark через CLI или Hue. Не из коробки после небольшой магии можно поднять Spark SQL Thrift Server или Hive LLAP + Spark. Самый кастомный вариант — можно держать контекст в отдельном приложении и сделать свой собственный интерфейс.
Несопоставимые вычислительные мощности, use case заведомо проигрышный для Oracle, неоптимальный способ запуска Spark (spark-submit для SQL, серьёзно?), однобокий запрос — методология абсолютно кустарна.
Если хотите сравнивать производительность аналитических запросов — сравнивайте Spark SQL, Teradata, Vertica, GreenPlum, HANA, ClickHouse и т.п. Причем у каждого из этих решений есть своя оптимальная ниша и свои условия работы. Зачем сравнивать с Oracle, который играет в совсем другие игры?
Это аналогично уменьшению числа бинов в гистограмме. Чем меньше число бинов (С), тем больше соотношение B/C, тем хуже видно артефакты дискретного пространства.
В изначальных графиках я брал 1000 бинов, на них всё отлично видно. Для 100 бинов самые сильные выбросы ещё заметны, но уже сливаются с шумом.
На картинке видно пики на дробных явках. Сделайте побольше разрешение и добавьте линии на дробных значениях, и выбросы будут еще отчетливее.
Как вот тут: https://habrahabr.ru/post/352424/#comment_10737414
Нарисовал:
https://habrahabr.ru/post/352424/#comment_10737414
Я напрягся и промоделировал сам.
На сгенерированных данных пики хорошо видно:
https://habrahabr.ru/post/352424/#comment_10737414
Спасибо, что провели моделирование! К сожалению, вы не уловили суть эксперимента и где-то ошиблись. Вот что должно было у вас получиться:
А если взять данные, похожие на настоящие выборы, получается вот что:
Как видите, пиковые выбросы присутствуют. Я нарисовал полосы для дробей от 1/2 до n/10, так что отлично видно, что пики присутствуют именно в этих значениях.
Объясню еще раз, почему это получается. У вас есть случайно распределенное целое число A. Вы делите его на другое случайно распределенное целое число B. Вы получаете дискретное вероятностное пространство A/B. Далее вы пытаетесь отобразить его на канвас с целым числом пикселов C, т.е. в другое дискретное пространство. При недостаточно большом соотношении B/C A/B мапится на C неравномерно и искажает изначальное распределение A/B.
Вот код, если желаете повторить результат. Там буквально 25 строк.
Мои рассуждения — про дроби. Они подходят вообще под любые распределения шансов. Наверняка можно обобщить их в строгое доказательство, но это потребует массу времени, а читать его никто не будет.
Давайте же закончим голословно.
Омг, да это не принципиально, размер участка. Чем больше размер, тем более редкими и выраженными будут пики.
Можете проверить сами. Нагенерируйте случайных участков с правдоподобным распределением размеров (гамма вокруг 1220?), нагенерируйте правдоподобной явки (гаусс вокруг 70%?), а потом загоните результат все в бакеты с шагом по 1%.
За график вам все спасибо скажут.
Я дал ссылку на свой блог пост 2017го года, прошу прощения, что получилось незаметно. Там буквально несколько абзацев.
Вот та же ссылка plain text'ом: http://fediq.ru/fraction-distribuiton-plot/
В ответе на комментарий выше я показал пример, как получается пик для трехзначных чисел.
Если размеры участков распределены равномерно на интервале от 1 до 104, то получить 75 из 103 можно только в одном случае (75/103), то 75% достигается 26 способами (3/4, 6/8, ..., 75/100, 78/104). В этом модельном случае пик на 75% будет в 26 раз больше, чем на 75/103.
Прочтите, пожалуйста, статью. Она именно об этом.
Мы это уже обсудили выше, дважды.
Круглые числа объясняет распределение дробей. Мы же это уже обсудили?
Обратите внимание, что это за участки. Высокая явка — нормальное явление для высокоорганизованных УИКов типа традиционных общин, режимных учреждений, военных частей. Дух конформизма в таких местах весьма силен, этим может объясняться традиционно высокий процент за действующую власть.
В моей статье числа по порядку довольно близко соответствуют выборам, как число точек (около 100к), так и порядок делимых чисел (от 1 до нескольких тысяч). Это совпадение, не специально.
Высокая явка — нормальное явление для высокоорганизованных УИКов типа традиционных общин, режимных учреждений, военных частей. Дух конформизма в таких местах весьма силен, этим может объясняться традиционно высокий процент за действующую власть.
На моем изображении реальные данные, около ста тысяч точек, числитель и знаменатель варьировались от 1 до нескольких тысяч, примерно по гамма-распределениям. Масштабы чисел достаточно близки к данным по УИКам, но это не специально. На изображении увеличен фрагмент от 0.0 до 1.0 по обоим осям.
95 тысяч точек недостаточно, чтобы получить гладкую картинку на холсте в миллион пикселов, тем более, что голоса и размеры УИКов распределены неслучайно.
Вот, пожалуйста.
Похожие ситуации как раз и возникают, когда отделы в компании друг к другу никак не относятся.
А ещё так появляется десяток лабораторий больших данных, каждая из которых всех бигдатей и пишет что-то своё. Часто на одну и ту же тему, зато все эксперименты очень удачные.
А если вдруг доходит до внедрения, сберджайл заканчивается, и начинаются подковёрные шахматы.
Сама по себе Presto, без QueryGrid, имеет схожую функциональность и изначально разрабатывалась в Facebook для тех же целей и, рискну, предположить, еще больших объемов и производительности. Что забавно, Presto умеет использовать Teradata как источник данных, пробрасывать туда предикаты и распараллеливать вычисления.
Можете разъяснить подробнее, какие преимущества привносит Teradata QueryGrid?