阿里云MaxCompute网站用户访问数据分析从零到实战：完整技术指南

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

网站用户访问数据是互联网企业最核心的数据资产之一。每一笔用户请求都会在服务器日志中留下记录，这些日志蕴含着页面浏览量、独立访客数、用户来源地域、访问终端类型、用户行为路径等丰富信息。通过对这些数据的深度分析，企业可以精准把握用户偏好、优化产品功能、提升转化率，从而实现精细化运营。

然而，网站访问日志的数据量往往非常庞大——一个日均PV百万级的中型网站，一天产生的原始日志就可能达到数十GB。传统的关系型数据库难以承载如此规模的数据存储与计算，而阿里云MaxCompute正是为这种海量数据场景而生的云原生大数据计算服务。MaxCompute支持EB级数据存储、提供标准SQL分析能力、按量付费的弹性计费模式，并且与DataWorks数据开发平台无缝集成，能够一站式完成从数据集成、数据开发到运维调度的全流程工作。

本文将以一个完整的网站用户访问数据分析项目为载体，从零开始讲解如何利用MaxCompute加DataWorks完成数据集成、数仓建模、指标计算、性能优化和可视化展示的全链路操作。无论你是数据开发工程师还是数据分析师，都可以通过本文掌握一套可直接落地的方法论和代码模板。

需要先登录阿里云控制台，点击：阿里云控制台

2. 环境准备与数据集成

2.1 开通MaxCompute与DataWorks

在开始分析之前，首先需要完成MaxCompute和DataWorks的开通与项目创建。MaxCompute是计算引擎，DataWorks是数据开发与运维平台，两者通常配合使用。

开通MaxCompute时，推荐选择华东2（上海）地域，规格类型选择标准计算资源。首次使用可以选用按量付费模式，无需预购资源，用多少付多少。开通后，需要新建MaxCompute项目——建议按照开发和生产环境隔离的标准模式，分别创建两个项目，例如生产环境项目名为workshop_2026_prod，开发环境项目名为workshop_2026_dev。数据类型建议选择2.0数据类型，以获得更丰富的SQL类型支持。

DataWorks方面，需要创建一个标准模式的工作空间（开发与生产环境隔离），并购买Serverless资源组用于数据同步和任务调度。如果是在华东2（上海）地域首次开通DataWorks，系统会默认启用新版数据开发（Data Studio）。

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

网站访问日志通常以两种形式存在：一种是直接写入日志文件（如Nginx日志），存储在云服务器或对象存储OSS中；另一种是通过日志服务SLS实时采集。无论哪种形式，DataWorks数据集成模块都提供了成熟的同步方案。

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

如果网站日志以文件形式存储在OSS，可以通过DataWorks的离线同步节点，将OSS中的user_log.txt文件同步至MaxCompute的ods_raw_log_d_odps表。同步时需要注意：源端OSS文件需确认其格式（如CSV、TEXT）和字段分隔符；目标端MaxCompute表建议按日期分区（dt字段），便于后续按天查询和管理；同步任务可配置为每天定时执行，实现日志的T+1分析。

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

如果网站已接入日志服务SLS进行日志采集，则可以通过DataWorks的LogHub数据源配置实时同步任务，将SLS中的日志数据近乎实时地投递到MaxCompute。配置时需提供LogHub的Endpoint、Project名称以及AccessKey信息。实时同步适用于对数据时效性要求较高的场景，如实时大屏监控。

场景三：使用Tunnel命令上传

对于临时性或小批量数据，也可以使用MaxCompute提供的Tunnel命令行工具直接上传本地数据文件。这种方式适合开发测试阶段快速验证。

无论采用哪种同步方式，最终都需要在MaxCompute中构建两张核心的ODS层表：ods_raw_log_d_odps存储原始网站访问日志，每行一条记录；ods_user_info_d_odps存储用户基本信息（如用户ID、性别、年龄、星座等），通常来自业务数据库。

原始日志表的结构通常只有一个字段col（STRING类型），存储整行原始日志，以及分区字段dt（日期分区）。这种设计保留了最原始的数据，便于后续灵活解析。

3. 数仓分层建模与数据加工

3.1 数仓分层架构概述

