Аналитика больших данных может стоить больших денег.

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

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

Проблема силоса данных

Если у вас есть проблема с силосом данных, и это относительно легко понять, - тогда пришло время столкнуться с фактами: ваша организация тратит слишком много денег на анализ, который не добавляет достаточной ценности. Это потому, что он почти наверняка основан на неполных наборах данных.

Фактически, тенденции и приложения в базе данных говорят о том, что плохое качество данных снижает производительность на 20 процентов и препятствует достижению 40 процентов бизнес-инициатив. Недавнее исследование Gartner показало, что низкое качество данных стоит предприятиям 15 миллионов долларов в год.

Помимо этого, у вас также есть тонна скрытых расходов:

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

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

Для начала запустите анализ TCO

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

Первое, что вам нужно сделать, - провести анализ совокупной стоимости владения - начальные капитальные затраты (CapEx), суммированные с операционными расходами (OpEx) - как для текущей, так и для предлагаемой системы.

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

Таким образом, в то время как облачные пользователи получают регулярный счет, они не шокированы гигантскими первоначальными инвестициями. Google Cloud Platform и Microsoft Azure даже выпустили собственные калькуляторы затрат, чтобы довести этот момент до ума.

Бизнес-кейс можно разбить следующим образом:

• Большие расходы по CapEx, связанные с системой on-prem, могут занять значительные средства в других областях организации
• Ежемесячный OpEx, оплачиваемый в качестве абонентской платы, намного проще в корпоративном кошельке, что дает большую свободу организациям
• Если производительность или затраты не соответствуют стандарту, облачные пользователи всегда могут отказаться

Но здесь возникает вопрос: если облако - это путь к оптимизации затрат, как оптимизировать затраты дальше внутри самого облака - особенно для целей аналитики?

Оптимизация затрат на обработку в облаке

Независимо от того, используете ли вы Google Cloud Platform или Microsoft Azure или AWS, оптимизация затрат на облачную аналитику, по сути, сводится к двум вещам: оптимизации затрат на обработку данных и оптимизации затрат на хранение данных.

Хорошим первым шагом является просмотр текущих преобразований данных вне хранилища данных. Это может показаться противоречивым, но после проглатывания и интеграции всех ваших данных в хранилище данных более эффективно извлекать эти данные и обрабатывать их как нечто вроде Apache Spark - структуры, которая в сочетании с Dataproc Google может быть на 30% более рентабельной, чем аналогичные альтернативы. Это минимизирует затраты на обработку облачного хранилища данных.

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

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

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

Оптимизация затрат на хранение в облаке

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

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

• AVRO вместо JSON: вместо хранения данных в виде файлов JSON разумно внедрять стандартное преобразование файлов в файлы AVRO, которые более эффективны по размеру
• Сжатие уравнивает сбережения. Аналогичным образом, сжатие всех ваших файлов данных в качестве процесса помогает снизить затраты на хранение
• Рассмотрите холодное хранение: облачные платформы, такие как Azure и GCP, предлагают варианты холодного хранения, такие как Azure Cool Blob и Google Closeline и Coldline, которые являются менее дорогими вариантами для хранения больших наборов данных и архивированной информации: при некоторых условиях хранение в холодном ярусе может равняться экономии до 50 процентов
• Оцените политику хранения данных: в идеальном мире вы сохраните все свои данные. Но если у вас есть так много, что даже хранение в холодном хранилище стоит дорого, вы всегда можете изменить свои политики хранения для удаления очень старых необработанных данных (у вас всегда есть возможность хранить сводные данные, что занимает меньше места для хранения).

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

За счет включения лучших облачных сервисов, программного обеспечение с открытым исходным кодом и автоматизированных процессов, платформа Pythian для облачных вычислений Kick AaaS имеет встроенные в нее средства контроля затрат. Она начинается с уровня инфраструктуры, который использует Spark на Kubernetes, что упрощает управление кластерами и повышает эффективность использования ресурсов для рабочих нагрузок Spark, позволяя вам разворачивать их вверх и вниз по мере необходимости. Kick AaaS также использует эффективные по размеру файлы Avro, сжатие файлов данных и максимально использует доступные функции контроля за облачными расходами, такие как холодное хранение и установление верхних пределов обработки данных для запросов. Платформа Kick AaaS, наряду с профессиональными сервисами Pythian, гарантирует, что ваши расходы на облачную аналитику всегда оптимизируются и контролируются.

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

No Comments