Ivan DurakЗапросы удобно вертеть на х#ю. Он же hue

А действительно, почему hue не включили в список?

Yo.!дело не в строках, дело в цене ошибки. мы не картошку или твиты считаем и пришли к тому, что проще всего полноценно оттестировать - написать sql. задачи разные бывают
Если цена ошибки ДЕЙСТВИТЕЛЬНО велика и Вы работаете со структурированными данными, использовать стек Hadoop для чего-то сложнее простой агрегации ...может быть опрометчиво.
Впрочем, это в России такие решения не инженеры принимают и даже не менеджеры среднего звена. Было в советском лексиконе такое прикольное слово "волюнатаризм"...Хрущева уже давно нет, но дело его живет (это когда после визита первого лица в США в СССР решили кукурузу сеять вблизи Полярного Круга (условно), впечатлившись тем, насколько это полезный продукт)

dbms_photoshopМы используем хадуп как полностью реляционное хранилище, хотя он не для этого изначально задумывался.
[/quot]
Если данных меньше пары сотен терабайт - это извращение. Если меньше пары петабайт - не факт, что оправдано экономически в крупной компании. С учетом ВСЕХ издержек и возможностей использования этих данных для внедрения сложной аналитики в операционный контур бизнеса (банально, там есть такая вещь как SLA, а хадупопепелацы даже после обработки напильником не сказать, что очень стабильны или отличаются высокой транзакционностью и т.д.)
А если данных СТРУКТУРИРОВАННЫХ сотни терабайт или петабайты, а организация небольшая, то не очень понятно, откуда это обилие данных у этой конторы
ФНС в Hadoop сырые данные хранит (детальные данные бухгалтерских книг), но у них задач с этими данными что-то хитрое делать в этом Hadoop не стоИт (да и вообще пока не стоит - некому ни ставить такие задачи, ни делать).
Да и после очистки они все в Oracle загоняют обычно.
В двух госбанках делают то, что Вы описали (испрользование Hadoop как платформы для DWH), но дальше "смотрите, как мы умеем", прогресс там не пошел, как не прижились там в свое время MPP системы в качестве DWH. Но проблемы там не Хадупе или Терадате ИМХО
Сейчас, впрочем, в одном из госбанков решили двигаться в сторону связки Hadoop и Oracle, посмотрю, чем закончится. Учитывая последние достижения Oracle, выглядит по крайней мере здраво для некоторых задач. И не очень дорого, если уже есть годовой абонемент от Oracle (у крупных банков он обычно есть)

Что до прочего, равняться на ту контору, которую мы все знаем, и которая выпилила "свой inhouse cluster с нуля и они пишут логику используя свой конструктор. У них свой аналог yarn, свой аналог spark, свой аналог HDFS etc" не стоит, если Вы не другая ИТ компания мирового уровня.

Yo.!это распространенное заблуждение. дело не в размерах терабайтов, все дело в деньгах. основная причина отказа от оракла - бабло

Все, о чем я говорю - про бабло. При объемах порядка сотен терабайт и меньше можно спокойно прожить без MPP и строить решение на midrange железе, например, при необходимости используя In-memory. Для крупной организации там ценник достаточно небольшой, чтобы заморачиваться по этому поводу. Да и TCO не только из стоимости лицензий складывается, не стоит про это забывать.
При больших объемах данных (порядка петабайтов) вполне можно жить на MPP и более дорогом железе, но при объемах выше нескольких петабайт ценник на все это становится таким диким, что действительно приходится искать альтернативу.


Yo.!в европе дохрена банков размером со всю банковскую систему России живут счастливо с хадупом. и тоже не потому, что в оракл не вмещались, а потому, что оно работает за меньшие деньги


В Европе меньше 20 банков, которые по размеру активов превосходят крупнейший российский банк. И около дюжины, которые по размеру активов превосходят активы топ-10 РФ, но хадуп там далеко не везде есть. Банки типа HSBC даже в Европе стоят особняком.

Плюс как там идет в реале мне сказать сложно, но в банках на WS переход на связки типа Hadoop+R (и велосипеды на Java) идет не настолько гладко, как коллегам бы хотелось и люди все больше смотрят в сторону чего-то типа Hadoop+H2O и присматриваются к другим технологиям, которые бы позволили лопатить имеющиеся у них данные.
От себя замечу, что в США часто стимулом становится не только стоимость лицензий для ХРАНЕНИЯ данных, но и стоимость лицензий для анализа данных и внедрения аналитики. Потому что на данных там реально делают бизнес, но SAS или S+ стоят конских денег, особенно отраслевые solution на их основе (где стоимость лицензии вендоры любят привязывать к прибыли/капитализации), да и специалисты, которые с этими продуктами работают недешевые. А R на Западе по всех университетах преподают, где статистика в каком-то виде есть, и стоят такие спецы НАМНОГО дешевле. Так что у всей этой движухи больше измерений

