1. 引言：为什么选择MaxCompute分析网站用户访问数据

网站用户访问数据，是互联网企业最宝贵的资产之一。

每一笔用户请求都在服务器日志里留下了清晰的脚印。这里面藏着页面浏览量、独立访客数、用户来源、设备信息、行为路径等丰富内容。

吃透这些数据，企业就能精准把握用户喜好、优化产品功能、提升转化率，精细化运营也就有了抓手。

但问题也很明显：网站访问日志的数据量实在太大了。

一个日均PV百万级的中型网站，一天产生的原始日志能达到几十个GB。传统关系型数据库面对这种海量数据，往往力不从心。

而腾讯云MaxCompute，正是为这种场景量身打造的云原生大数据计算服务。它支持EB级数据存储，提供标准SQL分析能力，按量付费模式使成本更可控。

更重要的是，它能和WeData数据开发平台无缝衔接，一站式搞定数据集成、开发、运维调度的全流程。

接下来，我们将以一个完整的网站用户访问数据分析项目为例，从零开始，手把手带你走一遍利用MaxCompute + WeData完成数据集成、数仓建模、指标计算、性能优化和可视化展示的完整链路。

2. 环境准备与数据集成

2.1 开通MaxCompute与WeData

开工前，首先需要开通MaxCompute和WeData并创建好项目。

简单来说，MaxCompute是计算引擎，WeData是开发运维平台，两者经常协同工作。

开通MaxCompute时，推荐选择离业务数据源近的地域，规格类型选标准计算资源。如果是首次使用，按量付费是不错的选择，用多少付多少，无需提前购买资源。

开通后，需要新建MaxCompute项目。建议按照开发和生产环境隔离的标准做法，分别创建两个项目。例如：生产环境叫workshop_prod，开发环境叫workshop_dev。数据类型建议选2.0数据类型，能获得更丰富的SQL类型支持。

WeData这边，需要创建一个标准模式的工作空间，再购买一个Serverless资源组，用于运行数据同步和任务调度。

2.2 数据集成：将网站日志同步至MaxCompute

网站访问日志通常有两种存在形式：一种是直接写入日志文件，存在云服务器或对象存储COS里；另一种是通过日志服务CLS实时采集。

无论哪种形式，WeData的数据集成模块都提供了成熟的同步方案。

场景一：从COS同步日志文件

如果日志文件存在COS里，可以通过WeData的离线同步节点，将它们同步到MaxCompute的ODS原始日志表。

同步时需要注意以下几点：

• 源端COS文件：确认好格式和字段分隔符。
• 目标端MaxCompute表：建议按日期分区，方便后续按天查询和管理。
• 同步任务：可以配置成每天定时运行，实现日志的T+1分析。

场景二：从日志服务CLS实时同步

如果网站已经接入CLS进行日志采集，可以通过CLS的投递功能，直接将日志数据投递到MaxCompute。

在CLS控制台配置投递任务，选好目标MaxCompute项目和表，就能实现日志从采集到存储的无缝流转，省心省力。

场景三：通过DataHub实时接入

对于需要实时接入的场景，DataHub服务可以帮忙。DataHub的DataConnector支持将Topic中的数据实时或准实时同步到MaxCompute、COS、ElasticSearch等多种云产品。

2.3 建表：定义数据模型

数据同步前，需要在MaxCompute里先把目标表建好。

下面是一张典型的网站访问日志ODS表建表语句：

CREATE TABLE IF NOT EXISTS ods_raw_log_d (
nip STRING COMMENT '客户端IP地址',
nts BIGINT COMMENT '访问时间戳',
nmethod STRING COMMENT '请求方法 GET/POST',
nurl STRING COMMENT '请求URL',
nstatus BIGINT COMMENT 'HTTP状态码',
nbytes BIGINT COMMENT '响应字节数',
nreferer STRING COMMENT '来源页面',
nuser_agent STRING COMMENT '用户袋里字符串',
ncookie_id STRING COMMENT 'Cookie标识',
nsession_id STRING COMMENT '会话ID'
n) PARTITIONED BY (dt STRING COMMENT '日期分区 yyyyMMdd');

