企业官网建设流程全解析

.net网站源码下载,怎么把网站关联到万网,网站logo修改,沈阳工程信息造价网1. Flink OLAP 服务整体架构 Flink OLAP 服务由三部分组成#xff1a; Client#xff08;客户端#xff09; 任何能和 Flink SQL Gateway 交互的客户端都行#xff1a;SQL Client、Flink JDBC Driver 等 Flink SQL Gateway 负责解析 SQL、元数据查找、统计信息分析、优化…1. Flink OLAP 服务整体架构Flink OLAP 服务由三部分组成Client客户端任何能和 Flink SQL Gateway 交互的客户端都行SQL Client、Flink JDBC Driver 等Flink SQL Gateway负责解析 SQL、元数据查找、统计信息分析、优化执行计划然后把 JobGraph 提交到集群Flink Session ClusterSession 集群OLAP 查询运行在 Session 集群上主要目的是避免每次查询都启动集群的额外开销你可以把它理解成Client 提交 SQL → SQL Gateway 做“编译/优化/生成作业” → Session 集群执行。为什么 Flink 做 OLAP 有优势大规模并行MPPFlink 天生是并行计算系统Planner 可以调整并行度来适配不同数据规模的延迟目标资源弹性资源管理支持 min/max scaling能随工作负载动态伸缩尤其在 K8s 上更明显复用生态 Connector直接复用 Flink 丰富的 Connector读各种数据源、写各种下游统一引擎Streaming / Batch / OLAP 统一一套引擎与开发体验团队成本更低2. 本地快速跑通Local Mode2.1 准备Java 11先确认 Java 版本Quickstart 里要求至少 Java 11java-version下载并解压 Flink 二进制包tar-xzfflink-*.tgz2.2 启动本地集群./bin/start-cluster.sh启动后打开 Flink Web UI本地默认http://localhost:8081你应该能看到集群已启动。2.3 启动 SQL Client CLI内嵌 Gateway./bin/sql-client.sh2.4 跑一条 OLAP 风格聚合查询先把结果模式设置成 table示例里用 tableauSETsql-client.execution.result-modetableau;创建一个 datagen 表模拟 Orders10 万行CREATETABLEOrders(order_numberBIGINT,priceDECIMAL(32,2),buyerROWfirst_name STRING,last_name STRING,order_timeTIMESTAMP(3))WITH(connectordatagen,number-of-rows100000);执行聚合 排序 TopNSELECTbuyer,SUM(price)AStotal_costFROMOrdersGROUPBYbuyerORDERBYtotal_costLIMIT3;执行后去 Web UIhttp://localhost:8081里看 Job 详情你能直观看到查询如何被拆成算子、如何并行执行。3. 生产部署要点Production Ready真正要把 Flink 用成“OLAP 服务”关键点是稳定、低冷启动、低端到端延迟E2E、更好的资源利用率。Quickstart 给了一个非常典型的生产形态Flink Session Cluster长期在线承载 OLAP 查询Flink SQL Gateway无状态服务可水平扩展Client推荐 JDBC Driver更适合生产连接管理3.1 Client优先用 Flink JDBC Driver并复用连接生产提交查询推荐 Flink JDBC Driver因为它提供底层连接管理能力。最关键的实践是尽量复用 JDBC 连接避免频繁创建/关闭 Gateway session这样可以显著降低 E2E 查询延迟尤其是短查询、交互式场景3.2 集群Session 模式 Native Kubernetes生产建议用 Native Kubernetes 的 session mode 部署 Session Cluster动态分配/回收 TaskManager承载波峰波谷更友好并且推荐配置slotmanager.number-of-slots.min它的意义是预留一部分“随时可用”的 slot 作为资源池明显降低查询冷启动时间Quickstart 里提到这和 FLIP-362 相关。3.3 SQL Gateway无状态 服务发现 负载均衡Gateway 推荐作为无状态微服务部署多实例注册到服务发现客户端做负载均衡把查询均匀打到各 Gateway 实例这样做的收益是提升可用性、避免单点、扩容简单。3.4 数据源配置Catalog 与 Connector 管理CatalogOLAP 场景建议配置 Catalog StoreQuickstart 提到 FileCatalogStore因为 OLAP 集群是长期运行服务Catalog 信息变化不频繁跨 session 复用可以减少冷启动成本ConnectorsSession Cluster 和 SQL Gateway 都依赖 connectors分析 stats、读取数据源生产要把 connectors 的交付和版本治理当成“基础设施”不要临时手动拷 jar4. 推荐的生产配置与背后原因下面是 Quickstart 提到的一组“很 OLAP 的配置”我按模块解释一下它们为什么有用。4.1 SQL Table 选项table.optimizer.join-reorder-enabled true开启 join reorder 可以让优化器选择更优 join 顺序对复杂多表查询收益明显pipeline.object-reuse true对象复用减少 GC 压力提升吞吐和延迟稳定性sql-gateway.session.plan-cache.enabled true计划缓存能减少重复查询的编译/优化成本OLAP 场景非常实用4.2 RuntimeOLAP 查询要用 BATCH 运行模式execution.runtime-mode BATCHexecution.batch-shuffle-mode ALL_EXCHANGES_PIPELINED原因Quickstart 说得很关键OLAP 查询的执行计划里可能同时出现 pipelined 与 blocking 边Batch scheduler 可以按 stage 调度避免某些场景的调度死锁风险pipelined shuffle 能降低批查询延迟让链路更“实时交互”4.3 JDK 与 JVMJDK17 ZGC code cache 调优Quickstart 推荐JDK 版本17JVM 参数额外-XX:PerMethodRecompilationCutoff10000-XX:PerBytecodeRecompilationCutoff10000-XX:ReservedCodeCacheSize512M-XX:UseZGC背后逻辑JDK17 ZGC 能显著降低停顿时间OLAP 场景对“尾延迟”非常敏感CodeCache 与 recompilation cutoff 调优更偏向稳定长时间运行的服务形态4.4 调度/容错/重启策略更像“查询服务”而不是“长跑作业”jobmanager.execution.failover-strategy fullrestart-strategy.type disablejobstore.type Memoryjobstore.max-capacity 500OLAP 查询通常是短作业或高频作业更希望失败时快速失败并由上层重试/兜底而不是集群内部反复重启拖时间jobstore 放内存更快容量限制避免无限膨胀4.5 网络与 Web面向高并发查询的服务化调优rest.server.numThreads 32提升 REST 并发处理能力Gateway/集群交互更密集web.refresh-interval 300000降低 Web UI 刷新频率避免 UI 本身成为额外负担pekko.framesize 104857600b增大通信 frame适配更复杂计划/更大消息4.6 资源管理TaskManager 与 JobManager 都要“够大”Quickstart 的资源建议非常激进典型 OLAP 配置思路JM2 副本K8sJM CPU16JM memory32gTM CPU16TM slots32TM memory65536m64gmanaged memory16384m16gslotmanager.number-of-slots.min taskManagerNumber * numberOfTaskSlots核心思想OLAP 更倾向“单查询把计算尽量放在本地、减少网络/序列化”TM 配大一些能减少 shuffle、降低反序列化开销整体更快更稳JM 也要配大因为它是计算与调度的单点5. 一些落地经验把“可用性”和“低冷启动”做扎实你可以把 OLAP 服务的体验拆成三块去优化查询冷启动预留 slotslotmanager.number-of-slots.min复用 JDBC 连接启用 plan cache复用 catalog store尾延迟稳定性JDK17 ZGCobject reuse控制 Web UI 刷新与 REST 线程池TM 资源不要太“碎片化”大 TM 更利于局部计算运维友好Gateway 无状态多副本Session 集群独立出来不跟别的 workload 混跑connector 与 catalog 的版本治理避免“今天能查明天 jar 不见了”6. Future Work社区路线与相关 TicketsQuickstart 提到 Flink OLAP 已在 Roadmap 中相关工作追踪在https://issues.apache.org/jira/browse/FLINK-25318 https://issues.apache.org/jira/browse/FLINK-32898如果你准备在生产上深用 Flink OLAP建议持续关注这些票据的进展很多性能、可用性、冷启动体验的改进都会在这里推进。