This is an automated email from the ASF dual-hosted git repository.

benjobs pushed a commit to branch dev
in repository 
https://gitbox.apache.org/repos/asf/incubator-streampark-website.git


The following commit(s) were added to refs/heads/dev by this push:
     new 2066549  image url minor improvement
2066549 is described below

commit 206654925638d16406f3a060d7f2d0e6f11d6336
Author: benjobs <[email protected]>
AuthorDate: Fri Oct 6 13:47:14 2023 +0800

    image url minor improvement
---
 blog/1-flink-framework-streampark.md               |  22 ++++----
 blog/2-strampark-usercase-chinaunion.md            |  40 +++++++-------
 blog/3-streampark-usercase-bondex-paimon.md        |  60 ++++++++++-----------
 blog/4-streampark-usercase-sunwang.md              |  39 +++++++-------
 blog/6-streampark-usercase-joyme.md                |  24 ++++-----
 ...ase-haibo.md => 7-streampark-usercase-haibo.md} |  16 +++---
 static/blog/{ => belle}/author.png                 | Bin
 static/blog/{ => belle}/dashboard.png              | Bin
 static/blog/{ => belle}/dependency.png             | Bin
 static/blog/{ => belle}/detail.png                 | Bin
 static/blog/{ => belle}/doris.png                  | Bin
 static/blog/{ => belle}/flinksql.png               | Bin
 static/blog/{ => belle}/flow.png                   | Bin
 static/blog/{ => belle}/k8s.png                    | Bin
 static/blog/{ => belle}/pod.png                    | Bin
 static/blog/{ => belle}/sqlverify.png              | Bin
 static/blog/{ => belle}/start.png                  | Bin
 static/blog/{Bondex => bondex}/Bondex.png          | Bin
 static/blog/{Bondex => bondex}/aliyun.png          | Bin
 static/blog/{Bondex => bondex}/all_datastream.jpg  | Bin
 .../{Bondex => bondex}/application_setting.png     | Bin
 static/blog/{Bondex => bondex}/cp_fail.jpg         | Bin
 .../{Bondex => bondex}/dockersystem_setting.png    | Bin
 .../blog/{Bondex => bondex}/dwd_business_order.png | Bin
 static/blog/{Bondex => bondex}/dwd_orders.png      | Bin
 .../dwm_business_order_count.png                   | Bin
 .../dws_business_order_count_op.png                | Bin
 .../blog/{Bondex => bondex}/dynamic_properties.jpg | Bin
 static/blog/{Bondex => bondex}/flink_conf.jpg      | Bin
 static/blog/{Bondex => bondex}/flink_dashboard.png | Bin
 static/blog/{Bondex => bondex}/kappa.png           | Bin
 static/blog/{Bondex => bondex}/lambda.png          | Bin
 static/blog/{Bondex => bondex}/log.png             | Bin
 static/blog/{Bondex => bondex}/loki.png            | Bin
 static/blog/{Bondex => bondex}/ods.png             | Bin
 static/blog/{Bondex => bondex}/paimon-dwd.png      | Bin
 static/blog/{Bondex => bondex}/paimon-dwm.png      | Bin
 static/blog/{Bondex => bondex}/paimon-dws.png      | Bin
 static/blog/{Bondex => bondex}/paimon-ods.png      | Bin
 .../{Bondex => bondex}/paimon_catalog_setting.png  | Bin
 static/blog/{Bondex => bondex}/pipline.png         | Bin
 static/blog/{Bondex => bondex}/pod_template.png    | Bin
 static/blog/{Bondex => bondex}/pom.jpg             | Bin
 .../blog/{Bondex => bondex}/realtime_warehouse.png | Bin
 static/blog/{Bondex => bondex}/source.png          | Bin
 static/blog/{Bondex => bondex}/status_log.png      | Bin
 .../{Bondex => bondex}/streaming_warehouse.png     | Bin
 .../contribution_and_enhancement.png               | Bin
 .../data_processing_processes.png                  | Bin
 .../development_efficiency.png                     | Bin
 .../blog/{LTYW => chinaunion}/devops_platform.png  | Bin
 static/blog/{LTYW => chinaunion}/difficulties.png  | Bin
 .../blog/{LTYW => chinaunion}/job_management.png   | Bin
 .../{LTYW => chinaunion}/multi_team_support.png    | Bin
 .../multiple_environments_and_components.png       | Bin
 .../multiple_execution_modes.png                   | Bin
 .../operational_background.png                     | Bin
 .../{LTYW => chinaunion}/overall_architecture.png  | Bin
 .../{LTYW => chinaunion}/platform_background.png   | Bin
 .../{LTYW => chinaunion}/platform_evolution.png    | Bin
 .../platformized_management.png                    | Bin
 static/blog/{LTYW => chinaunion}/road_map.png      | Bin
 .../{LTYW => chinaunion}/state_optimization.png    | Bin
 .../blog/{LTYW => chinaunion}/state_recovery.png   | Bin
 .../status_acquisition_bottleneck.png              | Bin
 .../{LTYW => chinaunion}/submission_process.png    | Bin
 static/blog/{LTYW => chinaunion}/versioning.png    | Bin
 static/blog/{Joyme => joyme}/add_dependency.png    | Bin
 .../{Joyme => joyme}/add_projectconfiguration.png  | Bin
 static/blog/{Joyme => joyme}/alarm_eamil.png       | Bin
 .../{Joyme => joyme}/application_interface.png     | Bin
 static/blog/{Joyme => joyme}/application_job.png   | Bin
 .../{Joyme => joyme}/checkpoint_configuration.png  | Bin
 static/blog/{Joyme => joyme}/email_setting.png     | Bin
 static/blog/{Joyme => joyme}/flink_system.png      | Bin
 .../{Joyme => joyme}/project_configuration.png     | Bin
 static/blog/{Joyme => joyme}/start_log.png         | Bin
 static/blog/{Joyme => joyme}/system_setting.png    | Bin
 static/blog/{Joyme => joyme}/yarn_log.png          | Bin
 static/blog/{SF => shunwang}/achievements1.png     | Bin
 static/blog/{SF => shunwang}/achievements2.png     | Bin
 static/blog/{SF => shunwang}/alarm.png             | Bin
 static/blog/{SF => shunwang}/application.png       | Bin
 static/blog/{SF => shunwang}/autor.png             | Bin
 static/blog/{SF => shunwang}/cluster.png           | Bin
 static/blog/{SF => shunwang}/connectors.png        | Bin
 static/blog/{SF => shunwang}/function.png          | Bin
 static/blog/{SF => shunwang}/homework.png          | Bin
 static/blog/{SF => shunwang}/homework_manager.png  | Bin
 static/blog/{SF => shunwang}/launcher.png          | Bin
 static/blog/{SF => shunwang}/logs.png              | Bin
 static/blog/{SF => shunwang}/management.png        | Bin
 static/blog/{SF => shunwang}/pain.png              | Bin
 static/blog/{SF => shunwang}/permission.png        | Bin
 static/blog/{SF => shunwang}/queue.png             | Bin
 static/blog/{SF => shunwang}/sql_client.png        | Bin
 static/blog/{SF => shunwang}/sql_develop.png       | Bin
 static/blog/{SF => shunwang}/step.png              | Bin
 98 files changed, 100 insertions(+), 101 deletions(-)

diff --git a/blog/1-flink-framework-streampark.md 
b/blog/1-flink-framework-streampark.md
index 01fcc3e..dcd97dd 100644
--- a/blog/1-flink-framework-streampark.md
+++ b/blog/1-flink-framework-streampark.md
@@ -10,7 +10,7 @@ tags: [StreamPark, DataStream, FlinkSQL]
 
 Hadoop 
体系虽然在目前应用非常广泛,但架构繁琐、运维复杂度过高、版本升级困难,且由于部门原因,数据中台需求排期较长,我们急需探索敏捷性开发的数据平台模式。在目前云原生架构的普及和湖仓一体化的大背景下,我们已经确定了将
 Doris 作为离线数据仓库,将 TiDB(目前已经应用于生产)作为实时数据平台,同时因为 Doris 具有 on MySQL 的 ODBC 
能力,所以又可以对外部数据库资源进行整合,统一对外输出报表
 
-![](/blog/doris.png)
+![](/blog/belle/doris.png)
 
 <center style={{"color": "gray"}}>(这里借用一下 Doris 官方的架构图)</center>
 
@@ -44,7 +44,7 @@ Hadoop 体系虽然在目前应用非常广泛,但架构繁琐、运维复杂
 
 首先,针对 Flink 原生镜像需要二次 build 的问题:我们利用了 MinIO 作为外部存储,并使用 s3-fuse 通过 DaemonSet 
的方式直接挂载在了每个宿主节点上,我们所需要提交的 jar 包都可以放到上面统一管理。这样的话,即使扩缩容 Flink 节点,也能实现 S3 挂载自动伸缩。
 
-![](/blog/k8s.png)
+![](/blog/belle/k8s.png)
 
 Flink 从 1.13 版本开始,就支持 Pod Template,我们可以在 Pod Template 中利用数据卷挂载的方式再将宿主机目录挂载到每个 
pod 中,从而无需镜像打包而直接在 K8s 上运行 Flink 程序。如上图,我们将 S3 先通过 s3-fuse Pod 挂载在 Node 1、Node 
2 的 `/mnt/data-s3fs` 目录下,然后再将 `/mnt/data-s3fs` 挂载到 Pod A 中。
 
@@ -155,25 +155,25 @@ Flink 从 1.13 版本开始,就支持 Pod Template,我们可以在 Pod Templ
 
 在 StreamPark 中,我们只需要配置相应的参数,并在 Maven POM 中填写相应的依赖,或者上传依赖 jar 包,点击 