网站用户访问数据分析遵循经典的数仓分层架构：ODS（操作数据存储层）→ DWD（明细数据层）→ DWS（汇总数据层）→ ADS（应用数据层）。每一层都有明确的职责：

• ODS层存储原始日志和原始业务数据，不做任何清洗和转换
• DWD层对ODS数据进行清洗、解析、标准化，将原始日志拆解为结构化字段
• DWS层基于DWD层进行多维度汇总，按用户、日期等维度预计算宽表
• ADS层面向具体应用场景（如用户画像、运营报表）的个性化数据产品

这种分层设计的核心价值在于：数据逐层收束、逻辑清晰可追溯、复用性高、便于排查问题。

3.2 DWD层：原始日志解析

ODS层的ods_raw_log_d_odps表存储的是整行原始日志，例如典型的Nginx combined格式：

192.168.1.1 - - [10/Dec/2026:08:30:15 +0800] 'GET /index.html HTTP/1.1' 200 2326 'https://www.example.com/' 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36'

DWD层的任务就是将这些非结构化的原始日志解析为结构化的字段。在DataWorks中创建一个ODPS SQL节点，执行以下逻辑：

CREATE TABLE IF NOT EXISTS dwd_log_info_di_odps (
    remote_addr STRING COMMENT '客户端IP',
    remote_user STRING COMMENT '远程用户',
    time_local STRING COMMENT '访问时间',
    request_method STRING COMMENT '请求方法',
    request_uri STRING COMMENT '请求URI',
    request_protocol STRING COMMENT '请求协议',
    status INT COMMENT 'HTTP状态码',
    body_bytes_sent BIGINT COMMENT '响应字节数',
    http_referer STRING COMMENT '来源页面',
    http_user_agent STRING COMMENT '用户代理',
    uid STRING COMMENT '用户ID（从日志中提取或关联）'
) PARTITIONED BY (dt STRING COMMENT '日期分区') STORED AS ALICLOUD_OSS;

