Comments 7
В качестве аппаратной платформы закупили сервера Oracle Big Data Appliance. Начинали с шести узлов в продуктивном контуре с 2x24-core CPU и 256 ГБ памяти на каждом. Текущая конфигурация содержит 18 таких же узлов с расширенной до 512 ГБ памятью.
Сейчас в Data Lake находится порядка 100 Тб данных из розничного хранилища плюс около 50 Тб из ряда OLTP-источников.
Интересно было бы взглянуть на тесты производительности, т.к. объем данных вызывает улыбку на фоне доступных ресурсов
Задача хранилища данных не сводится к накоплению максимального их объема. Нужно еще максимизировать конкурентность и производительность пользовательских и ELT-запросов, надежность системы и при этом минимизировать стоимость владения. Также можно уточнить, что в Hadoop данные можно хранить с использованием компрессии (например, Snappy). Если имеющиеся у нас в DRP данные представить в виде CSV без компрессии, то их объем был бы около 900 Тб. Без учета этих факторов хранилища на классических MPP тоже могут показаться недостаточно большими, хотя они и будут обеспечивать хорошую производительность. На текущий момент, вы абсолютно правы, у нас действительно серьезные задел по производительности.
Спасибо!
Управление проектами стандартный РМ или аджайл?
Управление проектами стандартный РМ или аджайл?
Как-то у вас про импалу уж очень оптимистично все. Неужели например на issues.apache.org/jira/browse/IMPALA-3316 не натыкались? (да, исправили, да, через два года всего-навсего ;)
У нас как-то почти не видно таких, что был бы в особом восторге — во-первых, несовместимо, то есть к несовместимостям скажем Spark и Hive добавляются лишние проблемы между Hive и Impala. Во-вторых, со сложными типами (array, struct и map) все тоже как-то как минимум неудобно — а при отсутствии индексов де-факто эти типы и денормализация местами наше все.
>Данные в Impala доступны через Hue, Spark
Это вы что имели в виду, когда говорили про Spark? У импалы разве есть какие-то «свои» данные, с которыми может работать Spark?
У нас как-то почти не видно таких, что был бы в особом восторге — во-первых, несовместимо, то есть к несовместимостям скажем Spark и Hive добавляются лишние проблемы между Hive и Impala. Во-вторых, со сложными типами (array, struct и map) все тоже как-то как минимум неудобно — а при отсутствии индексов де-факто эти типы и денормализация местами наше все.
>Данные в Impala доступны через Hue, Spark
Это вы что имели в виду, когда говорили про Spark? У импалы разве есть какие-то «свои» данные, с которыми может работать Spark?
1) Да, мы знаем про ограничения использования TIMESTAMP и поэтому используем представление даты-времени в STRING, как это указано в статье. Сама проблема заключается в том, что если писать в Parquet поля TIMESTAMP с помощью Hive, а потом читать Impala, то может возникнуть серьезное замедление запроса.
Но это не наш случай, так как мы не используем Hive.
2) Мы стараемся выбирать способы использования, для которых совместимость и работоспособность гарантируется. Практически во всех СУБД и особенно MPP-СУБД есть свои ограничения и вопрос только в том, умеет ли DWH-команда находить приемлемые способы борьбы с ними. Мы — нашли. Ну и задачи DWH пока не потребовали у нас хранения сложных типов данных — мы обходимся простыми.
С точки зрения производительности отсутствие индексов не сильно влияет на нас из-за наличия runtime bloom-фильтров в Impala. Также для нас важна не производительность на единичных запросах, а в условиях их конкурентности и ad hoc + ELT нагрузки. По нашим замерам, Impala не уступает в этом профиле нагрузки классическим MPP.
OLTP-like нагрузка это немного другой профиль и он тоже может быть интересен. Тут есть несколько решений: во-первых, первичные ключи в Kudu отчасти похожи на индексы и для ряда приложений мы исследуем возможность хранения данных в Kudu; во-вторых мы ждем реализации доработок Impala, которые также должны увеличить производительность для немассовых выборок данных (https://blog.cloudera.com/blog/2017/12/faster-performance-for-selective-queries/ и issues.apache.org/jira/browse/IMPALA-3430)
3) Имелось в виду обращение Spark к данным в HDFS через схемы Hive Metastore, который использует и Impala. Impala не имеет «своих» данных (если опустить оговорку про Kudu) и является SQL-движком для параллельного выполнения на кластере.
Но это не наш случай, так как мы не используем Hive.
2) Мы стараемся выбирать способы использования, для которых совместимость и работоспособность гарантируется. Практически во всех СУБД и особенно MPP-СУБД есть свои ограничения и вопрос только в том, умеет ли DWH-команда находить приемлемые способы борьбы с ними. Мы — нашли. Ну и задачи DWH пока не потребовали у нас хранения сложных типов данных — мы обходимся простыми.
С точки зрения производительности отсутствие индексов не сильно влияет на нас из-за наличия runtime bloom-фильтров в Impala. Также для нас важна не производительность на единичных запросах, а в условиях их конкурентности и ad hoc + ELT нагрузки. По нашим замерам, Impala не уступает в этом профиле нагрузки классическим MPP.
OLTP-like нагрузка это немного другой профиль и он тоже может быть интересен. Тут есть несколько решений: во-первых, первичные ключи в Kudu отчасти похожи на индексы и для ряда приложений мы исследуем возможность хранения данных в Kudu; во-вторых мы ждем реализации доработок Impala, которые также должны увеличить производительность для немассовых выборок данных (https://blog.cloudera.com/blog/2017/12/faster-performance-for-selective-queries/ и issues.apache.org/jira/browse/IMPALA-3430)
3) Имелось в виду обращение Spark к данным в HDFS через схемы Hive Metastore, который использует и Impala. Impala не имеет «своих» данных (если опустить оговорку про Kudu) и является SQL-движком для параллельного выполнения на кластере.
- Toad for hadoop более не доступен, его лицензия была не совсем free.
- Два года назад банк в котором использовалось данное решение назывался немного по другому.
Sign up to leave a comment.
Из нагруженной MPP СУБД — бодрый Data Lake с аналитическими инструментами: делимся подробностями создания