分区字段dt用于按天组织数据，既能提升查询效率，也方便数据生命周期管理。

3. 数仓分层建模

网站用户访问数据分析，通常遵循经典的四层数仓建模架构：ODS（操作数据存储层）、DWD（明细数据仓库层）、DWS（汇总数据仓库层）和ADS（应用数据层）。

3.1 ODS层：原始日志表

ODS层是数据仓库的源头，存放从业务系统直接同步过来的原始数据，不做任何清洗和转换。

上面创建的ods_raw_log_d表就属于这层。ODS层数据与源系统保持一致，保留了最完整的日志明细，方便后续数据回溯和问题排查。

3.2 DWD层：明细数据仓库表

DWD层需要对ODS层的原始数据进行清洗、标准化和维度退化处理。

主要操作包括：

• 过滤掉无效数据
• 解析User-Agent获取设备类型和浏览器信息
• 解析IP获取地域信息
• 将时间戳转为可读的日期时间格式

以下是ODS层数据加工到DWD层的SQL示例：

INSERT OVERWRITE TABLE dwd_access_log_d PARTITION (dt = '${bizdate}')
SELECT
nip,
nFROM_UNIXTIME(ts) AS access_time,
nmethod,
nurl,
nstatus,
nbytes,
nreferer,
nuser_agent,
nGET_JSON_OBJECT(user_agent, '$.device_type') AS device_type,
nGET_JSON_OBJECT(user_agent, '$.browser') AS browser,
nSUBSTR(ip, 1, INSTR(ip, '.') - 1) AS ip_segment,
n-- 使用MaxCompute内置函数或UDF解析IP地域
nip_to_region(ip) AS region,
ncookie_id,
nsession_id,
n-- 提取URL中的页面路径
nREGEXP_EXTRACT(url, '^(https://[^/]+)([^]+)', 2) AS page_path
nFROM ods_raw_log_d
nWHERE dt = '${bizdate}'
nAND status < 500  -- 过滤服务端错误
nAND url IS NOT NULL
nAND LENGTH(TRIM(url)) > 0;

经过DWD层加工，数据从“脏乱差”的原始日志，变成了结构清晰、字段规范的明细数据，为后续汇总分析打下坚实基础。

3.3 DWS层：汇总数据仓库表

DWS层是在DWD层基础上，按分析主题进行预聚合的轻度汇总层。

这一层通常按天、小时等粒度，对用户、页面、地域等维度进行聚合计算，能显著提升查询性能。

下面是一张按天和页面汇总的DWS表建表语句：

CREATE TABLE IF NOT EXISTS dws_page_stat_d (
npage_path STRING COMMENT '页面路径',
npv BIGINT COMMENT '页面浏览量',
nuv BIGINT COMMENT '独立访客数',
na vg_response_time DOUBLE COMMENT '平均响应时间',
ntotal_bytes BIGINT COMMENT '总流量字节数'
n) PARTITIONED BY (dt STRING COMMENT '日期分区');

3.4 ADS层：应用数据层

ADS层直接面向具体应用场景，为报表、仪表盘和数据分析师提供数据服务。

这一层的数据通常已完成多维度聚合和计算，查询响应速度很快。例如面向运营报表的每日核心指标汇总表、面向用户画像的标签宽表等，都属于这一层。

4. 核心分析场景与SQL实现

4.1 PV和UV统计

PV和UV是衡量网站流量的两项最基础指标。PV统计页面被访问的总次数，UV统计访问网站的不重复用户数。

按天统计全站PV和UV：

SELECT
ndt,
nCOUNT(*) AS pv,
nCOUNT(DISTINCT cookie_id) AS uv
nFROM dwd_access_log_d
nWHERE dt BETWEEN '20260101' AND '20260131'
nGROUP BY dt
nORDER BY dt;

按页面路径统计PV和UV：

SELECT
npage_path,
nCOUNT(*) AS pv,
nCOUNT(DISTINCT cookie_id) AS uv
nFROM dwd_access_log_d
nWHERE dt = '20260115'
nGROUP BY page_path
nORDER BY pv DESC
nLIMIT 20;

