Поток потока кликов на веб-сайте + клиент 360 с использованием AWS Kinesis Firehose

Question

Мы пытаемся реализовать поток кликов в нашей электронной торговле на AWS. В поток кликов будут попадать все действия, совершаемые «анонимными» пользователями. Анонимные пользователи отслеживаются через UUID, сгенерированный во время их первого посещения, который сохраняется в cook ie. Мы использовали пример AWS здесь , чтобы предложить архитектуру решения, как на диаграмме ниже:

Now 2 questions :

1. Different pages in the e-commerce have different clickstream data. For example on the Item view page , we would like to send Item related info such as itemId as well. Or on Checkout page , we would like to have few order related info tied to the clickstream data. Should we have separate Firehose delivery streams for different pages to support custom clickstream data? Or we should send a generic clickstream record (with possible null values for some attributes) to a FH delivery stream?

2. At some point our anonymous users become identified (ex. they login so we know their User_ID) So we would like to link the {UUID and User_ID} to be able to have a customer 360 view. Should we consider a separate stream flow + separate S3 bucket for tracking UUID+ User_ID mappings? Should we then use Athena for showing aggregated reports for customer 360? Should we aggregate the data and create a customer dimension in the Redshift? What would be a good solution for this?

Regards, Lina

[Update]: Is the following diagram an acceptable solution for the question? введите описание изображения здесь

Answer 1

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

Чтобы иметь возможность надежно сделать это, вам придется использовать несколько потоков Kinesis.

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

Отказ от ответственности: личное мнение: я бы посоветовал вам переместить это в Kinesis Firehose, чтобы у вас была возможность начать загрузку данных в Redhift с минимальными изменениями процесса на более позднем этапе, в то же время также создавая резервную копию данных в S3 для холодного хранение / резервное копирование. Учитывая объем, Athena может быть не лучшим выбором для выполнения аналитических запросов к данным. Вы можете использовать внешние таблицы Redhift, в которых данные по-прежнему находятся на S3. Что касается стоимости самого экземпляра красного смещения, теперь вы можете приостановить кластер. Прочтите объявление здесь .

Чтобы обратиться к обновленной схеме архитектуры, которую вы добавили, вы можете полностью пропустить Glue. Kinesis может напрямую загружать данные в S3, и вы можете определять внешние таблицы с помощью спектра RedShift.

Общий подход заключается в загрузке данных в Redshift, а также их резервном копировании на S3. Затем на Redshift вы можете периодически удалять старые данные (скажем, больше года go). Это уравновешивает стоимость и производительность, поскольку запрос будет более производительным для данных, лежащих в Redshift.

Что касается преобразований, вы можете напрямую использовать Lambdas с Kinesis Firehose. Подробнее об этом здесь .

Edit 1: добавлено мнение об использовании Redshift и почему это будет полезно и рентабельно

Edit 2: добавлены подробности об упрощении новая предлагаемая архитектура.