Apply,相应的依赖就会生成。这就意味着我们也可以将所有使用的 UDF 打成 jar 包,以及各种 connector.jar,直接在 SQL 
中使用。如下图:
 
-![](/blog/dependency.png)
+![](/blog/belle/dependency.png)
 
 SQL 校验能力和 Zeppelin 基本一致:
 
-![](/blog/sqlverify.png)
+![](/blog/belle/sqlverify.png)
 
 我们也可以指定资源,指定 Flink Run 中的动态参数 Dynamic Option,甚至参数可以整合 Pod  Template
 
-![](/blog/pod.png)
+![](/blog/belle/pod.png)
 
 程序保存后,点击运行时,也可以指定 savepoint。任务提交成功后,StreamPark 会根据 FlinkPod 网络 Exposed 
Type(loadBalancer/NodePort/ClusterIp),返回相应的 WebURL,从而自然的实现 WebUI 跳转。但是,目前因为线上私有 
K8s 集群出于安全性考虑,尚未打通 Pod 与客户端节点网络(目前也没有这个规划)。所以么,我们只使用 NodePort。如果后续任务数过多,有使用 
ClusterIP 的需求的话,我们可能会将 StreamPark 部署在 K8s,或者同 Ingress 做进一步整合。
 
-![](/blog/start.png)
+![](/blog/belle/start.png)
 
 注意:K8s master 如果使用 vip 做均衡代理的情况下,Flink 1.13 版本会返回 vip 的 ip 地址,在 1.14 
版本中已经修复该问题。
 
 下面是 K8s Application 模式下具体提交流程
 
-![](/blog/flow.png)
+![](/blog/belle/flow.png)
 
 <center style={{"color": "gray"}}>(以上是依据个人理解绘制的任务提交流程图,如有错误,敬请谅解)</center>
 
