О чем эта статья

Всем привет! Меня зовут Сергей Коньков — я архитектор данных в компании BR Systems. Когда есть возможность, я посещаю различные конференции по анализу данных, машинному обучению и разработке. Однажды мне пришла в голову мысль, что часто на сцене этих конференций мы видим представителей одних и тех же компаний из ТОП 5 крупнейших банков или ритейлеров страны. Они рассказывают очень интересные кейсы, как кластеры из десятков серверов обрабатывают терабайты данных, как тысячи сотрудников корпорации используют результаты этого анализа. А в зале сидят и слушают их айтишники из среднего бизнеса, для которых насущные проблемы, это выбить бюджет на дополнительны диски и память для единственного SQL сервера.

Тут же на этих конференциях нам предлагают записаться на курсы дата инженеров и аналитиков. Средний бизнес отправляют туда сотрудника и там преподаватель (иногда тот же сотрудник суперкорпорации) объясняет, что для того что бы работать с данными нужно на хорошем уровне знать Linux, Hadoop, Spark, Kafka, Airflow. Это так называемый классический стек технологий для работы с bigdata.

Как быть если у вас в ИТ отделе всего 5 человек и один из них отвечает за данные в нагрузку к прочей работе? Ему нужно достать данные из 1С, CRM, Google Analytics, соединить это все вместе и быстро построить отчетность, а завтра уже будет новые источники из новой производственной системы. И все это каждый день меняется. Он знает SQL, иногда Python и где в 1С найти данные. И у него нет времени на изучение Spark. Да даже у тех у кого в ИТ службе 50 человек проблематично иметь в штате инженера данных который знает все эти технологии.

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

Разбираемся в задачах

Итак мы компания среднего бизнеса. Торгуем оптом строительными материалами. Что у нас есть:

  • ERP система в компании (например: 1С или Axapta)

  • CRM система (Amo CRM или Bitrix 24)

  • Облачная система для учета товаров которая используется в одном из филиалов (Мой склад)

  • Интернет магазин написанный на PHP с подключенным Google Analytics

Что нам нужно: строить консолидированную отчетность на основании данных их всех этих источников.

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

Что хотим получить

Примерно это:

Хотим загружать данные из разных источников в одну базу (хранилище данных) и строить на основании него отчеты. И все это желательно автоматически.

Многие компании используют технологию OLAP, как правило от Microsoft. Продукт SQL Server Analysis Services включен во все версии MS SQL Server, начиная со Standard и является отличной технологией для решения данной задачи. Однако если вы разворачиваете OLAP в компании вам нужен специалист который в нем хорошо разбирается, а это не так просто. И зачастую этот специалист становиться бутылочным горлышком в процессе создания отчетности.

Мы рассмотрим альтернативу OLAP и вышеупомянутому классическому стеку для работы с bigdata - Google BigQuery и посмотрим какие плюсы можно извлечь из этого.

Google BigQuery (BQ)

Что это?

Это база данных, она находится в облаке Google, точнее в Google Cloud Platform. Она поддерживает язык SQL для работы с данными. Эту технологию Google сделал специально для анализа данных. Архитектура и движок этой базы отличается от привычных MS SQL и MySQL. Колоночное хранение данных и ряд других особенностей делают все расчеты очень быстрыми. Например можно посчитать сумму продаж из розничной сети используя таблицу из 10 миллионов чеков за пару секунд.

Как все это работает?

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

Сколько это стоит?

Не дорого. Цены здесь: https://cloud.google.com/bigquery/pricing. Вы платите за хранение данных ($0.020 за GB, 10 GB бесплатно) и за обработку данных при анализе (5$ за TB, 1 TB в месяц бесплатно). Пример: вы загрузили в BQ данные объемом 10 GB и ваши аналитики делают SQL запросы к ним. Допустим за один запрос они обрабатывают в среднем 1 GB данных (это объем данных в таблиц который нужно обработать что бы получить результат. Ваши аналитики за месяц сделали 1000 запросов (в сумме 1 TB данных). В итоге использование BQ в этом месяце будет для вам бесплатным - вы уложились в лимиты на бесплатное использование.

