72,53
рейтинг
9 апреля 2014 в 09:25

Разработка → Мифы и легенды про Big Data


Один из наших кластеров для пилотных задач (Data node: 18 servers /2 CPUs, 12 Cores, 64GB RAM/, 12 Disks, 3 TB, SATA — HP DL380g)

— Что такое Big Data вообще?
Все знают, что это обработка огромных массивов данных. Но, например, работа с Oracle-базой на 20 Гигабайт или 4 Петабайта — это ещё не Big Data, это просто highload-БД.

— Так в чём ключевое отличие Big Data от «обычных» highload-систем?
В возможности строить гибкие запросы. Реляционная база данных, в силу своей архитектуры, предназначена для коротких быстрых запросов, идущих однотипным потоком. Если вы вдруг решите выйти за пределы таких запросов и собрать новый сложный, то базу придётся переписывать – или же она умрёт под нагрузкой.

— Откуда берётся эта новая нагрузка?
Если чуть углубиться в архитектуру, то можно увидеть, что традиционные базы данных хранят информацию очень дисперсионно. Например, у нас номер абонента может быть на одном сервере в одной таблице, а его баланс — в другой таблице. Быстродействие требует максимального разбиения данных. Как только мы начинаем делать сложные join'ы, производительность резко падает.

— Есть пример такой задачи?
Вот пример: нам стало интересно, когда люди переходят на современные смарфтоны с «кирпичей»-звонилок. Оказалось, что есть достаточно чёткий порог: для жителя Москвы, например, сочетание старого телефона 2007-го года и использования ряда сервисов вкупе с большим потреблением трафика может означать желание перейти на смартфон. Соответственно, увидев такую границу, мы посмотрели, на какие именно модели переходят люди. И пошли дальше – решили находить тех, кто готов прямо сегодня приобрести такой телефон. А дальше – вопрос техники. У нас есть около 250 офисов продаж в Москве. Мы выделяем группу тех, кто в течение недели решит перейти на смартфон по нашим данным. Мониторим, когда один из них подойдёт на 50 метров к нашему салону. А затем отправляем ему SMS с рекомендацией про «зайти посмотреть», если в данном салоне есть смартфон и если он готов к демонстрации. Традиционную систему такая задача просто взорвёт.

— И как это решается?
Нужна другая архитектура базы данных. Если вам нужны гибкие запросы, то проще всего хранить данные неструктурированно — потому что для каждого нового запроса придётся иначе строить новую оптимальную структуру. Обычные базы данных направлены на максимальное быстродействие в рамках ограниченных вычислительных ресурсов.

— Так давайте просто промасштабируем их — и проблема решится?
В целом, если есть куда масштабироваться — да, это выход. Согласитесь, проще докупить пару серверов или СХД, чем переписывать всю структуру БД. Однако в случае именно больших данных это не очень просто. Реляционные базы данных маштабируются достаточно сложно, как правило, до бутылочного горлышка в единой СХД. Есть горизонтальный порог масштабирования, после которого становится проще писать новую структуру, чем вводить очень сложные аппаратные комплексы.

— Так что получается в итоге?
В итоге у вас есть некий набор сырых данных, который прекрасно поддаётся анализу. По нему бегают роботы на Java-коде. Они прекрасно параллелятся, поскольку нет никаких специфических требований к архитектуре по железу. Если нужно добавить вычислительных мощностей — мы просто отдаём чуть больше ресурсов виртуальной среды или довозим и втыкаем железо. На боевой реляционной БД так не сделать.

— Но ведь это чудовищно медленно, разве не так?
Не всегда. Есть две ситуации, когда имеет смысл сравнивать:
  1. Короткие запросы с малым количеством join’ов. Здесь архитектура базы данных часто даёт выигрыш по времени, но мы платим за это резким увеличением нагрузки при запросах, которые не являются оптимальными для выбранной архитектуры.
  2. Сложные запросы разового типа. Иногда бывает проще составить запрос для реляционной базы за 10 минут и подождать два часа решения, чем писать Java-робота для Big Data 4 часа и ждать ответ 5 минут. Зависит от задач.

Поэтому, как правило, Big Data используется для задач, которые повторяются не очень часто и достаточно неординарны. Если мы вдруг решим сделать что-то из задач Big Data постоянным, и это будет возможно решить реляционной базой, то мы просто «захардкодим» это в обычную базу с фиксированной архитектурой.

— Какие есть известные примеры использования Big Data?
Рано или поздно практически все, кто работает с большими данными, приходят к примерно похожему подходу: структурированные и хорошо разбитые базы с грамотной архитектурой для быстрых запросов, неструктурированные сырые данные для сложных разовых. На Хабре было упоминание про подход Twitter к архитектуре — там используется нечто похожее.

— А почему тогда все на конференциях говорят про Big Data?
Потому что тренд модный, слово любят журналисты. Даже если вы обработаете 50 тысяч записей интернет-магазина и назовёте это Big Data — это будет достаточно пафосно, чтобы написать в пресс-релизе.

— Получается, что одна из целей Big Data — возможность уйти от долгих проектных циклов?
Да, и от массы костылей к традиционным БД. Java-методология давно известна, но в аналитике её стали применять сравнительно недавно. При решении каких-то аналитических задач традиционными методами, заранее не получается сказать, что будет работать не так. Иногда требуется несколько месяцев для анализа какой-то возникшей неприятной ситуации с использованием реляционной базы данных. Подход Big Data совсем иной, поскольку данные собираются в реальном времени, хранятся без обработки, а обрабатываются тогда и так, как это требуется исходя из текущих задач, которые могут постоянно меняться.

— Есть примеры уже решенных задач, где это было видно?
Да. Партнёры в Европе смотрели за устройствами в зоне покрытия LTE, но без подключённого по факту LTE. К примеру — владелец iPhone со старой SIM, владелец одного из китайских телефонов без знания того, что есть вообще такая вещь как LTE. У партнеров программа заняла 6 месяцев. У нас этот проект тоже был реализован в рамках пилота на нашей платформе за 3 недели. В нашей реализации удалось обнаружить немало людей с устройствами с поддержкой LTE, которые этим функционалом не пользуются, возможно, даже не знают о нем. Или вот ещё пример. В ВымпелКоме есть подразделение, которое занимается анализом устройств, используемых абонентами. Это делается из соображений оптимизации оказания услуг. Например, если число аппаратов одной модели начинает быть больше 500, мы начинаем поддерживать такие устройства, в частности, запрашиваем информацию у производителя, чтобы уметь ответить на возможные вопросы клиента. Наш инструментарий позволяет очень быстро строить подобные разовые отчёты по использованию устройств в нашей сети.

— Какова структура платформы?
  1. Источники данных. Мы сводим все данные в одно место, даже не думая о том, понадобятся они или нет — просто собираем сырой массив. Например, это события (вызовы, обрывы и т.п.), геолокационные, данные CRM, данные биллинга, данные о пополнении счета и так далее.
  2. Есть фабрика идей — это коммерческие идеи, которые могут быть реализованы, если на них выделить время разработчиков и вычислительные мощности.
  3. Есть зона пилотных проектов — это демо-версии, которые реализуются на малой выборке абонентов. И есть продуктив (про него ниже).
  4. Платформа. В систему работы с Big Data в ВымпелКоме интегрировано уже значительное число так называемых «узлов», машин, занимающихся сбором и анализом данных почти в реальном времени. Будем и далее наращивать эту сеть. Например, у компании Verizon уже около пятисот узлов задействовано в аналогичной системе. Платформа у нас разделена на кластер для пилотов (песочницу) и кластер для продуктивов. Принципиально они почти ничем не отличаются, кроме мощности и поддержки. Кластер для продуктивов более мощный, здесь уже не место для экспериментов, это «мельница» для концентрации и обработки данных. А в песочнице отрабатываются новые идеи, причем к ней подключены все источники данных, как и к кластеру для продуктивов.


— Есть примеры прогностических задач такого плана?
Да, нам очень интересно знать, когда человек едет в другую страну. Не сообщать ему на месте, что «Добро пожаловать в Казахастан», например, а ещё до начала поездки предлагать тарифные опции и информировать о ценах на месте. Один из проектов — анализ потока клиентов в аэропортах. Нужно отсечь тех, кто возвращается домой (это просто), отсечь персонал аэропорта и таксистов (по данным предыдущих визитов) и выделить тех, кто собирается сесть в самолёт через час-два. Вот пока они ждут самолёт — им и приходит SMS с предложением: иногда общим (где и как посмотреть информацию), в некоторых случаях — по конкретному региону или стране (если терминал работает только в этом направлении).