按终端类型分别统计：

SELECT
ndevice_type,
nCOUNT(*) AS pv,
nCOUNT(DISTINCT cookie_id) AS uv
nFROM dwd_access_log_d
nWHERE dt = '20260115'
nGROUP BY device_type;

4.2 漏斗转化分析

漏斗模型通过产品各项数据的转化率来判断产品运营情况。

通过各阶段数据的转化，能看出产品在哪个环节出了问题。以电商网站为例，典型的用户转化路径是：浏览首页 → 搜索商品 → 查看详情 → 加入购物车 → 提交订单 → 支付成功。

下面是一个漏斗分析的SQL实现：

WITH funnel_data AS (
nSELECT
ncookie_id,
nsession_id,
ndt,
n-- 定义各阶段的触发条件
nMAX(CASE WHEN page_path = '/index' THEN 1 ELSE 0 END) AS step1_home,
nMAX(CASE WHEN page_path LIKE '/search/%' THEN 1 ELSE 0 END) AS step2_search,
nMAX(CASE WHEN page_path LIKE '/product/%' THEN 1 ELSE 0 END) AS step3_detail,
nMAX(CASE WHEN page_path = '/cart' THEN 1 ELSE 0 END) AS step4_cart,
nMAX(CASE WHEN page_path = '/checkout' THEN 1 ELSE 0 END) AS step5_checkout,
nMAX(CASE WHEN page_path = '/pay/success' THEN 1 ELSE 0 END) AS step6_pay
nFROM dwd_access_log_d
nWHERE dt = '20260115'
nAND session_id IS NOT NULL
nGROUP BY cookie_id, session_id, dt
n)
SELECT
nCOUNT(DISTINCT CASE WHEN step1_home = 1 THEN cookie_id END) AS step1_users,
nCOUNT(DISTINCT CASE WHEN step2_search = 1 THEN cookie_id END) AS step2_users,
nCOUNT(DISTINCT CASE WHEN step3_detail = 1 THEN cookie_id END) AS step3_users,
nCOUNT(DISTINCT CASE WHEN step4_cart = 1 THEN cookie_id END) AS step4_users,
nCOUNT(DISTINCT CASE WHEN step5_checkout = 1 THEN cookie_id END) AS step5_users,
nCOUNT(DISTINCT CASE WHEN step6_pay = 1 THEN cookie_id END) AS step6_users,
n-- 计算转化率
nROUND(COUNT(DISTINCT CASE WHEN step2_search = 1 THEN cookie_id END) * 100.0 /
nNULLIF(COUNT(DISTINCT CASE WHEN step1_home = 1 THEN cookie_id END), 0), 2) AS rate1_2,
nROUND(COUNT(DISTINCT CASE WHEN step3_detail = 1 THEN cookie_id END) * 100.0 /
nNULLIF(COUNT(DISTINCT CASE WHEN step2_search = 1 THEN cookie_id END), 0), 2) AS rate2_3,
nROUND(COUNT(DISTINCT CASE WHEN step4_cart = 1 THEN cookie_id END) * 100.0 /
nNULLIF(COUNT(DISTINCT CASE WHEN step3_detail = 1 THEN cookie_id END), 0), 2) AS rate3_4,
nROUND(COUNT(DISTINCT CASE WHEN step5_checkout = 1 THEN cookie_id END) * 100.0 /
nNULLIF(COUNT(DISTINCT CASE WHEN step4_cart = 1 THEN cookie_id END), 0), 2) AS rate4_5,
nROUND(COUNT(DISTINCT CASE WHEN step6_pay = 1 THEN cookie_id END) * 100.0 /
nNULLIF(COUNT(DISTINCT CASE WHEN step5_checkout = 1 THEN cookie_id END), 0), 2) AS rate5_6
nFROM funnel_data;

通过漏斗分析，运营团队可以清晰看到用户在哪个环节流失最严重，从而有针对性地进行优化。

4.3 用户留存计算

