Источник контента:21 октября 2017 года Гао Ян, соучредитель Shenqi Wisdom, выступил с речью «Практика создания хранилищ больших данных на основе Greenplum, postgreSQL» на «Китайской технологической конференции PostgreSQL 2017». IT Dajiashuo (идентификатор WeChat: itdakashuo), как эксклюзивный видео-партнер, имеет право публиковать видео после просмотра организатором и спикерами.
Количество слов для чтения:4263 | 11 минут чтения
Резюме
Устарела ли традиционная технология хранилища данных в эпоху больших данных? Мы обсудим, как спроектировать сверхбольшую платформу хранилища данных за пределами традиционного хранилища данных и на основе традиционного хранилища данных. В этом разделе будет подробно рассказано о статусе и практике использования Greenplum и postgreSQL в больших хранилищах данных.
Традиционные хранилища данных устарели?
Традиционная архитектура хранилища данных
Традиционное хранилище данных состоит из исходной системы, ODS, EDW и Data Mart. Исходная система — это бизнес-система и производственная система, ODS — это оперативное хранилище данных, EDW — это хранилище данных на уровне предприятия, а Data Mart — это данные. рынок
исходная система
Производственная система, финансовая система, система управления персоналом и система бронирования 12306 на самом деле являются исходными системами, и основная функция исходной системы заключается в генерировании данных. Большинство традиционных отраслей хранят эти данные в Oracle и db2, а большинство интернет-отраслей выбирают базы данных с открытым исходным кодом.
ODS
ODS — это аббревиатура от Openrational Data Store, называемая Operational Data Store, также называемая промежуточной библиотекой или временной библиотекой в проекте. Прежде чем данные попадут в реальное хранилище данных из бизнес-системы, будет существовать промежуточный уровень, которым является ODS.
Как ОРВ среднего уровня имеет следующие характеристики.
Интеграция разнородных данных, таких как различные бизнес-данные и данные mysql или oracle, ввод в хранилище данных через промежуточную библиотеку
Функция передачи части подробного запроса бизнес-системы, если бизнес-система, использующая традиционную реляционную базу данных, запрашивается напрямую, имеет определенные ограничения для таких баз данных, как Oracle и db2.
Трансформация стандартизации кодирования данных.
DW — это статические данные, а данные в ODS — динамические и обновляемые.
Различное содержание данных, ODS хранит текущие или недавние данные, DW хранит исторические данные.
Уровень емкости данных ODS невелик, а емкость данных DW велика.
Упомянутое выше является определением ОРВ в традиционном смысле, и ОРВ, которые мы понимаем сейчас, уже не ограничиваются этим. Теперь ODS хранит не только текст, но и картинки и видео. Другими словами, он становится средним уровнем, а задействованные технологии — это не только реляционные базы данных, но и такие типы баз данных, как NoSQL или Redis. Когда объем данных, собираемых внешним интерфейсом, очень велик, реляционная база данных может не выдержать нагрузки, но если это Redis, данные можно кэшировать в памяти, а затем сбрасывать в реляционную базу данных пакетами.
Введение в ЭДВ
EDW — это корпоративное хранилище данных. Вот некоторые из его характеристик.
Тематическая: организация данных оперативной базы данных ориентирована на задачи обработки транзакций, и каждая бизнес-система отделена друг от друга, а данные в хранилище данных организованы в соответствии с определенной предметной областью. Например: предметы, соглашения, учреждения, финансы, события, продукты и т. д.
Интеграция: данные в хранилище данных систематически обрабатываются, агрегируются и сортируются на основе извлечения и очистки исходных разрозненных данных базы данных.Несоответствия в исходных данных должны быть устранены, чтобы обеспечить правильность информации в хранилище данных. Согласованная глобальная информация обо всем предприятии.
Относительно стабильный: данные в хранилище данных в основном используются для принятия решений и анализа на предприятии, а задействованные операции с данными в основном представляют собой запросы данных.После того как определенные данные попадают в хранилище данных, они обычно сохраняются в течение длительного времени. большое количество операций запроса, но мало операций модификации и удаления, обычно требуют только периодической загрузки и обновления.
Отражать исторические изменения: данные в хранилище данных обычно содержат историческую информацию.Система записывает информацию о предприятии с определенного момента в прошлом (например, время запуска хранилища данных) до текущего этапа.Благодаря этой информации , развитие предприятия можно улучшить Количественный анализ и прогнозирование истории и будущих тенденций.
Будь то традиционное хранилище данных или хранилище данных в эпоху больших данных, функции, предоставляемые EDW, мало чем отличаются. Основными из них являются случайные запросы, фиксированные отчеты и интеллектуальный анализ данных.В целом уровень больших данных больше ориентирован на интеллектуальный анализ данных.
Введение в ДМ
Английское название витрины данных — Data Marts. Это небольшое хранилище данных на уровне отдела, в основном для бизнеса на уровне отдела и только для определенной темы.Это аналитическая среда, созданная для удовлетворения потребностей конкретных пользователей (как правило, на уровне отдела). Инвестиции меньше и больше направлены на встраивание сложных бизнес-правил в данные для поддержки мощной аналитики.
Концепция больших данных противоположна концепции витрины данных.Витрина данных предназначена для получения подмножества из надмножества, в то время как большие данные предназначены для сбора большого количества бизнес-данных, а затем изучения корреляции и ценности данных из них. . Поэтому мы считаем, что концепция витрин данных устарела в эпоху больших данных, поэтому в последние годы мало кто обсуждал витрины данных.
Изображение выше — это то, что мы считаем правильной архитектурой, с окончательным DW, замененным DV (визуальная база данных/библиотека результатов). Результаты, рассчитанные в EDW, в конечном итоге сохраняются в DW, а затем отображаются или визуализируются в DW.
PG/GP устарели?
Как упоминалось выше, у традиционных баз данных много ограничений, и далее мы их реорганизуем и спроектируем так, чтобы традиционные хранилища данных также могли адаптироваться к изменениям в эпоху больших данных.
дизайн исходной системы
На приведенном выше рисунке показана SCADA (Система сбора данных и диспетчерского управления) Если в такой системе есть десятки тысяч датчиков, объем данных, генерируемых в одно мгновение, будет огромным. В прошлом практика SCADA заключалась в том, чтобы хранить собранные данные в памяти, но, поскольку количество данных было слишком большим и значение данных не могло быть найдено, оно периодически очищалось.
В последние годы с развитием больших данных ценность этих данных постепенно отражается, поэтому возникает необходимость хранить данные на бэкенде. В плане выбора БД многие склоняются к PG.Основная причина в том, что SCADA продается в комплекте с БД.Если в комплекте MySQL, то будут определенные риски.У PG на этот счет опасений нет.
Они упомянуты выше, чтобы проиллюстрировать, что PG может быть лучшим выбором в исходной системе.
Проект промежуточной библиотеки (ODS)
Промежуточные библиотеки обычно разрабатываются как кластеры баз данных, а не как отдельные машины. База данных интерфейса на рисунке ниже на самом деле является промежуточной библиотекой, представляющей собой кластер, состоящий из нескольких машин, и каждая машина будет иметь несколько экземпляров MySQL или PG. Таким образом, данные могут быть распределены по разным машинам, чтобы сформировать библиотеку интерфейса и стать кластером. Кластер здесь не является кластером в традиционном понимании.Промежуточной библиотекой должен быть свободный кластер MySQL или кластер PG.При большом объеме данных можно также выбрать кластер Redis.
ЭДВ Дизайн
Поскольку речь идет о проектировании хранилища данных, мы должны сначала вернуться к традиционному уровню — хранилищу данных на базе Oracle.
Традиционное хранилище данных имеет следующие характеристики. Во-первых, оно использует технологию секционирования для ускорения доступа к данным. Большая таблица в Oracle может быть разделена на несколько областей, и каждая область может быть размещена на разных физических жестких дисках. повышает производительность.Он очень большой, но немного растянут в эпоху больших данных. Во-вторых, применение кластерной технологии.Фронтенд обеспечивается несколькими серверами для обеспечения вычислительной мощности, а бэкэнд — общим хранилищем, то есть вводом-выводом. Из архитектуры видно, что на самом деле это параллельный диск, как только возникнет узкое место ввода-вывода, проблемы возникнут и у всего кластера приложений, поэтому такая архитектура также не подходит для хранилищ данных. Третий — Oracle Exadata, который широко используется на торговых платформах, но редко используется в хранилищах данных. Кроме того, с точки зрения визуализации Oracle BIEE также сложно идти в ногу со временем.
Подводя итог, можно сказать, что хотя традиционная технология хранилища данных не полностью устарела, она постепенно сходит со сцены.
Когда у нас есть массивные данные, нам приходится сталкиваться с проблемой выбора хранилища данных, такого как Oracle, DB2, экосистема PG или экосистема Hadoop. Исходя из вышеупомянутого Oracle и DB2 должны быть исключены, если выбор между PG и Hadoop является экосистемой PG, будет два варианта: PostgreSQL и Greenplum. Выбор для системы онлайн-транзакций, безусловно, PostgreSQL, а для реального хранилища данных следует выбрать Greenplum.
Гринплам Архитектура
Greenplum — это кластер, состоящий из нескольких узлов управления (главных) и нескольких узлов данных (узлов сегмента).
Причина выбора Greenplum заключается в его высокой производительности.
Высокая производительность в первую очередь отражается на распределении больших таблиц.Greenplum равномерно распределяет данные большой таблицы на несколько узлов, закладывая основу для параллельного выполнения (параллельных вычислений). Во-вторых, параллельное выполнение.Параллельное выполнение Greenplum может быть параллельной загрузкой данных из внешней таблицы, параллельным запросом, параллельным созданием и использованием индекса, параллельным сбором статистики, параллельным сопоставлением таблиц и так далее. Третий момент — хранение по столбцам и сжатие данных. Если обычный запрос извлекает только несколько полей в таблице, режим столбца более эффективен. Например, если запросу нужно получить большое количество полей в таблице, строка режим более эффективен.
Второй причиной выбора Greenplum является высокая зрелость продукта. Как упоминалось ранее, Greenplum состоит из нескольких узлов, каждый из которых представляет собой PostgreSQL. PostgreSQL начал исследования и разработки в 1986 году, разработал первую версию в 1987 году и представил ее в 1988 году. Можно сказать, что после стольких лет разработки PG является очень зрелым продуктом.
Третья причина — механизм аварийного восстановления: у Greenplum может быть две мастер-ноды, когда одна из них выйдет из строя, другая продолжит получать доступ, а каталоги и журналы транзакций двух нод будут синхронизироваться в режиме реального времени.
Четвертая причина — линейное расширение.Greenplum использует общую архитектуру параллельной обработки MPP.Добавление узлов к архитектуре MPP может линейно увеличить емкость хранилища и вычислительную мощность системы. Greenplum прост в эксплуатации при масштабировании узлов, а перераспределение данных может быть выполнено за очень короткое время. Поддержка линейного расширения Greenplum обеспечивает техническую гарантию будущего расширения системы анализа данных, и пользователи могут расширять емкость и производительность в соответствии с потребностями внедрения.
Последняя причина — знакомая среда разработки: поскольку Greenplum основан на PostgreSQL, он мало чем отличается от PG по синтаксису, поэтому может позволить традиционным Java-разработчикам плавно перейти на Greenplum.
Знакомство с Hadoop
Greenplum легко справляется с традиционными SQL-запросами, но его явно недостаточно для машинного обучения.Хотя MADlib Greenplum поддерживает машинное обучение, реальные случаи встречаются редко. Поэтому необходимо внедрить экосистему Hadoop в EDW для удовлетворения потребностей машинного обучения.
На приведенном выше рисунке показана введенная экосистема Hadoop: уровень управления ресурсами использует Mesos и Yarm, уровень распределенного хранилища — HDPS, а уровень механизма обработки может выбирать между ядром MapReduce и Spark. Итак, если вы хотите заниматься машинным обучением, на самом деле есть два варианта: один — MapReduce плюс Mahout, а другой — ядро Spark плюс MLlib. Производительность MapReduce не так хороша, поэтому мы обычно предпочитаем второе решение.
Окончательные данные поступают в экосистему Hadoop через Greenplum, а затем выбирают место для их хранения в соответствии с возможностями разработки и приложениями. Источником данных для машинного обучения здесь стал Greenplum.Кроме того, после поступления данных в Hadoop по-прежнему можно выполнять запросы на основе SQL.
Еще один момент, который следует отметить, заключается в том, что результаты вычислений хранилища данных или платформы больших данных обычно хранятся в PG, поскольку возможности PG для обработки больших таблиц сильнее, чем у MySQL.
Суммировать
Наконец, мы рассматриваем всю архитектуру по очереди.Основной DV использует PG, EDW использует Greenplum и Hadoop, а уровень ODS лучше всего использовать PG.Это позволяет избежать слишком большого количества разнородных баз данных в проекте, а также это удобно для разработки разработчиками.