Работник языкомпарень, да за версту видно, что ты ни разу не программист
Хм..спасибо кэп.

БумбарашВам надо в работе дальше за Россию тереть. Лучше получается.
Вы много примеров видели в России за пределами интернет-компаний (от поисковиков до DMP-платформ), когда системы на основе Hadoop РЕАЛЬНО генерируют бизнес-value в сколь-либо заметном масштабе? А не выступают в роли игрушки или, в лучшем случае, вспомогательного инструмента?
Тема зацепила тем, что аргументы Yo.! мне сильно напомнило, что я слышу от людей из родного ИТ.
Подход dbms_photoshop куда более взвешенный. Но проблема в том, что есть 4 разных категории пользователей, без которых зарабатывание денег не взлетит. С сильно разными навыками и задачами:
1. Служба качества данных
2. Аналитики отчетности (во многих организациях 1 и 2 группы часто не разделяются)
3. Специалисты по разработке моделей (DS, если угодно)
4. Инженеры данных
А дальше начинаются тонкости, из-за которых выработать единый подход в принципе не получится.
Частный пример. На разработку модели отводится редко больше 5 рабочих дней чистого времени. В рамках этой активности DS генерирует несколько сотен фичей (по сути каждая фича это отдельная гипотеза, но не суть). Прикол в том, что за это время даже человек, который умеет бодро писать MapReduce, не успеет их закодить банально из-за трудоемкости процесса.
Привет Hive (или Pig, или что есть). Но тут начинается вторая проблема. Все эти движки собственно SQL поддерживают довольно ограниченно (аналитические функции, например, обычно недоступны, да и в join какие-то виды сравнений могут не поддерживаться) и некоторые вещи тупо на этих движках сделать нельзя от слова совсем, приходится или шаманить с расширенными возможностями (некоторые из которых dbms_photoshop демонстрирует, но которыми далеко не все владеют), или писать те самые MapReduce, подряжая иногда для этого инженеров данных.
Впрочем, это тоже не самая большая проблема. Грубо говоря, какая черт разница, насколько крут Spark SQL, если в MlLib нет нужного метода и ты модель не можешь сделать нормально? А если тебе данные один черт тащить на локальный нод для разработки модели, то зачем тогда вообще извращаться с работой в кластере, если фичи можно будет на той же локальной ноде Pandas сделать? В итоге все использование этих SQL-движков при разработке моделей нередко сводится к семплированию и агрегации данных, перед тем, как ты их на локальную ноду потащишь. Да, потом тебе качество этой модели надо на всех данных проверить доступных, и там иногда приходится фичи делать через написание MapReduce, но если у тебя в процессе разработки модели могут быть сотни фичей, то в самой модели их будут десятки, а того, что нельзя сделать через SQL-движки может быть всего полдюжины, и это уже вполне посильная задача.
Опять-таки, инструменты для работы с движками. Все четко представляют разницу в уровне компетенции среднего специалиста по очистке данных и инженера данных? И разницу в задачах, которые они решают? Инженера данных можно(и нужно) привлекать к тестированию на этапе приемки, но припахать к ежедневной монотонной выверке данных их нереально - при обилии такой "интеллектуальной работы" они сбегут, даже если это щедро оплачивать (а там далеко не все можно автоматизировать). С другой стороны, специалистам по подготовке отчетов редко требуются какие-то опции, которые недоступны через hue, на кой им shell+putty?

Ivan Durakмигель1Т.е. что такое хадуп вроде разобрались. теперь надо понять где его можно и нужно применять )
хорошо подходит для хранения бесполезных данных.

1. Хорошо подходит для хранения логов и телеметрии. Данных там очень много. Мы в пилотах пока работаем с логами, где объемы сырых данных порядка десятка терабайт за месяц (от одной системы), но если снимать эти данные раз в несколько секунд, а не минуту, брать расширенный набор данных или брать еще и телеметрию, то там отдельные системы и сейчас по паре петабайт за год генерируют, а может быть и больше десятка.
Год это хранить и не нужно имхо, но все равно очень приличные объемы получаются. Поэтому одна из задач - определение того, с какой глубиной эти данные реально нужны, как эти данные "схлопывать", какие именно данные и с какой частотой надо собирать, чтобы value было больше, чем затраты на сбор, хранение и анализ
Зачем: задачи повышения надежности ЦОД, оперативное выявление сбоев в процессинге или работе банкоматной сети.
В перспективе - повышение эффективности автострахования (мониторинг работы агрегатов автомобиля для снижения стоимости ремонта, анализ манеры вождения для справедливого установления цены автостраховки, детектирование ДТП и т.д.)
Задачи интернета вещей короче. И вот тут реально без хадупообразия не обойтись.

2. Хранение сырых данных по транзакциям. Объемы сырых данных сравнительно небольшие, порядка сотен терабайт в год, если вообще все брать (включая цифровой профиль устройства, с которого осуществляется транзакция) и по всем каналам (CP, CNP) и не имеют тенденции к сильному росту (и так уже полстраны через нас идет), но в Oracle без MPP даже на hi-end железе (которое у нас есть и стоит как чугунный мост) такое ворочать сейчас не очень... комфортно (и просто дорого). После "схлопывания" данных (реально то все на агрегатах считается), в Oracle эти данные крутить удобнее (или как минимум - привычнее) и стабильнее (что для прома куда важнее), но сырец тоже надо где-то держать.
Я сейчас ратую за то, чтобы нам дали к Oracle свой Hadoop прикрутить, т.к. по предварительным оценкам работать все будет более-менее: раз в неделю (а чаще для большинства задач нафиг надо) пересчитываем агрегаты, дальше в Oracle и все как обычно (и где все давно работает как часы).
Плюс есть надежды, что после перехода на 12 версию и использования In Memory cамые нужные вещи в Oracle вообще летать будут.
Год напильником поработаем, можно будет и раз в день в Hadoop все пересчитывать. А там год-другой и видно будет, может, и без Oracle можно будет прожить (или без Hadoop, если мощности железа будут расти, а цена падать - война маневр подскажет, зачем заранее загадывать)
А вот текущая идея СРАЗУ все делать в Hadoop+GridGain, причем считать все чуть ли не онлайн, мне ОЧЕНЬ не нравится. Причем по многим причинам. Включая ту, что люди, которые сейчас официальным Hadoop занимаются, никогда в пром не выводили системы с жесткими SLA и высокой ценой сбоев. И то, что в GridGain модели на обсчет пока вообще никто в мире не ставил.
Ну просто опции такой нет. А бравурные заявления, что де мы, да сами, да одним броском парашютно-десантной дивизии...Я уже насмотрелся, как одним броском BPM Pega внедряли. Четвертый год идет, бизнес на Excel просится.
Есть простое правило: моделирование -> макеты -> стендовые испытания -> прототип -> заводские испытания -> опытная партия -> независимая приемка на государственных испытаниях -> мелкая серия + конструкторское сопровождение -> обкатка и выявление детских болезней -> подготовка к крупносерийному производству +обучение персонала-> тиражирование -> массовое производство. ИТ, не ИТ, самолеты, пепелацы - один шайтан разница. Жизненный цикл производства - он и в Африке жизненный цикл
И пропуск хотя бы одного этапа не проактивность-креативность, а саботаж

Зачем: поведенческие скоринговые модели на транзакционных данных для оценки кредитного риска, некоторые задачи событийного маркетинга, не требующие жесткого онлайн (а это почти все крупные покупки и все покупки, где клиент демонстрирует силу привычки, которая вторая натура), разработка персонализированных финансовых сервисов и анализ потребностей клиентов, model-based AML, пилотирование антифрод в процессинге (разработка моделей на ретроспективных данных для оценки эффективности). Последние две опции - если смежникам захочется. Сделать за других мы что-то можем, но вот ХОТЕТЬ за других мы еще как-то не научились.

3. Хранение аудиофайлов и оцифированных в текст записей. Почему: Oracle под такое не заточен.
Зачем: анализ и маршрутизация жалоб клиентов, повышение эффективности удержания розничных клиентов, оценка успешности новых продуктов.
P.S. вероятность, что сие взлетит и даст какой-то value, низкая. Если ответственные пОциенты не хотят (работать руками, идти на компромиссы, напрягаться), наука бессильна. Как говорил классик, основная привилегия монополиста - право не напрягаться. Классик был прав.

4. Хранение данных о том, кто как мышкой водит и куда пальцем в экран смартофона тыкает. Почему: Oracle под это не заточен
Зачем: при правильном использовании позволяет улучшить UX и повысить конверсию, чтобы это не значило. При ставке на цифровые каналы, задача далеко не последней степени важности.