用户留存是衡量产品用户粘性的关键指标。日留存、周留存和月留存是三种最常用的留存计算方式。

计算次日留存率：

WITH first_visit AS (
nSELECT
ncookie_id,
nMIN(dt) AS first_dt
nFROM dwd_access_log_d
nWHERE dt BETWEEN '20260101' AND '20260131'
nGROUP BY cookie_id
n),
nreturn_visit AS (
nSELECT DISTINCT
ncookie_id,
ndt
nFROM dwd_access_log_d
nWHERE dt BETWEEN '20260101' AND '20260207'
n)
SELECT
nf.first_dt,
nCOUNT(DISTINCT f.cookie_id) AS new_users,
nCOUNT(DISTINCT r.cookie_id) AS retained_users,
nROUND(COUNT(DISTINCT r.cookie_id) * 100.0 /
nNULLIF(COUNT(DISTINCT f.cookie_id), 0), 2) AS retention_rate
nFROM first_visit f
nLEFT JOIN return_visit r
nON f.cookie_id = r.cookie_id
nAND r.dt = DATE_ADD(f.first_dt, 1)
nGROUP BY f.first_dt
nORDER BY f.first_dt;

4.4 地域分布分析

了解用户的地域分布，有助于制定区域化的运营策略和资源配置。

通过在DWD层解析IP地址获取地域信息，就能轻松实现地域维度的分析。

SELECT
nregion,
nCOUNT(*) AS pv,
nCOUNT(DISTINCT cookie_id) AS uv,
nCOUNT(DISTINCT session_id) AS sessions
nFROM dwd_access_log_d
nWHERE dt = '20260115'
nAND region IS NOT NULL
nGROUP BY region
nORDER BY uv DESC
nLIMIT 20;

4.5 用户画像标签开发

用户画像是基于用户历史行为数据构建的用户特征集合。

下面是一个简单的用户标签开发示例，计算用户的访问频次、偏好页面类型和活跃时段：

CREATE TABLE IF NOT EXISTS ads_user_profile_d AS
SELECT
ncookie_id,
nCOUNT(*) AS total_visits,
nCOUNT(DISTINCT dt) AS active_days,
n-- 偏好页面类型：出现次数最多的页面一级分类
nMAX(page_category) AS preferred_category,
n-- 活跃时段：访问次数最多的时段
nMAX(hour_slot) AS active_hour,
n-- 设备偏好
nMAX(device_type) AS preferred_device,
n-- 最近访问时间
nMAX(access_time) AS last_visit_time
nFROM (
nSELECT
ncookie_id,
ndt,
naccess_time,
nSPLIT(page_path, '/')[1] AS page_category,
ndevice_type,
nCONCAT(CAST(HOUR(access_time) AS STRING), ':00-',
n        CAST(HOUR(access_time) + 1 AS STRING), ':00') AS hour_slot,
nROW_NUMBER() OVER (PARTITION BY cookie_id, page_path ORDER BY access_time DESC) AS rn
nFROM dwd_access_log_d
nWHERE dt BETWEEN '20260101' AND '20260131'
n) t
nWHERE rn = 1
nGROUP BY cookie_id;

5. 性能优化最佳实践

5.1 分区设计优化

合理设计分区，是MaxCompute性能优化的第一原则。

对于网站访问日志，最常用的分区策略是按日期分区。但如果日志量特别大，还可以考虑二级分区，比如按日期+小时分区，能进一步提升查询效率。

不过要注意，分区列取值不均匀可能会导致数据倾斜。如果发现某个分区的数据量远大于其他分区，可以考虑调整分区粒度，比如从按天分区改成按小时分区，或者增加随机分桶来平衡数据分布。

5.2 数据倾斜调优

数据倾斜是大数据计算中最常见的性能问题之一，表现为某些Reducer处理的数据量远大于其他Reducer，导致整体任务执行时间被拖长。

常见的数据倾斜场景与解决方案：