@@ -197,15 +197,15 @@ Native-Session 模式需要事先使用 Flink 命令创建一个运行在 K8s 
 -Dkubernetes.rest-service.exposed.type=Nodeport
 ```
 
-![](/blog/flinksql.png)
+![](/blog/belle/flinksql.png)
 
 如上图,使用该 ClusterId 作为 StreamPark 的任务参数 Kubernetes ClusterId。保存提交任务后,任务会很快处于 
Running 状态:
 
-![](/blog/detail.png)
+![](/blog/belle/detail.png)
 
 我们顺着 application info 的 WebUI 点击跳转:
 
-![](/blog/dashboard.png)
+![](/blog/belle/dashboard.png)
 
 可以看到,其实 StreamPark 是将 jar 包通过 REST API 上传到 Flink 集群上,并调度执行任务的。
 
@@ -243,4 +243,4 @@ Native-Session 模式需要事先使用 Flink 命令创建一个运行在 K8s 
 StreamPark 
GitHub:[https://github.com/apache/incubator-streampark](https://github.com/apache/incubator-streampark)
 <br/>
 Doris GitHub:[https://github.com/apache/doris](https://github.com/apache/doris)
 
-![](/blog/author.png)
+![](/blog/belle/author.png)
diff --git a/blog/2-strampark-usercase-chinaunion.md 
b/blog/2-strampark-usercase-chinaunion.md
index c4056d0..98e5b3d 100644
--- a/blog/2-strampark-usercase-chinaunion.md
+++ b/blog/2-strampark-usercase-chinaunion.md
@@ -15,7 +15,7 @@ tags: [StreamPark, 生产实践, FlinkSQL]
 
 ## **实时计算平台背景介绍**
 
-![](/blog/LTYW/overall_architecture.png)
+![](/blog/chinaunion/overall_architecture.png)
 
 
 
@@ -23,7 +23,7 @@ tags: [StreamPark, 生产实践, FlinkSQL]
 
 
 
-![](/blog/LTYW/data_processing_processes.png)
+![](/blog/chinaunion/data_processing_processes.png)
 
 上图是数据处理的详细的流程。
 
@@ -31,11 +31,11 @@ tags: [StreamPark, 生产实践, FlinkSQL]
 
 第二部分是实时计算, 这个环节处理的数据量很大,数据量在万亿级别,支撑了 10000+的数据实时订阅,有 200 多个 Flink 
任务,我们将某一种同类型的业务封装成一种场景,同一个 Flink 作业可以支持相同场景的多个订阅,目前 Flink 作业数还在不停的增长,后续可能会增加到 
500 
多个;其中面临的一个很大挑战是每天万亿级的数据实时关联电子围栏、用户特征等信息,电子围栏有几万个,用户特征涉及数亿用户,最初我们将电子围栏信息和用户特征放到 
HBase, 但这样会导致 HBase 压力很大,经常遇到性能问题造成数据延迟,而且一旦产生数据积压,需要很长的时间去消化,得益于 Flink State 
的强大,我们将电子围栏信息和用户特征放到状态里,目前已经很好的支撑了大并发的场景,同时我们也增加了数据处理的性能监控;最后是实时产品和营销触达前
 端的一些应用。
 
-![](/blog/LTYW/platform_evolution.png)
+![](/blog/chinaunion/platform_evolution.png)
 
 2018 年采用了三方黑盒的计算引擎,不能支持灵活定制个性化功能,且依赖过多外部系统,导致外部系统负载高,运维复杂;2019 年使用了 Spark 
Streaming 的微批处理,2020 年开始使用 Flink 的流式计算,从 2021 年开始,几乎所有 Spark Streaming 的微批处理都被 
Flink 替代了,同时上线了 Apache StreamPark 对我们的 Flink 作业进行管理。
 
-![](/blog/LTYW/platform_background.png)
+![](/blog/chinaunion/platform_background.png)
 
 总结一下平台背景,主要包含以下几部分:
 
@@ -44,7 +44,7 @@ tags: [StreamPark, 生产实践, FlinkSQL]
 - 订阅多:支撑了 10000+的数据服务订阅。
 - 用户多:支撑了 30 多个内部和外部用户使用。
 
-![](/blog/LTYW/operational_background.png)
+![](/blog/chinaunion/operational_background.png)
 
 运维背景也可以分为以下几部分:
 
@@ -57,7 +57,7 @@ tags: [StreamPark, 生产实践, FlinkSQL]
 
 ## **Flink 实时作业运维挑战**
 
-![](/blog/LTYW/difficulties.png)
+![](/blog/chinaunion/difficulties.png)
 
 基于平台和运维背景,尤其是 Flink 作业越来越多的情况下,遇到了很大的挑战,主要有两方面,分别是作业运维困境和业务支撑困境。
 
@@ -71,7 +71,7 @@ tags: [StreamPark, 生产实践, FlinkSQL]
 
 ## **基于 StreamPark 一体化管理**
 
-![](/blog/LTYW/job_management.png)
+![](/blog/chinaunion/job_management.png)
 
 对于以上的两种困境,我们基于 StreamPark 一体化管理解决了很多问题,首先来看一下 StreamPark 的双线演进,分别是 Flink 作业管理和 
Flink 作业 DevOps 平台;在作业管理上,StreamPark 支持将 Flink 实时作业部署到不同的集群里去,比如 Flink 原生自带的 
Standalone 模式,Flink on Yarn 的 Session、Application、PerJob 模式,在最新的版本中将支持 
Kubernetes Native Session 模式;中间层是项目管理、作业管理、集群管理、团队管理、变量管理、告警管理。
 
@@ -88,7 +88,7 @@ tags: [StreamPark, 生产实践, FlinkSQL]
 
 StreamPark 支持 Flink SQL、Flink Jar 
的提交,支持资源配置,支持状态跟踪,如状态是运行状态,失败状态等,同时支持指标大屏和各种日志查看。
 
-![](/blog/LTYW/devops_platform.png)
+![](/blog/chinaunion/devops_platform.png)
 
 Flink 作业 DevOps 平台,主要包括以下几部分:
 - 团队:StreamPark 支持多个团队,每个团队都有团队的管理员,他拥有所有权限,同时还有团队的开发者,他只有少量的一部分权限。
@@ -97,11 +97,11 @@ Flink 作业 DevOps 平台,主要包括以下几部分:
 - 状态监测:Flink 作业启动完成之后,就是状态的实时跟踪,包括 Flink 的运行状态、运行时长、Checkpoint 信息等,并支持一键跳转到 
Flink 的 Web UI。
 - 日志、告警:包含构建的一些日志和启动日志,同时支持钉钉、微信、邮件、短信等告警方式。
 
-![](/blog/LTYW/multi_team_support.png)
+![](/blog/chinaunion/multi_team_support.png)
 
 企业一般有多个团队同时开发实时作业,在我们公司包含实时采集团队、数据处理团队和实时的营销团队,StreamPark 支持多个团队的资源隔离。
 
-![](/blog/LTYW/platformized_management.png)
+![](/blog/chinaunion/platformized_management.png)
 
 Flink 作业平台化管理面临如下挑战:
 - 脚本数量多:平台有几百个脚本,分散在多个服务器上。
@@ -118,15 +118,15 @@ Flink 作业平台化管理面临如下挑战:
 
 可以看一下上图中下面的图,通过项目管理进行打包,通过作业管理进行配置,然后发布,可以进行一键启停,通过 API 提交作业。
 
-![图片](/blog/LTYW/development_efficiency.png)
+![图片](/blog/chinaunion/development_efficiency.png)
 
 早期我们需要通过 7 步进行部署,包括连接 VPN、登录 4A、执行编译脚本、执行启动脚本、打开 Yarn、搜索作业名、进入 Flink UI 等 7 
个步骤,StreamPark 可以支持 4 个一键进行部署,包括一键打包、一键发布、一键启动、一键到 Flink UI。
 
-![图片](/blog/LTYW/submission_process.png)
+![图片](/blog/chinaunion/submission_process.png)
 
 上图是我们 StreamPark 的作业提交流程,首先 StreamPark 
会将作业进行发布,发布的时候会上传一些资源,然后会进行作业的提交,提交的时候会带上配置的一些参数,以 Flink Submit 
的方式调用接口发布到集群上;这里会有多个 Flink Submit 对应着不同的执行模式,比如 Yarn Session、Yarn 
Application、Kubernetes Session、Kubernetes Application 等都是在这里控制的,提交作业之后,如果是 
Flink on Yarn 作业,会得到这个 Flink 作业的 Application ID 或者 Job ID,这个 ID 
会保存在我们的数据库中,如果是基于 Kubernetes 执行的话,也会得到 Job ID,后面我们在跟踪作业状态的时候,主要就是通过保存的这些 ID 
去跟踪作业的状态。
 
-![图片](/blog/LTYW/status_acquisition_bottleneck.png)
+![图片](/blog/chinaunion/status_acquisition_bottleneck.png)
 
 如上所述,如果是 Flink on Yarn 作业,在提交作业的时候会获取两个 ID,Application ID 或者 Job ID,基于这两个 ID 
可以获取我们的状态,但当 Flink 作业非常多的时候会遇到一些问题,StreamPark 它是有一个状态获取器,它会通过我们保存的数据库里的 
Application ID 或者 Job ID,去向 ResourceManager 做一个请求,会做每五秒钟周期性的轮询,如果作业特别多,每次轮询 
ResourceManager 会负责再去调用 Job Manager 的地址访问它的状态,这就会导致 ResourceManager 
的连接数压力较大和连接数过高。
 
@@ -134,29 +134,29 @@ Flink 作业平台化管理面临如下挑战:
 
 上图中 ResourceManager 的连接数阶段性、周期性的持续走高,可以看到 ResourceManager 
处于比较红的状态,从主机上去监控的时候,它的连接数确实比较高。
 
-![图片](/blog/LTYW/state_optimization.png)
+![图片](/blog/chinaunion/state_optimization.png)
 
 针对上面的问题,我们做了一些优化,首先 StreamPark 保存了提交作业之后的 Application ID 或者 Job ID,同时也会获取 Job 
Manager 直接访问的地址,并保存在数据库中,每次轮询时不再通过 ResourceManager 获取作业的状态,它可以直接调用各个 Job 
Manager 的地址实时获取状态,极大的降低了 ResourceManager 的连接数;从上图最后的部分可以看到,基本不会产生太大的连接数,大大减轻了 
ResourceManager 的压力,且后续当 Flink 作业越来越多时获取状态也不会遇到瓶颈的问题。
 
-![图片](/blog/LTYW/state_recovery.png)
+![图片](/blog/chinaunion/state_recovery.png)
 
 StreamPark 解决的另一个问题是 Flink 从状态恢复的保障,以前我们用脚本做运维的时候,在启动 Flink 
的时候,尤其是在业务升级的时候,要从上一个最新的 Checkpoint 
来恢复,但经常有开发人员忘记从上一个检查点进行恢复,导致数据质量产生很大的问题,遭到投诉,StreamPark 的流程是在首次启动的时候,每五秒钟轮询一次获取 
Checkpoint 的记录,同时保存在数据库之中,在 StreamPark 上手动停止 Flink 作业的时候,可以选择做不做 
Savepoint,如果选择了做 Savepoint,会将 Savepoint 的路径保存在数据库中,同时每次的 Checkpoint 
记录也保存在数据库中,当下次启动 Flink 作业的时候,默认会选择最新的 Checkpoint 或者 Savepoint 
记录,有效避免了无法从上一个检查点去恢复的问题,也避免了导致问题后要进行 offset 回拨重跑作业造成的资源浪费,同时也保证了数据处理
 的一致性。
 
-![图片](/blog/LTYW/multiple_environments_and_components.png)
+![图片](/blog/chinaunion/multiple_environments_and_components.png)
 
 StreamPark 
还解决了在多环境下多个组件的引用挑战,比如在企业中通常会有多套环境,如开发环境、测试环境、生产环境等,一般来说每套环境下都会有多个组件,比如 
Kafka,HBase、Redis 等,而且在同一套环境里还可能会存在多个相同的组件,比如在联通的实时计算平台,从上游的 Kafka 
消费数据的时候,将符合要求的数据再写到下游的 Kafka,这个时候同一套环境会涉及到两套 Kafka,单纯从 IP 
很难判断是哪个环境哪个组件,所以我们将所有组件的 IP 地址都定义成一个变量,比如 Kafka 集群,开发环境、测试环境、生产环境都有 
Kafka.cluster 这个变量,但它们指向的 Broker 的地址是不一样的,这样不管是在哪个环境下配置 Flink 
作业,只要引用这个变量就可以了,大大降低了生产上的故障率。
 
-![图片](/blog/LTYW/multiple_execution_modes.png)
+![图片](/blog/chinaunion/multiple_execution_modes.png)
 
 StreamPark 支持 Flink 多执行的模式,包括基于 on Yarn 的 Application/ Perjob / Session 
三种部署模式,还支持 Kubernetes 的 Application 和 Session 两种部署模式,还有一些 Remote 的模式。
 
-![图片](/blog/LTYW/versioning.png)
+![图片](/blog/chinaunion/versioning.png)
 
 StreamPark 也支持 Flink 的多版本,比如联通现在用的是 1.14.x,现在 1.16.x 
出来后我们也想体验一下,但不可能把所有的作业都升级到 1.16.x,我们可以把新上线的升级到 
1.16.x,这样可以很好的满足使用新版本的要求,同时也兼容老版本。
 
 ## **未来规划与演进**
 
-![图片](/blog/LTYW/contribution_and_enhancement.png)
+![图片](/blog/chinaunion/contribution_and_enhancement.png)
 
 未来我们将加大力度参与 StreamPark 建设,以下我们计划要增强的方向。
 - 高可用:StreamPark 目前不支持高可用,这方面还需要做一些加强。
@@ -164,7 +164,7 @@ StreamPark 也支持 Flink 的多版本,比如联通现在用的是 1.14.x,
 - 更细致的监控:目前支持 Flink 作业失败之后,StreamPark 发出告警。我们希望 Task 
失败之后也可以发出告警,我们需要知道失败的原因;还有作业反压监控告警、Checkpoint 超时、失败告警性能指标采集,也有待加强。
 - 流批一体:结合 Flink 流批一体引擎和数据湖流批一体存储探索流批一体平台。
 
-![](/blog/LTYW/road_map.png)
+![](/blog/chinaunion/road_map.png)
 
 上图是 StreamPark 的 Roadmap。
 - 数据源:StreamPark 会支持更多数据源的快速接入,达到数据一键入户。
diff --git a/blog/3-streampark-usercase-bondex-paimon.md 
b/blog/3-streampark-usercase-bondex-paimon.md
index 25a5d86..b7eb7f4 100644
--- a/blog/3-streampark-usercase-bondex-paimon.md
+++ b/blog/3-streampark-usercase-bondex-paimon.md
@@ -6,7 +6,7 @@ tags: [StreamPark, 生产实践, paimon, streaming-warehouse]
 
 # 海程邦达基于 Apache Paimon + StreamPark 的流式数仓实践
 
-![](/blog/Bondex/Bondex.png)
+![](/blog/bondex/Bondex.png)
 
 **导读:**本文主要介绍作为供应链物流服务商海程邦达在数字化转型过程中采用 Paimon + StreamPark 平台实现流式数仓的落地方案。我们以 
Apache StreamPark 流批一体平台提供了一个易于上手的生产操作手册,以帮助用户提交 Flink 任务并迅速掌握 Paimon 的使用方法。
 
@@ -28,7 +28,7 @@ tags: [StreamPark, 生产实践, paimon, streaming-warehouse]
 
 **实时数仓架构:**
 
-![](/blog/Bondex/realtime_warehouse.png)
+![](/blog/bondex/realtime_warehouse.png)
 
 
当前系统要求直接从生产系统收集实时数据,但存在多个数据源需要进行关联查询,而帆软报表在处理多个数据源时展示不够友好,且无法再次聚合多个数据源。定时查询生产系统会给生产系统数据库带来压力,影响生产系统的稳定运行。因此,我们需要引入一个可以通过
 [Flink CDC](https://github.com/ververica/flink-cdc-connectors) 
技术实现流式处理的数仓,以解决实时数据处理的问题。这个数仓需要能够从多个数据源收集实时数据并在此基础上实现复杂的关联 SQL 
查询、机器学习等操作,并且可以避免不定时查询生产系统,从而减轻生产系统的压力,保障生产系统的稳定运行。
 
@@ -56,7 +56,7 @@ tags: [StreamPark, 生产实践, paimon, streaming-warehouse]
 
 Lambda 架构是由 Storm 的作者 Nathan Marz 提出的一个实时大数据处理框架。Marz 在 Twitter 
工作期间开发了著名的实时大数据处理框架 [Apache Storm](https://github.com/apache/storm) ,Lambda 
架构是其根据多年进行分布式大数据系统的经验总结提炼而成。
 
-![](/blog/Bondex/lambda.png)
+![](/blog/bondex/lambda.png)
 
 数据流处理分为 ServingLayer、SpeedLayer、BatchLayer 三层:
 
@@ -76,7 +76,7 @@ kappa 架构只用一套数据流处理架构来解决离线和实时数据,
 
 它通常使用流处理引擎实现,例如Apache Flink、Apache Storm、Apache Kinesis、 Apache 
Kafka,旨在处理大量数据流并提供快速可靠的查询访问结果。
 
-![](/blog/Bondex/kappa.png)
+![](/blog/bondex/kappa.png)
 
 **优点是:**单数据流处理框架
 
@@ -96,7 +96,7 @@ kappa 架构只用一套数据流处理架构来解决离线和实时数据,
 
 **流式数仓架构如下:**
 
-![](/blog/Bondex/streaming_warehouse.png)
+![](/blog/bondex/streaming_warehouse.png)
 
 延续了 kappa 架构的特点,一套流处理架构,好处在与,底层 Paimon 
的技术支撑使得数据在全链路可查,数仓分层架构得以复用,同时兼顾了离线和实时的处理能力,减少存储和计算的浪费
 
@@ -116,7 +116,7 @@ kappa 架构只用一套数据流处理架构来解决离线和实时数据,
 
 通过在 StreamPark 平台上提交 Paimon 任务,我们可以建立一个全链路实时流动、可查询和分层可复用的 Pipline。
 
-![](/blog/Bondex/pipline.png)
+![](/blog/bondex/pipline.png)
 
 主要采用组件版本如下:
 
@@ -184,7 +184,7 @@ source /etc/profile
 
 在 StreamPark 添加 Flink conf:
 
-![](/blog/Bondex/flink_conf.jpg)
+![](/blog/bondex/flink_conf.jpg)
 
 构建 Flink 1.16.0 基础镜像从 dockerhub拉取对应版本的镜像
 
@@ -274,11 +274,11 @@ kubectl create secret docker-registry streamparksecret
 
 创建命名空间 StreamPark (安全设置需要设置为私有)
 
-![](/blog/Bondex/aliyun.png)
+![](/blog/bondex/aliyun.png)
 
 在 StreamPark 配置镜像仓库,任务构建镜像会推送到镜像仓库
 
-![](/blog/Bondex/dockersystem_setting.png)
+![](/blog/bondex/dockersystem_setting.png)
 
 创建 k8s secret 密钥用来拉取 ACR 中的镜像 streamparksecret 为密钥名称 自定义
 
@@ -332,7 +332,7 @@ kubectl -f checkpoints_pvc.yaml kubectl -f 
savepoints_pvc.yaml
 
 任务提交:初始化 Paimon catalog 配置
 
-![](/blog/Bondex/paimon_catalog_setting.png)
+![](/blog/bondex/paimon_catalog_setting.png)
 
 ```sql
 SET 'execution.runtime-mode' = 'streaming';
@@ -348,11 +348,11 @@ USE CATALOG `table_store`;
 
 一个任务同时抽取 postgres、mysql、sqlserver 三种数据库的表数据写入到 Paimon
 
-![](/blog/Bondex/application_setting.png)
+![](/blog/bondex/application_setting.png)
 
-![](/blog/Bondex/pom.jpg)
+![](/blog/bondex/pom.jpg)
 
-![](/blog/Bondex/pod_template.png)
+![](/blog/bondex/pod_template.png)
 
 **信息如下:**
 
@@ -578,7 +578,7 @@ FROM `OrderHAWB` where CreateOPDate > '2023-01-01';
 
 业务表数据实时写入 Paimon ods 表效果如下:
 
-![](/blog/Bondex/ods.png)
+![](/blog/bondex/ods.png)
 
 2. 将ods层表的数据打宽写入 dwd 层中,这里其实就是将 ods 层相关业务表合并写入dwd 中,这里主要是处理 count_order 
字段的值,因为源表中的数据存在逻辑删除和物理删除所以通过 count 函数统计会有问题,所以我们这里采用 sum 
聚合来计算单量,每个reference_no对应的count_order是1,如果逻辑作废通过sql将它处理成0,物理删除 Paimon 会自动处理。
 
@@ -651,7 +651,7 @@ FROM
 
 flink ui 可以看到 ods 数据经过 paimon 实时 join 清洗到表 dwd_business_order
 
-![](/blog/Bondex/dwd_business_order.png)
+![](/blog/bondex/dwd_business_order.png)
 
 2.将dwd层数据轻度聚合到dwm层中,将相关数据写入dwm.`dwm_business_order_count` 表中,该表数据会根据主键对聚合字段做 
sum,sum_orderCount 字段就是聚合结果,物理删除的数据 sum 时 paimon 会自动处理。
 
@@ -714,7 +714,7 @@ dwd.`dwd_business_order` o
 
 Flink UI 效果如下 dwd_business_orders 数据聚合写到 dwm_business_order_count:
 
-![](/blog/Bondex/dwm_business_order_count.png)
+![](/blog/bondex/dwm_business_order_count.png)
 
 4.将 dwm 层数据聚合到 dws 层中,dws 层是做了更小维度的汇总
 
@@ -757,31 +757,31 @@ FROM
 
 Flink UI 效果如下 dws_business_order_count_op 数据写到 dws_business_order_count_op:
 
-![](/blog/Bondex/dws_business_order_count_op.png)
+![](/blog/bondex/dws_business_order_count_op.png)
 
 总体数据流转示例
 
-![](/blog/Bondex/all_datastream.jpg)
+![](/blog/bondex/all_datastream.jpg)
 
 源表:
 
-![](/blog/Bondex/source.png)
+![](/blog/bondex/source.png)
 
 paimon-ods:
 
-![](/blog/Bondex/paimon-ods.png)
+![](/blog/bondex/paimon-ods.png)
 
 paimon-dwd:
 
-![](/blog/Bondex/paimon-dwd.png)
+![](/blog/bondex/paimon-dwd.png)
 
 paimon-dwm:
 
-![](/blog/Bondex/paimon-dwm.png)
+![](/blog/bondex/paimon-dwm.png)
 
 paimon-dws:
 
-![](/blog/Bondex/paimon-dws.png)
+![](/blog/bondex/paimon-dws.png)
 
 特别提醒 sqlserver 数据库抽取时如果源表数据量过大全量抽取会锁表,建议在业务允许的情况下采用增量抽取。对于全量抽取 sqlserver 
可以采用中转的方式 sqlserver 全量数据导入到 mysql,从 mysql 再到 paimon-ods ,后面再通过 sqlserever 做增量抽取。
 
@@ -833,11 +833,11 @@ set 'table.exec.sink.upsert-materialize' = 'none'
 
 在 MySQL 源端执行 update 数据修改成功后,dwd_orders 表数据能同步成功
 
-![](/blog/Bondex/dwd_orders.png)
+![](/blog/bondex/dwd_orders.png)
 
 但是查看 dwd_enriched_orders 表数据无法同步,启动流模式查看数据,发现没有数据流向
 
-![](/blog/Bondex/log.png)
+![](/blog/bondex/log.png)
 
 **解决:**
 
@@ -870,7 +870,7 @@ WITH (
 
 任务异常中断 导致pod挂掉,查看loki日志显示akka.pattern.AskTimeoutException: Ask timed out on
 
-![](/blog/Bondex/loki.png)
+![](/blog/bondex/loki.png)
 
 java.util.concurrent.TimeoutException: Invocation of 
[RemoteRpcInvocation(JobMasterGateway.updateTaskExecutionState(TaskExecutionState))]
 at recipient 
[akka.tcp://[email protected]:6123/user/rpc/jobmanager_2] 
timed out. This is usually caused by: 1) Akka failed sending the message 
silently, due to problems like oversized payload or serialization failures. In 
that case, you should find detailed error information in the logs. 2) The 
recipient needs more time for respon [...]
 
@@ -899,11 +899,11 @@ java.util.concurrent.TimeoutException: Invocation of 
[RemoteRpcInvocation(JobMas
 
 发现 cp 出现失败情况
 
-![](/blog/Bondex/cp_fail.jpg)
+![](/blog/bondex/cp_fail.jpg)
 
 对应时间点日志显示 Snapshot 丢失,任务显示为 running 状态,但是源表 mysql 数据无法写入 paimon ods 表
 
-![](/blog/Bondex/status_log.png)
+![](/blog/bondex/status_log.png)
 
 定位cp失败原因为:计算量大,CPU密集性,导致TM内线程一直在processElement,而没有时间做CP
 
@@ -923,9 +923,9 @@ https://github.com/apache/incubator-paimon/pull/1308
 -D jobmanager.adaptive-batch-scheduler.default-source-parallelism=2
 ```
 
-![](/blog/Bondex/dynamic_properties.jpg)
+![](/blog/bondex/dynamic_properties.jpg)
 
-![](/blog/Bondex/flink_dashboard.png)
+![](/blog/bondex/flink_dashboard.png)
 
 在复杂的实时任务中,可以通过修改动态参数的方式,增加资源。
 
diff --git a/blog/4-streampark-usercase-sunwang.md 
b/blog/4-streampark-usercase-sunwang.md
index 3c4b9e0..410f162 100644
--- a/blog/4-streampark-usercase-sunwang.md
+++ b/blog/4-streampark-usercase-sunwang.md
@@ -6,12 +6,11 @@ tags: [StreamPark, 生产实践, FlinkSQL]
 
 # StreamPark 在顺网科技的大规模生产实践
 
-![](/blog/SF/autor.png)
+![](/blog/shunwang/autor.png)
 
 **导读:**本文主要介绍顺网科技在使用 Flink 计算引擎中遇到的一些挑战,基于 StreamPark 
作为实时数据平台如何来解决这些问题,从而大规模支持公司的业务。
 
 
-
 - 公司业务介绍
 - 遇到的挑战
 - 为什么用 StreamPark
@@ -40,13 +39,13 @@ tags: [StreamPark, 生产实践, FlinkSQL]
 
 Flink 作为当下实时计算领域中最流行的技术框架之一,拥有高吞吐、低延迟、有状态计算等强大的特性。在探索中我们发现 Flink 
虽然拥有强大的计算能力,但是对于作业开发管理和运维问题,社区并没有提供有效的解决方案。我们对 Flink 作业开发管理上遇到的一些痛点大概总结为 4 
个方面,如下:
 
-![图片](/blog/SF/pain.png)
+![图片](/blog/shunwang/pain.png)
 
 在面对 Flink 作业管理和运维上的的一系列痛点后,我们一直在寻找合适的解决方案来降低开发同学使用 Flink 门槛,提高工作效率。
 
 在没有遇到 StreamPark 之前,我们调研了部分公司的 Flink 管理解决方案,发现都是通过自研实时作业平台的方式来开发和管理 Flink 
作业。于是,我们也决定自研一套实时计算管理平台,来满足了开发同学对于 Flink 作业管理和运维的基础需求,我们这套平台叫 
Streaming-Launcher,大体功能如下:
 
-![图片](/blog/SF/launcher.png)
+![图片](/blog/shunwang/launcher.png)
 
 但是后续开发同学在使用过程中,发现 Streaming-Launcher 存在比较多的缺陷:Flink 
开发成本依然过高、工作效率低下、问题排查困难。我们总结了 Streaming-Launcher 存在的缺陷,大致如下:
 
@@ -54,13 +53,13 @@ Flink 作为当下实时计算领域中最流行的技术框架之一,拥有
 
 作业务开发需要多个工具完成一个 SQL 作业开发,提高了开发同学的使用门槛。
 
-![cc0b1414ed43942e0ef5e9129c2bf817](/blog/SF/sql_develop.png)
+![cc0b1414ed43942e0ef5e9129c2bf817](/blog/shunwang/sql_develop.png)
 
 ### **SQL-Client 存在弊端**
 
 Flink 提供的 SQL-Client 目前对作业运行模式支持上,存在一定的弊端。
 
-![图片](/blog/SF/sql_client.png)
+![图片](/blog/shunwang/sql_client.png)
 
 ### **作业缺少统一管理**
 
@@ -70,7 +69,7 @@ Streaming-Launcher 中,没有提供统一的作业管理界面。开发同学
 
 一个作业查看日志需要通过多个步骤,一定程度上降低了开发同学工作效率。
 
-![图片](/blog/SF/step.png)
+![图片](/blog/shunwang/step.png)
 
 ## **为什么用** **StreamPark**
 
@@ -88,7 +87,7 @@ Streaming-Launcher 中,没有提供统一的作业管理界面。开发同学
 
 
 
-![图片](/blog/SF/permission.png)
+![图片](/blog/shunwang/permission.png)
 
 
 
@@ -96,7 +95,7 @@ Streaming-Launcher 中,没有提供统一的作业管理界面。开发同学
 
 **我们在对 StreamPark 做调研的时候,最关注的是 StreamPark 对于作业的管理的能力。**StreamPark 
是否有能力管理作业一个完整的生命周期:作业开发、作业部署、作业管理、问题诊断等。**很幸运,StreamPark 
在这一方面非常优秀,对于开发同学来说只需要关注业务本身,不再需要特别关心 Flink 作业管理和运维上遇到的一系列痛点。**在 StreamPark 
作业开发管理管理中,大致分为三个模块:作业管理基础功能,Jar 作业管理,FlinkSQL 作业管理。如下:
 
-![图片](/blog/SF/homework_manager.png)
+![图片](/blog/shunwang/homework_manager.png)
 
 **开发脚手架**
 
@@ -104,7 +103,7 @@ Streaming-Launcher 中,没有提供统一的作业管理界面。开发同学
 
 
 
-![图片](/blog/SF/connectors.png)
+![图片](/blog/shunwang/connectors.png)
 
 
 
@@ -116,7 +115,7 @@ Streaming-Launcher 中,没有提供统一的作业管理界面。开发同学
 
 
 
-![图片](/blog/SF/function.png)
+![图片](/blog/shunwang/function.png)
 
 
 
@@ -124,7 +123,7 @@ Streaming-Launcher 中,没有提供统一的作业管理界面。开发同学
 
 StreamPark 为了降低 Flink 作业开发门槛,提高开发同学工作效率,**提供了 FlinkSQL 
IDE、参数管理、任务管理、代码管理、一键编译、一键作业上下线等使用的功能**。在调研中,我们发现 StreamPark 
集成的这些功能可以进一步提升开发同学的工作效率。在某种程度上来说,开发同学不需要去关心 Flink 
作业管理和运维的难题,只要专注于业务的开发。同时,这些功能也解决了 Streaming-Launcher 中 SQL 开发流程繁琐的痛点。
 
-![图片](/blog/SF/application.png)
+![图片](/blog/shunwang/application.png)
 
 **支持多种部署模式**
 
@@ -134,11 +133,11 @@ StreamPark 为了降低 Flink 作业开发门槛,提高开发同学工作效
 
 对于开发同学来说,作业运行状态是他们最关心的内容之一。在 Streaming-Launcher 中由于缺乏作业统一管理界面,开发同学只能通过告警信息和 
Yarn 中Application 的状态信息来判断任务状态,这对开发同学来说非常不友好。StreamPark 
针对这一点,提供了作业统一管理界面,可以一目了然查看到每个任务的运行情况。
 
-![图片](/blog/SF/management.png)
+![图片](/blog/shunwang/management.png)
 
 在 Streaming-Launcher 中,开发同学在作业问题诊断的时候,需要通过多个步骤才能定位作业运行日志。StreamPark 
提供了一键跳转功能,能快速定位到作业运行日志。
 
-![图片](/blog/SF/logs.png)
+![图片](/blog/shunwang/logs.png)
 
 
 
@@ -152,7 +151,7 @@ StreamPark 为了降低 Flink 作业开发门槛,提高开发同学工作效
 
 开发同学如果想在 ODPS 上查询实时数据,我们需要提供一个 Flink SQL 的运行环境。我们使用 StreamPark 运行了一个 Yarn 
Session 的 Flink 环境提供给 ODPS 做实时查询。
 
-![图片](/blog/SF/homework.png)
+![图片](/blog/shunwang/homework.png)
 
 目前 StreamPark 社区为了进一步降低实时作业开发门槛,正在对接 Flink-SQL-Gateway。
 
@@ -166,7 +165,7 @@ https://github.com/apache/streampark/issues/2274
 
 在实践中我们发现业务开发同学很难直观的知道在每个 Yarn Session 
中运行了多少个作业,其中包括作业总数和正在运行中的作业数量。基于这个原因,我们为了方便开发同学可以直观地观察到 Yarn Session 中的作业数量,在 
Flink Cluster 界面增加了 All Jobs 和 Running Jobs 来表示在一个 Yarn Session 中总的作业数和正在运行的作业数。
 
-![图片](/blog/SF/cluster.png)
+![图片](/blog/shunwang/cluster.png)
 
 
 
@@ -174,7 +173,7 @@ https://github.com/apache/streampark/issues/2274
 
 因为每个公司的短信告警平台实现都各不相同,所以 StreamPark 社区并没有抽象出统一的短信告警功能。在此,我们通过 Webhook 
的方式,自己实现了短信告警功能。
 
-![图片](/blog/SF/alarm.png)
+![图片](/blog/shunwang/alarm.png)
 
 
 
@@ -182,7 +181,7 @@ https://github.com/apache/streampark/issues/2274
 
 在生产实践中,我们发现在大批量任务同时失败的时候,比如 Yarn Session 集群挂了,飞书 / 
微信等平台在多线程同时调用告警接口时会存在限流的问题,那么大量的告警信息因为飞书 / 微信等平台限流问题,StreamPark 
只会发送一部分的告警信息,这样非常容易误导开发同学排查问题。在顺网科技,我们增加了一个阻塞队列和一个告警线程,来解决限流问题。
 
-![图片](/blog/SF/queue.png)
+![图片](/blog/shunwang/queue.png)
 
 
当作业监控调度器检测到作业异常时,会产生一条作业异常的消息发送的阻塞队列中,在告警线程中会一直消费阻塞队列中的消息,在得到作业异常消息后则会根据用户配置的告警信息单线程发送到不同的平台中。虽然这样做可能会让用户延迟收到告警,但是我们在实践中发现同时有
 100+ 个 Flink 作业失败,用户接受到告警的延迟时间小于 3s。对于这种延迟时间,我们业务开发同学完全是可以接受的。该改进目前已经记录 
ISSUE,正在考虑贡献到社区中。
 
@@ -198,9 +197,9 @@ StreamPark 给顺网科技带来的最大的收益就是降低了 Flink 的使
 
 **目前 StreamPark 在顺网科技已经大规模在生产环境投入使用,StreamPark 从最开始管理的 500+ 个 FlinkSQL 作业增加到了近 
700 个 FlinkSQL作业,同时管理了 10+ 个 Yarn Sesssion Cluster。**
 
-![图片](/blog/SF/achievements1.png)
+![图片](/blog/shunwang/achievements1.png)
 
-![图片](/blog/SF/achievements2.png)
+![图片](/blog/shunwang/achievements2.png)
 
 ##  未 来 规 划 
 
diff --git a/blog/6-streampark-usercase-joyme.md 
b/blog/6-streampark-usercase-joyme.md
index 5d14350..ed4174c 100644
--- a/blog/6-streampark-usercase-joyme.md
+++ b/blog/6-streampark-usercase-joyme.md
@@ -78,7 +78,7 @@ SELECT  Data.uid  FROM source_table;
 
 关于依赖这块是 StreamPark 里特有的,在 StreamPark 中创新型的将一个完整的 Flink Sql 任务拆分成两部分组成: Sql 和 
依赖, Sql 很好理解不多啰嗦, 依赖是 Sql 里需要用到的一些 Connector 的 Jar, 如 Sql 里用到了 Kafka 和 MySQL 的 
Connector, 那就需要引入这两个 Connector 的依赖, 在 StreamPark 中添加依赖两种方式,一种是基于标准的 Maven pom 
坐标方式,另一种是从本地上传需要的 Jar 。这两种也可以混着用,按需添加,点击应用即可, 在提交作业的时候就会自动加载这些依赖。
 
-![](/blog/Joyme/add_dependency.png)
+![](/blog/joyme/add_dependency.png)
 
 ### **3. 参数配置**
 
@@ -86,7 +86,7 @@ SELECT  Data.uid  FROM source_table;
 
 
剩下的一些参数设置就要根据作业的具体情况去对症下药的配置了,处理的数据量大了,逻辑复杂了,可能就需要更多的内存,并行度给多一些。有时候需要根据作业的运行情况进行多次调整。
 
-![](/blog/Joyme/checkpoint_configuration.png)
+![](/blog/joyme/checkpoint_configuration.png)
 
 ### **4. 动态参数设置**
 
@@ -98,39 +98,39 @@ SELECT  Data.uid  FROM source_table;
 
 完成配置以后提交,然后在 application 界面进行部署。
 
-![](/blog/Joyme/application_job.png)
+![](/blog/joyme/application_job.png)
 
 ## 3 Custom Code 作业开发
 
 Streaming 作业我们是使用 Flink java 进行开发,将之前 Spark scala,Flink scala,Flink java 
的作业进行了重构,然后工程整合到了一起,目的就是为了维护起来方便。Custom code 作业需要提交代码到 Git,然后配置项目:
 
-![](/blog/Joyme/project_configuration.png)
+![](/blog/joyme/project_configuration.png)
 
 配置完成以后,根据对应的项目进行编译,也就完成项目的打包环节。这样后面的 Constom code 
作业也可以引用。每次需要上线都需要进行编译才可以,否则只能是上次编译的代码。这里有个问题,为了安全,我司的 gitlab 
账号密码都是定期更新的。这样就会导致,StreamPark 已经配置好的项目还是之前的密码,结果导致编译时从 git 
里拉取项目失败,导致整个编译环节失败,针对这个问题,我们联系到社区,了解到这部分已经在后续的 1.2.1 版本中支持了项目的修改操作。
 
-![](/blog/Joyme/flink_system.png)
+![](/blog/joyme/flink_system.png)
 
 新建任务,选择 Custom code ,选择 Flink 版本,选择项目以及模块 Jar 包,选择开发的应用模式为 Apache Flink (标准的 
Flink 程序),程序主函数入口类,任务的名称。
 
-![](/blog/Joyme/add_projectconfiguration.png)
+![](/blog/joyme/add_projectconfiguration.png)
 
 以及任务的并行度,监控的方式等,内存大小根据任务需要进行配置。Program Args 程序的参数则根据程序需要自行定义入口参数,比如:我们统一启动类是 
StartJobApp,那么启动作业就需要传入作业的 Full name 告诉启动类要去找哪个类来启动此次任务,也就是一个反射机制,作业配置完成以后同样也是 
Submit 提交,然后在 application 界面部署任务。
 
-![](/blog/Joyme/application_interface.png)
+![](/blog/joyme/application_interface.png)
 
 ## 4 监控告警
 
 StreamPark 的监控需要在 setting 模块去配置发送邮件的基本信息。
 
-![](/blog/Joyme/system_setting.png)
+![](/blog/joyme/system_setting.png)
 
 然后在任务里配置重启策略:监控在多久内几次异常,然后是报警还是重启的策略,同时发送报警要发到哪个邮箱。目前我司使用版本是 1.2.1 只支持邮件发送。
 
-![](/blog/Joyme/email_setting.png)
+![](/blog/joyme/email_setting.png)
 
 当我们的作业出现失败的情况下,就可以接收到报警邮箱。这报警还是很好看的有木有,可以清楚看到我们的哪个作业,什么状态。也可以点击下面的具体地址进行查看。
 
-![](/blog/Joyme/alarm_eamil.png)
+![](/blog/joyme/alarm_eamil.png)
 
 关于报警这一块目前我们基于 StreamPark 的 t_flink_app 
表进行了一个定时任务的开发。为什么要这么做?因为发送邮件这种通知,大部分人可能不会去及时去看。所以我们选择监控每个任务的状态去把对应的监控信息发送我们的飞书报警群,这样可以及时发现问题去解决任务。一个简单的
 python 脚本,然后配置了 crontab 去定时执行。
 
@@ -142,13 +142,13 @@ StreamPark 的监控需要在 setting 模块去配置发送邮件的基本信息
 
 作业启动失败的问题,就是点击启动运行部署。发现起不来,这时候需要看界面的详情信息的日志。在我们的任务列表中有一个眼睛的按钮,点进去。在start logs 
中会找到提交的作业日志信息,点进去查看,如果有明显的提示信息,直接解决就可以了。如果没有,就需要去查看后台部署任务的目录 logs/下面的 
streamx.out,打开以后会找到启动失败的日志信息。
 
-![](/blog/Joyme/start_log.png)
+![](/blog/joyme/start_log.png)
 
 ### **2. 作业运行失败**
 
 
如果是任务已经起来了,但是在运行阶段失败了。这种情况表面看上去和上面的情况一样,实则完全不同,这种情况是已经将任务提交给集群了,但是任务运行不起来,那就是我们的任务自身有问题了。同样可以用上面第一种情况的排查方式打开作业的具体日志,找到任务在
 yarn 上运行的信息,根据日志里记录的 yarn 的 tackurl 去 yarn 的日志里查看具体的原因,是 Sql 的 Connector 
不存在,还是代码的哪行代码空指针了,都可以看到具体的堆栈信息。有了具体信息,就可以对症下药了。
 
-![](/blog/Joyme/yarn_log.png)
+![](/blog/joyme/yarn_log.png)
 
 ## 6 社区印象
 
diff --git a/blog/7-streampark-usecase-haibo.md 
b/blog/7-streampark-usercase-haibo.md
similarity index 95%
rename from blog/7-streampark-usecase-haibo.md
rename to blog/7-streampark-usercase-haibo.md
index 1f305bd..821cacd 100644
--- a/blog/7-streampark-usecase-haibo.md
+++ b/blog/7-streampark-usercase-haibo.md
@@ -34,15 +34,15 @@ tags: [StreamPark, 生产实践, FlinkSQL]
 
 - 编辑 SQL
 
-![](/blog/Haibo/flink_sql.png)
+![](/blog/haibo/flink_sql.png)
 
 - 上传依赖包
 
-![](/blog/Haibo/dependency.png)
+![](/blog/haibo/dependency.png)
 
 - 部署运行
 
-![](/blog/Haibo/deploy.png)
+![](/blog/haibo/deploy.png)
 
 仅需上述三步,即可完成 Mysql 到 Elasticsearch 的汇聚任务,大大提升数据接入效率。
 
@@ -54,7 +54,7 @@ StreamPark 在海博主要用于运行实时 Flink SQL任务: 读取 Kafka 上
 
 截至目前,StreamPark 已在多个政府、公安生产环境进行部署,汇聚处理城市实时物联数据、人车抓拍数据。以下是在某市专网部署的 StreamPark 
平台截图 : 
 
-![](/blog/Haibo/application.png)
+![](/blog/haibo/application.png)
 
 ## **03. 应用场景**
 
@@ -64,13 +64,13 @@ StreamPark 在海博主要用于运行实时 Flink SQL任务: 读取 Kafka 上
 
 “SQL+UDF” 的方式,能够满足我们绝大部分的数据汇聚场景,如果后期业务变动,也只需要在 StreamPark 中修改 SQL 
语句,即可完成业务变更与上线。
 
-![](/blog/Haibo/data_aggregation.png)
+![](/blog/haibo/data_aggregation.png)
 
 #### **2. Flink CDC数据库同步**
 
 为了实现各类数据库与数据仓库之前的同步,我们使用 StreamPark 开发 Flink CDC SQL 任务。借助于 Flink CDC 的能力,实现了 
Oracle 与 Oracle 之间的数据同步, Mysql/Postgresql 与 Clickhouse 之间的数据同步。
 
-![](/blog/Haibo/flink_cdc.png)
+![](/blog/haibo/flink_cdc.png)
 
 **3. 数据分析模型管理**
 
@@ -78,7 +78,7 @@ StreamPark 在海博主要用于运行实时 Flink SQL任务: 读取 Kafka 上
 
 目前,我们已经将人员,车辆等 20 余类分析模型上传至 StreamPark,交由 StreamPark 管理运行。
 
-![](/blog/Haibo/data_aggregation.png)
+![](/blog/haibo/data_aggregation.png)
 
 **综上:** 无论是 Flink SQL 任务还是 Custome code 任务,StreamPark 均提供了很好的支持,满足各种不同的业务场景。 
但是 StreamPark 缺少任务调度的能力,如果你需要定期调度任务, StreamPark 目前无法满足。社区成员正在努力开发调度相关的模块,在即将发布的 
1.2.3 中 会支持任务调度功能,敬请期待。
 
@@ -98,4 +98,4 @@ Workbench 将使用全新的工作台式的 SQL 开发风格,选择数据源
 
 下图是 StreamPark 开发者设计的原型图,敬请期待。
 
-![](/blog/Haibo/data_source.png)
+![](/blog/haibo/data_source.png)
diff --git a/static/blog/author.png b/static/blog/belle/author.png
similarity index 100%
rename from static/blog/author.png
rename to static/blog/belle/author.png
diff --git a/static/blog/dashboard.png b/static/blog/belle/dashboard.png
similarity index 100%
rename from static/blog/dashboard.png
rename to static/blog/belle/dashboard.png
diff --git a/static/blog/dependency.png b/static/blog/belle/dependency.png
similarity index 100%
rename from static/blog/dependency.png
rename to static/blog/belle/dependency.png
diff --git a/static/blog/detail.png b/static/blog/belle/detail.png
similarity index 100%
rename from static/blog/detail.png
rename to static/blog/belle/detail.png
diff --git a/static/blog/doris.png b/static/blog/belle/doris.png
similarity index 100%
rename from static/blog/doris.png
rename to static/blog/belle/doris.png
diff --git a/static/blog/flinksql.png b/static/blog/belle/flinksql.png
similarity index 100%
rename from static/blog/flinksql.png
rename to static/blog/belle/flinksql.png
diff --git a/static/blog/flow.png b/static/blog/belle/flow.png
similarity index 100%
rename from static/blog/flow.png
rename to static/blog/belle/flow.png
diff --git a/static/blog/k8s.png b/static/blog/belle/k8s.png
similarity index 100%
rename from static/blog/k8s.png
rename to static/blog/belle/k8s.png
diff --git a/static/blog/pod.png b/static/blog/belle/pod.png
similarity index 100%
rename from static/blog/pod.png
rename to static/blog/belle/pod.png
diff --git a/static/blog/sqlverify.png b/static/blog/belle/sqlverify.png
similarity index 100%
rename from static/blog/sqlverify.png
rename to static/blog/belle/sqlverify.png
diff --git a/static/blog/start.png b/static/blog/belle/start.png
similarity index 100%
rename from static/blog/start.png
rename to static/blog/belle/start.png
diff --git a/static/blog/Bondex/Bondex.png b/static/blog/bondex/Bondex.png
similarity index 100%
rename from static/blog/Bondex/Bondex.png
rename to static/blog/bondex/Bondex.png
diff --git a/static/blog/Bondex/aliyun.png b/static/blog/bondex/aliyun.png
similarity index 100%
rename from static/blog/Bondex/aliyun.png
rename to static/blog/bondex/aliyun.png
diff --git a/static/blog/Bondex/all_datastream.jpg 
b/static/blog/bondex/all_datastream.jpg
similarity index 100%
rename from static/blog/Bondex/all_datastream.jpg
rename to static/blog/bondex/all_datastream.jpg
diff --git a/static/blog/Bondex/application_setting.png 
b/static/blog/bondex/application_setting.png
similarity index 100%
rename from static/blog/Bondex/application_setting.png
rename to static/blog/bondex/application_setting.png
diff --git a/static/blog/Bondex/cp_fail.jpg b/static/blog/bondex/cp_fail.jpg
similarity index 100%
rename from static/blog/Bondex/cp_fail.jpg
rename to static/blog/bondex/cp_fail.jpg
diff --git a/static/blog/Bondex/dockersystem_setting.png 
b/static/blog/bondex/dockersystem_setting.png
similarity index 100%
rename from static/blog/Bondex/dockersystem_setting.png
rename to static/blog/bondex/dockersystem_setting.png
diff --git a/static/blog/Bondex/dwd_business_order.png 
b/static/blog/bondex/dwd_business_order.png
similarity index 100%
rename from static/blog/Bondex/dwd_business_order.png
rename to static/blog/bondex/dwd_business_order.png
diff --git a/static/blog/Bondex/dwd_orders.png 
b/static/blog/bondex/dwd_orders.png
similarity index 100%
rename from static/blog/Bondex/dwd_orders.png
rename to static/blog/bondex/dwd_orders.png
diff --git a/static/blog/Bondex/dwm_business_order_count.png 
b/static/blog/bondex/dwm_business_order_count.png
similarity index 100%
rename from static/blog/Bondex/dwm_business_order_count.png
rename to static/blog/bondex/dwm_business_order_count.png
diff --git a/static/blog/Bondex/dws_business_order_count_op.png 
b/static/blog/bondex/dws_business_order_count_op.png
similarity index 100%
rename from static/blog/Bondex/dws_business_order_count_op.png
rename to static/blog/bondex/dws_business_order_count_op.png
diff --git a/static/blog/Bondex/dynamic_properties.jpg 
b/static/blog/bondex/dynamic_properties.jpg
similarity index 100%
rename from static/blog/Bondex/dynamic_properties.jpg
rename to static/blog/bondex/dynamic_properties.jpg
diff --git a/static/blog/Bondex/flink_conf.jpg 
b/static/blog/bondex/flink_conf.jpg
similarity index 100%
rename from static/blog/Bondex/flink_conf.jpg
rename to static/blog/bondex/flink_conf.jpg
diff --git a/static/blog/Bondex/flink_dashboard.png 
b/static/blog/bondex/flink_dashboard.png
similarity index 100%
rename from static/blog/Bondex/flink_dashboard.png
rename to static/blog/bondex/flink_dashboard.png
diff --git a/static/blog/Bondex/kappa.png b/static/blog/bondex/kappa.png
similarity index 100%
rename from static/blog/Bondex/kappa.png
rename to static/blog/bondex/kappa.png
diff --git a/static/blog/Bondex/lambda.png b/static/blog/bondex/lambda.png
similarity index 100%
rename from static/blog/Bondex/lambda.png
rename to static/blog/bondex/lambda.png
diff --git a/static/blog/Bondex/log.png b/static/blog/bondex/log.png
similarity index 100%
rename from static/blog/Bondex/log.png
rename to static/blog/bondex/log.png
diff --git a/static/blog/Bondex/loki.png b/static/blog/bondex/loki.png
similarity index 100%
rename from static/blog/Bondex/loki.png
rename to static/blog/bondex/loki.png
diff --git a/static/blog/Bondex/ods.png b/static/blog/bondex/ods.png
similarity index 100%
rename from static/blog/Bondex/ods.png
rename to static/blog/bondex/ods.png
diff --git a/static/blog/Bondex/paimon-dwd.png 
b/static/blog/bondex/paimon-dwd.png
similarity index 100%
rename from static/blog/Bondex/paimon-dwd.png
rename to static/blog/bondex/paimon-dwd.png
diff --git a/static/blog/Bondex/paimon-dwm.png 
b/static/blog/bondex/paimon-dwm.png
similarity index 100%
rename from static/blog/Bondex/paimon-dwm.png
rename to static/blog/bondex/paimon-dwm.png
diff --git a/static/blog/Bondex/paimon-dws.png 
b/static/blog/bondex/paimon-dws.png
similarity index 100%
rename from static/blog/Bondex/paimon-dws.png
rename to static/blog/bondex/paimon-dws.png
diff --git a/static/blog/Bondex/paimon-ods.png 
b/static/blog/bondex/paimon-ods.png
similarity index 100%
rename from static/blog/Bondex/paimon-ods.png
rename to static/blog/bondex/paimon-ods.png
diff --git a/static/blog/Bondex/paimon_catalog_setting.png 
b/static/blog/bondex/paimon_catalog_setting.png
similarity index 100%
rename from static/blog/Bondex/paimon_catalog_setting.png
rename to static/blog/bondex/paimon_catalog_setting.png
diff --git a/static/blog/Bondex/pipline.png b/static/blog/bondex/pipline.png
similarity index 100%
rename from static/blog/Bondex/pipline.png
rename to static/blog/bondex/pipline.png
diff --git a/static/blog/Bondex/pod_template.png 
b/static/blog/bondex/pod_template.png
similarity index 100%
rename from static/blog/Bondex/pod_template.png
rename to static/blog/bondex/pod_template.png
diff --git a/static/blog/Bondex/pom.jpg b/static/blog/bondex/pom.jpg
similarity index 100%
rename from static/blog/Bondex/pom.jpg
rename to static/blog/bondex/pom.jpg
diff --git a/static/blog/Bondex/realtime_warehouse.png 
b/static/blog/bondex/realtime_warehouse.png
similarity index 100%
rename from static/blog/Bondex/realtime_warehouse.png
rename to static/blog/bondex/realtime_warehouse.png
diff --git a/static/blog/Bondex/source.png b/static/blog/bondex/source.png
similarity index 100%
rename from static/blog/Bondex/source.png
rename to static/blog/bondex/source.png
diff --git a/static/blog/Bondex/status_log.png 
b/static/blog/bondex/status_log.png
similarity index 100%
rename from static/blog/Bondex/status_log.png
rename to static/blog/bondex/status_log.png
diff --git a/static/blog/Bondex/streaming_warehouse.png 
b/static/blog/bondex/streaming_warehouse.png
similarity index 100%
rename from static/blog/Bondex/streaming_warehouse.png
rename to static/blog/bondex/streaming_warehouse.png
diff --git a/static/blog/LTYW/contribution_and_enhancement.png 
b/static/blog/chinaunion/contribution_and_enhancement.png
similarity index 100%
rename from static/blog/LTYW/contribution_and_enhancement.png
rename to static/blog/chinaunion/contribution_and_enhancement.png
diff --git a/static/blog/LTYW/data_processing_processes.png 
b/static/blog/chinaunion/data_processing_processes.png
similarity index 100%
rename from static/blog/LTYW/data_processing_processes.png
rename to static/blog/chinaunion/data_processing_processes.png
diff --git a/static/blog/LTYW/development_efficiency.png 
b/static/blog/chinaunion/development_efficiency.png
similarity index 100%
rename from static/blog/LTYW/development_efficiency.png
rename to static/blog/chinaunion/development_efficiency.png
diff --git a/static/blog/LTYW/devops_platform.png 
b/static/blog/chinaunion/devops_platform.png
similarity index 100%
rename from static/blog/LTYW/devops_platform.png
rename to static/blog/chinaunion/devops_platform.png
diff --git a/static/blog/LTYW/difficulties.png 
b/static/blog/chinaunion/difficulties.png
similarity index 100%
rename from static/blog/LTYW/difficulties.png
rename to static/blog/chinaunion/difficulties.png
diff --git a/static/blog/LTYW/job_management.png 
b/static/blog/chinaunion/job_management.png
similarity index 100%
rename from static/blog/LTYW/job_management.png
rename to static/blog/chinaunion/job_management.png
diff --git a/static/blog/LTYW/multi_team_support.png 
b/static/blog/chinaunion/multi_team_support.png
similarity index 100%
rename from static/blog/LTYW/multi_team_support.png
rename to static/blog/chinaunion/multi_team_support.png
diff --git a/static/blog/LTYW/multiple_environments_and_components.png 
b/static/blog/chinaunion/multiple_environments_and_components.png
similarity index 100%
rename from static/blog/LTYW/multiple_environments_and_components.png
rename to static/blog/chinaunion/multiple_environments_and_components.png
diff --git a/static/blog/LTYW/multiple_execution_modes.png 
b/static/blog/chinaunion/multiple_execution_modes.png
similarity index 100%
rename from static/blog/LTYW/multiple_execution_modes.png
rename to static/blog/chinaunion/multiple_execution_modes.png
diff --git a/static/blog/LTYW/operational_background.png 
b/static/blog/chinaunion/operational_background.png
similarity index 100%
rename from static/blog/LTYW/operational_background.png
rename to static/blog/chinaunion/operational_background.png
diff --git a/static/blog/LTYW/overall_architecture.png 
b/static/blog/chinaunion/overall_architecture.png
similarity index 100%
rename from static/blog/LTYW/overall_architecture.png
rename to static/blog/chinaunion/overall_architecture.png
diff --git a/static/blog/LTYW/platform_background.png 
b/static/blog/chinaunion/platform_background.png
similarity index 100%
rename from static/blog/LTYW/platform_background.png
rename to static/blog/chinaunion/platform_background.png
diff --git a/static/blog/LTYW/platform_evolution.png 
b/static/blog/chinaunion/platform_evolution.png
similarity index 100%
rename from static/blog/LTYW/platform_evolution.png
rename to static/blog/chinaunion/platform_evolution.png
diff --git a/static/blog/LTYW/platformized_management.png 
b/static/blog/chinaunion/platformized_management.png
similarity index 100%
rename from static/blog/LTYW/platformized_management.png
rename to static/blog/chinaunion/platformized_management.png
diff --git a/static/blog/LTYW/road_map.png b/static/blog/chinaunion/road_map.png
similarity index 100%
rename from static/blog/LTYW/road_map.png
rename to static/blog/chinaunion/road_map.png
diff --git a/static/blog/LTYW/state_optimization.png 
b/static/blog/chinaunion/state_optimization.png
similarity index 100%
rename from static/blog/LTYW/state_optimization.png
rename to static/blog/chinaunion/state_optimization.png
diff --git a/static/blog/LTYW/state_recovery.png 
b/static/blog/chinaunion/state_recovery.png
similarity index 100%
rename from static/blog/LTYW/state_recovery.png
rename to static/blog/chinaunion/state_recovery.png
diff --git a/static/blog/LTYW/status_acquisition_bottleneck.png 
b/static/blog/chinaunion/status_acquisition_bottleneck.png
similarity index 100%
rename from static/blog/LTYW/status_acquisition_bottleneck.png
rename to static/blog/chinaunion/status_acquisition_bottleneck.png
diff --git a/static/blog/LTYW/submission_process.png 
b/static/blog/chinaunion/submission_process.png
similarity index 100%
rename from static/blog/LTYW/submission_process.png
rename to static/blog/chinaunion/submission_process.png
diff --git a/static/blog/LTYW/versioning.png 
b/static/blog/chinaunion/versioning.png
similarity index 100%
rename from static/blog/LTYW/versioning.png
rename to static/blog/chinaunion/versioning.png
diff --git a/static/blog/Joyme/add_dependency.png 
b/static/blog/joyme/add_dependency.png
similarity index 100%
rename from static/blog/Joyme/add_dependency.png
rename to static/blog/joyme/add_dependency.png
diff --git a/static/blog/Joyme/add_projectconfiguration.png 
b/static/blog/joyme/add_projectconfiguration.png
similarity index 100%
rename from static/blog/Joyme/add_projectconfiguration.png
rename to static/blog/joyme/add_projectconfiguration.png
diff --git a/static/blog/Joyme/alarm_eamil.png 
b/static/blog/joyme/alarm_eamil.png
similarity index 100%
rename from static/blog/Joyme/alarm_eamil.png
rename to static/blog/joyme/alarm_eamil.png
diff --git a/static/blog/Joyme/application_interface.png 
b/static/blog/joyme/application_interface.png
similarity index 100%
rename from static/blog/Joyme/application_interface.png
rename to static/blog/joyme/application_interface.png
diff --git a/static/blog/Joyme/application_job.png 
b/static/blog/joyme/application_job.png
similarity index 100%
rename from static/blog/Joyme/application_job.png
rename to static/blog/joyme/application_job.png
diff --git a/static/blog/Joyme/checkpoint_configuration.png 
b/static/blog/joyme/checkpoint_configuration.png
similarity index 100%
rename from static/blog/Joyme/checkpoint_configuration.png
rename to static/blog/joyme/checkpoint_configuration.png
diff --git a/static/blog/Joyme/email_setting.png 
b/static/blog/joyme/email_setting.png
similarity index 100%
rename from static/blog/Joyme/email_setting.png
rename to static/blog/joyme/email_setting.png
diff --git a/static/blog/Joyme/flink_system.png 
b/static/blog/joyme/flink_system.png
similarity index 100%
rename from static/blog/Joyme/flink_system.png
rename to static/blog/joyme/flink_system.png
diff --git a/static/blog/Joyme/project_configuration.png 
b/static/blog/joyme/project_configuration.png
similarity index 100%
rename from static/blog/Joyme/project_configuration.png
rename to static/blog/joyme/project_configuration.png
diff --git a/static/blog/Joyme/start_log.png b/static/blog/joyme/start_log.png
similarity index 100%
rename from static/blog/Joyme/start_log.png
rename to static/blog/joyme/start_log.png
diff --git a/static/blog/Joyme/system_setting.png 
b/static/blog/joyme/system_setting.png
similarity index 100%
rename from static/blog/Joyme/system_setting.png
rename to static/blog/joyme/system_setting.png
diff --git a/static/blog/Joyme/yarn_log.png b/static/blog/joyme/yarn_log.png
similarity index 100%
rename from static/blog/Joyme/yarn_log.png
rename to static/blog/joyme/yarn_log.png
diff --git a/static/blog/SF/achievements1.png 
b/static/blog/shunwang/achievements1.png
similarity index 100%
rename from static/blog/SF/achievements1.png
rename to static/blog/shunwang/achievements1.png
diff --git a/static/blog/SF/achievements2.png 
b/static/blog/shunwang/achievements2.png
similarity index 100%
rename from static/blog/SF/achievements2.png
rename to static/blog/shunwang/achievements2.png
diff --git a/static/blog/SF/alarm.png b/static/blog/shunwang/alarm.png
similarity index 100%
rename from static/blog/SF/alarm.png
rename to static/blog/shunwang/alarm.png
diff --git a/static/blog/SF/application.png 
b/static/blog/shunwang/application.png
similarity index 100%
rename from static/blog/SF/application.png
rename to static/blog/shunwang/application.png
diff --git a/static/blog/SF/autor.png b/static/blog/shunwang/autor.png
similarity index 100%
rename from static/blog/SF/autor.png
rename to static/blog/shunwang/autor.png
diff --git a/static/blog/SF/cluster.png b/static/blog/shunwang/cluster.png
similarity index 100%
rename from static/blog/SF/cluster.png
rename to static/blog/shunwang/cluster.png
diff --git a/static/blog/SF/connectors.png b/static/blog/shunwang/connectors.png
similarity index 100%
rename from static/blog/SF/connectors.png
rename to static/blog/shunwang/connectors.png
diff --git a/static/blog/SF/function.png b/static/blog/shunwang/function.png
similarity index 100%
rename from static/blog/SF/function.png
rename to static/blog/shunwang/function.png
diff --git a/static/blog/SF/homework.png b/static/blog/shunwang/homework.png
similarity index 100%
rename from static/blog/SF/homework.png
rename to static/blog/shunwang/homework.png
diff --git a/static/blog/SF/homework_manager.png 
b/static/blog/shunwang/homework_manager.png
similarity index 100%
rename from static/blog/SF/homework_manager.png
rename to static/blog/shunwang/homework_manager.png
diff --git a/static/blog/SF/launcher.png b/static/blog/shunwang/launcher.png
similarity index 100%
rename from static/blog/SF/launcher.png
rename to static/blog/shunwang/launcher.png
diff --git a/static/blog/SF/logs.png b/static/blog/shunwang/logs.png
similarity index 100%
rename from static/blog/SF/logs.png
rename to static/blog/shunwang/logs.png
diff --git a/static/blog/SF/management.png b/static/blog/shunwang/management.png
similarity index 100%
rename from static/blog/SF/management.png
rename to static/blog/shunwang/management.png
diff --git a/static/blog/SF/pain.png b/static/blog/shunwang/pain.png
similarity index 100%
rename from static/blog/SF/pain.png
rename to static/blog/shunwang/pain.png
diff --git a/static/blog/SF/permission.png b/static/blog/shunwang/permission.png
similarity index 100%
rename from static/blog/SF/permission.png
rename to static/blog/shunwang/permission.png
diff --git a/static/blog/SF/queue.png b/static/blog/shunwang/queue.png
similarity index 100%
rename from static/blog/SF/queue.png
rename to static/blog/shunwang/queue.png
diff --git a/static/blog/SF/sql_client.png b/static/blog/shunwang/sql_client.png
similarity index 100%
rename from static/blog/SF/sql_client.png
rename to static/blog/shunwang/sql_client.png
diff --git a/static/blog/SF/sql_develop.png 
b/static/blog/shunwang/sql_develop.png
similarity index 100%
rename from static/blog/SF/sql_develop.png
rename to static/blog/shunwang/sql_develop.png
diff --git a/static/blog/SF/step.png b/static/blog/shunwang/step.png
similarity index 100%
rename from static/blog/SF/step.png
rename to static/blog/shunwang/step.png

Reply via email to