Комментарии 21
Спасибо. Статья супер.
Не дорого. Цены здесь: https://cloud.google.com/bigquery/pricing. Вы платите за хранение данных ($0.020 за GB, 10 GB бесплатно) и за обработку данных при анализе (5$ за TB, 1 TB в месяц бесплатно)
Вообще это очень дорого.
Такое хранилище нет смысла использовать под то что влазит на один сервер. Проще взять сервер и держать/считать на нем. Или s3, если надо подешевле и сгодится помедленнее.
Серверные диски сейчас ну около 10 терабайт. Минимальный рейд, но в сервер напихать побольше одного диска можно. Путь будет 50 терабайт на сервер без особых проблем.
Итого допустим вы хотите хранить что-то выходящее за пределы одного сервера. 100 терабайт.
Это будет стоить 2к баксов в месяц только за хранение.
Запрос перебирающий 1% данных обойдется вам 5 баксов. Каждый запрос. Небольшой, но не очень качественный, скрипт вас быстро разорит.
Спасибо за комментарий.
Не согласен - это очень доступно по ценам!
В статье я привел реальный пример из практики: компания из среднего бизнеса объем данных для анализа 100 GB (транзакции из ERP и CRM систем), стоимость стоить $1.8 в месяц. Эта статья главным образом для них.
Вы привели пример: размер данных для анализа 100 терабайт, стоимость $ 2000 это дорого. Можете привести реальный пример.
Не много не сходиться логика. А именно: для среднего бизнеса да $ 2000 это дорого, но у них нет 100 терабайт данных.
А у тех у кого есть 100 терабайт транзакций у них наверняка есть $ 2000.
Ну т.е. что это за компания в вашем примере которая оперирует данными в 100 терабайт но для них $ 2000 это дорого?
по мне так тоже разорительно выйдет. я полагаю текст был для примера, в реальности то никто не будет выкачивать каждый раз все со всех источников. т.е. придется воротить инкрементную загрузку, наверняка не раз в день и с постройкой истории.
значит будет некая MERGE команда на bigquery, она явно будет читать все хранилище накручивая счетчик.
а если еще захочется разные витрины ... может выйти слишком дорого.
Можно прикинуть. Допустим мы загружаем данные в хранилище раз в час. И каждый раз когда грузим нам нужно сделать проверку по каким то ключам.
Важно: BQ при запросах считает только те данные которые он извлекает для запроса. Например у вас лежит таблица: ID + еще 9 полей. Делаем проверку по ID. Google будет считать объем данных только тех полей которые мы пропишем в запросе для проверки - в нашем случае только ID.
Возьмем общий объем базы 100GB, информация в полях с ключами по которым будем проверять и делать MERGE допустим 10GB.
10GB * 24 часа * 30 дней = 7,2 TB = $36 = 2 600 руб
А зачем туда грузить и крутить 100гб?
Они отлично влезут прямо в оперативку сервера. И их там можно будет крутить любым софтом прямо в риалтайме.
Реальный пример это когда не удаётся все запихать в один типовой сервер. Строить распределенные хранилища правда сложно. До этого уровня у вас обычная БД, обрабатываемая на обычном сервере. Я взял границу по 100тб, возможно оне немного ниже. Пусть в два раза, не на порядок точно. 10тб это один диск.
2000 долларов, конечно, найдётся. И 5 долларов на запрос найдётся. Тут уже все для себя сами считают что выгоднее. И БигТейблс выгоднее оказываются очень редко. По крайней мере по тем кейса которые я видел.
А сколько стоит купить сервер с оперативкой 100 гб?
Случайный конфигуратор говорит про аренду 27.000 в месяц https://www.reg.ru/dedicated/configurator
Не менее случайный магазин говорит про 200-500к купить https://www.depo.ru/catalog/servery/depo-storm-1000/server-depo-storm-1450v2/
Нынче 100 гигабайт оперативки для серверов это начальный уровень. Массовые идут по 512 гигабайт памяти.
Если вести такой расчет, то для точности надо учесть (1) количество дисков на своем сервере надо умножить в два-три раза, если данные важны (Гугл все реплицирует для надежности, но стоимость берет за логические байты, а не физические копии), (2) стоимость 100 терабайт в BigQuery надо делить на два - они по большей части будут long-term storage (старее 90 дней), (3) для своего сервера надо включить стоимость админа, электричества на машину и охлаждение.
Но согласен, даже учтя все это, если интерактивных запросов в компании нет, а только batch и скрипты - собственное решение может оказаться дешевле. Но BigQuery не столько для этого, сколько для интерактивной работы.
В нашем 100тб случае, запрос перебирающий 1% данных на выделенном сервере прочитает 1тб данных, и займет, если оптимистично, час (а если надо сделать какой-нибудь join, то пиши - пропало). Все это время аналитик будет пить смузи и ждать результата. В BigQuery типичный запрос читающий 1тб займет полминуты, так что аналитик даже не успеет прочитать почту. Причем аналитиков может быть много и они даже могут работать в одно и то же время, не сильно мешая друг другу. Имхо, сэкономленное время с лихвой окупит потраченные 5 долларов.
Конечно. Запихать 20 типовых дисков можно много куда. Это не очень дорого по серверным меркам. Это будет 100тб рейд10. Стоит около миллиона на круг.
Купив железо вы тратите капекс . Понятный и предсказуемый. В БигТейблс у вас опекс. Достаточно непредсказуемый. Развитой бизнес капекс любит больше.
Вы очень недооцениваете скорость работы выделенных серверов. Там все заметно быстрее чем вам кажется.
Аналитики имеют привычку свои разово написанные запросы превращать в скрипты и дашборды. И они крутятся регулярно.
Я очень люблю облака и контейнеры. Это правда удобно. БигТейблс архитектурно прекрасен. Но с их схемой оплаты надо очень хорошо понимать во что это в концов выйдет. С учётом оплаты избавления от вендор лока. Они несовместимы ни с чем.
Выделенные сервера бывают вполне быстрые. Только чтобы сделать их быстрыми нужно не мало экспертизы и людей, дорого выходит. Многим выгоднее аутсорсить это Google / Amazon / Snowflake и подобным.
И для небольшой компании (Фейсбук, Яндекс и подобные исключаем) будет основная проблема - загрузить эти выделенные сервера. Выбор у них будет между
1) небольшим числом серверов, которые они более-менее загрузят, но не обеспечат желаемую производительность, аналитики так же будут в основном пить смузи после каждого интерактивного запроса, и
2) большим числом серверов, которые дадут нужную производительность, но будут большую часть времени простаивать и стоить гораздо больше облака.
И в такой ситуации для интерактивной аналитики облачный датаварехауз, где платишь только за то что используешь, чаще всего оказывается дешевле. Те кто умеют считать все расходы, мигрируют и жутко довольны.
Это действительно так, со стороны маркетинговой информации все выглядит дешевым, а как только начинаешь использовать, то сразу понимаешь глубину кроличьей норы.
Проблема, как обычно, в альтернативах. Если не хочется вкладываться в свою и нфарструктуру, то можно использовать aws Athena, но выходит не особо дешевле, просто инструментов повлиять на стоимость больше. А самому presto развернуть тоже не скоро окупится из-за вложений в девопс (если вообще окупится).
Можно использовать всякие промежуточные сервисы для оптимизации запросов и данных, но это требует дополнительных вложений и времени.
Так что, на самом деле, альтернатив не так и много. Все плачут и кушают кактус.
>Так же вы можете использовать в BigQuery ML TensorFlow.
А вот и специалист по TensorFlow и машинному обучению вдруг откуда-то взялся…
В общем, описано решение как решение, вероятно ничем не хуже других при определенных условиях, но описанным в начале условиям местами текст очевидно противоречит.
Чтобы запустить Spark, кстати, Hadoop не нужен. И линукс знать тоже в общем не нужно — не сильно больше уровня обычного пользователя. И airflow в описанной ситуации тоже не требуется. Да и кафка не нужно, судя по описанию задач.
Поэтому сравнение вашего решения с предложенным вами изначально стеком некорректно — от него нужно оставить только спарк, и все будет сравнимо по сложности (или пандас, например). А изучить что-то все равно придется, так или иначе. И вы необходимость такого изучения явно преуменьшаете в пользу описанного решения.
Спасибо за комментарий.
Важный момент: в чем принципиальное отличие BigQuery от Oracle например? Быстрый запуск и доступное использование. В этом вся суть.
В статье я показываю как можно начать использование решение практически в течении часа. Теперь представьте что вы решили развернуть Oracle в компании - это кoординально отличается.
C точки зрения инженера по данным возможно различия не так сильны. Попробуйте думать как владелец бизнеса или руководитель ИТ. Что такое Oracle: железо, лицензии, администратор - это нужно спланировать и купить. Что такое BigQuery - готовое решение. Можно сразу начинать использование без вложений.
Понятно. спасибо за комментарий. Тут видите в чем плюс у BigQuery. Ест простой API. И есть библиотека BigQuery API Client Libraries для языков Go, Java, Node.js, Python, Ruby, PHP, C#.
Вы можете дать доступ командам разработки разных продуктов к своему BigQuery и сказать: ребята - вот вам простое API, такие то данные пишите сюда. Вот вам уже и основа ETL.
Плюс много готовых интеграций где вы загрузку можете на поток парой кнопок настроить.
Теперь возьмем пример с Hadoop. Туда нужно загружать в каждый час информацию по событиям на веб сайте. Как это быстро и просто решить?
Ну, обычно чем шире это используется — тем проще. Если это API распространен также как спарк — то в общем да, вы найдете людей, которые будут писать. Спарк ведь тоже несложный, пока вы не начинаете терабайты молотить, и вам не нужно это делать за фиксированное небольшое время.
>Как это быстро и просто решить?
В общем случае — никак. Ну т.е. я не знаю инструмента для интеграции, который был бы идеален и универсален. У нас такое решают через Ni-Fi, но когда я на него смотрю, по сравнению с известным мне Camel, он мне совсем не нравится.
В смысле — если вы знаете, что у вас будут такие-то и такие-то интеграции (и больше никаких), то вы можете выбрать решение заранее. Если же нет — то велики шансы, что рано или поздно вам все равно придется поставить и изучить ту же кафку.
Заметьте — я не говорю что вы не правы в своем решении. Я говорю, что в общем случае хрен тут угадаешь, что будет через пару лет.
Я думаю автор имел в виду, что порог вхождения в SQL гораздо ниже, чем порог вхождения в OLAP. Научиться писать SQL запросы гораздо проще, чем научиться строить OLAP систему.
Ну т.е., ETL в задаче вроде нужен — речь же не о больших данных, вроде бы все почти в Excel влезает. А кто этот ETL писать будет, в то что на Google Cloud он сам по себе заработает как-то, я, извините, не очень верю. Хотя и не исключаю, что в каких-то случаях может.
Вышла хорошая статья как использовать BigQuery для решения задачи анализа данных из облачных бизнес систем - https://habr.com/ru/post/684418/
Строим аналитическое хранилище данных с готовыми модулями ML на Google BigQuery: просто, быстро, доступно