Допустим вы загрузили 100 GB данных, тогда их хранение будет стоить $1.8 в месяц. Аналитики пусть сделали 1000 запросов по 10 GB, обработка будет вам стоить $45 в месяц.

Тестируем BigQuery шаг за шагом

Регистрация

Для начала нам нужна учетная запись в Google. Если у вас есть почта на gmail, то она у вас есть. Если нет, заведите: https://accounts.google.com.

Далее подключаем BigQuery. Есть два способа:

  • Обычный платежный аккаунт Google Cloud Platform

  • Песочница - для тех кто не хочет пока оставлять в Google Cloud данные своей банковской карты и хочет бесплатно протестировать систему

Платежный аккаунт подключаем по этой ссылке https://console.cloud.google.com/billing. Нужна будет банковская карта. Если вы впервые используете Google Cloud Platform вам будет предоставлен бесплатный пробный период 90 дней на использование ряда сервисов, в том числе и BigQuery в размере $300.

Если карту оставлять пока не хотите создаем песочницу. Переходим по ссылке https://console.cloud.google.com/bigquery, выбираем страну и подтверждаем условия. Все, среда создана, можно начинать работу.

Создаем проект, датасет

Данные в BigQuery хранятся в таблицах, таблицы находятся в датасетах, датасеты в проектах. На уровне проектов можно разграничивать доступ к данным. Например если у вас несколько независимых бизнесов, то для каждого можно сделать в проект. А внутри проекта сделать несколько датасетов по направлениям анализа, например датасет Производство и датасет Розница. На каждом уровне можно управлять правами доступа к объектам.

Создадим проект habrtest:

Нажмите три точки справа от названия проект и выберете опцию Create dataset, создайте датасет habrdata:

Загрузка данных в таблицу

  • Скачайте архив с тестовыми данными: https://www.ssa.gov/OACT/babynames/names.zip

  • Разархивируйте его у себя на пк

  • Нажмите три точки справа от названия датасета и выберите опцию Open

  • В открывшемся окне нажмите копку Create table

  • В настройках Source для Create table from, выберете Upload.

  • Для Select file, нажмите Browse, и выберете файл yob2014.txt из ранее разархивированной папке.

  • Для File format, выберете CSV.

  • В настройках Destination, для Table name, введите names_2014.

  • В настройках Schema, выберете Edit as text и введите этот код:

name:string,gender:string,count:integer
  • Нажмите Create table

  • Подождите пока BigQuery загрузит данные

  • В панели навигации нажмите созданную таблицу и в открывшемся окне выберете вкладку Preview что бы посмотреть загруженные нами данные:

Запросы к данным

  • Нажмите Compose new query и в открывшемся редакторе введите этот код:

SELECT
  name,
  count
FROM
  `habrdata.names_2014`
WHERE
  gender = 'M'
ORDER BY
  count DESC
LIMIT
  5
  • нажмите Run, отобразятся результаты запроса

Строим отчет

  • Сверху от результатов запроса нажмите Explore data

  • Дайте приложению Google Data Studio доступ к данным

  • В открывшемся дизайнере отчетов выберите тип диаграммы Кольцевая и в показатели добавьте поле count. Затем нажмите кнопку Сохранить

Выводы

Мы рассмотрели как за 10 минут зарегистрироваться в BigQuery, загрузить туда данные и построить отчет. Если вас заинтересовала эта технология - продолжайте читать. В следующей главе мы рассмотрим практические шаги по развертыванию BigQuery в компании.

Разворачиваем BigQuery в компании

Переходим на платный аккаунт

Ранее в примерах мы использовали режим песочницы. Часть функций в этом режиме не доступна. Например мы не можем выполнить sql инструкции Insert или Delete. Рекомендуем подключить платежный аккаунт. Напомню: вам будет предоставлен кредит на $300 и 90 дней для полноценного тестирования облачной платформы Google. Для начала перейдите по этой ссылке и следуйте инструкциям https://console.cloud.google.com/freetrial/signup.