INSERT OVERWRITE TABLE dwd_log_info_di_odps PARTITION (dt = '${bizdate}')
SELECT
    REGEXP_EXTRACT(col, '^(\\S+)', 1) AS remote_addr,
    REGEXP_EXTRACT(col, '^\\S+\\s+(\\S+)', 1) AS remote_user,
    REGEXP_EXTRACT(col, '\\[(.*?)\\]', 1) AS time_local,
    REGEXP_EXTRACT(col, ''(\\S+)\\s+(\\S+)\\s+(\\S+)'', 1) AS request_method,
    REGEXP_EXTRACT(col, ''\\S+\\s+(\\S+)\\s+\\S+'', 1) AS request_uri,
    REGEXP_EXTRACT(col, ''\\S+\\s+\\S+\\s+(\\S+)'', 1) AS request_protocol,
    CAST(REGEXP_EXTRACT(col, ''\\S+\\s+\\S+\\s+\\S+''\\s+(\\d+)', 1) AS INT) AS status,
    CAST(REGEXP_EXTRACT(col, ''\\S+\\s+\\S+\\s+\\S+''\\s+\\d+\\s+(\\d+)', 1) AS BIGINT) AS body_bytes_sent,
    REGEXP_EXTRACT(col, ''([^'']*)''\\s+''[^'']*''$', 1) AS http_referer,
    REGEXP_EXTRACT(col, ''[^'']*''\\s+''([^'']*)''$', 1) AS http_user_agent,
    NULL AS uid
FROM ods_raw_log_d_odps
WHERE dt = '${bizdate}';

上述SQL使用了MaxCompute的正则表达式函数REGEXP_EXTRACT，将原始日志中的IP、时间、请求方法、URI、状态码、Referer、User-Agent等关键信息逐一提取出来。其中${bizdate}是DataWorks调度参数，表示业务日期，在任务运行时会被自动替换。

3.3 DWS层：用户行为汇总宽表

DWD层虽然已经结构化，但仍然是明细级别的数据——每行代表一次页面请求。对于大多数分析场景（如用户画像、留存分析），我们需要以用户为粒度进行汇总。DWS层的任务就是将DWD明细数据与用户基本信息表关联，生成一张用户行为汇总宽表：

CREATE TABLE IF NOT EXISTS dws_user_info_all_di_odps (
    uid STRING COMMENT '用户ID',
    gender STRING COMMENT '性别',
    age_range STRING COMMENT '年龄段',
    zodiac STRING COMMENT '星座',
    pv_count BIGINT COMMENT '页面浏览量',
    visit_days INT COMMENT '访问天数',
    first_visit_time STRING COMMENT '首次访问时间',
    last_visit_time STRING COMMENT '最后访问时间',
    avg_response_bytes BIGINT COMMENT '平均响应字节数',
    terminal_type STRING COMMENT '终端类型'
) PARTITIONED BY (dt STRING COMMENT '日期分区') STORED AS ALICLOUD_OSS;

INSERT OVERWRITE TABLE dws_user_info_all_di_odps PARTITION (dt = '${bizdate}')
SELECT
    a.uid,
    b.gender,
    b.age_range,
    b.zodiac,
    COUNT(1) AS pv_count,
    COUNT(DISTINCT SUBSTR(a.time_local, 1, 10)) AS visit_days,
    MIN(a.time_local) AS first_visit_time,
    MAX(a.time_local) AS last_visit_time,
    AVG(a.body_bytes_sent) AS avg_response_bytes,
    CASE
        WHEN a.http_user_agent LIKE '%Android%' THEN 'Android'
        WHEN a.http_user_agent LIKE '%iPhone%' OR a.http_user_agent LIKE '%iPad%' THEN 'iOS'
        WHEN a.http_user_agent LIKE '%Windows%' OR a.http_user_agent LIKE '%Macintosh%' THEN 'PC'
        ELSE 'Other'
    END AS terminal_type
FROM dwd_log_info_di_odps a
LEFT JOIN ods_user_info_d_odps b ON a.uid = b.uid
WHERE a.dt = '${bizdate}'
GROUP BY
    a.uid,
    b.gender,
    b.age_range,
    b.zodiac,
    CASE
        WHEN a.http_user_agent LIKE '%Android%' THEN 'Android'
        WHEN a.http_user_agent LIKE '%iPhone%' OR a.http_user_agent LIKE '%iPad%' THEN 'iOS'
        WHEN a.http_user_agent LIKE '%Windows%' OR a.http_user_agent LIKE '%Macintosh%' THEN 'PC'
        ELSE 'Other'
    END;

这里通过CASE WHEN语句根据User-Agent判断用户终端类型，按用户维度汇总了PV数、访问天数、首次/最后访问时间、平均响应字节数等指标。

3.4 ADS层：用户画像数据产品

ADS层是面向具体业务场景的个性化数据产品。例如，如果运营团队需要一份包含用户地理属性、社会属性、行为偏好的用户画像表，可以在DWS层基础上进一步加工。通常ADS层的表结构更精简、字段更聚焦，直接服务于报表或API接口：

CREATE TABLE IF NOT EXISTS ads_user_info_1d_odps (
    uid STRING COMMENT '用户ID',
    gender STRING COMMENT '性别',
    age_range STRING COMMENT '年龄段',
    zodiac STRING COMMENT '星座',
    terminal_type STRING COMMENT '常用终端类型',
    pv_count BIGINT COMMENT '总PV',
    visit_days INT COMMENT '访问天数',
    avg_daily_pv DECIMAL(10,2) COMMENT '日均PV',
    user_level STRING COMMENT '用户等级（高/中/低活跃）'
) PARTITIONED BY (dt STRING COMMENT '日期分区') STORED AS ALICLOUD_OSS;

INSERT OVERWRITE TABLE ads_user_info_1d_odps PARTITION (dt = '${bizdate}')
SELECT
    uid,
    gender,
    age_range,
    zodiac,
    terminal_type,
    pv_count,
    visit_days,
    ROUND(pv_count / GREATEST(visit_days, 1), 2) AS avg_daily_pv,
    CASE
        WHEN pv_count >= 100 THEN '高活跃'
        WHEN pv_count >= 30 THEN '中活跃'
        ELSE '低活跃'
    END AS user_level
FROM dws_user_info_all_di_odps
WHERE dt = '${bizdate}';

至此，从原始日志到用户画像的完整数仓加工链路已经搭建完成。

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

4.1 PV（页面浏览量）与UV（独立访客数）统计

PV和UV是衡量网站流量的两项最基础、最重要的指标。PV（Page View）指页面浏览量，用户每打开一个页面记录一次PV，多次打开同一页面累计计算；UV（Unique Visitor）指独立访客数，一天内同一访客多次访问只计算一次。

基于DWD层明细数据，计算每日PV和UV的SQL如下：

SELECT
    dt,
    COUNT(1) AS pv,
    COUNT(DISTINCT uid) AS uv
FROM dwd_log_info_di_odps
WHERE dt BETWEEN '2026-06-01' AND '2026-06-07'
GROUP BY dt
ORDER BY dt;

如果需要按终端类型分别统计：

SELECT
    dt,
    CASE
        WHEN http_user_agent LIKE '%Android%' THEN 'Android'
        WHEN http_user_agent LIKE '%iPhone%' OR http_user_agent LIKE '%iPad%' THEN 'iOS'
        WHEN http_user_agent LIKE '%Windows%' OR http_user_agent LIKE '%Macintosh%' THEN 'PC'
        ELSE 'Other'
    END AS terminal_type,
    COUNT(1) AS pv,
    COUNT(DISTINCT uid) AS uv
FROM dwd_log_info_di_odps
WHERE dt = '2026-06-07'
GROUP BY
    dt,
    CASE
        WHEN http_user_agent LIKE '%Android%' THEN 'Android'
        WHEN http_user_agent LIKE '%iPhone%' OR http_user_agent LIKE '%iPad%' THEN 'iOS'
        WHEN http_user_agent LIKE '%Windows%' OR http_user_agent LIKE '%Macintosh%' THEN 'PC'
        ELSE 'Other'
    END
ORDER BY pv DESC;

对于长周期（如30天）的UV统计，直接使用COUNT(DISTINCT uid)可能会导致性能问题，因为需要扫描大量历史分区数据。

4.2 用户留存分析

留存率是衡量用户粘性的关键指标。以次日留存为例，计算逻辑是：在某天访问过网站的用户中，有多少人在第二天再次访问：

WITH daily_users AS (
    SELECT
        dt,
        uid
    FROM dwd_log_info_di_odps
    WHERE dt BETWEEN '2026-06-01' AND '2026-06-07'
    GROUP BY dt, uid
)
SELECT
    a.dt AS base_date,
    COUNT(DISTINCT a.uid) AS day0_users,
    COUNT(DISTINCT b.uid) AS day1_retained_users,
    ROUND(COUNT(DISTINCT b.uid) * 100.0 / COUNT(DISTINCT a.uid), 2) AS retention_rate
FROM daily_users a
LEFT JOIN daily_users b ON a.uid = b.uid AND b.dt = DATE_ADD(a.dt, 1)
GROUP BY a.dt
ORDER BY a.dt;

同理，可以计算3日留存、7日留存，只需调整DATE_ADD的天数参数即可。

4.3 漏斗转化分析

漏斗模型是电商和内容平台最常用的分析工具之一，用于追踪用户在产品关键路径上的转化情况。以电商场景为例，典型的用户路径是：浏览商品 → 加入购物车 → 提交订单 → 支付成功。

实现漏斗分析的关键是定义每个阶段的事件，并为每个用户标记其到达的最高阶段：

WITH user_journey AS (
    SELECT
        uid,
        MAX(CASE WHEN event_type = 'view' THEN 1 ELSE 0 END) AS has_view,
        MAX(CASE WHEN event_type = 'cart' THEN 1 ELSE 0 END) AS has_cart,
        MAX(CASE WHEN event_type = 'order' THEN 1 ELSE 0 END) AS has_order,
        MAX(CASE WHEN event_type = 'pay' THEN 1 ELSE 0 END) AS has_pay
    FROM dwd_user_event_di_odps
    WHERE dt = '2026-06-07'
    GROUP BY uid
)
SELECT '浏览' AS stage, SUM(has_view) AS user_count, 100.00 AS conversion_rate FROM user_journey
UNION ALL
SELECT '加购', SUM(has_cart), ROUND(SUM(has_cart) * 100.0 / SUM(has_view), 2) FROM user_journey
UNION ALL
SELECT '下单', SUM(has_order), ROUND(SUM(has_order) * 100.0 / SUM(has_view), 2) FROM user_journey
UNION ALL
SELECT '支付', SUM(has_pay), ROUND(SUM(has_pay) * 100.0 / SUM(has_view), 2) FROM user_journey;

漏斗分析的结果可以进一步通过Quick BI等BI工具进行可视化展示。

4.4 流量来源地域分析

通过解析客户端IP地址，可以统计用户的地域分布，帮助运营团队了解核心市场区域。MaxCompute提供了内置的IP地理信息解析函数，也可以使用第三方IP库（如纯真IP库）通过UDF（用户自定义函数）实现：

SELECT
    ip_province(remote_addr) AS province,
    COUNT(1) AS visit_count,
    COUNT(DISTINCT uid) AS uv
FROM dwd_log_info_di_odps
WHERE dt = '2026-06-07'
GROUP BY ip_province(remote_addr)
ORDER BY visit_count DESC
LIMIT 10;

注意：ip_province为示例函数名，实际使用时需要根据MaxCompute支持的IP库函数或自定义UDF进行调整。

5. 性能优化最佳实践

5.1 数据倾斜的识别与处理

数据倾斜是MaxCompute作业中最常见的性能问题之一。当数据按某个Key（如uid）进行GROUP BY或JOIN时，如果某些Key对应的数据量远大于其他Key，就会导致部分Reducer处理的数据量过大，拖慢整个作业。

识别数据倾斜：通过MaxCompute的Logview工具可以快速定位数据倾斜。在Logview的Fuxi Jobs页面中，按运行时间（Latency）降序排列，运行时间最长的Job Stage通常就是数据倾斜发生的阶段。

处理数据倾斜的常用方法：

• 打散热点Key——对于GROUP BY倾斜，可以在Key后面添加随机数后缀将数据打散，然后进行两阶段聚合
• 使用MapJoin——对于小表关联大表的场景，使用/*+ MAPJOIN(t) */提示将小表广播到所有Map端，避免Shuffle阶段的倾斜
• 优化COUNT(DISTINCT)——COUNT(DISTINCT uid)在数据量极大时容易产生倾斜，可以改写为SUM(1)配合子查询去重的方式

以下是一个处理COUNT(DISTINCT)倾斜的改写示例：

-- 原始写法（可能倾斜）
SELECT COUNT(DISTINCT uid) AS uv FROM dwd_log_info_di_odps WHERE dt = '2026-06-07';

-- 优化写法：先按uid去重再计数
SELECT COUNT(1) AS uv FROM (
    SELECT uid FROM dwd_log_info_di_odps WHERE dt = '2026-06-07' GROUP BY uid
) t;

5.2 长周期指标的计算优化

计算近30天UV、近90天GMV等长周期指标时，如果每次都扫描全部历史明细数据，成本极高且性能低下。常用的优化策略包括：

• 按天预聚合——每天计算当天的去重用户列表（Bitmap或数组形式），查询多天数据时只需合并每天的预聚合结果
• 分层增量计算——维护一张每日活跃用户中间表，长周期指标基于中间表累加计算，避免重复扫描明细数据
• 使用窗口函数——对于滑动窗口类指标，合理使用RANGE BETWEEN等窗口函数可以减少重复扫描

5.3 分区设计与小文件治理

合理的分区设计是MaxCompute性能优化的基础。网站日志分析通常按日期（dt）进行分区，每日数据写入一个独立分区。这样做的好处是：

• 查询时可以通过分区裁剪大幅减少扫描数据量
• 便于按天进行数据管理和生命周期管理
• 支持按分区进行增量ETL处理

但分区过多也可能导致小文件问题——每个分区内的文件数量过多会影响元数据管理和任务启动效率。建议定期对小文件进行合并（ALTER TABLE ... MERGE SMALLFILES），或通过DataWorks的运维中心配置自动合并策略。

5.4 使用Logview诊断慢作业

MaxCompute的Logview是诊断作业性能问题的核心工具。通过Logview可以查看：

• 作业的DAG执行图，了解各个Stage的依赖关系
• 每个Stage的输入输出数据量和运行时长
• 数据倾斜的具体位置（通过Fuxi Jobs的Latency排序）
• 作业的详细日志，包括错误信息和警告

建议在每次大规模数据加工任务运行后，养成查看Logview的习惯，及时发现并优化性能瓶颈。

6. 任务调度与数据质量监控

6.1 DataWorks调度配置

网站用户访问数据分析是一个典型的周期性ETL任务，通常需要每天定时运行。在DataWorks中，可以通过以下方式配置调度：

• 在数据开发（Data Studio）中为每个ODPS SQL节点配置调度属性，包括调度周期（如每天凌晨2点执行）、依赖关系（如DWD节点依赖ODS同步节点完成）
• 通过业务流程（Workflow）将多个节点串联起来，形成完整的DAG（有向无环图）
• 配置调度参数（如${bizdate}），实现按业务日期回刷数据
• 提交发布到生产环境后，任务会按照配置的调度周期自动运行

标准模式下，开发环境的任务需要先提交、再发布到生产环境，确保生产任务的稳定性和可追溯性。

6.2 数据质量监控

数据质量是数据分析的生命线。DataWorks的数据质量模块支持对MaxCompute表配置多种监控规则。常见的监控规则包括：

• 表行数监控——检查每日分区数据量是否在合理范围内（如波动不超过20%）
• 字段空值率监控——检查关键字段（如uid）的空值率是否过高
• 唯一性监控——检查主键字段是否存在重复
• 自定义SQL监控——通过自定义SQL检查业务逻辑的合理性

配置好监控规则后，当数据质量异常时，系统会自动触发告警（如短信、邮件、钉钉通知），帮助运维人员及时发现和处理问题。

7. 数据可视化与消费

数据加工的最终目的是服务于业务决策。MaxCompute分析完成后的数据，可以通过多种方式进行消费：

• Quick BI——阿里云自研的BI工具，可以直接连接MaxCompute数据源，通过拖拽式操作快速生成仪表盘和报表
• DataV数据可视化——适合搭建大屏展示，支持丰富的图表组件和实时数据刷新
• 数据服务API——通过DataWorks的数据服务模块，将MaxCompute表封装为RESTful API，供业务系统调用
• 第三方BI工具——通过JDBC/ODBC驱动，Tableau、Power BI等工具也可以直接连接MaxCompute进行分析

在数据消费环节，建议根据业务场景选择合适的可视化工具：运营日报适合Quick BI，大屏监控适合DataV，系统集成适合数据服务API。

8. 常见问题解答

问1：MaxCompute和DataWorks是什么关系？

答：MaxCompute是云原生大数据计算服务，负责海量数据的存储和计算；DataWorks是数据开发与运维平台，提供数据集成、数据开发、任务调度、数据质量监控等一站式数据开发能力。两者配合使用，MaxCompute提供计算引擎能力，DataWorks提供开发和管理界面。

问2：网站访问日志同步到MaxCompute有哪些方式？

答：主要有三种方式：从OSS同步日志文件（适合日志已存储在OSS的场景）、从日志服务SLS实时同步（适合对时效性要求高的场景）、使用Tunnel命令行工具上传（适合临时性或小批量数据）。

问3：数仓分层中的ODS、DWD、DWS、ADS分别是什么？

答：ODS是操作数据存储层，存储原始日志不做清洗；DWD是明细数据层，对ODS数据进行清洗解析为结构化字段；DWS是汇总数据层，按用户维度预计算宽表；ADS是应用数据层，面向具体业务场景的个性化数据产品。

问4：MaxCompute中COUNT(DISTINCT)为什么可能产生数据倾斜？如何优化？

答：COUNT(DISTINCT uid)在数据量极大时，如果uid分布不均匀，某些uid值对应的数据量过大，会导致部分Reducer处理压力过大。优化方法是先按uid去重再计数：SELECT COUNT(1) AS uv FROM (SELECT uid FROM table GROUP BY uid) t。

问5：如何诊断MaxCompute作业的性能问题？

答：使用MaxCompute的Logview工具。通过Logview可以查看作业的DAG执行图、各Stage的运行时长和数据量、数据倾斜的具体位置（在Fuxi Jobs中按Latency降序排列）以及详细日志信息。

问6：MaxCompute分析完成后的数据如何可视化展示？

答：可以通过Quick BI直接连接MaxCompute数据源生成仪表盘，通过DataV搭建大屏展示，通过DataWorks数据服务封装为API供业务系统调用，也可以通过JDBC/ODBC驱动连接Tableau、Power BI等第三方BI工具。