• Group By倾斜： 当某个分组键的值分布极不均匀时（比如某个热门页面的访问量占比极高），可以在Group By之前先进行随机打散，或者使用参数set odps.sql.groupby.skewindata=true;开启倾斜优化。
• Join倾斜： 当大表和小表Join时，可以使用Map Join提示/*+ MAPJOIN(small_table) */将小表加载到内存中，避免Shuffle阶段的数据倾斜。
• Distinct Count倾斜： 对于COUNT(DISTINCT)操作，如果去重字段的基数很高且分布不均，可以使用approx_distinct近似函数替代精确去重，或者分两步计算。

5.3 长周期指标计算优化

计算近30天、近90天的累计指标时，如果每次都是从明细表里重新算，性能开销会非常大。

优化思路是构建中间汇总表。

举个例子，计算商品近30天的访客数，可以每天构建一个cookie_id粒度的日汇总表，然后基于日汇总表计算30天的累计去重，而不是每次都去扫描30天的明细数据：

-- 日汇总表：每天每个cookie_id的访问汇总
CREATE TABLE IF NOT EXISTS dws_user_daily_summary_d (
ncookie_id STRING,
npage_count BIGINT,
nsession_count BIGINT,
ntotal_bytes BIGINT
n) PARTITIONED BY (dt STRING);

-- 基于日汇总表计算近30天累计UV
SELECT
nCOUNT(DISTINCT cookie_id) AS uv_30d
nFROM dws_user_daily_summary_d
nWHERE dt >= DATE_ADD(CURRENT_DATE(), -30)
nAND dt <= CURRENT_DATE();

5.4 SQL查询优化技巧

• 先过滤后关联： 在Join操作前，先通过子查询或CTE对数据进行过滤，减少参与Join的数据量。
• 避免全表扫描： 始终在WHERE条件中使用分区字段进行裁剪。
• 合理使用索引： 对于频繁查询的字段，可以考虑创建聚簇索引或使用Clustering Key优化。
• 使用CUBE/ROLLUP： 对于多维度汇总需求，使用GROUP BY CUBE或ROLLUP可以一次计算多个维度的组合汇总，减少重复扫描。

6. 调度配置与数据质量监控

6.1 WeData调度配置

WeData提供了完善的调度能力，支持分钟、小时、天、周、月等多种调度周期。

在网站访问数据分析场景中，典型的调度配置如下：

• ODS层同步任务： 每天凌晨1点执行，从COS或CLS同步前一天的日志数据。
• DWD层加工任务： 每天凌晨2点执行，依赖ODS层任务完成。
• DWS层汇总任务： 每天凌晨3点执行，依赖DWD层任务完成。
• ADS层报表任务： 每天凌晨4点执行，依赖DWS层任务完成。

通过配置任务间的上下游依赖关系，可以确保数据按照正确的顺序流转。同时，WeData支持设置任务的生效时间范围，超过有效期后任务将不再自动调度。

6.2 数据质量监控

数据质量是数据分析的生命线。在WeData中，可以通过配置数据质量规则来监控数据的完整性、准确性和及时性：

• 完整性检查： 检查ODS层数据是否完整同步，比如对比源端记录数和目标端记录数。
• 一致性检查： 检查DWD层加工后的关键字段是否存在空值或异常值。
• 趋势监控： 监控每日PV、UV等核心指标的环比变化，发现异常波动时及时告警。

7. 可视化展示

完成数据计算后，需要通过可视化的方式把分析结果呈现给业务人员。

MaxCompute可以和多种BI工具无缝集成：

• Quick BI： 腾讯云自研的BI工具，支持直接连接MaxCompute数据源，拖拽式生成报表和仪表盘。
• DataV： 适用于大屏展示场景，支持丰富的可视化组件。
• 第三方BI工具： 通过JDBC/ODBC接口，MaxCompute可以和Tableau、Power BI等主流BI工具对接。

典型的网站运营仪表盘可以包含以下图表：每日PV/UV趋势图、TOP页面排行榜、用户地域分布地图、漏斗转化图、用户留存曲线等。

8. 成本优化策略

8.1 存储成本优化

MaxCompute的存储费用按实际存储量计费。为控制存储成本，可以采取以下措施：