Читаем литературу и документацию

Проектируем таблицы в хранилище

Информацию об этом вы найдете в книге. Если вы ранее создавали витрины данных для аналитиков, вы можете следовать тем же принципам. Для тех у кого мало опыта в этом читайте книжку. Построение таблиц в хранилище данных отличается от обычных схем-снежинок, так например иногда данные могут храниться в ненормализованном виде. Например информация о заказе покупателя (дата, имя клиента, адрес клиента) и информация о строчках заказов (товар, количество, сумма): в 90% случаях эти данные используются в одном запросе и есть смысл хранить их в одной таблице, повторяя данные о клиенте в каждой строчкой с товаром. Таким образом можно увеличить быстродействие запросов к данным.

Загружаем данные

Так выглядят основные пути загрузки данных по рекомендациям Google:

Дадим краткие пояснения по ним:

  • Можно загружать CSV и JSON файл с помощью консоли, как мы делали выше

  • Есть множество готовых интеграций c BigQuery для различных сервисов, например Google Analytics, и их становится все больше. Например мы в нашей компании разработали за последний год интеграции с BigQuery для нескольких российских облачных сервисов

  • Есть мощный ETL инструмент от Google - Cloud Data Fusion. Но он не дешевый.

  • Есть клиентская библиотека Google Cloud Client Library для BigQuery. Сейчас она доступна для семи языков: Go, Java, Node.js, Python, Ruby, PHP и C++. Вот пример загрузки данных с помощью Python из MS SQL Server в BigQuery:

from sqlalchemy import create_engine
from pandas import DataFrame
from google.cloud import bigquery
import pandas
import pytz

# подключаемся к MS SQL
engine = create_engine("mssql+pyodbc://(localdb)\MSSQLLocalDB/habrtest?driver= \
                       ODBC Driver 17 for SQL Server",
                       fast_executemany=True)
connection = engine.connect()

# подключаемся к BigQuery с помощью сервисного аккаунта
client = bigquery.Client.from_service_account_json('habrtest.json')
# определяем таблицу в BigQuery для загрузки данных
table_id = "habrtest.habrdata.tb2"

# запрос к  MS SQL для выборки данных
resoverall = connection.execute('select * from Test')
df = DataFrame(resoverall.fetchall())
df.columns = resoverall.keys()

# отправляем данные в BigQuery
job = client.load_table_from_dataframe(df, table_id)  
job.result() 

Данный код будет работать только для платного аккаунта BigQuery (в песочнице не будет).

В целом по загрузке данных такие рекомендации: используйте где можно готовые интеграции, в остальных случаях стройте свои интеграционные процессы используя Google Cloud Client Library. Разработчики которые поддерживают информационные системы в вашей компании могут загружать данные с помощью Cloud Client Library в указанные вами таблицы с необходимой периодичностью.

Настраиваем безопасность

В Google Clooud Platform механизм управления идентификацией и доступом (Identity and Access Management, IAM). Он позволяет разграничить доступ к данным: https://console.cloud.google.com/iam-admin. Вы можете дать доступ к данным для учетной записи @gmail.com или @example.com, где example.com — это домен G Suite. Например таким образом вы можете дать вашим аналитикам доступ для анализа данных.

Так же вы можете создавать сервисные аккаунты: https://console.cloud.google.com/iam-admin/serviceaccounts для доступа приложений. Например вы можете создать тестовый аккаунт для ваших разработчиков 1С, передать им ключ доступа (JSON файл), а они используя этот ключ смогут загружать данные в BigQuery.

