Существует множество определений хранилища данных. Я взял случайное определение из Интернета. Это соответствует общему пониманию в индустрии управления данными того, что такое хранилище данных, а что нет.
Это тоже неправильно.
«Хранилище данных - это технология, которая объединяет структурированные данные из одного или нескольких источников, чтобы их можно было сравнивать и анализировать для большей бизнес-аналитики».
Если вы смотрите на это определение и думаете: «Мне это кажется правильным», читайте дальше. Когда-то я, наверное, тоже согласился бы с этим определением. Но времена изменились.
Процессы и технологии создания хранилищ данных сильно изменились за последние десять лет, но, как профессионалы отрасли, мы часто думаем о хранилищах данных одинаково. В нашем сознании мы все еще используем то же определение хранилища данных, которое мы использовали десять лет назад.
Это определение.
Итак, в чем же неправильность этого определения?
Рост больших данных
За последнее десятилетие область управления данными радикально изменилась. Большинство людей не верят, что это изменение каким-либо образом коснулось хранилища данных. Это заблуждение.
Классические три буквы V Дуга Лэйни поразили индустрию управления данными цунами данных, а вместе с ним и коренным изменением типов аналитики, которые мы можем использовать с этими данными. Аналитические базы данных старой школы содержали слишком много данных, чтобы обрабатывать их по доступной цене, не допуская попадания ценных данных в открытый доступ. У нас был бизнес-спрос на анализ типов данных, с которыми мы никогда даже не пытались иметь дело в прошлом, полуструктурированные данные, такие как JSON и Avro, файлы журналов от датчиков и компонентов, геопространственные данные, данные потока кликов и т. Д. . Данные поступали к нам слишком быстро, чтобы старая технология могла их принять, очистить, объединить с другими наборами данных и предоставить бизнесу в удобной форме.
Но это было только частью проблемы.
Обладая всеми этими данными, мы могли делать то, чего никогда раньше не делали. Машинное обучение, наука о данных и искусственный интеллект были областями изучения еще в 90-х, когда я учился в колледже, но тогда у нас не было всех возможностей, чтобы заставить их выполнять полезную работу.
Проблема заключалась также в обещании.
Обладание тоннами данных во всех этих разнообразных форматах позволяет проводить новые интересные и потенциально революционные анализы. Ранние эксперименты показали, что машинное обучение может обеспечить впечатляющие улучшения в существующих системах, совершенно новых системах, делающих организации более успешными, и даже в совершенно новых отраслях и бизнес-моделях.
Задача заключалась в том, чтобы найти способ хранить и обрабатывать все эти данные, чтобы привести их в надлежащую форму для всех этих классных новых типов расширенной аналитики данных.
Hadoop спешит на помощь… или нет.
Пришел милый желтый слоник с спасательной шлюпкой, пообещавший хранить все эти данные по доступной цене и обрабатывать их за нас, а также предоставить нам отличную платформу для причудливой аналитики больших данных, такой как машинное обучение. Казалось, это именно то, что нам нужно. Это была новая горячность.
Выбросьте свое старое и поврежденное хранилище данных, в котором вы десятилетиями использовали важную бизнес-аналитику.
Что может пойти не так?
Очевидно, много чего. Размещение всех важных данных на гигантской группе серверов по разумной цене вместе с множеством других данных не принесло многим компаниям особого результата. Это никогда не было намерением людей, придумавших концепцию озера данных, но в основном это было то, для чего оно использовалось; свалка данных. Это было отличное место для архивации данных за годы, которые не помещались в транзакционных системах и не казались достаточно ценными для размещения в самом хранилище данных. Здорово. Все хранилось. Тогда что?
Не будем даже говорить о бизнес-аналитике. Поставщики Hadoop заявляли о возможностях хранилища данных, но механизм запросов поверх большого массива данных не является хранилищем данных. В нем отсутствовал параллелизм, поэтому пользоваться им могли лишь несколько человек. Ему не хватало безопасности, ему не хватало управления. Прежде всего, ему не хватало надежности и скорости работы, которые были отличительными чертами хранилища данных.
Предполагалось, что специалисты по обработке данных будут теми, кто сможет творить удивительные вещи с Hadoop. Они перебирали гигантские кучи данных, проводя почти все свое время, просто пытаясь превратить эти данные во что-то, что они могли бы использовать, чтобы наконец-то заняться классной предиктивной аналитикой данных, для которой их наняли.
Часто они просто брали несколько образцов нужных им данных и уходили выполнять свою работу изолированно в среде «песочницы» или на своих собственных ноутбуках. Они использовали такие технологии, как R, которые делали именно то, что им нужно, быстро и легко, но никогда не предназначались для масштабирования для работы на многосерверных озерах данных.
Таким образом, даже когда специалисту по данным удалось создать что-то, что могло быть чрезвычайно полезно для бизнеса, это было даже близко к тому, чтобы быть готовым к запуску в производство.
Развитие специалистов по обработке данных
Эта часть кажется немного личной для такого старого специалиста по интеграции данных, как я, но, наконец, все осознали, что конвейеры производственных данных имеют значение. Даже в старые времена хранилищ данных ETL считался несексуальным каналом для хранилища данных. База данных и инструменты визуализации были классными ребятами. Теперь люди внезапно осознали, что без правильной сантехники ничего не работает.
Так что, по сути, кто-то другой должен был взять эту классную модель, которую специалисты по данным построили изолированно на одной машине, и выяснить, как воссоздать все, что они делали, но в массовом распределенном производственном масштабе. Они могут переделать большую часть конвейерной обработки данных в таких технологиях, как Kafka для потоковой передачи данных, Spark для распределенного ETL и машинного обучения. Иногда к тому времени, когда завершался многомесячный проект по перестройке, он не работал ни в чем похожем на исходную модель, созданную специалистом по данным. Ну что ж. Вернуться к доске для рисования.
Неудивительно, что частота отказов проектов в области обработки данных варьируется от 60 до 90%. Это было плохо для бизнеса. Вся эта крутая продвинутая аналитика данных - это всего лишь трата, пока они не попадут в производственную среду, где они могут иметь значение для организации.
Но как насчет хранилища данных?
Итак, какое отношение все это имеет к хранилищу данных? Что ж, аналитические базы данных, сердце архитектуры хранилищ данных, не просто почивали на лаврах, пока все это происходило.
Поставщики аналитических баз данных увидели преимущества неограниченного масштабирования на обычных серверах, о которых так ясно заявил Hadoop. Во многих случаях они перепроектировали свои продукты для работы на кластерах обычных серверов. Массивно-параллельная обработка (MPP) - это не только то, чем занимается Hadoop. Большинство аналитических баз данных делают то же самое. В большинстве случаев они уже были многопоточными для распределения рабочих нагрузок по нескольким ядрам. Это был не такой уж большой скачок в распределении рабочих нагрузок между несколькими компьютерами.
Облако долгое время обещало стать ЭТОМ способом решения задач. Теперь, наконец, взлет. Одна из причин - массивное, масштабируемое и доступное хранилище, которое не нужно масштабировать и управлять самостоятельно.
Хороший. У Hadoop много преимуществ, но вам не нужно покупать оборудование или управлять программным обеспечением. Неудивительно, что такая комбинация нравится многим компаниям.
Итак, в большинство аналитических баз добавлена возможность работы в облаке. Некоторые из них были приняты поставщиком облачных услуг, например, ParAccel превратился в Amazon Redshift. Google и Azure имеют собственный бренд аналитических баз данных. Некоторые новички построили свои аналитические базы данных для работы только в облаке, например Snowflake. Vertica , где я работаю, добавила все три облака в качестве поддерживаемых платформ, чтобы клиенты могли решить, хотят ли они работать локально, в облаке, гибридном или нескольких облаках.
Разве хранилища данных не дороги в масштабировании?
Не больше, чем любое другое программное обеспечение. И да, я включаю в это ПО с открытым исходным кодом. Программное обеспечение с открытым исходным кодом может быть бесплатным, но только в том случае, если вы на самом деле не используете его в бизнесе. Мой начальник, Джой Кинг, вице-президент по продуктам Vertica, говорит: Программное обеспечение с открытым исходным кодом бесплатно, как щенок. Хороший эквивалент. Первоначальная стоимость бесплатна, но содержание, обучение, уход, кормление и т. Д. Связаны с расходами. В конце концов, совокупная стоимость владения сопоставима с другими типами программного обеспечения. Преимущества программного обеспечения с открытым исходным кодом не в деньгах. Открытый исходный код - это свобода как свобода слова, а не как бесплатное пиво.
Конечно, существует большая разница в стоимости между проприетарными аналитическими базами данных, но некоторые из них находятся в пределах ценового диапазона хорошего решения с открытым исходным кодом с поддержкой предприятия.
Затраты на облачную базу данных частично основаны на использовании вычислений, поэтому общая стоимость владения (TCO) будет меняться от месяца к месяцу. Даже компании, занимающиеся только облачными базами данных, признают, что это может быть шоком для вашего финансового директора, если они этого не ожидают.
Локальная совокупная стоимость владения более предсказуема, но она включает в себя компанию, владеющую и управляющую оборудованием, независимо от того, какое программное обеспечение вы используете. Главное остается: да, вы можете масштабировать современное хранилище данных по разумной цене, настолько большим, насколько это необходимо. Итак, вот о первом V позаботились. Объем больше не проблема.
Но хранилища данных обрабатывают только структурированные данные, верно?
Это еще одна вещь, которая со временем немного изменилась. Я не так хорошо знаком с тем, как с этим справляются другие базы данных, но Vertica имеет встроенный искусственный интеллект, который автоматически анализирует файлы JSON, определяет типы данных, алгоритмы сжатия и т. Д. Это позволяет хранилищу данных обрабатывать два V одновременно, поскольку большая часть потоковых данных быстро передается из чего-то вроде Kafka - это данные JSON, а у Vertica есть прямой соединитель Kafka.
Vertica также может напрямую запрашивать данные Parquet и ORC. Сложные типы в Parquet, такие как карты, структуры и массивы, могут быть запрошены на месте, без необходимости увеличивать объем данных, поэтому красота этих типов данных не нарушается. Конечно, внутреннее хранилище базы данных лучше оптимизировано для скорости запросов, поэтому оно имеет лучшую производительность. Vertica позволяет импортировать и экспортировать данные Parquet, если вы хотите поместить важные данные в свою базу данных, и выталкивать данные с меньшими значениями, но при этом сохранять их доступными. Управление жизненным циклом данных относительно просто.
В Vertica и других распределенных аналитических базах данных есть и другие связанные функции, такие как встроенная геопространственная аналитика и аналитика временных рядов, но это дает вам общее представление. Сложные данные и полуструктурированные данные больше не являются проблемой. И потоковые данные тоже. Vertica позволяет вам непрерывно передавать данные, одновременно запрашивая их.
А у Vertica есть конкуренты. Как бы мне ни хотелось, чтобы мои конкуренты вздремнули и не улучшили свои продукты, они тоже не спали для всей этой шумихи с большими данными.
Как и поставщики конвейера и ETL. Никто из нас не дремал последние десять лет, ребята.
Современные хранилища данных прекрасно справляются с большими наборами данных, наборами данных с высокой вариабельностью и быстро перемещающимися наборами данных. Три буквы V не проблема для современного хранилища данных.
А как насчет науки о данных?
Самое интересное в наличии всех этих данных - это возможность делать с ними что-то новое: расширенная аналитика данных, такая как машинное обучение, прогнозирование и т. Д. Технологии хранилищ данных были разработаны для бизнес-аналитики, которую обычно считают отсталой. -Ищу; понимание текущего состояния бизнеса или прошлых тенденций.
Vertica включает алгоритмы машинного обучения, созданные для работы с оптимизированным внутренним форматом данных и для одновременной работы с несколькими узлами. Обработка данных не требуется. Он имеет расширенные функции подготовки аналитики данных, такие как обнаружение аномалий, вменение отсутствующих значений, статистика наборов данных, быстрое объединение разрозненных наборов данных и т. Д. Он также имеет оценку модели и управление моделью как первоклассный гражданин, аналогично тому, как он обрабатывает столы.
Опять же, я лучше всех знаю Vertica, но другие частные базы данных тоже пережили эту волну. Не зря это называется Google ML. Автономная база данных Oracle имеет встроенный R. В Azure SQL есть службы машинного обучения. У Teradata есть свой движок Vantage ML.
Технология баз данных, которая раньше использовалась исключительно для бизнес-аналитики, теперь полностью способна выполнять машинное обучение в базе данных, либо как часть аналитической базы данных, либо как надстройка, которая работает с базой данных.
Итак, почему это определение хранилища данных неверно?
И снова определение:
«Хранилище данных - это технология, которая объединяет структурированные данные из одного или нескольких источников, чтобы их можно было сравнивать и анализировать для большей бизнес-аналитики».
Хранилище данных - это не технология.
Хранилище данных - это процесс и архитектура. У него определенно есть аналитическая база данных как ядро архитектуры, и да, это технология. Но для передачи данных из широкого диапазона источников данных, быстрых и медленных, старых и новых, требуются другие технологии, такие как Kafka или какой-либо другой потоковый конвейер, такой как Kinesis или Pulsar, и Informatica или какой-либо другой движок ETL, такой как Apache Airflow. или Actian DataConnect. Хранилищу данных требуется хорошее программное обеспечение для визуализации, например Tableau или Looker. Кроме того, это требует, чтобы люди использовали все эти технологии. Для этого требуются бизнес-процессы, которые используют анализ, предоставляемый складом, для принятия решений, будь то человек или автоматизированный.
Современные хранилища данных объединяют структурированные данные, полуструктурированные данные, потоковые данные и т. д.
Современные хранилища данных теперь обрабатывают данные, выходящие за рамки тщательно структурированных данных транзакционных систем. Структурированные данные - одни из самых важных данных в бизнесе, но они больше не являются единственными важными данными в бизнесе. Хорошие современные аналитические базы данных, составляющие основу архитектур хранилищ данных, могут обрабатывать все эти данные.
Современные хранилища данных поддерживают как бизнес-аналитику, так и анализ данных.
Любое современное хранилище данных, достойное его соли, по-прежнему выполняет бизнес-аналитику, теперь уже с более крупными и сложными наборами данных, по-прежнему с высокой производительностью и по-прежнему важным для бизнес-решений. Однако это уже не все. Машинное обучение, предиктивная аналитика, расширенная аналитика, наука о данных, как бы вы это ни называли, современное хранилище данных тоже делает это, в том числе с целью поддержки важных бизнес-решений и процессов. Если вам интересно, зачем вам машинное обучение в базе данных, мы с Вакасом Диллоном, менеджером по продуктам машинного обучения в Vertica, написали об этом сообщение в блоге Vertica. Главное заключается в том, что внедрение машинного обучения в производственную среду является самым большим препятствием, а база данных - это одна и та же среда при разработке, тестировании и производстве.
Итак, каково хорошее определение современного хранилища данных?
Я поклонник Мартина Джонса и его способности пролить свет на слабые места и выдумки индустрии. Я не всегда с ним согласен, но я никогда не могу утверждать, что у него нет веских аргументов в пользу своих взглядов. Вот его определение современного хранилища данных:
«Хранилище данных - это, по сути, бизнес-решение, ориентированное на предприятие и основанное на технологиях. И он используется для обеспечения постоянного повышения качества при поиске, интеграции, упаковке и доставке данных для стратегического, тактического и оперативного моделирования, отчетности, визуализации, аналитики, статистики и принятия решений ».
Для меня это определение интересно тем, что оно актуально сейчас и было точным десять лет назад. По своей сути современное хранилище данных по-прежнему является хранилищем данных.
