实时计算

摘要：基于对数据工夫旅行的思考，引出了对目前三种数仓状态和两种数仓架构的思考。联合数据湖在 Flink 的利用和数据湖元数据类型的思考，摸索了基于数据湖的 Flink SQL 流批一体的实际，在流批一体 SQL 表白统一、后果一致性、流批工作拆散、混合调度依赖等进行了设计和摸索。同时，欢送大家多分享具体实际，一起共筑新的数据实际形式。一、数据的工夫旅行和业务对数据的实质要求大规模的数据处理衰亡于 Hadoop 生态的倒退，关键在于分布式贮存和分布式计算的倒退，造就了现在近百种无关大数据的生态技术。数仓实践和建模实践基于大数据技术体系得以疾速倒退，其中离线数仓的标准化建设失去了广泛应用。数据的实质是一种行为的具象，业务在对数据的需要，外围在于对行为的可摸索和可察看。基于此，咱们须要明确一点，大数据技术是否齐全满足了业务对数据需要在工夫维度上的确定性了呢，这点是值得思考的。那么咱们先来看一下数据的工夫旅行。 业务冀望的数据：用户空间下的工夫数据，t1工夫数据，用户天然工夫点或天然时间段的明细或者统计数据。 传输提早：App 用户，数据发送到网关或者日志服务零碎，或者 Server 日志落文件系统所产生的提早。Event 进入到存储空间，能够代表数据曾经是确定的，根本可察看，个别状况下，这个提早很小。然而，在某些状况，比方 APP 的日志产生之后，然而因为网络等问题始终没有发送，或者 Server 宕机，导致提早发送或者最终失落。总体而言，传输提早属于不可控提早，临时没有什么好的技术计划来解决。 存储空间：数据承载于理论的存储中，离线数仓承载于具体的分布式文件系统，实时数仓基于 Kafka 的音讯队列零碎，近实时数仓承载于数据湖存储中。这里能够形象来看离线数仓，Event 承载于分布式文件系统，以小时分区为例，某个小时的分区实质是天然工夫产生的文件的汇合，工夫精度进化为小时级别。 计算提早：数据进入存储之后，与进入计算空间的时间差，t3-t2。实时数仓中，计算提早是数据的 ProcessTime-IngestTime。离线数仓中，计算提早是调度产生实例运行工夫-数据进入存储空间的时间差。实质离线数仓和实时数仓的计算提早在形象上看是统一的。计算提早在不同的数仓体系下，产生的时效不同，咱们会划分为三种支流的数仓体系，秒级的实时数仓，分钟级的近实时数仓，小时级的离线数仓。能够看出，数仓的时效性差别，因为传输提早的不可控，进化为计算提早的差别。 二、离线、近实时、实时三种数仓在工夫维度下的成因在离线数仓和实时数仓，经常会提到数据的有界和无界，认为离线数仓的数据是有界的，实时数仓的音讯流是无界的。精确与否在于数据的确定性考量。 离线数仓的确定性，在于文件天然生成工夫的确定性和不可更改性，某个小时的天然文件生成，近似等于事件工夫在天然工夫的确定性，反例就是咱们能看到数据漂移的状况，事件工夫会或多或少落入上个小时或者下个小时的天然文件生成工夫。那么离线数仓的确定性，本质是数据的 IngestTime 的确定性，具备人造的文件属性，易于宰割。当咱们说离线数仓计算的数据是精确的时候，默认了传输提早带来的影响很小或者默认了以后小时的数据指标的规范是文件的天然造成工夫。 实时数仓，经常会提及不确定性或者说 Lambda 架构理论是对实时数仓的不确定性的代替计划。这种不确定性的起因是什么呢？这里分为四类状况阐明，一是 ETL 的解决，从窗口上来说，是单条数据即为一个窗口，窗口的产生和销毁在一个 Event 中实现，y=window(data)。二是基于 EventTime 的工夫窗口，如果再定义延迟时间，y=window(datas, datas.EventTime, delay)，第三种和第四种别离就是 IngestTime 和 ProcessTime 的工夫窗口函数。比照离线数仓，能够看出，基于 IngestTime 的工夫窗口和离线数仓的工夫语义最为统一。离线数仓在工夫窗口上，能够看做为数据进入文件的天然工夫所对应的小时窗口，数据所承载的文件的确定性，保障了小时窗口的数据确定性，y=window(files)。 近实时数仓，比方基于 Iceberg 的数据湖建设的近实时数仓，在于离线数仓比照中，理论是将基于小时文件细分到分钟级别的快照文件上来，y=window(snapshots)。比照实时数仓，因为 Kafka 的 IngestTime 目前在精确性上是不准确的，基于快照的文件划分，在精确性上有肯定的保障，同时在升高时效水平，从秒进化为分钟，很多场景是能够容忍的。 三种在工夫维度比照上看，一是在某个工夫，统计的实质对业务的需要都是近似的，这个实质是传输提早所带来的，然而这个在实践中，不影响数据的可用性和统计学意义。二是不同数仓的划分，是存储和计算技术倒退所带来的。三是离线数仓的确定性含糊了传输提早，实时数仓的不确定性，是对传输提早的一种取舍，人为的限定了 EventTime 的最大延迟时间，从而保障了指标的时效性，都是具备实际的意义所在。 三、Lambda 和 Kappa 架构在工夫维度下的取舍当离线数仓刚刚倒退的时候，只有一种数仓架构，也是基于大数据分布式解决刚刚倒退的起因。随着实时技术的倒退，大家在时效性上有了更多要求，然而同离线数仓比照的时候，在数据的准确性上，因为统计的窗口不同，必然会导致某个时刻的指标后果的不严格统一。 为了解决这种不严格统一的状况，Lambda 架构（由 Storm 的作者 Nathan Marz 提出的）产生的，实时确保时效，离线确保精确。最终会以确保离线三个工夫窗口的统计一个事件工夫窗口的后果，来回补实时数仓认为 EventTime 窗口，因为时效性抛弃的提早数据的后果，从而保障业务上对 EventTime 窗口的要求，或者默认为离线的 IngestTime 所产生的文件分区近似认为 EventTime 的工夫窗口。这种带来的弊病，保护两套数据路线，而大家总在想方法解决。 ...

FBEC将来商业生态链接大会于2023年2月24日在深圳福田大中华喜来登酒店隆重召开，本次大会由广东省游戏产业协会、深圳市互联网文化市场协会领导，陀螺科技主办。 大会以“勇毅前行·逐光而上”为主题，以具备行业前瞻洞察的“探索者”为视角，逐“光”之旅为主线，聚焦元宇宙、XR、游戏、电竞、数字营销等前沿行业，全方位出现科技前沿成绩，探讨时代与商业议题，筹划新科技、新商业、新模式将来价值，与时代同行者共赴巨变变革下的勇毅逐光之道！ FBEC主会场C：置信的力量——FBEC寰球元宇宙CEO峰会由武汉东湖新技术开发区治理委员会与陀螺科技联结主办，邀请到瑞云科技 CTO 赵志杰带来主题为“元宇宙时代的基础设施——实时云渲染”的精彩演讲。赵志杰认为，元宇宙将来的趋势必定是越来越粗劣、越来越宏大的场景建设，背地离不开实时云渲染技术的反对。 01 元宇宙的撑持技术之一是实时云渲染 我是来自瑞云科技的赵志杰，明天给大家分享对于实时云渲染方面的见解。 咱们的观点是：元宇宙的撑持技术之一是实时云渲染。元宇宙将来的趋势必定是越来越粗劣、越来越宏大的场景建设，如何撑持这些货色的实现，背地离不开实时云渲染技术的反对。 讲实时云渲染之前，先讲讲渲染这个概念。目前渲染和咱们的生存密不可分，无论影视作品，还是各种游戏的实现，背地都离不开渲染技术。以往的渲染过程通常都部署在本地端，当渲染过程部署在云端，咱们则称之为云渲染。目前的趋势，咱们心愿云渲染的能力越来越强，可能补救轻量化终端的低性能劣势。 对于最近比拟火的AIGC，AIGC其实也是渲染的体现形式，通过这种形式，会加强咱们在元宇宙当中体验的真实感、高级感，加强元宇宙的体验。在元宇宙当中，人们能够随时切换身份，在外面进行各种各样的操作，无论是学习，又或者工作、交友、购物、旅行等。为了实现更好的体验，更好的画面成果，咱们则须要更好的云端实时云渲染服务体系的撑持。 02 实时云渲染技术倒退依赖以下几个方面 实时云渲染技术能达到当初的倒退水平，次要依赖于以下几方面技术的晋升和推动： • 5G时代，5G网络带来了技术的引进； • 云计算的倒退为云计算提供了更好的扩展性，用户通过网络能够取得更好、更有限的资源。 • 游戏引擎的倒退，不仅是对游戏行业自身有微小的带动作用，尤其在真实性、模仿性等方面给用户带来了更好的体验。所以游戏引擎的根底倒退，对整个技术也有很大的推动作用。 • 还有显卡技术的倒退，对于所有行业的利用来说也是离不开的。 03 实时云渲染技术原理 实时云渲染技术的原理非常简单。当咱们用手机或者轻量化的终端来操作的时候，个别状况下，它的利用大小和画面成果是受限制的。举个例子，如果咱们要在手机上看到十分真切的几十万根头发的虚拟人，靠手机、Pad的算力其实无奈实现实在实时的渲染。 对于如何在手机等轻量化的终端上实现高画质的渲染和大场景输入，咱们的思路是把重度的和图形图像相干的算力部署在云端。云端能够借助于高性能的服务器，把图形图像的重度计算放在云端执行，当云端实时渲染的画面进行编解码之后，再通过网络传送到各种各样的终端，除了手机、平板外，也包含VR设施等，这就解决了轻量化终端算力有余的问题。 04 瑞云科技实时云渲染技术特点 首先，是依靠于利用的运行平台。无论是什么利用，须要把这个平台先托管到云渲染平台上，在平台上的真正计算节点，都能够在计算平台上实时调取利用，实时运行。 第二，实时云渲染集成了当先的SaaS服务，登陆咱们的网站，只用简略的几步操作就能够体验SaaS服务，流程非常简单。 第三，依靠于自主研发的协定。一些大型开发我的项目，用现在支流的引擎软件，打进去的包变得越来越大，从原来的几百兆倒退到几十G，当须要把利用上传到云端的时候，都会面临传输速度的瓶颈。而通过咱们自研的协定，能够把上传过程大大放慢，10G的文件几分钟就可能传完。此外，咱们这个协定能够通过浏览器进行拜访，这对分享来说十分便当，大家能够通过微信、小程序推送给用户。 05 3DCAT技术劣势 接下来简略谈一下咱们的技术劣势，包含：反对各种各样的引擎、适配WebRTC协定、反对提供多规格、自适应的码流能力等。咱们有业界当先的调度性能，也反对多零碎的平台调度，反对调度策略的灵便设置。咱们当初用不同的卡，以匹配对应的工作性能。比方Unity利用对显卡要求不高，1660就能够满足，而有些利用对显卡的需要更高，比方帕斯卡等，这时候咱们能够指定不同的利用，指定不同的显卡类型。并且还能够提供浏览器来监控和治理后盾。 06 3DCAT分为私有云和公有云两个版本 对于实时云渲染，咱们本人有一个品牌，叫3DCAT，分为私有云和公有云两个版本。 私有云的架构比较简单，底层是X86，外面从属了自研的推流零碎。登陆咱们的网站注册之后，只须要几步就能够实现。这种原理决定了咱们对终端的兼容性特地好，无论是手机、平板，还是PC，甚至VR头显都能够用同样的形式来进行输入。此外，咱们也反对微信、小程序等。 为了让用户有更好的体验，咱们在国内建设了各种各样的多个边缘计算节点，当用户有申请的时候，零碎主动判断调用离用户最近的计算中心，为用户提供更好的网络服务，缩小用户的延时和期待。 无论是资源老本，还是服务方面，咱们都有相应的劣势，因为咱们做云渲染相干服务有超过10年的历史，对于利用平安较有保障。举个例子，个别手机上浏览一些3D在线数据的时候，它会缓存到本地终端，从安全性上来讲，实时云渲染的安全性会高很多。 咱们还通过了TPN认证，是国内少数几家有TPN认证的厂家。咱们计划的劣势包含： • 云端部署：所有货色都部署在云端； • 全域反对：除了提供平台，也提供从利用制作到散发一体化的解决方案； • 所有的货色都能够进行对立的治理：以往装置或者运行交互式的利用，须要逐台机器去装置运行，而当初能够对所有利用进行对立的治理，比方降级一次或者是内容替换之后，所有的用户再次关上都是对立更新过的画面； • 端云联合：所有的简单运算都集中在云端，轻量化终端变成接管工具，这样就能够实现升高终端配置需要； • 极简操作：所有的操作都十分的便捷，只有几步就能够实现； • 数据安全：内容存储在云端，数据与用户拆散，无效爱护知识产权，平台取得TPN权威认证 除了方才说的私有云，咱们也提供公有云的计划。公有云的计划特地适宜于对安全性要求十分高的单位，比方军事单位，或者是对性能要求比拟高的场景，比方VR头显。如果是同样的内容，立体类的利用对带宽的要求不高，但VR头显对带宽要求会比拟高，个别推流码率能达到40～60兆，所以私有化的计划也特地适宜对性能要求比拟高的场景。 07 3DCAT领有丰盛的落地案例 最初，我再聊一下咱们曾经落地的案例。一是Matterverse（次元跃升），它通过实时云渲染的形式，在手机上也能够关上。通过云渲染，它能够进行各种各样的交互，实现虚构角色的各种操作。对于目前比拟火的数字人，咱们也有一些本人的体验。 当初的趋势是往越来越实在的方向走，但凭借目前的手机算力，想打造十分真切的数字人并不简略，而咱们能够通过实时云渲染的形式，将这个画面实时推送到手机终端。还有一个是汽车畛域的案例，咱们与奥迪进行了相应的单干，借助实时云渲染技术甚至是光线追踪技术，能实现实时交互的高精度画面输入。 以上讲的案例都是运行在实时云渲染的平台之上，心愿将来有更多、更好的利用能够运行在咱们的平台之上，谢谢大家！ 文字起源：VR陀螺本文 《FBEC大会 | 瑞云科技 CTO 赵志杰：元宇宙时代的基础设施——实时云渲染》内容由3DCAT实时云渲染解决方案提供商整顿公布，如需转载，请注明出处及链接。

作者：vivo 互联网实时计算团队- Chen Tao 本文依据“2022 vivo开发者大会"现场演讲内容整顿而成。 vivo 实时计算平台是 vivo 实时团队基于 Apache Flink 计算引擎自研的笼罩实时流数据接入、开发、部署、运维和经营全流程的一站式数据建设与治理平台。 一、vivo 实时计算业务现状2022年，vivo互联网在网用户总数达到2.8亿，多款互联网利用的日活超过了千万甚至冲破了1亿，为了向用户提供优质的内容和服务，咱们须要对如此大规模的用户所产生的海量数据进行实时处理，帮忙咱们进行经营决策、精准举荐、晋升终端用户体验，同时通过晋升咱们的商业化能力为广告主提供更加优质的广告服务。 近几年，大数据实时计算技术和公司的实时数据业务都在飞速发展，截止到往年8月，vivo实时计算每日解决数据量达到5PB，无效工作数超过4000，目前已接入98个我的项目，从趋势上来看，每年都有超过100%的规模增长，如此大的业务规模和业务增速给咱们实时计算团队带来的十分大的挑战。首先，咱们要确保业务的稳固，高速增长的数据、简单的业务场景和零碎架构须要咱们自底向上的全方位的稳定性建设；为了帮忙用户疾速落地业务，咱们须要升高开发门槛，提供良好的易用性和笼罩各种场景的性能个性，业务的高效接入和运维能带来长期的降本收益。同时，大规模的数据和计算咱们也心愿可能以尽可能低的老本去运行，这就须要咱们提供高效的存储、计算能力，并且对于许多要害业务，实时计算时效性保障的要求也十分高。在简单的数据环境中要保障数据安全须要有十分良好的且具备前瞻性的设计，优良的平安能力须要可能提前防备可能的危险。 咱们从2019年下半年启动了实时计算平台的建设，2020年关注在稳定性建设，初步上线了SQL能力，2021年引入了Flink 1.13版本并启动了容器化建设，2022年次要关注在效率晋升，包含流批一体、工作诊断等，到目前为止，咱们平台已初步具备了一些能力，所以明天我代表咱们团队简略给大家介绍一下咱们的平台建设实际。 二、实时计算平台建设实际 从咱们大数据平台的体系架构上来看，咱们通过汇聚层能力收集整个vivo互联网的埋点、服务器日志，通过计算、存储、剖析等能力从海量数据中挖掘出业务价值。实时计算作为平台的外围能力之一，它同时满足了大规模数据计算和高时效计算的需要，咱们通过实时计算平台来承载和向业务提供这方面的能力。 vivo实时计算平台是基于Apache Flink计算引擎自研的笼罩实时流数据接入、开发、部署、运维和经营全流程的一站式数据建设与治理平台。接下来我会从根底服务建设、稳定性建设、易用性建设、效率晋升和平安能力建设五个方面来介绍咱们团队的建设思路和实际过程。 2.1 根底服务建设 咱们自研的实时平台后端架构包含两个外围服务： SubmissionServer：负责作业的提交，以及跟资源管理零碎的交互，具备高可用、高可扩大能力，反对多版本Flink和多种工作类型。ControlServer：负责工作运行状态的保护，咱们定义了9种工作状态，通过一个内置状态机进行实时的状态保护，状态的更新提早在秒级。根底服务还包含对立的元数据服务和实时的监控告警服务。这两个局部做一下简略介绍。 咱们应用HiveMetaStore作为元数据根底服务，基于TIDB的扩大能力，以后元数据实体规模已达到亿级，通过对MetaStore服务的优化，大分区表操作性能晋升了10倍，目前已接入Spark、Hive、Flink、Presto等引擎，同时，对立的权限管制、数据分类分级、数据血统、元数据变更记录等能力也为数据治理提供了良好的根底。 咱们基于Flink的CEP能力构建了一套秒级提早、反对动静规定配置的监控告警零碎，同时从基础设施、根底服务、实时工作和业务多个维度构建了全方位的监控体系。以上这三个方面形成了咱们的根底服务。根底服务都具备高可用个性，然而要保障业务稳固，还须要关注整个零碎以及在零碎上运行的业务数据链路，这里最重要的有两个方面：大数据组件服务的稳定性和工作自身的稳定性。 2.2 稳定性建设 咱们应用HDFS作为状态的长久存储和业务数据落地的存储，随着存储规模和读写量的增长，咱们遇到了DataNode的StaleNode问题、低版本HDFS流式写无奈复原问题和越来越重大的小文件问题，为此咱们通过平滑降级HDFS到3版本、优化Flink Sink性能和基于Spark3建设小文件合并服务来解决这些问题。 Kafka是次要的流存储组件，然而在集群运维上存在一些痛点，比方扩缩容和节点硬件故障会导致资源不平衡和生产生产的异样，Kafka团队建设了流量平衡和动静限流能力，显著晋升了Kafka服务的稳定性，同时咱们也晋升了Flink对Kafka Broker重启的容忍度，可能无效缩小Broker故障对运行工作带来的影响。 另外，Flink工作的高可用依赖于Zookeeper，为了防止ZK leader切换对实时作业的影响，咱们对1.10和1.13版本的Flink进行了容忍度加强，对更低版本的工作做了版本升级，也依据社区教训优化了Flink HA局部的性能，以及增强了对ZK的全面监控和治理，保障了ZK的稳定性。 通过这些对相干组件的优化措施缩小了工作异样工夫和次数，无效的晋升了工作稳定性。接下来介绍一下咱们针对某种特定场景的Flink工作稳定性优化实际。 在内容实时举荐场景，产生自在线预估服务的用户特色快照须要与用户实时数据进行拼接，因为数据量微小在做Join时须要一个大缓存，相比于原来采纳Redis作为缓存的计划，Flink的RocksDB状态后端是一个更适合的计划，然而在状态大小达到TB级别时，工作稳定性很难保障。咱们基于对RocksDB内存模型的深刻理解，扩大原生监控指标，降级RocksDB版本，建设了状态治理相干能力，把工作稳定性晋升到了生产可用级别。在多个业务场景上线后，样本和模型的时效性和稳定性失去保障，举荐成果失去很大晋升。 后续咱们布局通过减少读缓存和优化前缀匹配策略进一步晋升RocksDB状态后端的性能。 咱们始终在思考如何进一步晋升业务的稳定性，绝对于工作的稳定性咱们的用户更加关怀他们所须要的数据是否准时、数据品质是否合乎预期，而工作的稳固不齐全等同于时效和品质。在时效这个维度咱们定义了数据准时率的SLI指标，这对咱们有两方面的指引：更自动化和精细化的故障分级保障和流计算的弹性能力的建设。其中前者正在建设中，后者也在咱们的布局之中。 2.3 易用性建设 从实时作业开发角度， 咱们提供了功能完善、体验良好的FlinkSQL开发环境。相比于社区版本Flink，咱们对SQL能力进行了扩大，比方更加可控的窗口计算触发性能，兼容性更强的DDL性能，更加不便的流表创立性能，咱们对Format、Connector、UDF都做了一些扩大和优化，实用于更多业务场景，晋升了性能；同时咱们建设了运行于Standalone集群的SQL调试能力，具备数据抽样、上传、DAG图展现、调试后果实时展现等性能。通过一年的建设，新增SQL运行工作占比从5%晋升到了60%。 从实时作业运维角度， 咱们提供了实时全链路的血统与提早监控性能。为了实现数据业务，实时计算链路往往是很长的，而一个团队个别只负责其中一段，为了解决链路中呈现的问题，可能须要上下游多个团队配合，效率很低。咱们作为平台团队为用户提供了一个全局的视角，这样能够迅速定位到异样工作节点，十分高效。血统数据能够实时生成，并且不须要工作的重启，因而不存在血统不全的问题。同时，咱们也能够输入端到端全链路提早数据和工作解决提早数据，帮忙咱们的用户做品质监控。 2.4 效率晋升 往年，降本提效是咱们的重点工作方向，咱们从计算、存储和资源治理三个方面做了一些工作，获得初步成果。YARN资源管理的粒度较大，而K8s更精密的资源粒度从整体上来看能够无效晋升资源利用效率。YARN尽管开启了cgroups，然而对系统资源的隔离能力依然较弱，个别异样工作耗尽机器资源可能影响失常运行的工作。因而平台反对了K8s的资源管理能力，借助于Flink社区提供的Native K8s个性以及平台良好的可扩展性，咱们以后反对JAR工作的容器化部署，并且通过在开发、运维、资源交付等方面的建设确保了用户体验与YARN是统一的。借助于容器化，咱们能够确保开发、测试、线上等环境的一致性，研发效率也失去晋升。目前已接入3个业务，明年会比拟大规模的利用。 多年以来，大数据畛域在倒退过程中造成了批和流两套架构并存的现状，很多时候，业务在落地过程中不得不同时思考和投入建设两套链路。比方离线数仓和实时数仓独立建设，数据口径和计算结果的一致性保障须要付出额定的致力，Hive表不反对数据更新、探查较慢，Kafka数据回溯和查问艰难等问题也始终困扰着数据开发人员。 侥幸的是，业界曾经摸索进去基于数据湖组件在分布式存储之上构建流批对立存储的技术，咱们依据vivo的业务特点抉择并设计了咱们的流批一体计划，目前曾经实现基于Hudi的对立存储引擎、基于Flink的对立入湖、基于HMS的对立元数据建设，目前业务曾经实现试用并开始接入。往年咱们次要接入实时业务，明年会有离线业务的接入。这也是咱们大数据平台构建湖仓一体很重要的一步。 在长期的实时作业运维过程中，咱们积攒的大量作业调优和问题解决教训，随着运维压力的减少，咱们在思考如何晋升运维效率。咱们也发现用户资源队列用满的同时，机器的CPU利用率却处于较低水平，因而咱们思考如何缩小资源节约，晋升集群的资源利用效率。资源诊断和异样诊断这两类问题都是作业优化问题，要优化作业，首先须要把握作业及其运行环境的信息，包含运行指标、运行日志、GC日志、依赖组件运行状况、操作系统过程级别信息，以及作业配置、环境配置等等，而后须要将运维教训和思路转化为启发式算法的规定和数据，使用这些数据、算法和规定去找到优化的办法。基于这个思路，咱们建设了一个诊断服务，具备灵便的信息收集、规定配置、数据调优性能，可能在作业启动或运行时，诊断作业的衰弱水平，提供一些作业的优化倡议给咱们的用户。目前资源诊断能力曾经在运行，异样诊断还在建设中。 2.5 平安能力建设 作为一个根底的大数据服务，平安在咱们看来是一个十分重要的命题，因而咱们在零碎设计之初就思考了实时数据拜访、离线数据读写、各个系统与服务之间的平安隔离能力等方面的设计，在实时数仓具备肯定规模后，咱们又建设了数据分类分级、日志审计等能力。去年，依据最新的合规要求，离线存储反对了列级别通明加密，实时数据反对了敏感字段自动检测等能力。平安无止境，咱们也在对DSMM进行钻研解读，以继续晋升大数据的平安能力。 以上是咱们平台建设的一些实际，总结来看，咱们基于Flink建设了性能比较完善的实时计算开发和运维能力，业务复杂度越来越高，咱们的挑战还有很多，比方Flink引擎的优化与难点问题的解决、计算效率的进一步晋升、流批一体、容器化的大规模利用等，都是咱们后续的重点方向。 后面有提到，基于实时计算平台，公司的多个中台团队建设了五大中台能力，笼罩了各种各样的实时场景，这里就跟大家简略分享下其中两个典型场景。 ...

Flink Forward Asia 2022 将于 11 月 26-27 日在线上举办，议程内容正式上线！往年是 Flink Forward Asia（下文简称 FFA）落地中国的第五个年头，也是 Flink 成为 Apache 软件基金会顶级我的项目的第八年。过来这几年，Flink 一方面继续优化其流计算外围能力，一直进步整个行业的流计算解决规范，另一方面沿着流批一体的思路逐步推进架构革新和利用场景落地。随同着实时化浪潮的倒退和深入，Flink 已逐渐演进为流解决的领军角色和事实标准。 作为开源大数据畛域的顶级盛会之一，往年的 FFA 将持续集结 Flink 最新技术动静和最佳行业实际 ，并踊跃拥抱生态搭档，共建凋敝开源大数据生态。 连续 FFA 常规，会议所有议题均为凋谢征集而来，并由业余的议题评比委员会评分筛选，确保内容代表行业领先水平，为开发者们输入更加优质的干货。往年，咱们将在 FFA 上看到阿里巴巴、字节跳动、快手、美团、华为、Shopee、运满满、米哈游、蔚来汽车、集度汽车、菜鸟、网易等寰球 40+ 各行业一线厂商，围绕 Flink 核心技术、行业实际、平台建设、实时风控、实时湖仓、数据集成等多个时下热门方向，分享 80+ 干货议题，带来一场专属于开发者的技术盛宴。 Flink Forward Asia 2022 工夫：11月26日-27日 PC端直播观看：https://flink-forward.org.cn/ 「点击议题，即可查看议题详情以及讲师介绍」挪动端倡议观看 ApacheFlink 视频号预约观看: 一、重量级内容评审团FFA 2022 邀请了 11 位行业首领及开拓者组成议题评比委员会，并持续由阿里巴巴开源技术委员会负责人贾扬清负责主席，独特为大会内容护航，他们别离是： 二、Apache Flink 新方向、新利用及新成绩在去年的 FFA 2021 主题演讲中，Apache Flink 中文社区发起人、阿里巴巴开源大数据平台负责人王峰提出了 Flink 下一步的倒退方向——流式数仓（Streaming Warehouse，简称 Streamhouse），预示着 Flink 要从 Stream Processing 走向 Streaming Warehouse 去笼罩更大的场景，帮忙开发者解决更多问题。Flink 社区也把拓展适宜流批一体的数据存储作为重点技术方向来推动，并在前不久公布了 Flink Table Store 0.2.0。过来这一年，Flink Table Store 这一全新数据湖存储我的项目获得了哪些新进展？又有哪些利用实际新成绩？Flink 接下来还有什么新打算？将在这次 FFA 2022 主会场上一一揭晓。 ...

摘要：本文整顿自智慧芽数据仓库架构师曲明星在 Flink Forward Asia 2021 实时数仓专场的分享。本篇内容次要分为三个局部： 产品架构技术架构将来打算点击查看直播回放 & 演讲PPT 一、产品架构 上图是智慧芽APP 的产品架构图，包含后盾管理系统、AI、内容引擎、帮忙核心，为客户提供知识产权信息化服务和科技翻新情报系统。 二、技术架构2.1 原实时剖析计划 上图是原来的实时剖析计划。流程大抵是客户检索一个条件，通过剖析 API 把客户检索的相干条件发送到不同的搜索引擎。这种计划会产生 4 个问题： 对检索性能产生影响；简单剖析须要开发插件反对；跨多个搜索引擎剖析复杂度高；不同维度的数据无奈存储。在建设实时数仓前，收集了业务要求实时数仓特点： 秒级响应；准实时数据更新；能反对一定量的并发能力；与搜索引擎数据保持一致；反对简单剖析的能力；反对对立应用形式及支流个性；反对与搜索引擎交互；反对存储容量横向扩大的能力。 上图是数据平台概览。从下往上看： 最上层是数据底座，包含数据存储和数据计算，其中数据计算层由 Spark、Kafka、Flink 组成；中间层是数据平台，包含数据开发、数据分类、数据管理和数据服务；下层是数据利用，次要有数据业务、内部剖析服务和外部剖析业务形成。2.2 新实时剖析计划 新的技术选型次要基于 TiDB，次要包含数据存储、数仓服务两个局部。数仓服务分为安全检查、驱动表治理、缓存治理、集群负载查看以及执行器等局部。 抉择 TiDB 是因为它是云原生并且社区沉闷、满足 TP 及 AP 业务场景、丰盛的生态工具及多平台以及其应用简略，兼容 MySQL 以及大数据能力。 抉择 Flink 也是因为它是一个开源的大数据计算引擎，并且有沉闷的云原生社区，可能满足对数据的及时性要求，一致性方面有 exactly-once 语义，同时具备低提早高吞吐量。 在线业务数据写入流程：把源头的数据变更放到音讯队列中去，通过索引程序将数据散发到不同的搜索引擎，同时搜索引擎也会给索引程序发送音讯。 离线剖析技术体系：整个离线剖析技术体系比拟依赖于 oss。将每日的增量数据离线放到 oss 里，对全量的数据进行一些比较复杂的剖析。 离线业务数据写入流程：数据变更会触发长久流化至 oss，oss 同时会和历史流进行合并在 oss 放一份全量数据。 2.3 原用户行为剖析计划原用户行为剖析计划是非常复杂的计划，这个计划在前端有 JS 和 Java 的 API，JS 会将用户的埋点数据搁置到 Segment 中去，同时有 Gainsight 和 AMPLITUDE 两个合成化引擎。 2.4 新用户行为剖析计划 ...

本⽂由社区志愿者邹志业整顿，内容起源⾃阿里云实时计算产品经理李佳林（风元）在 7 月 5 日 Flink 峰会（CSDN 云原生系列）的演讲。次要内容包含： 基于 Flink 构建风控系统阿里风控实战大规模风控技术难点阿里云 FY23 风控演进打算点击查看直播回放 & 演讲PPT 目前 Flink 根本服务于团体的所有 BU ，在双十一峰值的计算能力达到 40 亿条每秒，计算工作达到了 3 万多个，总共应用 100 万+ Core ；简直涵盖了团体内的所有具体业务，比方：数据中台、AI中台、风控中台、实时运维、搜寻举荐等。 一、基于 Flink 构建风控系统风控是一个很大的话题，波及到规定引擎、NoSQL DB、CEP 等等，本章次要讲一些风控的基本概念。在大数据侧，咱们把风控划分成 3 × 2 的关系： 2 代表风控要么是基于规定的，要么是基于算法或模型的；3 代表包含三种风控类型：当时风控、事中风控和预先风控。1.1 三种风控业务 对于事中风控和预先风控来讲，端上的感知是异步的，对于当时风控来讲，端上的感知是同步的。 对于当时风控这里稍做一些解释，当时风控是把曾经训练好的模型或者把曾经计算好的数据存在 Redis 、MongoDB 等数据库中； 一种形式是端上有相似 Sidden 、Groovy 、Drools 这样的规定引擎间接去 Redis 、MongoDB 取数据来返回后果；另外一种形式是基于 Kubeflow KFserving ，端上申请过去之后基于训练好的算法和模型返回后果。整体来讲这两种形式的时延都在 200 毫秒左右，能够作为一个同步的 RPC 或 HTTP 申请。 对于 Flink 相干的大数据场景是一个异步的风控申请，它的异步时效性非常低，通常是一秒或者两秒。如果谋求超低时延，则能够认为它是一种事中的风控，风控决策过程能够由机器染指解决。 很常见的一种类型是用 Flink SQL 做指标阈值的统计、用 Flink CEP 做行为序列规定剖析，还有一种是用 Tensorflow on Flink ，在 Tensorflow 中进行算法形容，而后用 Flink 来执行 Tensorflow 规定的计算。 ...

业务介绍新东方教育科技团体定位于以学生全面成长为外围，以科技为驱动力的综合性教育团体。团体由1993年成立的北京新东方学校发展壮大而来，领有短期培训零碎、基础教育零碎、文化流传零碎等业务。 在互联网大潮中，新东方在IT技术上也一直重构，继续投入大数据建设，研发大数据的相干技术和利用，从而疾速而精准地响应业务需要，并用数据为团体各级领导提供决策依据。新东方的大数据利用次要包含两局部： 企业应用端的业务场景（B端）：包含交易，教学，人员等数据，数据规模为TB级。数据会被依照不同的条件和学校层级等，造成营收、教学、客服、财产人事等实时报表，为CRM零碎的成千上万名业务参谋提供线索和商机的明细报表查问，同时也供各级管理人员理解业务的运行状况，辅助业务决策。互联网间接面向用户场景（C端）：次要为招生引流类、云教室等利用，包含网页版，App端，H5等，数据量为PB级。这部分数据记录了用户（学员和潜在用户）在新东方的教学闭环轨迹，C端数据除了生成惯例的经营报表外，还会绘制用户画像，进而开发举荐零碎和圈选等利用，改善C端各种利用的用户体验，进一步精细化经营。数仓建设和利用痛点为了满足日益增长的业务需要，团体开始投入数仓建设。在数据仓库建设的初期，以业务驱动为主。通过阿里云的MaxCompute为外围构建数据仓库，间接集成业务库数据以及WEB利用的OSS日志等，而后在数据仓库中剖析业务数据并产生统计分析后果。初期的架构如下： 依据业务须要，将中小型规模的后果导入MySQL并反对数据更新。数据规模较大的只读后果则导入 MongoDB。而后Web服务层查问MySQL和MongoDB并向用户提供服务接口， Web服务层也能够通过Lightning减速接口间接查问MaxCompute的数据， Lightning协定是MaxCompute查问减速服务，反对以PostgreSQL协定及语法连贯拜访MaxCompute数据，相比MaxCompute提供的odps jdbc接口速度要快得多。起因是后者把每次拜访作为一个Map-Reduce解决，即便很小的数据量查问响应工夫也要超过10秒，而 Lightning能将延时降到百毫秒内，满足业务后果报表的展现需要。目前Lightning服务进入服务下线阶段，新的减速服务由Hologres减速集群代替。 应用这套架构能够在较短的工夫内满足报表开发、用户画像和举荐服务等需要，为新东方的日常经营和招生引流提供较好的数据反对。然而随着业务的发展，这套架构越来越难以满足用户的需要，次要体现在： 实时性，业务心愿可能达到1分钟级甚至秒级的实时性，而应用MaxCompute只能实现批量解决，个别只能提供分钟级（个别5分钟以上）的延时来自Web服务层的高并发查问，MaxCompute的大数据量查问只能反对到100左右的QPS，满足不了来自C端利用的高并发查问简单逻辑的大数据量剖析和Ad-hoc查问，随着剖析数据迅速从数百G上涨到TB级，在多个数亿行以上的数据进行简单报表开发，单实例MySQL难以反对；而MongoDB无奈应用规范的SQL进行简单查问，同时MongoDB自身简单的查问业务，开发效率很低。Lightning接口尽管反对规范的SQL并且某些场景上速度比拟快，然而Lightning开始逐步下线，须要找到替换的办法。实时数仓选型要解决以上的业务痛点，就须要找到能满足实时数仓建设需要的产品。大数据团队调研了多种实时数仓计划，基于新东方的数据和利用特点进行选型，计划比对如下： 产品Ad-hoc查问高并发反对（QPS）SQL反对TP(交易)反对与MaxCompute/Flink集成文档和技术支持ClickHouse 20.1反对PB级以上默认反对100的并发查问，qps取决于单个查问的响应工夫单表查问反对较好，简单报表查问反对较弱通过mutation反对update，较弱反对文档丰盛，社区反对较好Doris 0.9反对PB级以上数百兼容MySQL不反对通过兼容MySQL与MaxCompute集成,与Flink的集成 不明确文档和社区都较差Hologres 1.1反对PB级以上数万以上兼容PostgreSQLDDL反对与MaxCompute间接在存储层集成，并且都兼容PostgreSQL，提供Flink Connector集成阿里在线文档和技术支持Tidb 4.x （含Tiflash）反对PB级以上数万以上兼容MySQL反对反对文档丰盛，社区反对较好Elastic Search 7.x反对PB级以上数万以上不反对规范SQL不反对反对与MaxCompute集成，Flink Connector只反对Source文档丰盛，社区反对较好从以上的表格能看出，Tidb和Hologres能够较好地解决新东方在大数据方面面临的问题。然而Tidb须要公有云部署并运维，而MaxCompute部署在私有云，两者在不同的云环境。Hologres是阿里云提供的云原生服务，并与MaxCompute都部署在私有云，且在Pangu文件层严密集成，数据交换效率远高于其余内部零碎，两者都兼容PostgreSQL，从离线数据仓库开发迁徙到实时数据仓库开发难度升高。 基于以上的剖析，抉择Hologres作为实时数仓。 实时数仓建设实时数仓是在离线数仓的根底上，基于Lambda架构构建，离线和实时同时进行建设。无关Lambda的，参阅：[Lambda architecture] 架构的各组件阐明：1）数据源： Binlog，即各类利用（B端和C端）的数据库Binlog，对于SQL SERVER的数据库则是CT log;App音讯，即App运行时上报的事件;Web日志/埋点日志，即Web服务器所产生的ngix日志，以及Web app/H5运行时埋点服务产生的日志2）CDC数据总线（简称CDC） CDC数据总线采集数据源，写入Kafka Topic。对于离线数仓和实时数仓, CDC都是间接交互的数据源/CDC包含Source Connector、Kafka 集群、Sink Connector三局部。 Source Connector 负责从数据源采集数据并写入Kafka集群的Topic，而Sink Connector则将Kafka Topic的数据ETL到指标库，包含实时和离线数仓。CDC易于部署和监控，并提供了简略的数据过滤，老本较低，数据ETL工作尽量采纳CDC。3）离线数据处理 离线数据处理基于MaxCompute搭建，用于计算全量数据，数据源来自于CDC的实时导入。离线数据通过离线数仓计算（ODS->DWD/DWS→ADS）导入Hologres作为存量数据，一部分离线的DWD/DWS数据也导入Hologres作为维表的存量数据。Flink计算工作会将ADS层后果Sink到MaxCompute， 用于数据备份。4）实时数据处理实时数据处理基于阿里云托管的 Flink流式计算引擎。与离线数仓解决固定日期的数据（如T+1）不同，实时数仓解决的是流式数据，从工作启动开始，就始终运行，除非异样终止，否则不会完结。数仓的档次与离线数仓相似，依据实时处理的特点做了简化。如下表所示: 数仓档次形容数据载体ODS层与数据源表构造类似，数据未通过解决Kafka Topic/cdc ConnectorDWD/DWS层数据仓库层，依据业务线/主题解决数据，可复用Kafka TopicDIM层维度层holo 维表，Kafka TopicADS层应用层，面向利用创立，存储处理结果holo实时后果表，Kafka Topic5）Hologres 数据查问 数据表名称形容数仓档次数据源维度数据表维度建模后的数据表，在实时计算时事实表通过JDBC查问DIM层初始化数据来自离线数仓dim 层、CDC、Flink维表计算工作实时后果表实时数仓的计算结果表实时数仓DWS/ADS层实时数仓的DWS/ADS层计算工作存量后果表离线数仓的计算结果表实时数仓DWS/ADS层离线数仓的DWS/ADS层计算工作查问view合并实时和存量后果，对外提供对立的展现View实时数仓ADS层存量后果表实时后果表 表面来自MaxCompute的数据表援用各层次离线数仓备份表备份实时计算一段时间内的数据，用于做数据校验和问题诊断DWD/DWS层实时数仓利用场景通过新的架构，反对了新东方团体内如下利用场景： 实时报表查问：为CRM零碎的成千上万名业务参谋提供线索和商机的明细报表查问，同时为管理层提供实时流动看板服务，延时秒级，辅助业务决策。Ad-hoc查问：B端和C端经营人员能够间接通过Hologres定制本人的简单业务查问用户轨迹和画像场景：实时处理用户来自B端和C端的数据，生成用户轨迹和标签，为业务疾速决策提供根据。举荐零碎和圈选业务：通过Maxcompute训练离线模型，并通过Flink数据调整模型的参数。基于用户的实时轨迹数据圈选出符合条件的用户并推送服务，进一步精细化经营。应用实际一个典型的实时工作解决流程如下图所示： ODS层数据通过CDC数据总线导入MaxCompute， 提供离线计算源数据。 同时也会将数据写入到Hologres,用于做数据验证。 在Hologres中，维表存储全量数据。而其余类型的ODS数据表个别存储工夫>离线的计算周期即可，如离线T+1，则存储2天，无相应的离线计算工作依据验证数据周期而定。Flink工作读取ODS层数据作为输出，与存储在Hologres中的维表做关联，计算的后果存储到DWD/DWS层的Kafka Topic中，同时将后果写入到Hologres用于数据验证，数据存储工夫与ODS层雷同Flink工作读取DWD/DWS层数据，与存储在Hologres中的维表做关联， 将结算的后果存储到Hologres。依据利用须要，如果是Lambda架构，存储工夫>离线的计算周期即可，如离线T+1，则存储2天，如果是Kappa架构，保留全副数据， 同时将后果数据写入离线数仓用于离线剖析用（可选）。上面具体介绍在每一步解决流程中的应用实际与教训优化，以帮忙达到更好的成果。 数据验证因为实时处理源数据和后果都是动静的，数据验证无奈在工作中进行。能够在Hologres中，对实时数仓的各层落仓后果进行验证。因为实时处理和工夫相干，每一档次的数据都须要带上一个解决工夫戳(Process Time)。在Lambda架构中，将实时后果和离线后果进行比对，假如离线解决周期为T+1, 则实时处理取工夫戳与昨天的数据进行比对，计算出准确率。如果是Kappa架构，须要进行逻辑验证，并与业务人员解决的后果数据进行比对。 全量数据初始化Kafka Topic个别存储几天内的数据，不能提供全量数据，所以须要从离线数仓进行全量数据初始化，将维表、ADS层后果等导入Hologres。 Hologres维表的Lookup和性能优化1）Lookup在Flink计算工作中，流表和Hologres的维度数据表Join，就是Lookup。Lookup须要解决两个问题： ...