• 生命周期管理： 为ODS层和DWD层的明细表设置生命周期，比如保留最近90天的数据，超过90天的历史数据自动删除或归档到低频存储。
• 数据压缩： MaxCompute默认对数据进行列式存储和压缩，但在建表时可以指定更高效的压缩算法。
• 合理分层： 把明细数据存在ODS/DWD层，汇总数据存在DWS/ADS层，避免在DWS/ADS层存大量明细数据。

8.2 计算成本优化

MaxCompute的计算费用按实际使用的计算资源量计费。优化计算成本的核心思路是减少不必要的计算：

• 分区裁剪： 在查询时始终用分区字段进行过滤，避免全表扫描。
• 列裁剪： 只SELECT需要的字段，避免SELECT *。
• 预聚合： 在DWS层进行充分的预聚合，减少ADS层查询时的计算量。
• 错峰调度： 把计算密集型任务安排在业务低峰期执行，利用闲时计算资源。

8.3 内网免流量

如果网站日志存在COS，而MaxCompute和COS在同一个地域，数据读取走内网通道可以免收流量费用。

在配置数据同步任务时，务必确认数据源和目标端在同一地域。

9. 总结

这篇文章系统地讲解了如何利用腾讯云MaxCompute对网站用户访问数据进行全链路分析。

从环境准备、数据集成、数仓分层建模，到PV/UV统计、漏斗转化分析、用户留存计算、地域分布分析等核心分析场景，再到数据倾斜调优、长周期指标优化、分区设计等性能最佳实践，以及调度配置、数据质量监控、可视化展示和成本优化，形成了一套完整可落地的技术方案。

通过MaxCompute + WeData的组合，数据开发工程师和数据分析师可以快速搭建起企业级的网站用户行为分析平台，把海量的日志数据转化为驱动业务决策的数据洞察。

常见问题解答

问1：MaxCompute和传统数据库有什么区别？

答：MaxCompute是云原生的大数据计算服务，专为海量数据场景设计，支持EB级数据存储和PB级数据计算。与传统数据库相比，MaxCompute采用分布式架构，计算和存储分离，支持按量付费的弹性计费模式，适合处理TB级别以上的网站访问日志数据。

问2：网站访问日志数据量很大，同步到MaxCompute需要多长时间？

答：同步时间取决于数据量大小和网络带宽。对于日均数十GB的日志数据，使用WeData的离线同步功能通常在1-2小时内可以完成同步。如果使用CLS直接投递到MaxCompute，可以实现准实时同步，延迟在分钟级别。

问3：MaxCompute的SQL和标准SQL有什么差异？

答：MaxCompute SQL兼容大部分标准SQL语法，但也有一些差异。例如，MaxCompute不支持事务操作、不支持UPDATE和DELETE（可通过INSERT OVERWRITE实现数据更新）、对某些函数的行为可能与标准SQL略有不同。建议在开发前仔细阅读MaxCompute SQL官方文档。

问4：如何处理数据倾斜问题？

答：数据倾斜的常见解决方案包括：开启倾斜优化参数set odps.sql.groupby.skewindata=true;、使用Map Join优化小表与大表的关联、对倾斜键进行加盐打散后二次聚合、合理设计分区键避免数据分布不均等。具体采用哪种方案需要根据实际的倾斜场景来判断。

问5：网站访问日志分析一般需要保留多长时间的数据？

答：这取决于业务需求。通常，ODS层的原始日志建议保留30-90天，以便进行问题回溯和数据校验；DWD层的明细数据建议保留90-180天；DWS层的汇总数据可以根据需要保留更长时间（如1-3年），用于长期趋势分析。可以通过配置表的生命周期来自动管理数据的保留和清理。

问6：MaxCompute的费用构成是怎样的？如何控制成本？

答：MaxCompute的费用主要包括存储费用和计算费用两部分。存储费用按实际存储量计费，计算费用按实际使用的计算资源量计费。控制成本的核心方法包括：合理设计分区和生命周期管理、在查询时进行分区裁剪和列裁剪、在DWS层进行充分的预聚合减少重复计算、将计算任务安排在业务低峰期执行等。