— Кто этим занимается в «Билайне»?
Вот я этим занимаюсь и мой коллега Виктор Булгаков. Я начинал в Нидерландах в телекоме, где был архитектором реалтайм-биллинга и MNP. Потом HP, KPN, отвечал за внедрение бизнес-аналитики и Data Mining в «Адидасе» — и теперь Билайн. А Виктор работал в «Инкомбанке» с ERP. Потом с 1999 года у нас занимается бизнес-аналитикой (по сути – всю её с нуля и делал) и теперь вот вплотную Big Data.

Думаю, вам может захотеться узнать про то, как мы работаем с данными на низком уровне, либо услышать про железо. Если тема интересна – пишите.
Автор: @SergeyMarin

Комментарии (93)

  • +9
    Очень интересно узнать по больше про архитектуру Вашей системы, хотя бы на концептуальном уровне. Также интересно услышать пару слов про процесс разработки в такого рода проектах.
    Спасибо за статью!
    • +10
      Поддерживаю. Из повествования сложилось впечатление, что автор полностью владеет вопросом… но никому ничего не скажет. Дайте чуть больше чего-то, что можно было бы пощупать и принять на вооружение.
      • +15
        Спасибо. Тогда буду готовить пост про устройство нашей платформы и принципы хранения данных.
        • 0
          А можно уточнить — когда этот пост появится?
  • +2
    Спасибо, очень интересная статья.
  • +2
    Big Data — это то количество данных, которые вы не можете управлять и обрабатывать. Для кого-то это 2MB, а для кого-то 100PB.
    • +1
      Big Data — это то количество данных

      Big Money — это такое количество денег, которыми вы не сможете эффективно распоряжаться, за владение которыми вас убьют, ограбят или посадят. (Можно так сформулировать?)
    • +2
      Зря поставили минус человеку, он конечно не совсем прав (или неверно выразил мысль), но автор статьи тоже довольно странно трактует понятие «big data». Я везде встречал именно дословную трактовку термина — то есть «большие данные». Скорость работы джойнов, возможность выполнения сложных запросов или еще что-то — это скорее особенности конкретного инструмента и\или вашего кластера. Впрочем, подробнее мысль я изложил в комментарии ниже (не люблю повторяться).
  • +5
    Проводили анализ как реагируют пользователи на подобные «внезапные предложения»? Какой процент предложений конвертируется в приобретеннную услугу, а какой процент раздражает рассылка такого спама? Стоит дать пользователям простой способ отписаться от таких предложений прямо внутри СМС, можно по каждой группе функции отдельно, например «Не присылать предложения о покупке телефона» и т.д.
    • 0
      1. Мы делаем выборку таких ситуаций и передаем их целевым подразделениям.
      2. Общий принцип — если будут негативные обращения, отключим функционал.
      3. Насколько я знаю, эти СМС приходят только один раз, поэтому отписываться не надо.
      • +6
        Имеется ввиду «отписаться и не получать НИКАКИЕ рекламные рекомендательные предложения». Или такой опции нет?
        • 0
          В личном кабинете или по звонку в контакт-центр можно отключить все подобные уведомления, конечно.
      • +6
        А вы не думаете что большая часть негативных отзывов остается невысказанными, потому что:
        — сообщение приходит на улице, когда я имел неосторожность проходить МИМО офиса продаж, а значит шел по делам и у меня нет желания звонить и разбираться перекрикивая шум автомобилей
        — я проезжал МИМО офиса продаж, и мало того что непонятный спам я принял за важное СМС и уже один раз отвлекся, я тем более не горю желанием общаться во время вождения с оператором
        — с трудом верится в эфемерную «пользу» подобных обращений: когда оператор засыпая выслушивает у телефона одно и то же в 100 раз, 15 минут объясняет заученными фразами всю «пользу» подобных рассылок, кладет трубку и благополучно забывает о звонке. Поэтому хотелось бы донести столь важную для компании информацию до лиц непосредственно принимающих решение об отключении функционала (не только для меня)
        — ну и конечно «удобство» общения с роботом в контакт-центре когда «ваш звонок очень важен для нас» и поиск скрытой галочки в паутине переходов личного кабинета трудно переоценить
        — в результате многим проще донести «негативное обращение» до близких и знакомых, увеличив «узнаваемость» бренда
        — одноразовые СМС? Конечно всем нужно больше разнобразного спама! Сделайте личный кабинет в виде приложения для смартфонов и добавляйте в специальный раздел персональные предложения, с управлением подпиской и прочим

        А тут вы получаете моментальный feedback, прозрачный коэффициент конверсии и белый список ло… яльных пользователей
        • +4
          Госсподи. До чего же мы все любим воображать себя пупами даже не Замли, а, скорее, Метагалактики, вокруг которых всё вертится.

          Да, после превышения некоего предела (ну скажем SMS каждые 5 минут) все люди озвереют и начнут какую-либо войну с соответствующими провайдерами. И да, определённый процент людей будут истерить даже из-за получаения одной SMS'ки.

          Однако. Люди, которые категорически не хотят ничего получать никакой прибыли операторам не приносят! Современные ОпСоСы всё больше начинают напоминать парки развлечений, которые получают основную прибыль не с продажи билетов (она хорошо если покрывает затраты на ремонт всего железа), а с продажи газировки (и именно поэтому вам чуть не в анус, чтобы изъять пронесённую с собой воду).

          В результате получается что наилучший вариант для ОпСоСа — это сделать так, чтобы эти вечно зудящие и ничерта никогда не покупающие из «премиальных услуг» товарищи свалили бы уже к чёртовой матери к другому ОпСоСу и перестали портить всем нервы. Да, конечно они могут опосредованно отпугнуть и ещё какое-то количество «блондинок» (я здесь про «состояние души», а не про волосы — волосы могут быть и зелёными и филетовыми), но реально это просиходит крайне редко: подобное тянется к подобному, скорее всего круг ваших знакомых и без ваших нотаций слабо на всякие подобные SMS'ки клюёт, так что в любом случае для ОпСоСа интереса не представляет.

          Собственно если (по вполне правильно описанным вами причинам) люди не звонят в службу техподдержки, то это значит, что затронуты пока только люди на которых можно внимания не обращать, так как прибыли от них всё равно не будет. А вот если начали звонить, то это значит, что затронуты уже и другие слои и тут уже нужно подумать над принятием мер.

          Когда вам кажется что «с другой стороны баррикад» сидят полные идиоты всегда стоит остановиться и задуматься: если они все такие кретины, то почему у них миллиардные прибыли? Подумайте немного над этим — и всё поймёте. Честное слово: даже +100 полученные вашим комментарием на Хабре куда меньше повлияют на оператора, чем хотя бы парочка клиентов, которых удастся перевести на более дорогой тариф с большим количеством траффика.
          • –2
            В России вполне можно быть кретином и мудаком, но иметь миллиардные прибыли, так уж повелось. Например, действия описанные выше (слежение за пользователем и отправка рекламного смс при приближении к салону связи) называются «ограничение конкуренции» и являются отличной причиной для разбирательства с антимонопольными органами. Но это в Европе, где «полные идиоты», а в России можно так вести бизнес, смеясь клиентам в лицо: «не нравится — не хавайте!».
          • 0
            Вы неправильно прочитали написанное :)
            Речь как раз про то, что ОпСоС может максимизировать свою прибыль и минимизировать имиджевые убытки если:
            — НЕ будет присылать СМС тем кто НЕ приносит прибыли, дав им возможность отписаться и НЕ давать больше повода рассказывать наивным знакомым какой плохой оператор ХХХ. Не нужно будет тратить на них СМС загружая впустую канал, не нужно будет тратить на них время операторов тех. поддержки объясняя что услуга полезна, не придется в салоне связи отвлекать менеджера на заверения что «вам не будут приходить лишние смс и навязанных услуг тоже не будет»
            — определить круг пользователей которые считают допустимым получение СМС в 3 часа ночи, а заодно отфильтровать тех кто «еще не определился» от тех кто легче всего ведется на любые предложения
            — первую категорию лояльных пользователей «окучивать» аккуратно и нежно, чтобы они не успели сбежать, окружить ежедневной заботой и лаской лишь бы они сделали первую и вторую покупку
            — вторую категорию жестко напрягать предложениями «только сейчас, только для вас, с умопомрачительными скидками!», определить приоритетный канал перевода денег ОпСоСу и предложить платиновую пластиковую карту, открыть любой виртуальный счет, лишь бы он платил и побольше, можно даже втихую загружать бесплатное видео на телефон пользователя и запускать рекламу очередного айФона, да все что угодно, что придет в воспаленный «эффективным маркетингом» мозг
            Я не считаю себя пупом земли, но почему-то когда я прохожу мимо метро я могу взять рекламную листовку, а могу не взять, при этом никто насильно не пихает мне эту листовку в карман. Миллиардные убытки легко объясняются тем что полные идиоты преимущественно сидят по эту сторону баррикад, что как раз и описано в вашем комментарии.
            • +2
              Смотрите, я абонент билайна уже больше 10 лет. Расскажу как у них сейчас, и многих проблем просто нет которые вы описываете.
              — одноразовые СМС? Конечно всем нужно больше разнобразного спама! Сделайте личный кабинет в виде приложения для смартфонов и добавляйте в специальный раздел персональные предложения, с управлением подпиской и прочим

              Никаких смс я не получаю и в кабинете специальные предложения для меня появляются. Но я их не вижу, мне нечего делать в кабинете и я туда не хожу.
              Иногда звонят девочки и говорят, что у вас тут штука есть, давайте подключим и штуки обычно хорошие. Вначале меня это напрягало, всё-таки когда тебе что-то предлагают по телефону, ощущение что впаривают. Но на деле оказывалось выгодно для меня. Например последний раз мне предложили безлимит, хотя у меня было 100 минут за 100 рублей с посекундной тарификацией, я отказался. Но мне объяснили что за 2 недели последние я уже потратил 1500р., только на разговоры(по выписке которую я проверил так и оказалось), а безлимит всего 600р. в месяц. Зачем им это делать? Они же экономят мои деньги. Поэтому теперь я хорошо отношусь к таким звонкам.
              — определить круг пользователей которые считают допустимым получение СМС в 3 часа ночи

              У билайна такой проблемы нет уже лет 5 наверное, все смски любого рекламного характера начинают приходить только после 9 утра. Не знаю как они это делают, но от моих сервисов через api смс шлюзов мне приходят, а вот реклама нет. Да и у них есть возможность это отключить совсем.
              Так что не всё так плохо как вам кажется.
  • +15
    Стоп, стоп.
    Но, например, работа с Oracle-базой на 20 Гигабайт или 4 Петабайта — это ещё не Big Data, это просто highload-БД.

    Big Data — это данные, слишком большие, чтобы их можно было обработать на одной машине в приемлемое время. А highload — это «высокие нагрузки», и суть не в размере данных (хотя это и важно), а в быстродействии и надежности.

    Реляционная база данных, в силу своей архитектуры, предназначена для коротких быстрых запросов, идущих однотипным потоком.
    Да ну? Как раз нормализация и нужна в том числе для того, чтобы можно было строить разные запросы, пусть в ущерб производительности.

    Если чуть углубиться в архитектуру, то можно увидеть, что традиционные базы данных хранят информацию очень дисперсионно. Например, у нас номер абонента может быть на одном сервере в одной таблице, а его баланс — в другой таблице. Быстродействие требует максимального разбиения данных. Как только мы начинаем делать сложные join'ы, производительность резко падает.

    Это вообще ломает мозг.

    Ну и дальше в том же духе, хотя смысл статьи прост, если я правильно понял — «мы сохраняем все сырые данные, а потом используем их для нетривиальных запросов, используя масштабируемые числодробилки».
    • +1
      Упрощая, Big Data — это методы обработки больших объемов данных и значительного многообразия. Чтобы соответствовать критерию «значительного многообразия» нужно иметь запросы совершенно разного характера. На чём вы их делаете — на сырых данных или подготовленной дисперсионной базе — уже не так важно. Но чисто технически удобнее хранить сырые данные в ряде случаев.
      • +2
        Поддержу вас в ответе.

        Чтобы было ещё проще, можно сказать, что BigData в частном случае — это массивы данных с множественными разнородными признаками у экземпляров.
        В одном случае «рост, вес, цвет глаз», в другом случае «модель смартфона, адрес, ученая степень» и т.д. и т.п.

        Для обычной RDBMS придётся делать или супернормализованную структуру, которая ведёт к большому количеству джойнов на выборках, или суперненормализованную разреженную таблицу (из-за этого появляются решения с «нестандартными» вертикальными RDBMS).
        Или что ещё хуже — двоичную базу с метаданными описания данных, помимо стандартного DDL.
        Дальше грабли, костыли, хождение по минному полю при добавлении сущностей…

        В любом случае, если заранее полностью не известен и не определён домен данных, то RDBMS рано или поздно становится странно управляемым монстром.
        Технологии BigData — это методы работы с заранее неизвестными данными, когда часто данные управляют алгоритмами их обработки.
        Сейчас даже новый термин придумали — «переход от database к dataspace».
        Говоря в общем, BigData — это стратегия, при помощи которой пытаются сохранить и использовать данные по максимуму.

        А статья очень неплохая.
        Будет интересно узнать о конкретных решениях, спасибо.
        • +1
          А если в RDBMS есть поддержка денормализованного хранения данных, например, в JSON, то это BigData или нет?
          • 0
            В любой RDBMS есть поддержка денормализованного хранения данных :)

            Доказать? Легко — в поле типа varchar можно запихнуть текстовое описание сложной сущности, например работника («Иванов Иван Иванович, 1972 года рождения, не женат, бухгалтер, ...» и т.д.).
            Тут весь вопрос отвечает ли структура данных реляционной модели.
            А «физический» уровень хранения данных менее важен для отличия RDBMS от неRDBMS.
            Есть и блобы, и XML и т.д. и т.п.

            Тут вам, как разработчику, решать стоит ли игра свеч в причесывании исходных данных в реляционную модель или дешевле обрабатывать их так как есть.
            Нельзя сравнивать или противопоставлять BigData и RDBMS — это термины разных терминологических полей.

            Можно построить решение типа BigData, составной частью которого будет классическая RDBMS, такое часто бывает.
            А можно хранить в приложении RDBMS данные, которые отвечают критериям BigData.

            Раньше это называли Data Warehouse, но тут требуются значительные усилия по ETL, прежде чем данные можно будет использовать.
            А в решениях «true BigData» можно обойтись и без ETL, или ETL получается само собой в процессе извлечения сведений из сырых данных.

            Надеюсь, вопрос понял правильно и ответил в правильном направлении :)
    • +1
      нормализация и нужна в том числе для того, чтобы можно было строить разные запросы, пусть в ущерб производительности

      ошибка, нормализация нужна для повышения производительности.

      Например, поиск по двум табличкам Товары и Производители в большинстве SQL-серверов будет намного быстрее чем в одной таблице где для каждого товара в той же строке стоит производитель.
      • 0
        Когда вы нормализуете данные для одного запроса, второй, сильно отличающийся от него, будет работать медленнее.
        • +1
          Для быстрых составных селектов данные обычно не нормализуются, а денормализуются :)
          Материализованные представления — это ведь про это.
          Вы наверно хотели сказать, что построение специализированной структуры данных, заточенной под конкретный запрос, не позволяет с той же производительностью гонять по ней другие сильно отличающиеся запросы.
        • 0
          Когда вы нормализуете данные для одного запроса,

          Мне кажется, что «нормализуете» здесь не уместно. Скорее, «когда вы ДЕнормализуете данные ради одного запроса ...».
      • 0
        Нет, не ошибка. В первую очередь, нормализация нужна для снижения избыточности и повышения способности системы быть в консистентном состоянии. Последующий сбор из разных таблиц результирующей строки будет снижать производительность.

        Например, поиск по двум табличкам Товары и Производители в большинстве SQL-серверов будет намного быстрее чем в одной таблице где для каждого товара в той же строке стоит производитель.


        Приведите, плиз, запросы для одного и другого случая и схемы таблиц, если есть желание продолжать тред.
        • –1
          снижение избыточности как раз и приведёт к повышению производительности. Даже в таком простом примере как выше (товары->производители против товарыИпроизводители, схема очевидна любому базаданщику).
          • 0
            Я бы посмотрел, как Вы быстро выберете данные из джойна из десяти таблиц по условию на поле последней таблицы в сильно нормализованной БД.

            Даже в Вашем примере, если Вы захотите выбрать товары вместе с производителями, что очень логичное желание, запрос, когда эти данные лежат в одной таблице, будет намного быстрее. Т.к. в этом случае, чтобы получить результирующую строку, серверу надо прочитать близколежащие данные в одной операции чтения, а не брать данные по товару из одного места на диске, а потом брать данные по производителю из совсем другого места на диске.

            Как раз оптимизация таблиц под конкретные часты запросы и предполагает денормализацию.
            • –9
              я ежедневно пишу запросы с джойнами из десятков табличек.
              Например вот такой (даже на андроидном планшете, в SQLite имеющем примитиный оптимизатор, на базе из нескольких сотен тысяч записей выполн\яется за 1-3 секунды):

              String sql = " select n._id "//
              + "\n ,n.[_IDRRef] "//
              + "\n ,n.[Artikul] "//
              + "\n ,n.[Naimenovanie] "//
              + " || ' (склад '"//
              + " || case (select sklad from AdresaPoSkladam_last where nomenklatura=n._idrref " + defaultSklad + " order by sklad limit 1)"//
              + " when " + ISklady.HORECA_sklad_8 + " then 8"//
              + " when " + ISklady.HORECA_sklad_10 + " then 10"//
              + " when " + ISklady.HORECA_sklad_12 + " then 12"//
              + " when " + ISklady.KAZAN_sklad_14 + " then 14"//
              + " else '?' end" //
              + " || ')'"//
              + " as Naimenovanie"//
              + "\n ,n.[OsnovnoyProizvoditel] "//
              + "\n ,p.Naimenovanie as ProizvoditelNaimenovanie "//
              + "\n ,CenyNomenklaturySklada.Cena as Cena "//
              + "\n ,0 as Skidka "//
              + "\n ,0 as CenaSoSkidkoy "//
              + "\n ,x'00' as VidSkidki "//
              + "\n ,eho.[Naimenovanie] as [EdinicyIzmereniyaNaimenovanie] "//
              + "\n ,VelichinaKvantovNomenklatury.Kolichestvo as MinNorma "//
              + "\n ,ei.Koephphicient as [Koephphicient] "//
              + "\n ,ei._IDRRef as [EdinicyIzmereniyaID] "//
              + "\n ,n.Roditel as Roditel "//
              ;
              if (ApplicationHoreca.getInstance().getCurrentAgent().getAgentKod().equals(«hrc00»)) {
              sql = sql + "\n ,0 as MinCena ";
              }
              else {
              sql = sql + "\n ,case when ifnull(nk1.ProcentSkidkiNacenki,nk2.ProcentSkidkiNacenki)>0"//
              + "\n then 0"//
              + "\n else (1.0+ifnull(n1.nacenka,ifnull(n2.nacenka,ifnull(n3.nacenka,ifnull(n4.nacenka,n5.nacenka))))/100.0)*TekuschieCenyOstatkovPartiy.Cena"//
              + "\n end as MinCena "//
              ;
              }
              sql = sql + "\n ,1.1*CenyNomenklaturySklada.Cena as MaxCena "//
              + "\n ,TekuschieCenyOstatkovPartiy.cena as BasePrice "//
              + "\n ,Prodazhi.Stoimost/Prodazhi.kolichestvo as LastPrice "//
              ;
              if (ApplicationHoreca.getInstance().getCurrentAgent().getAgentKod().equals(«hrc00»)) {
              sql = sql + "\n ,0 as Nacenka ";
              }
              else {
              sql = sql + "\n ,ifnull(nk1.ProcentSkidkiNacenki,nk2.ProcentSkidkiNacenki) as Nacenka "//
              ;
              }
              sql = sql + "\n ,ZapretSkidokTov.Individualnye as ZapretSkidokTovIndividualnye "//
              + "\n ,ZapretSkidokTov.Nokopitelnye as ZapretSkidokTovNokopitelnye "//
              + "\n ,ZapretSkidokTov.Partner as ZapretSkidokTovPartner "//
              + "\n ,ZapretSkidokTov.Razovie as ZapretSkidokTovRazovie "//
              + "\n ,ZapretSkidokTov.Nacenki as ZapretSkidokTovNacenki "//
              + "\n ,ZapretSkidokProizv.Individualnye as ZapretSkidokProizvIndividualnye "//
              + "\n ,ZapretSkidokProizv.Nokopitelnye as ZapretSkidokProizvNokopitelnye "//
              + "\n ,ZapretSkidokProizv.Partner as ZapretSkidokProizvPartner "//
              + "\n ,ZapretSkidokProizv.Razovie as ZapretSkidokProizvRazovie "//
              + "\n ,ZapretSkidokProizv.Nacenki as ZapretSkidokProizvNacenki "//
              + "\n ,ifnull(fx1.FixCena,fx2.FixCena) as FiksirovannyeCeny "//
              + "\n ,(select max(ProcentSkidkiNacenki) from SkidkaPartneraKarta"//
              + "\n where PoluchatelSkidki=n.[_IDRRef]"//
              + "\n and date(period)=date(parameters.dataOtgruzki) ) " //
              + "\n as SkidkaPartneraKarta"//
              + "\n ,(select max(ProcentSkidkiNacenki) from NakopitelnyeSkidki"//
              + "\n where PoluchatelSkidki=parameters.kontragent"//
              + "\n and date(period)=date(parameters.dataOtgruzki) ) " //
              + "\n as NakopitelnyeSkidki"//
              + "\n ,Prodazhi.period as LastSell "//
              + "\n ,(select sklad from AdresaPoSkladam_last where nomenklatura=n._idrref and baza="//
              + ISklady.KAZAN_ID + " and Traphik=" + isTraphik + " limit 1) as skladKazan "//
              + "\n ,(select sklad from AdresaPoSkladam_last where nomenklatura=n._idrref and baza=" //
              + ISklady.HORECA_ID + " and Traphik=" + isTraphik + " limit 1) as skladHoreca "//
              + "\n ,eho.ves as vesedizm";
              if (zapretOtgruzokOtvetsvennogo != ZapretOtgruzokOtvetsvennogoNone) {
              sql = sql + "\n ,(select 1 from zapretotgruzokotvetsvennogo where proizvoditel=n._idrref limit 1) as zoo1";
              sql = sql + "\n ,(select 1 from zapretotgruzokotvetsvennogo where proizvoditel=n2._idrref limit 1) as zoo2";
              sql = sql + "\n ,(select 1 from zapretotgruzokotvetsvennogo where proizvoditel=n3._idrref limit 1) as zoo3";
              }
              sql = sql + "\n from Nomenklatura_sorted n "//
              + "\n cross join Consts const "//
              + "\n cross join Price on Price.nomenklatura=n.[_IDRRef] and " + getPriceVladelec(kontragentID)//
              + "\n cross join (select "//
              + "\n '" + dataOtgruzki + "' as dataOtgruzki "//
              + "\n ," + kontragentID + " as kontragent "//
              + "\n ," + polzovatelID + " as polzovatel "//
              + "\n ) parameters "//
              ;
              if (ApplicationHoreca.getInstance().getCurrentAgent().getAgentKod().equals(«hrc00»)) {
              //
              }
              else {
              sql = sql + "\n cross join Polzovateli on Polzovateli._idrref=parameters.polzovatel "//
              + "\n cross join Podrazdeleniya p1 on p1._idrref=Polzovateli.podrazdelenie "//
              ;
              }
              sql = sql + "\n cross join kontragenty on kontragenty._idrref=parameters.kontragent ";
              if (history) {
              sql = sql//
              + "\n cross join Prodazhi_last Prodazhi on Prodazhi.DogovorKontragenta in (select DogovoryKontragentov_strip._IDRref from DogovoryKontragentov_strip where DogovoryKontragentov_strip.vladelec=parameters.kontragent ) "//
              + "\n and Prodazhi.nomenklatura=n.[_IDRRef] "//
              + "\n and Prodazhi.period>=date('" + dataNachala + "') "//
              + "\n and Prodazhi.period
              • +1
                Увеличьте количество записей до сотен миллионов и посмотрите что произойдёт.
                Положить навзничь любую реляционную базу «при помощи» множественных джойнов можно очень легко.
                Именно поэтому основные усилия в оптимизаторах запросов делались в области джойнов, и поэтому есть различные алгоритмы выполнения джойнов (Nested loops, Merge join, Hash join).
                Всё это из-за побочных эффектов «curse of dimensionality».
                Побочных, потому что основные эффекты ещё похуже будут :)
                • –1
                  если я приведу кусок из своего проекта с миллионами то от меня потребуют миллиарды, потом секстилионы. Так не пойдёт.

                  Вышеуказанного примера достаточно.
                  • +5
                    Нет, не потребую :)

                    Когда-то давным-давно, когда из систем для работы с большими данными приличным решением считалась только Oracle Database, была одна очень хорошая книга.
                    К сожалению, сейчас не вспомню ни автора ни точного названия.
                    Он в ней описывал принципы построения сверхбольших data storage для поддержки принятия решений на базе Oracle Database.
                    Писал он не в теории, а на основе своего опыта работы в 7-Eleven (можете оценить объемы данных).
                    Так вот у меня впечаталась его фраза что-то вроде «Вы можете как угодно строить базы, пока у вас сотни тысяч записей, десятки и сотни миллионов, но как только их количество переваливает за триллион, возникают непонятные проблемы, которые очень тяжело решать».

                    Тут дело не в цифрах, а в определенной границе, за которой некоторые решения просто перестают работать.
                    Ну даже такой банальный вопрос как сортировка больших наборов данных сейчас не делается на классических RDBMS.
                    Хотя казалось бы чего проще — засунул в таблицу и сказал select order by.
                    • +4
                      О, нашёл! Всё-таки гугл — великий поисковик :)
                      Oracle DBA Guide to Data Warehousing and Star Schemas
                      By Bert Scalzo

                      2003 год.

                      Посмотрите, как раз на пятой странице есть другая хорошая цитата
                      Remember, size alone does not a data warehouse make

                      Ну и дальше он расшифровывает что имеет в виду.
                      Сейчас в ней можно заменить data warehouse на BigData — смысл почти не поменяется :)
                    • –6
                      хватит ссылок. Хватит миллиардов и террабайтов.

                      Код практического примера в студию. Примерно как у меня.
                      • +2
                        Суров… :)
                        Код какого примера в студию?

                        В принципе, можно любую синтетику сделать.
                        Хотя бы просто как ниже описано сделать и попробовать селфджойн несколько десятков раз для сборки одного факта продажи.
                        Чур всякие хитрости типа CASE не применять!
                        Вот так постепенно наращивать количество таблиц в джойне и увидите как производительность будет деградировать.

                        И сдаётся мне, что ваши сотни тысяч записей все в память помещаются на планшете.
                        Как только не будут помещаться, так привет горячий — идём пить кофе, пока запрос выполнится.

                        Как ниже на картинке :)
                        image
                        • –2
                          ну, если нет опыта практической работы с базами данных, нет возможности показать свои наработки, то и спорить по поводу сикстиллионов не нужно.
                          • 0
                            :)))))))
                            Если абстрагироваться от попыток измерения experience в базах данных, то как вы себе мыслите предоставление «кода практического примера в студию»? :))))
                            Вам выгрузить сюда продакшн базу на несколько терабайтов?
                            Или на чем вы будете проверять как работает запрос?

                            В общем, нет желания прислушиваться? — без проблем.
                            Если останетесь в песочнице с сотнями тысяч записей, то и предоставленный вами код будет работать, и будет вам счастье.
                            Если придёт время и понадобится обрабатывать что-то посерьёзнее, то наедитесь проблем по горло.
                            Предупреждён — значит вооружён.
                      • +2
                        Код практического примера в студию. Примерно как у меня.

                        Извините, но Ваш код, кхм, весьма далек от идеала. По многим характеристикам — перфоманс, безопасность, простота сопровождения.

                        И чтобы избежать такого кода, базу данных денормализуют, вплоть до хранения данных в сыром виде.
                • +1
                  Если у запроса «правильный» WHERE, а поля, участвующие в условиях, проиндексированы, то количеств записей в таблицах не [так] важно. Вы же не думаете, что SQL сначала джойнит, а потом условия накладывает? ;)
                  • 0
                    Правильно говорите :)
                    Для случая, когда нужно получить несколько записей, и кардинальность связей большая.
                    Тогда да, тогда и nested loops отлично справится по обычным индексам (B*Tree).

                    Но что делать, когда кардинальность мала (поля типа «да/нет», пол человека и т.п.)?
                    Bitmap индексы отчасти спасают, но опять же только в случае нескольких результирующих записей.

                    Если достаточно поработать с оптимизатором оракла и посмотреть планы его запросов, то попервоначалу удивительно почему он иногда отказывается от индексов и других хитрых алгоритмов, а шурует просто FULL SCAN.
                    Но это только попервоначалу :)

                    Так вот для задач BigData чаще бывают нужно получить не отдельные записи по хорошо сформированным критериям (where primary_key = 123).
                    Специфика задач BigData как и задач Machine Learning в том, что необходима оптимизация.
                    Например, сравнить все записи и найти наилучшую по нетривиальным критериям.
                    Или найти наиболее похожие записи.
                    Или найти набор признаков наибольшей длины, который отвечает какому-то условию.
                    И тут часто наступает комбинаторный взрыв, и на помощь приходят всякие эвристические алгоритмы (например, градиентный спуск).
                    Так что индексы тут могут просто не помочь.

                    А с другой стороны вы же знаете, что для того, чтобы пользоваться индексом, надо его сначала построить?
                    Ну вот на построение индекса может уйти такое количество ресурсов, что игра свеч стоить не будет.
                    При непрерывном поступлении данных со скоростью терабайты в сутки (не красное словцо — логи Facebookа копятся таким темпом) построение индекса в обычном смысле БД нецелесообразно.
                    Поэтому строится просто слой информационной системы, который в онлайне парсит сырые данные и раскладывает их по полкам для дальнейшего использования другими.

                    Как правило, это можно сделать только параллельной обработкой системами аля Hadoop.
                    На нем, кстати, свет клином не сошёлся, есть ещё варианты, например, Dryad у Microsoft, MAD-платформа у Fox Interactive Media, не говоря уж о решениях от Google.

                    В общем тут вопрос не в пальцегнутии и мерянии петабайтами, это просто реальность, которая заставляет искать нестандартные выходы, если стандартные не срабатывают.
                    Я очень люблю Oracle Database (работал с версии 7.3), но у всякого инструмента есть предел полезности.
                    • 0
                      >>При непрерывном поступлении данных со скоростью терабайты в сутки
                      Оффтоп: вот мне интересны 2 вопроса:
                      1) Нафига копить эту хрень? Давайте еще видеокамеры на каждом углу повесим и будем видеопоток с 100500 камер писать, оцифровывая всю реальность, так сказать (со скоростью 10000 кадров в секунду, а то вдруг чего пропустим)
                      2) Если мы все-таки решили копить эту хрень (вдруг понадобится), откуда столько места берется под это? Насколько понимаю, круче жестких дисков по 4-6-8 (?) ТБ ничего не придумано (стримеры не в счет, у них доступ последовательный, а так не интересно).
                      Взять к примеру, сколько видео на Ютуб заливается ежедневно, неужели WD/Toshiba поставляют миллионы дисков в день?
                      • +1
                        Попробую ответить на эти вопросы.

                        1) Этот вопрос несколько даже философский. Скажем так, глубоко копнули. :-)
                        Может быть немного навязло в зубах, но тут есть связь с байесовским подходом к вероятности и к мировосприятию вообще. Надеюсь, не звучит слишком пафосно. Когда до меня дошла вся мощь байесовского подхода, я некоторое время был стукнут пыльным мешком по голове.
                        Сначала небольшое теоретическое отступление.

                        Вот смотрите.
                        Идея байесовского подхода состоит в том, что абсолютно случайных событий не бывает, а случайность исхода говорит только о нашем незнании, то есть, неполноте нашего знания о явлении.

                        Пример! Чтоб не скучно было от теории. Погода считается случайным событием. Так изменение температуры воздуха является в полный рост случайным процессом, который мы можем прогнозировать только с определенным уровнем допустимой ошибки. И чем больше мы собираем данных (чем больше метеостанций натыкаем и чем чаще будет сетка расчёта), тем точнее будет прогноз и меньше ошибка. В пределе, если мы соберем всю информацию о каждой молекуле (или атоме, или кварке), то сможем построить абсолютно детерминированную модель и без ошибки предсказать погоду.

                        Ну вот, значит, чем больше мы будем собирать данные, тем точнее будет наше знание об окружающем мире, тем точнее сможем делать выводы и прогнозировать будущее.
                        Вот на этом принципе и построена идея модели BigData и этим она отличается от классических статистических подходов: собираем всё, что только можем и ищем корреляции между причинами и следствиями.

                        В классике мы берём ограниченные выборки и пытаемся строить точные модели, которые потом распространяем на всю, простите за выражение, генеральную совокупность. В BigData мы пытаемся собрать всю генеральную совокупность и строить приближенные модели, которые за счет громадных объемов исходной информации получаются точнее классических.
                        Ну вот в чем смысл сбора всего подряд.

                        2) Подход к хранению такой же как раньше, как в идее RAID. Только теперь не много дисков, а много станций, которые работают совместно и обеспечивают относительно дешевый способ постоянного хранения данных. С избыточностью, с распределением, с распараллеливанием.

                        Вообще на хабре писали про заводы по обработке информации с собственной электростанцией, выделяющие тепла, которое может вскипятить небольшое озеро.
                        • 0
                          С первой частью полностью согласен, наверное это логично.
                          А насчет «только теперь не много дисков, а много станций», это понятно, я имел в виду, что в этом множестве станций натыканы обычные диски по 4 TБ, это сколько же дисков надо, чтобы все эти петабайты хранить. При этом срок службы диска ну лет 5 максимум непрерывной работы, да и то вряд ли. Я просто имею в виду, что объем информации может расти гораздо быстрее роста производственных мощностей по производству средств хранения информации, т.к. прорывов в этой части что-то пока не видно, хотя потребность явно назрела.
              • 0
                я ежедневно пишу запросы с джойнами из десятков табличек.
                Например вот такой (даже на андроидном планшете, в SQLite имеющем примитиный оптимизатор, на базе из нескольких сотен тысяч записей выполн\яется за 1-3 секунды):


                1-3 секунды на запрос… это неприемлемо долго, например, для БД веб-сайта (мы же говорили о производительности?). Особенно, на сотнях тысяч записей.

                В структуру таблиц и в сам запрос не вникал, но куча вложенных селектов с агрегацией мне точно не нравятся.

                P.S. Подумайте насчет перехода на параметризованные запросы :)

                • 0
                  этот запрос выводит
                  — номенклатуру товаров (наименования)
                  — единицы измерений (молоко в литрах, колбаса в килограммах)
                  — единицы квантования (сок в упаковках 2л, 0,5л или конфеты вразвес)
                  — цены исходя из текущих остатков партий
                  — наценка
                  — жалетальная цена продажи
                  — цены и дата последней продажи данному контрагенту
                  — скидки на группу товаров
                  — скидка на контрагента с учётом иерархии холдинга
                  и ещё ряд значений

                  Всё это расчитывается полотенцем запроса размером меньше страницы за приемлимое время в жёстких условиях (Андроид) на объёмах типичных для 90% систем (десятки либо сотни тысяч записей в базе).

                  Я понимаю что людям далёким от баз данных запрос кажется сложным. Но с учётом того что он делает, объём кода чрезвычайно мал.

                  По параметризированным запросам:
                  придётся провести ликбез — параметризированные запросы никак не влияют на производительность. Это просто проверка подставляемях переменных а на сервер в конечном итоге пойдёт тоже самое полотенце с SQL-текстом запроса. Можно посмотреть исходники Java и убедиться что чуда нет.

                  Вот так.
                  • +2
                    К сожалению, ликбез нужно провести вам.

                    Почитайте порядок выполнения запросов на сервере.
                    Про компиляцию и оптимизацию запросов, про планы запросов, про кеш и т.д.

                    Параметризация запросов — это, как раз, азы грамотной работы с сервером БД.
                    Хинт: без параметризации компиляция запроса проводится повторно и с кеш может быть не задействован.
                    • 0
                      чтение учебников без практики может приводить к странным выводам.
                      • 0
                        Теперь без комментариев, аррогантный вы наш :)
      • +1
        Если у каждого товара один производитель, то количество строк в таблице товаров будет ровно таким же, что в случае указания названия производителя в таблице товаров, так и в случае названия производителей в отдельной табличке.
        Выборка из одной таблички конечно же быстрее, чем выборка из двух+операция джойна.
        Денормализация проводится для ускорения конкретных выборок в ущерб консистентности + дополнительные затраты при изменениях.
    • 0
      Мне сломало мозг «базу придётся переписывать».
  • +27
    >> Мониторим, когда один из них подойдёт на 50 метров к нашему салону. А затем отправляем ему SMS с рекомендацией про «зайти посмотреть», если в данном салоне есть смартфон и если он готов к демонстрации.

    Ну молодцы вообще. В одном флаконе и незаконная слежка и незапрошенная реклама. И, главное, никого не смущает (в том числе и читателей).
  • +1
    >> Да, нам очень интересно знать, когда человек едет в другую страну. Не сообщать ему на месте, что «Добро пожаловать в Казахастан», например, а ещё до начала поездки предлагать тарифные опции и информировать о ценах на месте. Один из проектов — анализ потока клиентов в аэропортах.

    Полезно, но никаких смс не приходило до начала поездки. Толмачево НСК, симка Барнаул. Оказался в Китае совершенно без связи %)
  • +2
    Статья интересная но:
    Java-методология давно известна, но в аналитике её стали применять сравнительно недавно.

    бегают роботы на Java-коде

    писать Java-робота для Big Data

    Для чего эта шифровка Hadoop'а? под «Java код» )
    • +2
      Видимо автор беспокоиться, что не все слышали о проекте Hadoop.
      Либо они пользуются чем-то самописным (переписанным Hadoop?).
    • +3
      Мне вот вообще интересно, почему автор считает, что Big Data – это обязательно что-то, что обрабатывается «Java-кодом». Как будто нет реализаций под другие языки.
  • +4
    А где вы еще следите за клиентами? Допустим, когда человек проходит мимо кафе, рекламу со скидками не шлете? Раскажите, интересно.
  • +13
    Как в том анекдоте, «средства гарны, цель погана». Вы как технарь пишете великолепным языком, видно что вы во всем этом собаку съели, и решения классные предлагаете.

    Но как подумаешь, что все это — обработка петабайтных массивов данных, распараллеливание на сотни серверов и т.п. делается только для того, чтобы мне в очередной раз пришла смс «в Евросети распродажа бюджетных смартфонов на андроид» на мою старую нокию, делается гадко и грустно. Ваши б мозги, да в другую область…
    • +5
      А мне гадко и грустно, что на такие трюки ведётся так много народа, что даже обработка петабайтных массивов данных и распараллеливание на сотни серверов себя оправдывают.
  • +5
    Читал статью, и с первых абзацев возникло ощущение однобокости трактовки терминов. Последние абзацы подтвердили догадку — автор из realtime-систем и трактует понятие «big data» соответственно. В целом статья понравилась, но давайте я подчеркну некоторые спорные моменты.

    1) «Java-методология» — поясните пожалуйста мысль, при чем здесь Java? Можно взять практически любой инструмент для работы с большими данными — от Cassandra до Hadoop — и подыскать ему вполне успешную альтернативу, написанную на других языках (к примеру, Riak и Disco соответственно).

    2) Ваша трактовка «big data». Я не хочу глубоко влезать в терминологию, но давайте все-таки трактовать этот термин по классическим канонам — то есть дословно: «большие данные». Реляционка на 20 терабайт — это таки «большие данные». И подходы к работе с ней уже начинают отличаться от той же базы на 500МБ: вам, как минимум, придется повозиться с грамотной настройкой кластера, с планированием архитектуры приложения, с созданием\восстановлением резервных копий и т.д. Если уж на то пошло, Ваша трактовка термина Big Data скорее относится к понятию «data mining», так как Вы делаете акцент больше на качество данных, чем на количество.

    В остальном статья вполне качественная, продолжайте (но хотелось бы больше технических подробностей).
    • +1
      Дело в том, что задолго до BigData уже были VLDB, DSS, Data Mining и прочие аббревиатуры и мемы.
      Так что BigData — это всё-таки не просто «большие данные».

      Классическим каноном, скорее, считается подход Гартнера «3Vs» — «Big data is high volume, high velocity, and/or high variety information assets that require new forms of processing to enable enhanced decision making, insight discovery and process optimization.»
      • +2
        Отчасти соглашусь с Вами. Но давайте посмотрим на конкретный пример — система определения предпочтений пользователей (классическое «с этим товаром также покупают...»). Если речь идет о крупном интернет-магазине, то это становится уже вполне себе классическим примером «big data». Люди используют MR-алгоритмы, Hadoop и прочее и прочее. Но входные данные в этой задаче на удивление однородны и хорошо структурированы. Быстрый доступ также не требуется — можно раз в неделю обсчитывать новые значения весов для товаров, быстрее не нужно. Остается по сути только одна «V» — это «Volume».

        Все вышесказанное еще в бОльшей степени относится к обработке логов веб-серверов и извлечению оттуда какой-то полезной информации — вроде глубины просмотра сайта на определенных устройствах или для определенных городов.
        • +1
          Вы привели пример, который больше является контрпримером :)

          Рекомендательные системы — это системы с очень разреженными матрицами: никто не покупает все товары, редко все покупают один и тот же товар каждый раз и т.д.
          Поэтому здесь реляционная база будет работать тяжело.
          Вот если бы данные действительно были бы хорошо структурированы и не разрежены, то решение на RDBMS било бы любые Hadoopы.

          Кстати, попробую убедить.
          Набор текстов — это однородный и структурированный набор данных? Вроде бы нет.
          А если мы сконвертируем в табличку, где будет информация в каком тексте, в какой позиции стоит какая буква? Уже структурированный?
          Но количество информации одно и то же, оно не изменилось ведь.
          И в том и в другом случае набор не является хорошо структурированным с точки зрения классической RDBMS.

          Для усиления идеи можно рассмотреть вместо набора текстов набор графических файлов и сконвертить их в таблицы положения пикселов.
          Что, в принципе, и делают при подготовке данных все методы ML, которые в том числе работают и в решениях BigData :)
          • 0
            Давайте я расскажу как мы решали эту задачу на практике, а не в теории. Вы увидите, что здесь все действительно структурировано.

            Входные данные такие:

            [пользователь1: товар23, товар15, товар1],
            [пользователь2: товар1, товар46, товар99]


            Чисто теоретически, айдишники пользователей даже можно исключить, оставив только массивы одновременно купленных товаров.

            Таким образом, поступает вполне структурированная информация, которую можно хранить даже в одной строке простым текстом (что конечно извращение). Либо, на практике, в двух моделях (где каждый товар будет ссылаться на модель «заказ»). Сложно? Нет: 2 таблички с 3 полями суммарно.

            Далее в RDBMS была бы простая аггрегация (и на самом деле небольшие интернет-магазины так и поступают).

            Если же реализовывать все в MR, то алгоритм похожий — делаем join по данному товару со всеми остальными «строками» (т.е. заказами) и подсчитываем кол-во «веса» для каждого другого товара.
            • +1
              Я же привел вам пример «структурированности», которая не структурирована :)
              В вашем случае эта проблема такая же.

              Если так настаиваете, то подумайте что для рекомендательной системы простой агрегацией не обойдёшься.
              Одной из задач в рекомендательных системах является поиск одинаковых групп товаров максимальной длины (в одной покупке).
              У вас они лежат в виде отдельных записей.
              Чтобы эффективно сравнивать покупки лучше бы они лежали как записи (товары как поля), не правда ли?
              Иначе получаются селфджойны чтобы свернуть обратно покупку в одну запись.
              А это прямой путь в «проклятие размерности».

              В ML системах часто делают бинаризацию, когда вводят поля типа Yes/No вместо одного поля с категориями, это работает лучше, несмотря на бешеное количество полей (признаков в терминологии ML).

              P.S. ML — это Machine Learning.

              • 0
                Наверное у нас просто разное понимание «структурированности». Здесь я спорить не буду, т.к. возможно мое понимание этой самой структурированности отличается от общепринятого. Я считаю что неструктурированные данные — это что-то вроде текстов новостей, из которых надо выдрать ключевые термины и — грубо говоря — сделать очень краткий «машинный» пересказ, но который будет неотличим от написанного человеком. Вот в этом случае начинаются проблемы =) Или — парсинг HTML-страниц, из которых нужно «выдрать» штук 5 ключевых слов\фраз, наиболее точно характеризующих контент. А простые массивы товаров — это вполне себе структура (в моем понимании). В общем, как я уже сказал, это лично мое видение ситуации, здесь я не претендую на вселенскую истину =)
                • +2
                  Ну так я ж написал пример про тексты :)

                  Предобработка данных для ML алгоритмов в основном и делает некое подобие структурированности.
                  Иногда это называют digitization, иногда datafication, иногда ещё как.
                  И всякие вариации на тему, например, bag-of-words это оттуда.

                  Но это совершенно не подходит под структуризацию в стиле RDBMS.
                  Там есть жестко определенная структура отношения (relation), и она заполнена кортежами, строго отвечающими этой структуре.
                  Вот тогда RDBMS работают отлично.

                  Так ведь даже проблемы существования NULL в RDBMS ведь поднимались.
                  Есть школы, которые призывали запретить NULL по причине возникновения троичной логики (true/false/null), которая нарушает реляционную алгебру.
                  А в BigData пропуски данных — это минимум, что может происходить с входными данными, вполне нормальное явление, и многие алгоритмы разрабатываются с учетом обработки данных с пропусками.

                  Я уж не говорю, что в BigData вполне нормальным явлением считается наличие ошибок в данных, лишь бы не превышало допустимого уровня.
                  Для «обычной» БД — это ужас и кошмар, нарушение целостности и errors различной severity, в зависимости от места положения ошибочного значения (я уж молчу в первичном ключе, свят-свят...)

                  Так что всё-таки BigData — это не просто большие данные :)
    • 0
      1) Похоже имелась в виду agile-методология.
  • +5
    Прозвучит неинтересно, но вы бы взялись за одно дело — быть «трубой» по передаче голоса и трафика данных — и его бы только и делали.

    Не нужно торговать телефонами (все равно это не европейские «телефон за евро», и всякий разумный человек найдет телефон дешевле, чем у вас в точках торговли — т.е. окучивание идет неразумных, а это называется «впаривать»), не надо ваших рассылок, поборитесь со спамом всерьез, не просто подняв цены, не нужно устраивать лотерей «от Билайна» — это не красит компанию. Тема «скрытых методов» повышения дохода (неверная APN забита — опа, тарификация по другому тарифу!, и ведь такого в разное время было и есть масса!) — вообще плач Ярославны, и это в контексте рассказов белой и пушистой, идущей на общение, компании…

    И читать про big data (чтобы это не значило), спасибо которым, юзеры оказываются все более под колпаком — противно. Я не хочу, чтобы сеть отслеживала, как часто я меняю телефон, как много я захожу на какие сайты и что я там делаю, не хочу думать, как мне чихнуть без того, чтобы потом не пришел счет за какой-нибудь premium-трафик.

    Спасибо, покрытие растет. Спасибо, 3G не только в городах появляется. Но вот это торгашество — вот оно так вас не красит, что не верится, что вы об этом не знаете!
    • –2
      Непонятно, за что вы на них так «взъелись»? Может у них «торгашество» — одна из основных статей дохода?
      • –1
        Вы, верно, смайлик забыли поставить.

        Торгашество у компании, в лицензии который указано «услуги связи», выглядело бы странно, но, уверен, там просто много-много компаний, одна из которых, и правда, торгует телефонами. Другая — устраивает лотереи, прикрываясь брендом/именем Билайна и крутя недешевую рекламу по всмогущему «Первому», в третьей работают спецы, которые придумывают иезуитские методы тарификации и противоестественные сноски к в общем-то нормально выглядящим тарифам. Про спамеров и прочее даже писать не буду.

        Но вопрос в том, что все это происходит под «добрым» именем Билайна. Да-да, той компании, которая недавно стала говорить, что типа премиум-услуги они теперь тарифицируют так, чтобы клиент не остался совсем недоволен. Сам факт, что «теперь» это оказалось хорошей идеей, а до того лет десять такая «честность» не использовалась… выглядит «не очень». Понимаете, Big Data прикрутить, чтобы понять, что клиент находится на терминале отлета в Монголию, и прислать ему нужну СМС — на это рук хватает, а чтобы без биг-даты, а просто раз сесть и придумать меры по придавливанию «премиумных» сверхдоходов — это никак?

        Я лично жду поста о том, как с помощью биг-даты умудрились удушить спам в зародыше, но, боюсь, пока провайдеру выгода от этого будет больше, чем репутационные потери, не дождусь. Так же, как не дождусь отключения платных «премиум» услуг — вероятно, хоть одна из них нормальна, и это просто я такую не нашел.

        А так, конечно, Вы правы — торгашество и доходы где-то рядом, особенно для провайдеров ) И, что самое смешное, я еще считаю Билайн самой приличной из «тройки».
        • +2
          В корне не согласен — возьмите тот же Гугл. По вашей логике — поисковому гиганту не пристало заниматься онлайн-рекламой и распихивать везде свои мерзкие баннеры. В противном случае гуглу, чтобы выжить, придеться таки брать с вас деньги за поиск. Продолжая аналогию — если Билайну закрыть направления по продаже мобильников, рассылке спама, ввести понятные для всех тарифы без сносок — им придется поднять цены на связь. Если вас не устраивает такая политика — идите к другому оператору (но там, как вы сами сказали, еще хуже). Таковы суровые законы всех крупных и средних бизнесов, будешь пытаться блюсти заповеди — выкинут с рынка в два счета.
        • +2
          Давайте я вашу тираду сокращу до одного предложения:

          я никак не могу понять почему Билайн вместо того, чтобы концентрироваться на зарабатывании денег не займётся улучшением того дела, за которое ему платят всё меньше и меньше.

          После такого сокращения вам всё ещё непонятно почему приоритеты в компании расставлены так, а не иначе??? Да, где-то когда-то как-то и Билайн может благотворительностью заняться, ничто человеческое руководителям и этой компании не чуждо, но в целом… компании, которые забывают про то, что их деятельность, в общем-то, должна в первую очередь приносить прибыль при капитализме долго не живут.

          Раз вы всё ещё считаете Билайн самой приличной компанией из большой «тройки» значит баланс выдержан не так и плохо.
          • –3
            Вы неправильно сократили )

            Надо так: вместо чем делать то, за что взялись (передавать трафик), и на что сами же установили такие цены, компания ведет игру с сомнительными способами повышения доходности, в т.ч. путем усложнения условия тарификации обычно простых вещей, путем (по сути) покрывательства рассылкам спама, и пр.

            Т.е. делает вещи, которые приличными назвать не поворачивается язык. Это лично мне не нравится.

            Риторика, что иначе они бы умерли… ну, тоже как-то не звучит. Но если Вам так нравится, можете находить утешение именно в ней.

            Мне же просто обидно, что оператор, от которого ждешь решений проблем, вместо этого (или вместо с ними) подкидывают другие проблемы. Лично мне жутко не нравится, скажем, что переход по определенной ссылке на сайте может меня, по факту, подписать на платную смс-рассылку, или что при наличии пакета трафика часть сайтом может тарифицироваться вне этого пакета по очень высоким ценам. Вы при том понимаете, что в обоих случаях можно просто встроить элемент с «премиум-сервера» на чужую, «не-премиум», страницу, и иметь таки свой маленький гешафт, пока Билайн устами своей техподдержки отвечает клиентам, что «мы эти сайты не контролируем, сделать ничего не можем, это вы сами зашли».

            Биг-дата, говорите? ))
  • +1
    Big Data это интересно. И статья достаточно интересная. Но русло, в которое идут усилия…

    Такие ресурсы тратятся на то, чтобы на ходу предлагать общую информацию при вылете из страны или прохде мимо точки продаж. Но работа по той же проблеме спама, кажется, за 10 лет так и не сдвинулась. Телефоны людей засыпает потоками спама, а решения массового так и нет. Максимум, что можно — локальные блэклисты делать. Но ОпСоСы тут не при чём. Это заслуга производителей телефонов/девелоперов ПО. А вот на уровне оператора продолжают гулять сообщения «нанокредит за 5 минут по тел. 8-800-ззз-хх-ъъ».

    Многие бы по достоинству оценили предложение услуг по блокировке такого хозяйства. А то, что обычно сейчас наблюдается — это увещевания, о том, что заблокировать можно, но отследить нет возможности и т.д.
    Невольно возникает вопрос «Это как?», если все остальные вещи, типа марок телефонов, передвижения абонентов, их маршруты — вполне отслеживаемы.
    • +1
      А зачем бороться со спамом? Если побороть спам, то те самые «смс-предложения», о которых говорится в статье, сразу станут как бельмо в глазу. А так, на фоне спамерских «нанокредитов», вроде как и ничего…
    • 0
      Так всё же ради денег. Так в статье и написано — черным по белому. Прошел мимо офиса-продаж — купи мартфон. Прошел мимо туалета — купи бумагу, прошел мимо авто-магазина, купи авто.
      Проблема в том, что спам отрицательно, я бы сказал даже негативно казываеться на рекламу. Черезмерная навящевость приводит к рвотному рефлексу.

      p.s. Нужно вектор развернуть. Не платить рекламщикам за рекламу, а платить пользователям за анкету или за активность пользователей.
    • 0
      А с другой стороны усилия идут в противоположную сторону :-)
      Ведь спам-фильтр — это хрестоматийный случай машинного обучения и BigData.
  • +1
    Реляционные базы данных маштабируются достаточно сложно, как правило, до бутылочного горлышка в единой СХД. Есть горизонтальный порог масштабирования, после которого становится проще писать новую структуру, чем вводить очень сложные аппаратные комплексы.

    А как же современные коммерческие MPP системы, например, Терадата, на форуме которой вы выступали зимой? Проблема в другом, экономически не выгодно хранить веб-логи личного кабинета в хранилище, которое стоит несколько миллионов долларов в «базовой комплектации».

    Нужна другая архитектура базы данных. Если вам нужны гибкие запросы, то проще всего хранить данные неструктурированно

    Теплое с мягким. «Schemaless» и архитектура не имеют ничего общего. энторпрайз и сырой json. IBM еще в 2008 году в DB2 версии 9.5, если не ошибаюсь, предоставил возможность делать запросы к XML данным. А архитектура как была, так и осталась — кусок мощного железа, в который запихивают десятки (30, 40, 50, ххх дисков), железки соединяют инфинибэндом. У кого нет денег на инфинибэнд и брэндовое железо, тот покупает commodity hardware, как у вас и многих других, и соединяет его медью. Все оптимизаторы, костыли вместо индексов и прочих плюшек СУБД тоже пишет сам. Так себе занятьице.

    — мы просто отдаём чуть больше ресурсов виртуальной среды или довозим и втыкаем железо.

    И ждете, пока десятки терабайт заедут на вашу железку, забив всю сеть. Пример из реальной, не песочной жизни, в кластере Spotify 500 машин, самые свежие имеют до 12 дисков по 3ТБ. Когда узел выходит из строя, около 25 Терабайт (утилизация дисков 50-70%) начинают лихорадочно реплицироваться по всем остальным узлам, забивая сеть. Обратная ситуация, пока ваши данные не будут сбалансированы и новый узел не получит реплики данных, вы не сможете полноценно этот узел использовать. Все свои данные он будет гонять по сети, перегружая её.

  • 0
    Что думаете об Exadata? Не присматривались? Мегафон вроде пользует и особо не жалуется.
    • +1
      Если в шутку, то Exadata is Still Oracle, если серьезно, то я не знаю, кто на что жалуется.
      • 0
        Вы из Мегафона?
  • 0
    А затем отправляем ему SMS с рекомендацией про «зайти посмотреть», если в данном салоне есть смартфон и если он готов к демонстрации.

    Предположим, получатель спама нашёл, где запарковаться рядом с салоном, зашёл туды, а там… всё тот же «ваш звонок просто офигеть как важен для нас» — два с половиной «менеджера по продажам» и очередь из двадцати человек.
  • 0
    По-моему, основное отличие BigData от RDBMS в том, что в нем просто забивается на ACID в целях производительности в ущерб консистентности.
    • 0
      Это Вы зацепили только базы данных. А есть еще ведь множество других инструментов — от анализа практически любых данных с помощью того же MapReduce до средств создания резервных копий больших данных. И кстати если с тем же Хадупом все более-менее понятно, то проектирование\организация систем резервирования — это весьма непростая вещь. Вылезает множество интересных нюансов, которые при работе с небольшим объемом данных просто не вспоминаются. Например, ограничения в пропускной способности сети (даже гигабита становится мало для быстрого восстановления). Или появление рандомных ошибок железа (к примеру, редкие на обычных объемах ошибки RAM). Или создание инкрементных архивов.
      • –1
        Все то, что есть в MapReduce можно точно также написать на sql/plsql :) Просто сделать много маленьких БД oracle, в каждой key-value таблички, распределение по на основе hash(key) и обработчик, который на будет распределять запросы по нужным БД :) Чем Вам не BigData? В призводительности, да, проиграете настоящей bigdata, да и консистентность потеряете, по сравнению с одной БД oracle.
        С резервированием, я особых проблем не вижу, если это делать, например, средставами СХД — можно иметь актуальную гео-копию на приличном расстоянии с набора дисковых массивов.
        По RAM — сервера имеют от этого защиту (ECC). При невосстановимых ошибках просто перегружаются.

        P.S. я oracle dba больших (>50Тб) баз в приличной нагрузкой как OLTP, так и DWH

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка