为了解决公司模型&特征迭代的系统性问题，提升算法开发与迭代效率，部门立项了特征平台项目。特征平台旨在解决数据存储分散、口径重复、提取复杂、链路过长等问题，在大数据与算法间架起科学桥梁，提供强有力的样本及特征数据支撑。平台从 Hive 、Hbase 结合关系型数据库等大数据 ODS ( Operational Data store ) 层、DWD、DWS层进行快速的数据 ETL ，将数据抽取到特征平台进行管理，并统一了数据出口，供数据科学家、数据工程师、机器学习工程师做算法模型的数据测试、训练、推理及其他数据应用。
由于容器化易管理、易扩容等优点，越来越多的组件都开始迁移到容器上，k8s作为容器化的事实标准，受到了越来越多的人的青睐，由于我们目前很多web开发的组件也是部署到k8s上的，为了后续运维更加方便，我把我们用到的一些大数据组件都迁移到了k8s，包括hive、trino、flink、clickhouse等等。
Flink 1.12 版本在 20 年 12 月已经正式 Release，目前我们的 Flink SQL 作业的 Flink 引擎版本还是 1.10，本文主要用以评估 Flink 1.10 升级到 1.12 整体所能带来的预期收益，同时结合所需投入的成本，决定是否需要升级 Flink SQL 引擎版本到 1.12。本次升级所评估的收益包含 1.11 和 1.12 版本所带来的收益，如有理解错误，欢迎指出，一起交流。
Kubernetes 相信大家都比较熟悉，近两年大家都在讨论云原生的话题，讨论 Kubernetes。那么什么是 Kubernetes 呢？
flink支持多种部署模式，比如standalone、sesson、per job、application，一般在生产环境我们都是将flink程序部署到k8s或者yarn等资源管理器上。目前k8s部署模式暂时不支持per job模式。不过由于k8s部署flink集群相对yarn要落后一些，是在最近几个版本才慢慢完善的，所以我猜测市面上很多公司还是以yarn为主，逐渐尝试k8s。
https://blog.csdn.net/zjerryj/article/details/100063858
之前文章介绍了 Flink session cluster on Kubernetes，需要注意，这种部署方式，可以在同一个 Cluster 上多次提交 Flink Job，而本文介绍的，是一种将任务和镜像绑定的部署方式，即 Flink 集群是不共享的，其组件是单独属于一个 Job。
Session 模式和 Per Job 模式的应用场景不一样。Per Job 模式比较适合那种对启动时间不敏感，运行时间较长的任务。
Flink session cluster 是作为 K8S 的 Deployment，Flink 的作业会被提交到 session cluster。至于什么是 Deployment，不清楚的同学可以看Deployment。Flink session cluster 会包含以下组件:
Flink作为新一代的大数据处理引擎，不仅是业内公认的最好的流处理引擎，而且具备机器学习等多种强大计算功能，用户只需根据业务逻辑开发一套代码，无论是全量数据还是增量数据，亦或者实时处理，一套方案即可全部解决。K8S是业内最流行的容器编排工具，与docker容器技术结合，可以提供比Yarn与Mesos更强大的集群资源管理功能，成为容器云的主要解决方案之一。如果能将两者结合，无疑是双剑合璧，对生产效能有着巨大的提升。本文将介绍目前为止，Flink On K8S的最前沿实现方案。
以 Flink 和 Spark 为代表的分布式流批计算框架的下层资源管理平台逐渐从 Hadoop 生态的 YARN 转向 Kubernetes 生态的 k8s 原生 scheduler 以及周边资源调度器，比如 Volcano 和 Yunikorn 等。这篇文章简单比较一下两种计算框架在 Native Kubernetes 的支持和实现上的异同，以及对于应用到生产环境我们还需要做些什么。
Flink Forward Asia 2020 三天的分享已经结束，在这次分享上，自己也收获到了很多。这里写一篇文章来记录下自己这次的收获和总结，从个人的视角以及理解，和大家一起分享下，当然，如果有理解错误的地方，也欢迎大家指出。
摘要：本文整理自集度汽车数据部门实时方向负责人、 Apache Flink Contributor 周磊&集度汽车数据开发专家顾云，在 FFA 2022 行业案例专场的分享。本篇内容主要分为四个部分：
摘要：本文介绍了 dinky 在 Flink on Kubernetes 的实践分享。内容包括：
摘要：本文介绍了安家老师带来的的 Dinky 在 K8S 上进行整库同步的实践分享。内容包括：
在小编的记忆里，Flink 自从出现在大众视野中，一直在高速迭代。Flink1.10版本之前因为重大功能的缺失(主要是和Hive的兼容性)，笔者一直都不推荐直接应用在大规模的生产实践中，可以做小范围内业务尝试。Flink 1.10版本可以被认为是一个承上启下的革命性版本。
ChunJun（原 FlinkX）是一个基于 Flink 提供易用、稳定、高效的批流统一的数据集成工具。2018 年 4 月，秉承着开源共享的理念，数栈技术团队在 github 上开源了 FlinkX，承蒙各位开发者的合作共建，FlinkX 得到了快速发展。
近些年随着云计算和云原生应用的兴起，容器技术可以很好地解决许多问题，所以将大数据平台容器化是一种理想的方案。本文将结合袋鼠云数栈在Flink on Kubernetes的实践让您对大数据平台容器化的操作和价值有初步的了解。
随着有赞实时计算业务场景全部以Flink SQL的方式接入，对有赞现有的引擎版本—Flink 1.10的SQL能力提出了越来越多无法满足的需求以及可以优化的功能点。目前有赞的Flink SQL是在Yarn上运行，但是在公司应用容器化的背景下，可以统一使用公司K8S资源池，同时考虑到任务之间的隔离性以及任务的弹性调度，Flink SQL任务K8S化是必须进行的，所以我们也希望通过这次升级直接利社区的on K8S能力，直接将FlinkSQL集群迁移到K8S上。特别是社区在Flink 1.13中on Native K8S能力的支持完善，为了紧跟社区同时提升有赞实时计算引擎的能力，经过一些列调研，我们决定将有赞实时计算引擎由Flink 1.10升级到Flink 1.13.2。
ChunJun（原FlinkX）是一个基于 Flink 提供易用、稳定、高效的批流统一的数据集成工具。2018年4月，秉承着开源共享的理念，数栈技术团队在github上开源了FlinkX，承蒙各位开发者的合作共建，FlinkX得到了快速发展。
作者：龙逸尘，腾讯 CSIG 高级工程师 腾讯云原生实时数仓建设实践 实时数仓面临的挑战 实时数仓被广泛应用于腾讯各大业务，涉及的平台众多，从统计信息中可以看出，集群规模庞大，数据量极大。 复杂的使用场景和超大的数据量，导致我们在实时数仓的建设与使用过程中遇到许多挑战。 时效性 数仓使用者对时效性有非常强烈的诉求：希望查询响应更快，看板更新更及时，指标开发更快完成。因为时效性越高，数据价值也就越高。如何保障数仓的时效性是首要难题。 架构复杂度 如何在保障时效性的同时，降低架构复杂度以减少开发和维护成本，
随着 Flink k8s 化以及实时集群迁移完成，有赞越来越多的 Flink 实时任务运行在 K8s 集群上，Flink k8s 化提升了实时集群在大促时弹性扩缩容能力，更好的降低大促期间机器扩缩容的成本。同时，由于 K8s 在公司内部有专门的团队进行维护，Flink k8s 化也能够更好的减低公司的运维成本。
在大数据行业里，2006 年 Hadoop 的诞生，给我们带来了变革意义的改变，大数据生态组件也开始层出不穷。各种不同体型的企业都喜欢选择开源大数据软件来搭建自己的系统，无论是先前十分繁荣的 Hadoop，还是后来涌现出来的 Kafka、Flink 等，都被广泛地使用着。
留言有奖 腾讯云容器产品技术产品月报 6月版，请阅。 继续给大伙薅羊毛的机会呀，点赞数最高的前 20条留言，送惊喜礼物哦~ 云原生 新势力 云原生新势力，新鲜出炉、热气腾腾的产品新特性，总有一款牵动你的心~ 腾讯云容器服务公有云版TKE ● 高可扩展和高性能容器管理服务 1. IPVS-bpf模式上线。 性能提升40%: 腾讯 TKE 用 eBPF绕过 conntrack 优化K8s Service，短连接性能提升40% 以上，p99 时延降低31% 以上。 2. CLB直通弹性网卡模式的Pod，
Flink SQL Gateway是一项允许多个客户端从远程并发执行 SQL 的服务。 它提供了一种简单的方法来提交 Flink 作业、查找元数据并在线分析数据。在Flink 1.16版本，官方即将SQL Gateway其合入Flink主线。可正式通过Flink官方包安装与启动Flink SQL Gateway。本为以Flink 1.17版本为例，介绍一种在K8s中启动Flink SQL Gateway，并连接到通过Flink kubernetes operator启动的Flink Session集群上。
这种模式我们一般是在用IDE调试程序的时候用到,当我们在本地用IDE开发程序的时候，执行main方法，flink会在本地启动一个包含jobmanager和taskmanager的进程的minicluster，程序运行完成之后，这个cluster进程退出。
无界数据是持续产生的数据，所以必须持续的处理无界数据流。因为输入是无限的，没有终止时间。处理无界数据通常要求以特定顺序获取，以便判断事件是否完整、有无遗漏。
Kubernetes 是一种流行的容器编排系统，用于自动化计算机应用程序的部署、扩展和管理。 Flink 的原生 Kubernetes 集成允许您直接在运行的 Kubernetes 集群上部署 Flink。 此外，Flink 能够根据所需资源动态分配和取消分配 TaskManager，因为它可以直接与 Kubernetes 对话。
摘要：本文介绍了 Dlink 的 Roadmap，站在巨人肩膀上的它，是否真的未来可期？内容包括：
随着互联网技术的广泛使用，信息的实时性对业务的开展越来越重要，特别是业务的异常信息，没滞后一点带来的就是直接的经济损失。所以实时信息处理能力，越来越成为企业的重要竞争力之一。Flink作为业内公认的性能最好的实时计算引擎，以席卷之势被各大公司用来进处理实时数据。然而Flink任务开发成本高，运维工作量大，面对瞬息万变得业务需求，工程师往往是应接不暇。如果能有一套实时计算平台，让工程师或者业务分析人员通过简单的SQL或者拖拽式操作就可以创建Flink任务，无疑可以快速提升业务的迭代能力。
本文是《K8S环境的Jenkin性能问题处理》的续篇，上一篇解决了Jenkins集群中的Master节点的性能问题，但是真正执行任务的并非Master节点，而是为每个任务临时创建的Pod，这些Pod的性能问题决定着任务的快慢甚至成败；
采访嘉宾｜王峰（莫问） 作者 | Tina 作为最活跃的大数据项目之一，Flink 进入 Apache 软件基金会顶级项目已经有八年了。 Apache Flink 是一款实时大数据分析引擎，同时支持流批执行模式，并与 Hadoop 生态可以无缝对接。2014 年，它被接纳为 Apache 孵化器项目，仅仅几个月后，它就成为了 Apache 的顶级项目。 对于 Flink 来说，阿里有非常适合的流式场景。作为 Flink 的主导力量，阿里从 2015 年开始调研 Flink，并于 2016 年第一次在搜
摘要：本文介绍了某零售企业用户基于 Dlink + FlinkSQL 构建批流一体数据平台的实践，主要为部署的分享。内容包括：
今天我们主要讲一下如何通过api的方式来停止一个通过per job模式部署在yarn集群上的任务。
Apache YuniKorn（Incubating）是一个独立的资源调度程序，旨在将针对大数据工作负载的高级调度功能引入容器化平台。具体可以参考前面的文章《YuniKorn：一个通用的资源调度程序》。
作者｜江烁 本文整理自 Pulsar Summit Asia 2022 上腾讯互娱 GDP 微服务开发平台网关技术负责人江烁的演讲《打通 Apache Pulsar 与 Envoy，构建高效游戏 OTO 营销平台实践》。本文将介绍介绍腾讯互娱利用 Apache Pulsar 和 Envoy 运营游戏 OTO 营销平台的经验。 腾讯互动娱乐旗下涵盖腾讯游戏、腾讯文学、腾讯动漫等多个互动娱乐业务平台。其中，腾讯游戏注册用户超过 8 亿。2022 年 6 月，腾讯游戏旗下王者荣耀日活跃用户数量超过 1 亿 6
摘要：本文整理自中泰证券大数据中心实时计算平台架构师连序全，在 Flink Forward Asia 2022 行业案例专场的分享。本篇内容主要分为四个部分：
ZOOKEEPER 3节点 FLINK JOB-MANAGER 3节点 每个节点一个pod FLINK TASK-MANAGER N节点 通过k8s replicas 扩缩容 负载均衡 1节点
背景：使用的 VictoriaMetrics(简称 VM) 作为监控的解决方案，需要将 django 服务、logstash 和 flink 引擎接入进来，VM 可以实时的获取它们的指标存储并进行监控告警，以上的服务都是部署在 k8s 中的。
目前 Flink 社区正如火如荼的发展，但苦于没有一款适合 Flink SQL 界面化开发的工具，于是增加了 Flink 的门槛与成本。虽然官方提供了 SQL Client，但仍有很多局限与不方便。
ChunJun（原FlinkX）是一个基于Flink提供易用、稳定、高效的批流统一的数据集成工具，是袋鼠云一站式大数据开发平台-数栈DTinsight的核心计算引擎，其技术架构基于实时计算框架Flink，打造出“具有袋鼠特色”的实时计算引擎。
目前对于flink来说，生产环境一般有两个部署模式，一个是 session模式，一个是per job模式。
Kubernetes中，应用服务使用ingress暴露后，默认是没有账号密码限制的，只要知道ingress的地址，所有人都可以访问服务(除非应用中有账号密码限制)，那么是否可以在k8s中给in
大数据文摘出品 作者：迟慧 随着行业的快速发展和业务的高速迭代，数据量也呈爆炸式增长，大数据云原生化逐渐成为企业数字化转型的重要演进方向。数字化驱动企业提升运营效率，洞察商业机会；云原生化提升 IT 系统效率，促进业务敏捷，大数据云原生化是为企业创新提供无限可能。 大势所趋：云原生大数据 传统的大数据架构在资源利用、高效运维、可观测性等方面存在诸多不足，已经越来越无法适应当下的发展需求。具体来讲，传统大数据架构主要存在以下几方面的问题： 传统大数据组件繁多，安装运维复杂，在生产使用中需要大量的人力支持； 在
本次Release版本修复1.2K个问题，对Flink作业的整体性能和稳定性做了重大改进，同时增加了对K8S，Python的支持。
使用ES来查询业务日志在开发中是非常常见的一种方式，典型的解决方案是ELK，已经非常成熟了。Flink是一个比较年轻的开源项目，已经发展了好几年，但是周边的生态还是不是很完善，比如日志收集其实不太友好，比如session模式想要按job收集日志就做不到，另外比较流行的是yarn和k8s模式，k8s理论上应该是比较容易收日志的，越来越多的公司大量java应用都跑在k8s里。日志收集这块也限制只能用商业产品，不好用。我们希望接到es里
随着云平台、容器等技术的不断成熟，云原生大数据解决了传统大数据平台建设和运维中的繁琐，使即时可得，按需分配的高效大数据开发平台成为可能。 云原生的到来不止为大数据部署和交付带来了变革，它更是帮助大数据连接了一个生态。利用云原生生态，真正做到了为大数据赋予云的能力，使得大数据可以“生长在云端”。 【腾讯云原生】收集了关于大数据云原生系列干货文8篇，帮助你更好了解”大数据云原生“，一定要收藏哦！ 技术原理 Apache Flink on K8s：四种运行模式，我该选择哪种？ 本文根据 Flink 在 Kuber
前面写了一些flink的基础组件，但是还没有说过flink的环境搭建，现在我们来说下基本的环境搭建 1. 使用StatefulSet的原因 对于Flink来说，使用sts的最大的原因是pod的hostname是有序的；这样潜在的好处有 hostname为-0和-1的pod可以直接指定为jobmanager；可以使用一个statefulset启动一个cluster，而deployment必须2个；Jobmanager和TaskManager分别独立的deployment pod由于各种原因fail后，由于StatefulSet重新拉起的pod的hostname不变，集群recover的速度理论上可以比deployment更快（deployment每次主机名随机） 2.使用StatefulSet部署Flink 2.1 docker的entrypoint 由于要由主机名来判断是启动jobmanager还是taskmanager，因此需要在entrypoint中去匹配设置的jobmanager的主机名是否有一致 传入参数为：cluster ha；则自动根据主机名判断启动那个角色；也可以直接指定角色名称 docker-entrypoint.sh的脚本内容如下：
原文链接：https://yq.aliyun.com/articles/717779
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