作者｜爱奇艺大数据团队 数据作为互联网时代的根底生产资料，在各大公司企业领有无足轻重的位置。数据的价值在互联网公司的体现，大抵而言能够分成三类： 挖掘数据中的信息来领导决策，如产品经营、用户增长相干的 BI 报表依靠数据优化用户体验和变现效率，如信息散发场景下的个性化举荐、成果广告等基于数据统计的业务监控，如监控大盘、平安风控等在这些体现大数据价值的业务场景上，存在一个广泛的法则，即数据产生的价值，随着工夫的推移而衰减。因而，随着公司业务的倒退，传统的 T+1 式（隔日）的离线大数据模式越来越无奈满足新兴业务的倒退需要。发展实时化的大数据业务，是企业深刻开掘数据价值的一条必经之路。 爱奇艺大数据团队自 2014 年开始引入Kafka、Storm、Spark Streaming 等实时化技术，2017 年引入 Apache Flink 实时计算框架，逐渐建设了一套买通数据采集、加工、散发、剖析、利用等残缺数据流程的实时大数据体系。这套实时大数据体系反对了峰值超过 3000 万 QPS 的实时数据处理，反对了如春晚直播、青春有你、尖叫之夜等大型流动的实时计算需要。本文将介绍爱奇艺实时大数据体系的次要架构、平台性能以及倒退过程中的一些思考。 一、传统实时 ETL 模式的问题在实时技术倒退初期，大团队为各业务提供的是单纯的日志数据的实时解析服务。通过 Flink ETL 程序，将用户端上报日志、后盾服务器日志、数据库 binlog 日志，解析成 key-value 组装的 json 状态的结构化数据，发送到 Kafka 中供各业务应用。其中，ETL 逻辑能够由内部配置平台注入，不便在解析逻辑批改时能够动静加载，缩小 Flink 工作的重启频率。这个实时 ETL 的体系如下图所述： 随着实时大数据业务的倒退，它的弊病一直呈现： 实时数据大量反复生产，各业务烟囱式开发，数据难以复用数据治理程度低下，数据生产者不晓得数据在被谁生产稳定性差，不能抵挡 Flink 和 Kafka 故障为了解决这些问题，爱奇艺大数据团队开始建设实时大数据体系，推出治理 Kafka 的流数据服务平台、基于 Flink 的实时数据生产平台、基于 Kafka 的实时数仓等组件，买通实时数据流程。 二、实时数仓与传统数仓的区别在传统的 BI 体系中，基于离线大数据构建数据仓库的过程，大部分是 T+1 的隔日离线计算。即每天凌晨开始从原始日志数据构建数仓，将多层级的离线计算工作，通过工作流零碎进行串联。数仓构建工作失败后能够有由工作流零碎触发工作重跑。一般来说，离线数仓构建工作的失败重跑，只影响数据生产进去的工夫，不影响数据的完整性、正确性。 在设计离线数仓模型和对应的计算工作时，个别会从以下几个角度去兼顾均衡： 数据收缩的老本束缚（Hive 存储）计算资源的老本束缚（YARN 队列）开发的人力老本束缚用户体验，蕴含数据的时效性以及数仓表应用的便捷性在实时数仓中，这几个约束条件产生了微小的变动： 基于这些变动，构建实时数仓的时候，切记不能照搬离线数仓的分层模型和构建逻辑，须要联合实时大数据业务的需要，依照实时业务的特点进行构建。实时数仓的构建，外围有以下几个特点： 1、器重数仓的程度拆分。在离线数仓中，数据的载体是 Hive 表，借助 Hive 的分区字段和谓词下推机制，咱们能够在各个层级构建一些稍大的表，而将要害的维度字段设置成分区，使用户在查大表的时候达到查小表的成果。在实时数仓中，数据的载体是 Kafka 队列，如果向用户提供一个大流，须要用户在生产数据实时过滤出其中的一小部分数据进行应用，那么对 Kafka 的带宽资源和 Flink 的计算资源都是极大的节约。因而，咱们须要尽量将罕用的维度进行程度拆分构建，例如“挪动端用户行为”“PC 端用户行为”能够拆分到两个流供用户应用。 ...

简介： 实时方面次要是补足咱们对游戏经营的体验，比如说在游戏里玩完一局或者做完一个工作后，立马就能失去相应的处分，或者下一步的玩法指引。对用户来说，这种及时的刺激和干涉，对于他们玩游戏的体验会更好。其实不单单是游戏，其余方面也是一样的，所以咱们在做这套零碎的时候，就是离线+实时联合着用，但次要还是往实时方面去聚拢，将来大数据的方向也是，尽量会往实时方向去走。 大家好我是许振文，明天分享的主题是《基于 Flink+ServiceMesh 的腾讯游戏大数据服务利用实际》，内容次要分为以下四个局部： 背景和解决框架介绍实时大数据计算 OneData数据接口服务 OneFun微服务化& ServiceMesh一、背景和解决框架介绍1、离线数据经营和实时数据经营 首先介绍下背景，咱们做游戏数据经营的工夫是比拟久的了，在 13 年的时候就曾经在做游戏离线数据分析，并且能把数据使用到游戏的经营流动中去。 但那时候的数据有一个缺点，就是大部分都是离线数据，比方明天产生的数据咱们算完后，第二天才会把这个数据推到线上。所以数据的实时性，和对游戏用户的实时干涉、实时经营成果就会十分不好。尤其是比方我明天中的奖，今天能力拿到礼包，这点是玩家很不爽的。 当初提倡的是：“我看到的就是我想要的”或者“我想要的我立马就要”，所以咱们从 16 年开始，整个游戏数据逐步从离线经营转到实时经营，但同时咱们在做的过程中，离线数据必定少不了，因为离线的一些计算、累计值、数据校准都是十分有价值的。 实时方面次要是补足咱们对游戏经营的体验，比如说在游戏里玩完一局或者做完一个工作后，立马就能失去相应的处分，或者下一步的玩法指引。对用户来说，这种及时的刺激和干涉，对于他们玩游戏的体验会更好。 其实不单单是游戏，其余方面也是一样的，所以咱们在做这套零碎的时候，就是离线+实时联合着用，但次要还是往实时方面去聚拢，将来大数据的方向也是，尽量会往实时方向去走。 2、利用场景■ 1）游戏内工作零碎 这个场景给大家介绍一下，是游戏内的工作零碎，大家都应该看过。比方第一个是吃鸡里的，每日实现几局？分享没有？还有其余一些流动都会做简历，但这种简历咱们当初都是实时的，尤其是须要全盘计算或者分享到其余社区里的。以前咱们在做数据经营的时候，都是工作做完回去计算，第二天才会发到处分，而当初所有工作都能够做到实时干涉。 游戏的工作零碎是游戏中特地重要的环节，大家不要认为工作零碎就是让大家实现工作，收大家钱，其实工作零碎给了玩家很好的指引，让玩家在游戏中能够失去更好的游戏体验。 ■ 2）实时排行版 还有一个很重要的利用场景就是游戏内的排行榜，比如说王者光荣里要上星耀、王者，其实都是用排行榜的形式。但咱们这个排行榜可能会更具体一些，比如说是明天的战力排行榜，或者明天的对局排行榜，这些都是全局计算的实时排行榜。而且咱们有快照的性能，比方 0 点 00 分 的时候有一个快照，就能立马给快照里的玩家发处分。 这些是实时计算的典型利用案例，一个工作零碎一个排行榜，其余的咱们前面还会缓缓介绍。 3、游戏对数据的需要 再说一下为什么会有这样一个平台，其实咱们最后在做数据经营的时候，是筒仓式或者手工作坊式的开发。当接到一个需要后，咱们会做一个资源的评审、数据接入、大数据的编码，编码和数据开发完后，还要做线上资源的申请、公布、验证，再去开发大数据计算实现后的服务接口，而后再开发页面和线上的零碎，这些都完了后再发到线下来，做线上监控，最初会有一个资源回收。 其实这种形式在很晚期的时候是没有问题的，那为什么说当初不适应了？次要还是流程太长了。咱们当初对游戏经营的要求十分高，比如说咱们会接入数据挖掘的能力，大数据实时计算实现之后，咱们还要把实时的用户画像，离线画像进行综合，接着举荐给他这个人适宜哪些工作，而后指引去实现。 这种状况下，原来的做法门槛就比拟高了，每一个都要独自去做，而且老本高效率低，在数据的复用性上也比拟差，容易出错，而且没有方法积淀。每一个做完之后代码回收就扔到一块，最多下次做的时候，想起来我有这个代码了能够略微借鉴一下，但这种借鉴基本上也都是一种手工的形式。 所以咱们心愿能有一个平台化的形式，从我的项目的创立、资源分配、服务开发、在线测试、独立部署、服务上线、线上监控、成果剖析、资源回收、我的项目结项整个综合成一站式的服务。 其实这块咱们是借鉴 DevOps 的思路，就是你的开发和经营应该是一个人就能够独立实现的，有这样一个零碎可能去撑持这件事。当一个服务在平台上出现进去的时候，有可能会复用到计算的数据，比说实时的登录次数或击杀数，那这个指标在前面的服务中就能够共用。 而且有了这样一个平台之后，开发者只需次要关注他的开发逻辑就行了，其余两条运维公布和线上经营都由平台来保障。所以咱们心愿有一个平台化的形式，把数据计算和接口服务对立起来，通过数据的标准化和数据字典的对立，可能造成下面不同的数据利用，这个是咱们的第一个指标。 其实咱们当初都是这种形式了，第一是要在 DevOps 的指导思想上来做，尤其是腾讯去做的时候数据服务的量是十分大的，比方咱们去年一共做了 5、6 万的营销服务，在这种状况下如果没有平台撑持，没有平台去治理和治理这些服务，单靠人的话老本十分大。 4、思路3 个现代化，大数据利用的 DevOps。 咱们的思路也是这样，三个现代化，而且把大数据利用的 DevOps 思路实现起来。 规范化：流程标准、数据开发标准和开发框架；自动化：资源分配、公布上线、监控部署（这是 DevOps 里不可短少的）；一体化：数据开发、数据接口开发、测试公布、运维监控。所以咱们针对大数据的利用零碎，会把它拆成这样三块，一个是大数据的开发，另外一个是数据服务接口的开发，当然接口前面就是一些页面和客户端，这些完了后这些开发还要有一个残缺的开发流程反对。 这样咱们就可能为各种数据利用场景提供一站式的数据开发及利用解决服务、对立的流动治理、数据指标计算开发治理和各种数据利用接口自动化生产治理的一站式的服务。 这样的零碎能保障这些的事件，而且咱们这里也正当拆分，不要把大数据和接口混到一块去，肯定要做解耦，这是一个十分要害的中央。 5、数据服务平台整体架构 ■ 1）计算存储这个框架大家能够看一下，我认为能够借鉴，如果你外部要去做一个数据服务平台的话，基本上思路也是这样的，底层的 Iass 能够不必管，间接用腾讯云或者阿里云或者其余云上的服务就能够了。 咱们次要是做下层这一块的货色，最上面的计算存储这个局部咱们外部在做零碎的时候也不是 care 的，这块最好是能承包进来。当初 Iass 倒退到这个水平，这些货色在云上能够间接像 MySQL 数据库或者 Redis 数据库一样购买就行了，比方 Kafka、Pulsar、Flink、Storm。 ...