Уровень доступа определяется ролями. Ниже представлены эти роли, в порядке увеличения прав:

  1. metadataViewer (полное имя roles/bigquery.metadataViewer) предоставляет доступ только к метаданным наборов данных, таблиц и представлений.

  2. dataViewer предоставляет право читать данные и метаданные.

  3. dataEditor предоставляет право читать наборы данных, а также перечислять, создавать, изменять, читать и удалять таблицы в наборе данных.

  4. dataOwner добавляет возможность удалить набор данных.

  5. readSessionUser предоставляет доступ к BigQuery Storage API, оплачиваемый за счет проекта.

  6. jobUser позволяет запускать задания (и выполнять запросы), оплачиваемые за счет проекта.

  7. user позволяет запускать задания и создавать наборы данных, хранение которых оплачивается за счет проекта.

  8. admin позволяет управлять всеми данными в проекте и отменять задания, запущенные другими пользователями.

Работаем с данными

Данные загрузили, права раздали, значит можно извлекать из данных пользу. Вот основные возможности:

  • Делаем SQL запросы в консоли BigQuery. Документация по синтаксису запросов - https://cloud.google.com/bigquery/docs/reference/standard-sql а так же в книжке.

  • Работаем с BiqQuery в ноутбуках на Python. Пример кода для выборки данных из ранее созданной нами таблицы

from google.colab import auth
auth.authenticate_user()
print('Authenticated')

%load_ext google.colab.data_table

%%bigquery --project yourprojectid
SELECT * FROM `habrtest.habrdata.names_2014` LIMIT 1000
  • Используем BI инструменты: Google DataStudio, MS Power BI, Tableau. У этих трех, и у многих других есть встроенные коннекторы к BigQuery

Источники данных Power BI
Источники данных Power BI

Ускоряем запросы с помощью BI Engine

Если есть таблицы, к которым вы часто обращаетесь из инструментов бизнес-аналитики, такие как информационные панели с агрегатами и фильтрами, для ускорения запросов можно воспользоваться движком BI Engine. Он автоматически сохраняет соответствующие фрагменты данных в памяти и использует специализированный процессор запросов. С помощью консоли администратора BigQuery Admin Console можно зарезервировать объем памяти (до 10 Гбайт), который BigQuery должна использовать для своего кеша: https://console.cloud.google.com/bigquery/admin/bi-engine. BI Engine платный: 1GB памяти будет стоить примерно $30 в месяц. Для пользователей Google DataStudio этот объем будет бесплатным. Здесь видео о том что такое BI Engine: https://youtu.be/kifUXfwqzVo

Подключаем модули машинного обучения

Модули BigQuery ML позволяют пользователям создавать и выполнять модели машинного обучения в BigQuery, используя стандартные запросы SQL.

Пример создания модели рекомендаций основании публичного набора данных о просмотре фильмов:

CREATE OR REPLACE MODEL ch09eu.movie_recommender_16
options(model_type='matrix_factorization',
user_col='userId', item_col='movieId',
rating_col='rating', l2_reg=0.2, num_factors=16)
AS
SELECT
userId, movieId, rating
FROM ch09eu.movielens_ratings

Получаем данные из модели, найдем лучшие комедийные фильмы, которые можно рекомендовать пользователю с идентификатором (userId) 903:

SELECT * FROM
ML.PREDICT(MODEL ch09eu.movie_recommender_16, (
SELECT
movieId, title, 903 AS userId
FROM ch09eu.movielens_movies, UNNEST(genres) g
WHERE g = 'Comedy'
))
ORDER BY predicted_rating DESC
LIMIT 5

Вот список типов задач машинного обучения, которые можно решать с помощью BigQuery ML:

  • Кластеризация

  • Регрессия

  • Рекомендации

  • Таргетинг клиентов (Выбор целевой аудитории для предложения продукта)

  • Бинарная классификация

  • Многоклассовая классификация

  • Классификация изображений, классификация текста, анализ эмоциональной окраски, извлечение сущностей

  • Ответы на вопросы, аннотирование текста, генерирование подписей к изображениям

Так же вы можете использовать в BigQuery ML TensorFlow.

За использование BigQuery ML взымается отдельная плата. Информация по ценам здесь.

Заключение

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

Комментарии (20)


  1. Vyacheslav_N
    05.08.2021 22:27

    Спасибо. Статья супер.


    1. mongohtotech Автор
      05.08.2021 22:29

      спасибо!


  1. BugM
    06.08.2021 01:31

    Не дорого. Цены здесь: https://cloud.google.com/bigquery/pricing. Вы платите за хранение данных ($0.020 за GB, 10 GB бесплатно) и за обработку данных при анализе (5$ за TB, 1 TB в месяц бесплатно)

    Вообще это очень дорого.

    Такое хранилище нет смысла использовать под то что влазит на один сервер. Проще взять сервер и держать/считать на нем. Или s3, если надо подешевле и сгодится помедленнее.

    Серверные диски сейчас ну около 10 терабайт. Минимальный рейд, но в сервер напихать побольше одного диска можно. Путь будет 50 терабайт на сервер без особых проблем.

    Итого допустим вы хотите хранить что-то выходящее за пределы одного сервера. 100 терабайт.

    Это будет стоить 2к баксов в месяц только за хранение.

    Запрос перебирающий 1% данных обойдется вам 5 баксов. Каждый запрос. Небольшой, но не очень качественный, скрипт вас быстро разорит.


    1. mongohtotech Автор
      06.08.2021 10:57

      Спасибо за комментарий.

      Не согласен - это очень доступно по ценам!

      В статье я привел реальный пример из практики: компания из среднего бизнеса объем данных для анализа 100 GB (транзакции из ERP и CRM систем), стоимость стоить $1.8 в месяц. Эта статья главным образом для них.

      Вы привели пример: размер данных для анализа 100 терабайт, стоимость $ 2000 это дорого. Можете привести реальный пример.

      Не много не сходиться логика. А именно: для среднего бизнеса да $ 2000 это дорого, но у них нет 100 терабайт данных.

      А у тех у кого есть 100 терабайт транзакций у них наверняка есть $ 2000.

      Ну т.е. что это за компания в вашем примере которая оперирует данными в 100 терабайт но для них $ 2000 это дорого?


      1. Yo1
        06.08.2021 14:09

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

        значит будет некая MERGE команда на bigquery, она явно будет читать все хранилище накручивая счетчик.

        а если еще захочется разные витрины ... может выйти слишком дорого.


        1. mongohtotech Автор
          06.08.2021 19:40

          Можно прикинуть. Допустим мы загружаем данные в хранилище раз в час. И каждый раз когда грузим нам нужно сделать проверку по каким то ключам.

          Важно: BQ при запросах считает только те данные которые он извлекает для запроса. Например у вас лежит таблица: ID + еще 9 полей. Делаем проверку по ID. Google будет считать объем данных только тех полей которые мы пропишем в запросе для проверки - в нашем случае только ID.

          Возьмем общий объем базы 100GB, информация в полях с ключами по которым будем проверять и делать MERGE допустим 10GB.

          10GB * 24 часа * 30 дней = 7,2 TB = $36 = 2 600 руб


      1. BugM
        06.08.2021 22:28

        А зачем туда грузить и крутить 100гб?

        Они отлично влезут прямо в оперативку сервера. И их там можно будет крутить любым софтом прямо в риалтайме.

        Реальный пример это когда не удаётся все запихать в один типовой сервер. Строить распределенные хранилища правда сложно. До этого уровня у вас обычная БД, обрабатываемая на обычном сервере. Я взял границу по 100тб, возможно оне немного ниже. Пусть в два раза, не на порядок точно. 10тб это один диск.

        2000 долларов, конечно, найдётся. И 5 долларов на запрос найдётся. Тут уже все для себя сами считают что выгоднее. И БигТейблс выгоднее оказываются очень редко. По крайней мере по тем кейса которые я видел.


        1. mongohtotech Автор
          07.08.2021 15:49

          А сколько стоит купить сервер с оперативкой 100 гб?


          1. BugM
            07.08.2021 16:17

            Случайный конфигуратор говорит про аренду 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. mentin
      06.08.2021 11:46
      +2

      Если вести такой расчет, то для точности надо учесть (1) количество дисков на своем сервере надо умножить в два-три раза, если данные важны (Гугл все реплицирует для надежности, но стоимость берет за логические байты, а не физические копии), (2) стоимость 100 терабайт в BigQuery надо делить на два - они по большей части будут long-term storage (старее 90 дней), (3) для своего сервера надо включить стоимость админа, электричества на машину и охлаждение.

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

      В нашем 100тб случае, запрос перебирающий 1% данных на выделенном сервере прочитает 1тб данных, и займет, если оптимистично, час (а если надо сделать какой-нибудь join, то пиши - пропало). Все это время аналитик будет пить смузи и ждать результата. В BigQuery типичный запрос читающий 1тб займет полминуты, так что аналитик даже не успеет прочитать почту. Причем аналитиков может быть много и они даже могут работать в одно и то же время, не сильно мешая друг другу. Имхо, сэкономленное время с лихвой окупит потраченные 5 долларов.


      1. BugM
        06.08.2021 22:38

        Конечно. Запихать 20 типовых дисков можно много куда. Это не очень дорого по серверным меркам. Это будет 100тб рейд10. Стоит около миллиона на круг.

        Купив железо вы тратите капекс . Понятный и предсказуемый. В БигТейблс у вас опекс. Достаточно непредсказуемый. Развитой бизнес капекс любит больше.

        Вы очень недооцениваете скорость работы выделенных серверов. Там все заметно быстрее чем вам кажется.

        Аналитики имеют привычку свои разово написанные запросы превращать в скрипты и дашборды. И они крутятся регулярно.

        Я очень люблю облака и контейнеры. Это правда удобно. БигТейблс архитектурно прекрасен. Но с их схемой оплаты надо очень хорошо понимать во что это в концов выйдет. С учётом оплаты избавления от вендор лока. Они несовместимы ни с чем.


        1. mentin
          09.08.2021 10:32
          +1

          Выделенные сервера бывают вполне быстрые. Только чтобы сделать их быстрыми нужно не мало экспертизы и людей, дорого выходит. Многим выгоднее аутсорсить это Google / Amazon / Snowflake и подобным.

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

          1) небольшим числом серверов, которые они более-менее загрузят, но не обеспечат желаемую производительность, аналитики так же будут в основном пить смузи после каждого интерактивного запроса, и

          2) большим числом серверов, которые дадут нужную производительность, но будут большую часть времени простаивать и стоить гораздо больше облака.

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


    1. shalomman
      06.08.2021 14:42

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


      Проблема, как обычно, в альтернативах. Если не хочется вкладываться в свою и нфарструктуру, то можно использовать aws Athena, но выходит не особо дешевле, просто инструментов повлиять на стоимость больше. А самому presto развернуть тоже не скоро окупится из-за вложений в девопс (если вообще окупится).


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


      Так что, на самом деле, альтернатив не так и много. Все плачут и кушают кактус.


  1. sshikov
    06.08.2021 07:16

    То у вас нет специалистов, и вы не можете развернуть OLAP на базе решения от MS (подставить сюда Оракл, или тот же Spark). А в Google Cloud вдруг почему-то начнет работать все само, и без специалиста?

    >Так же вы можете использовать в BigQuery ML TensorFlow.
    А вот и специалист по TensorFlow и машинному обучению вдруг откуда-то взялся…

    В общем, описано решение как решение, вероятно ничем не хуже других при определенных условиях, но описанным в начале условиям местами текст очевидно противоречит.

    Чтобы запустить Spark, кстати, Hadoop не нужен. И линукс знать тоже в общем не нужно — не сильно больше уровня обычного пользователя. И airflow в описанной ситуации тоже не требуется. Да и кафка не нужно, судя по описанию задач.

    Поэтому сравнение вашего решения с предложенным вами изначально стеком некорректно — от него нужно оставить только спарк, и все будет сравнимо по сложности (или пандас, например). А изучить что-то все равно придется, так или иначе. И вы необходимость такого изучения явно преуменьшаете в пользу описанного решения.


    1. mongohtotech Автор
      06.08.2021 11:33
      +1

      Спасибо за комментарий.

      Важный момент: в чем принципиальное отличие BigQuery от Oracle например? Быстрый запуск и доступное использование. В этом вся суть.

      В статье я показываю как можно начать использование решение практически в течении часа. Теперь представьте что вы решили развернуть Oracle в компании - это кoординально отличается.

      C точки зрения инженера по данным возможно различия не так сильны. Попробуйте думать как владелец бизнеса или руководитель ИТ. Что такое Oracle: железо, лицензии, администратор - это нужно спланировать и купить. Что такое BigQuery - готовое решение. Можно сразу начинать использование без вложений.


      1. sshikov
        06.08.2021 17:44

        Я ответил чуть ниже на следующий комментарий. Речь ведь не только о том, чтобы развернуть, но и о том, чтобы потом писать ETL, делать ML, и прочее. Все это так или иначе придется изучить все равно, не на хадупе, так на BigQuery. Поэтому та часть, которая про отсутствие специалистов — ну она у вас не очень согласуется со всем остальным. Да, вы возможно быстрее запуститесь — но потом те же деньги потратите на что-то еще. С хадупом — возможно будет наоборот. Ну т.е. сравнение стеков стоило бы сделать более развернутым.


        1. mongohtotech Автор
          06.08.2021 19:55

          Понятно. спасибо за комментарий. Тут видите в чем плюс у BigQuery. Ест простой API. И есть библиотека BigQuery API Client Libraries для языков Go, Java, Node.js, Python, Ruby, PHP, C#.

          Вы можете дать доступ командам разработки разных продуктов к своему BigQuery и сказать: ребята - вот вам простое API, такие то данные пишите сюда. Вот вам уже и основа ETL.

          Плюс много готовых интеграций где вы загрузку можете на поток парой кнопок настроить.

          Теперь возьмем пример с Hadoop. Туда нужно загружать в каждый час информацию по событиям на веб сайте. Как это быстро и просто решить?


          1. sshikov
            06.08.2021 20:00
            +1

            >ребята — вот вам простое API
            Ну, обычно чем шире это используется — тем проще. Если это API распространен также как спарк — то в общем да, вы найдете людей, которые будут писать. Спарк ведь тоже несложный, пока вы не начинаете терабайты молотить, и вам не нужно это делать за фиксированное небольшое время.

            >Как это быстро и просто решить?
            В общем случае — никак. Ну т.е. я не знаю инструмента для интеграции, который был бы идеален и универсален. У нас такое решают через Ni-Fi, но когда я на него смотрю, по сравнению с известным мне Camel, он мне совсем не нравится.

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

            Заметьте — я не говорю что вы не правы в своем решении. Я говорю, что в общем случае хрен тут угадаешь, что будет через пару лет.


    1. mentin
      06.08.2021 11:54
      +1

      Я думаю автор имел в виду, что порог вхождения в SQL гораздо ниже, чем порог вхождения в OLAP. Научиться писать SQL запросы гораздо проще, чем научиться строить OLAP систему.


      1. sshikov
        06.08.2021 17:41

        Ну, возможно. Я не говорю что тут написана чепуха, я скорее говорю что сравнение двух инструментов несколько предвзято выглядит. Да, полноценный Hadoop со всем вот этим развернуть будет и дорого, и сложно — только из статьи выглядит так, что это не нужно (в авторской постановке задачи). Ну вот зачем тут кафка, для каких таких целей? Мне лично это осталось неясным.

        Ну т.е., ETL в задаче вроде нужен — речь же не о больших данных, вроде бы все почти в Excel влезает. А кто этот ETL писать будет, в то что на Google Cloud он сам по себе заработает как-то, я, извините, не очень верю. Хотя и не исключаю, что в каких-то случаях может.