Проблема всех подобных решений с микрофонами в том, что на звуке чуть более сложном, чем прямой и отчетливый бит, мигание превращается во что-то хаотичное и не совпадающее с самой музыкой. Т.е. мигает, но очень редко в тему. Помню давным давно те же простенькие визуализаторы музыки в WinAMP намного лучше справлялись с этой задачей.
мы немного о разном. Вы свариваете все данные «как есть» в кластер на hadoop/spark и используете его и как хранилище и как процессор SQL запросов.
В риал-тайм задачах обычно (как и в моих проектах) немного другой workflow:
Сырые данные идут в хранилище как есть
Сырые данные «процессятся» в разных видах — аггрегации, скоринги, анализ на аномалии и т.д.
Результаты процессига вываливаются в витрины для разных приложений (DWH, no-SQL BD, in-memory BD, you name it
Сырые данные тоже доступны для запросов по требованию
Разделение хранения и процессинга — принципиальная вещь для таких архитектур (давайте я применю слово Big Data тут). Если у вас плавающая нагрузка (типичный сценарий, когда вы получаете от пары десятков до нескольких сотен миллионов сообщений в сутки от IoT устройств) и вам надо эти данные сохранять и обрабатывать прежде, чем давать данные в витрины, то все это крутить на одном кластере очень неудобно и накладно. В клауде вы по сути скалируете именно ресурсы для обработки не заботясь о компонентах хранения (они «безграничные»). Больше/меньше данных (или например сложность вычислений динамическая), то и больше/меньше ресурсов надо.
У нас с вами задачи немного разного масштаба, отсюда и непонятнки.
про тапок не понял, у меня в проекте клоудера, в том числе и спарк имеется. все вполне управляемо, правда пришлось самим писать оркестровку поверх спринга.
я имел ввиду, что если вы на одном собсвенном hadoop кластере и данные держите и процессинг выполняете, то скалировать вверх-вниз очень неудобно. Именно вниз.
aws athena это престо, который заметно даже spark уступает
cdn2.hubspot.net/hubfs/488249/Asset%20PDFs/Benchmark_BI-on-Hadoop_Performance_Q4_2016.pdf
Слушайте, ну вы посмотрите, во-первых там Presto лучше в параллельных запросах, во-вторых сравнивать абстрактный кластер Presto и вариант от AWS (возможно неплохо тюнингованный) тоже надо осторожно, а в-третьих — весь вывод вашего документа заключается в абзаце где сказано: хотите нивысшую производительность — под разные паттерны запросов поднимайте разные стеки и абстрагируйте запросы на отдельном уровне.
про лямбду слышал, собственно на нее и намекал. kinesis, aws emr конечно класно, но как видим если строить что-то современное с возможностями реалтайма, то мы вынуждены лепить именно «как у меня в DC было».
Я вам гарантирую (сам проходил все это) — поднимите себе Hortonworks Spark кластер в задаче с плавающей нагрузкой (100-1000%) и попробуйте поуправлять этим. Съедите свой тапочек рано или поздно, либо просто накидаете железа с запасом.
aws emr это цена… тот же разрыв со своей железкой в 5 раз, что и accenture для google dataproc насчитала. железячка 1x16 ядер тредриппера...
Все зависит от размера бизнеса и важности требований. Малый-средний бизнес — деньги важнее (хотя тоже не всегда). Средний-крупный — стабильность, независимость от шаманских знаний настройки кластера админа Пети, защита от катастроф и т.д.
персональные данные, gdpr, согласие клиентов передавать данные третьим лицам.
Персональные данные и GDPR тут вообще не при чем.
Согласие клиентов передавать данные третьим лицам — тут во первых ненадо мухи и котлеты вместе собирать. Если вы хоститесь у кого-то (т.е. третьи лица оказывают вам услуги для того, чтобы вы могли оказать обещанные услуги вашим клиентам) это не равнозначно тому, как если вы все личные данные продали другой компании. Возможность хостинга в облаке сегодня это вещь, которая должна присутствовать в договорах по умолчанию (даже если сейчас вы не используете эту возможность).
Клауд, да и любые сервисы внешние (например какой-нить сервис хитрой аналитики, чтобы построить который вам нужно будет 10 data scientists и 5 лет работы) — это все третьи лица. Вы что, отказываетесь от таких возможностей по-умолчанию?
PS: я соглашусь с вами, что до определенного момента на определенных задачах, при определенных условиях иметь свой кластер выгоднее по деньгам.
по кластерам редшифт не понятно, что значит убивать? а данные куда? если на S3 устроить datalake, а в redshift держать витрины для BI, убивать не получиться и снова возвращаемся к цене.
Да я ж написал, вам в большинстве случаев Redshift и ненужен — вы сырые данные трансформируете в витрины (например с помощью Glue) и держите в том же S3, запрашивая данные по SQL через Athena. Redshift вам нужен только при специфических требованиях по производительности. А убивать — значит, что если Redshift-витрина вам не нужна больше, то можно грохнуть (данные-то в S3) и потом создать при необходимости опять в пару кликов.
в то время как современная аналитика движется к риалтайм, сейчас модно доставлять в dwh горячие данные через какую-нибудь kafka. сколько будет стоить spark streaming job? подозреваю мого дороже.
Ооо. Это моя любимая тема. Вы слышали о лябда-архитектурах? Так вот, на AWS они реализуются очень элегантно: входящие данные (например вы получаете их как поток через Kinesis) разделяются на 2 потока (причем это деляется очень легко):
Один поток (обычно — все данные) идет на S3 в надежное хранилище и далее в поток «none real time» процессинга — например куча всяких аггрегаций и т.д. Ну и вообще тут применимо все то, что мы описали выше для Batch
Второй поток идет уже в тот же Spark кластер (а иногда и этого ненадо — данные важные для realtime часто намного меньше основной массы). А вот тут опять — я бы никому не посоветовал бы сегодня поднимать свой кластер, а вместо этого взял бы AWS EMR (если нагрузка более менее постоянная во времени) или подключил бы сервис Qubole (это подороже, но если надо чтобы кластер динамически масштабировался вверх и вниз — отличное решение. там еще экономия на использовании spot instances).
PS: я понимаю, что чисто по operational costs есть ситуации когда все на своем железе дешевле (с учетом мизерных з/п). Но вы не забывайте что у ентерпрайза не только деньги, но еще и другие требования к решениям (например availability, resilience, etc.) Разместите-ка свой on-premise Hadoop кластер и прочие компоненты в 3х регионах… И посчитаем. Вдруг окажется что клауд дешевле и надежней. Да даже в одном регионе, если уметь готовить клауд, а не лепить «как у меня в DC было», то все очень хорошо можно сделать.
про редшифт почти ничего не знаю, но пошел в их калькулятор, ткнул 3 ноды ds2.8xlarge/16Tb (т.е. hdd и примерно столько же ядер, как у у меня в спарке было). ценник $20,000 в месяц.
Это самая распространенная ошибка взять конфигурацию on-premise и попытаться повторить ее на облачных сервисах и потом удивиться ценнику. Фишка облачных сервисов в возможности использования их on demand.
В конкретно этом случае, я бы действовал так:
Данные поступают в S3 в виде orc / csv
Если их надо трансформировать (аггрегации, etc) — запускаете регулярно Glue jobs и результат сохраняете в S3 опять. Платите только за время работы Glue (там Spark jobs).
Теперь вы можете сразу же запрашивать данные по SQL напрямую использую Athena по цене "$5 per TB of data scanned" — уже неплохо, да? Нет запросов — нет затрат. А еще, если вы их сожмете в gzip, то цена уменьшится пропорционально степени сжатия.
Если вам нужны очень специфические модели данных, возможно, с очень специальными требованиями к производительности — тогда вы можете уже выплевывать данные в один или несколько Reshift инстансов/кластеров, убивать их при необходимости и т.д.
Помимо всяких hadoop решений не забывайте, что задачи DWH сегодня элегантно решаются и облачными сервисами типа AWS Redshift. Вообще, я считаю, что мы уже в post hadoop эре (в плане хранения данных). Намного интереснее хранить данные на чем-то вроде S3, трансформировать их при помощи spark и выплевывать опять-таки либо в S3 или в любое количество нужных DWH на Redshift. При этом данные могут читаться по SQL и напрямую с S3 (Athena, Spektrum). И никакой головной боли с администрирлванием собственных hadoop кластеров. Про лицензии Оракл/SAP я вообще молчу…
Ну да, если предположение о том, что причина именно в промышленном применении пестицидов — верно (а это скорее всего так и есть), то первыми странами, которые смогут переломить ситуацию будут те, кто начнут массово внедрять ГМО с учетом «жружелюбности» к насекомым. А страны-ретрограды останутся на обочине.
Как-то появилось ощущение, что при достаточно большом количестве белковых участников в такой сетке, модель из «сделать усредненное предсказание на базе лучших оценок» выподится в «сделать предсказание на базе оценки общего поведения белкового социума». Ведь «плохих» оценщиков в любой массе всегда больше и благодаря своему количеству и, соответствующему поведению, они тоже являются частью условий задачи. Грубо говоря, если в такую сеть подключить каждого (ну или репрезентативное число), то можно не оценивать мнения, а просто моделировать реальность.
Бэд-трипы обычно от чего-то сильно психоделичного типа ЛСД при высокой дозировке. Т.е. совсем необязательно использовать дозировки типичные для рекреационного использования. Вещества же типа МДМА вообще вызывают чаще всего стойкое чувство эйфории. Т.е. правильный подбор веществ и дозировок может свести риски к минимуму. Нужен научный подход, а с учеными в этой области пока трудно из-за законодательства.
Интересно было бы узнать, проводили ли исследования по воздействию психоделиков (ЛСД, МДМА и т.д.) на таких пациентов. Такие вещества напрямую оказывают влияние на сознание через баланс нейромедиаторов, что очень явно прослеживается на примере больных с психическими расстройствами.
Аккурат 4 года назад игрался с Wowee One. Чуть попроще, но работает по идентичному принципу. Wowee One работает в моно режиме, поэтому у меня была идея купить второй и через переходник раскидать каналы, ну и потом на 2 окна приклеить.
Руки не дошли, да и качество звука такое, что мотивации не хватило.
Инициатором ввода такой системы в работу стал Юрий Андропов.
После прочтения статьи создается впечатление, что до начала 80х никакой такой массовой прослушки небыло. Что-то мне не очень верится. Особенно, учитывая, что телефонизация в СССР 60х и 70х годов была пониже. Следовательно и просшлушивать было проще (чисто из-за количества аппаратов).
В риал-тайм задачах обычно (как и в моих проектах) немного другой workflow:
Разделение хранения и процессинга — принципиальная вещь для таких архитектур (давайте я применю слово Big Data тут). Если у вас плавающая нагрузка (типичный сценарий, когда вы получаете от пары десятков до нескольких сотен миллионов сообщений в сутки от IoT устройств) и вам надо эти данные сохранять и обрабатывать прежде, чем давать данные в витрины, то все это крутить на одном кластере очень неудобно и накладно. В клауде вы по сути скалируете именно ресурсы для обработки не заботясь о компонентах хранения (они «безграничные»). Больше/меньше данных (или например сложность вычислений динамическая), то и больше/меньше ресурсов надо.
У нас с вами задачи немного разного масштаба, отсюда и непонятнки.
я имел ввиду, что если вы на одном собсвенном hadoop кластере и данные держите и процессинг выполняете, то скалировать вверх-вниз очень неудобно. Именно вниз.
Слушайте, ну вы посмотрите, во-первых там Presto лучше в параллельных запросах, во-вторых сравнивать абстрактный кластер Presto и вариант от AWS (возможно неплохо тюнингованный) тоже надо осторожно, а в-третьих — весь вывод вашего документа заключается в абзаце где сказано: хотите нивысшую производительность — под разные паттерны запросов поднимайте разные стеки и абстрагируйте запросы на отдельном уровне.
Я вам гарантирую (сам проходил все это) — поднимите себе Hortonworks Spark кластер в задаче с плавающей нагрузкой (100-1000%) и попробуйте поуправлять этим. Съедите свой тапочек рано или поздно, либо просто накидаете железа с запасом.
Все зависит от размера бизнеса и важности требований. Малый-средний бизнес — деньги важнее (хотя тоже не всегда). Средний-крупный — стабильность, независимость от шаманских знаний настройки кластера админа Пети, защита от катастроф и т.д.
Персональные данные и GDPR тут вообще не при чем.
Согласие клиентов передавать данные третьим лицам — тут во первых ненадо мухи и котлеты вместе собирать. Если вы хоститесь у кого-то (т.е. третьи лица оказывают вам услуги для того, чтобы вы могли оказать обещанные услуги вашим клиентам) это не равнозначно тому, как если вы все личные данные продали другой компании. Возможность хостинга в облаке сегодня это вещь, которая должна присутствовать в договорах по умолчанию (даже если сейчас вы не используете эту возможность).
Клауд, да и любые сервисы внешние (например какой-нить сервис хитрой аналитики, чтобы построить который вам нужно будет 10 data scientists и 5 лет работы) — это все третьи лица. Вы что, отказываетесь от таких возможностей по-умолчанию?
PS: я соглашусь с вами, что до определенного момента на определенных задачах, при определенных условиях иметь свой кластер выгоднее по деньгам.
Да я ж написал, вам в большинстве случаев Redshift и ненужен — вы сырые данные трансформируете в витрины (например с помощью Glue) и держите в том же S3, запрашивая данные по SQL через Athena. Redshift вам нужен только при специфических требованиях по производительности. А убивать — значит, что если Redshift-витрина вам не нужна больше, то можно грохнуть (данные-то в S3) и потом создать при необходимости опять в пару кликов.
Ооо. Это моя любимая тема. Вы слышали о лябда-архитектурах? Так вот, на AWS они реализуются очень элегантно: входящие данные (например вы получаете их как поток через Kinesis) разделяются на 2 потока (причем это деляется очень легко):
PS: я понимаю, что чисто по operational costs есть ситуации когда все на своем железе дешевле (с учетом мизерных з/п). Но вы не забывайте что у ентерпрайза не только деньги, но еще и другие требования к решениям (например availability, resilience, etc.) Разместите-ка свой on-premise Hadoop кластер и прочие компоненты в 3х регионах… И посчитаем. Вдруг окажется что клауд дешевле и надежней. Да даже в одном регионе, если уметь готовить клауд, а не лепить «как у меня в DC было», то все очень хорошо можно сделать.
Это самая распространенная ошибка взять конфигурацию on-premise и попытаться повторить ее на облачных сервисах и потом удивиться ценнику. Фишка облачных сервисов в возможности использования их on demand.
В конкретно этом случае, я бы действовал так:
Как-то так.
Как заявила в ходе заседания сегодня представитель Роскомнадзора, Telegram представляет угрозу интересам РФ и жизням граждан.
=======
Ах какая ядреная (или ядерная?) формулировка. Интересно было бы услышать от представителя развитие этой мысли в части «интересов РФ».
Аккурат 4 года назад игрался с Wowee One. Чуть попроще, но работает по идентичному принципу. Wowee One работает в моно режиме, поэтому у меня была идея купить второй и через переходник раскидать каналы, ну и потом на 2 окна приклеить.
Руки не дошли, да и качество звука такое, что мотивации не хватило.
Автору: а можно в таких статьях давать краткое определение специализированным терминам? Конкретно: что такое бафтинг?
После прочтения статьи создается впечатление, что до начала 80х никакой такой массовой прослушки небыло. Что-то мне не очень верится. Особенно, учитывая, что телефонизация в СССР 60х и 70х годов была пониже. Следовательно и просшлушивать было проще (чисто из-за количества аппаратов).