java实时数仓项目

访问的时候 

这是因为properties中配置的是 本地 的localhost 

因为这里面请求地址是applog

 

 

发送到kafka的properties

 

添加一个logback.xml

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <property name="LOG_HOME" value="d:/logs" />
    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%msg%n</pattern>
        </encoder>
    </appender>

    <appender name="rollingFile" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${LOG_HOME}/app.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <fileNamePattern>${LOG_HOME}/app.%d{yyyy-MM-dd}.log</fileNamePattern>
        </rollingPolicy>
        <encoder>
            <pattern>%msg%n</pattern>a
        </encoder>
    </appender>


    <!-- 将某一个包下日志单独打印日志 -->
    <logger name="com.jsf.gmall.controller.LoggerController.java"
            level="INFO" additivity="false">
        <appender-ref ref="rollingFile" />
        <appender-ref ref="console" />
    </logger>

    <root level="error" additivity="false">
        <appender-ref ref="console" />
    </root>
</configuration>

导入一个lombok下的 

设置日志级别  (info ,和 warn  级别)

 

 

实时数仓项目推进过程中,常常会遇到一系列技术、架构及管理层面的问题,这些问题可能导致项目进展缓慢甚至停滞。以下是常见的问题及其对应的解决方案。 ### 一、数据延迟与处理性能瓶颈 **问题描述:** 实时数仓要求数据从源头采集到最终展示的延迟尽可能低,但在实际运行中,由于数据量大、计算复杂或资源分配不合理,可能出现任务延迟严重、吞吐量不足等问题。 **解决方案:** - 优化Flink或Spark Streaming的任务并行度设置,合理分配Slot和Core数量,确保CPU与内存比例协调[^4]。 - 对热点数据进行分区策略优化,避免数据倾斜导致部分节点负载过高。 - 引入Kafka作为消息队列,缓解上游数据写入压力,实现流量削峰填谷。 ```java // 示例:Flink设置并行度 env.setParallelism(3); ``` ### 二、数据一致性与口径不统一 **问题描述:** 不同业务部门或下游应用对同一指标的定义存在差异,导致多个集市重复加工,造成结果不一致,影响决策准确性。 **解决方案:** - 建立公共层(CDM),统一处理核心维度与事实表,保障基础数据的一致性与可复用性[^3]。 - 制定统一的指标字典与口径规范,明确每个指标的来源、计算逻辑与使用范围。 - 实施元数据管理工具,记录数据血缘与变更历史,提升数据治理能力。 ### 三、缺乏自助取数能力 **问题描述:** 业务方频繁提出临时取数需求,数仓团队疲于响应,无法专注于模型建设与架构优化。 **解决方案:** - 构建自助取数平台,提供可视化查询界面与SQL生成器,降低非技术人员的数据获取门槛。 - 集成权限控制机制,确保敏感数据仅限授权访问。 - 提供API接口服务,支持自动化取数流程,减少人工干预。 ### 四、数据监控与使用反馈缺失 **问题描述:** 数据被下游系统调用后缺乏有效监控,无法评估其价值与使用频率,难以形成闭环反馈。 **解决方案:** - 在数据服务层引入访问日志记录机制,统计各接口调用量、响应时间等关键指标。 - 建立数据资产目录,可视化展示数据热度与依赖关系。 - 定期进行数据价值评估,淘汰低频使用数据源,释放存储与计算资源。 ### 五、维度表维护困难 **问题描述:** 如dim_省份等维度表更新频繁,且涉及多层级关联(如城市与父ID),维护成本高且易出错。 **解决方案:** - 使用缓慢变化维度(SCD)类型2管理维度变更历史,保留版本信息[^2]。 - 自动化同步维度数据,通过ETL任务定期拉取业务系统最新状态。 - 引入缓存机制,提高维度表查询效率,减少对源系统的压力。 ---
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值