黑科技王者荣耀背后的实时大数据平台用了什么黑科技？( 四 ) |腾讯|数据|

还有一种方式，是我们在 Flink 和 Storm 直接把数据配置我们这边的一个函数接口，比如我刚才讲的排行榜的方式，就给一个接口，他直接在 Flink 这边处理完成之后，把数据吐到函数接口里面，函数接口对这个数据进行二次处理。
这个是整个处理方式，所以我们前面讲的就是，基于 Flink 和 Storm 构建一个全面的、托管的、可配置化的大数据处理服务。主要消费的是 Kafka 的数据， Pulsar 现在在少量的使用。
这样做就是我们把数据的开发门槛降低，不需要很多人懂 Flink 或者 Storm ，他只要会 SQL 或者一些简单的逻辑函数编写，那就可以去完成大数据的开发。
2、数据计算统一
其实我们之前在做的时候，有一些优化的过程，原来每一个计算任务都是用 Jar 包去写，写完之后就是编辑、打包、开发、发布。后来我们划分了三种场景，一种是 SQL 化，就是一些我们能用 SQL 表示的我们就尽量分装成 SQL ，然后有一个 Jar 包能去执行这个提交的 SQL 就可以了。
还有一种是在线的 WebIDE ，是处理函数的逻辑，举例子 Storm 里可以把 blot 和 spout 暴露出来，你把这两函数写完后，再把并行度提交就可以运行。但这里我们具体实现的时候是基于 Flink 去做的。
另一个是场景化的配置，我们个性化的 Jar 包能够统一调度，根据调度逻辑去执行。
3、数据计算服务体系
这是我们整个 OneData 计算体系的过程，支持三种，一种的自研的 SQL ，一种是 Flink SQL ，还有是 Jar 包。
我们自研的 SQL 是怎么存储，最早是使用 Storm ，但 StormSQL 的效率非常低，所以我们根据 SQL Parser 做的 SQL 的分装，我们对 SQL 自己进行解析，自己形成函数，在 SQL 提交之后，我们用这样的方式直接把它编译成 Java 的字节码，再把字节码扔到 Storm 里去计算。
Flink 这块我们也继承了这种方式，后面会讲一下两种方式有什么区别。其实我们自研 SQL 在灵活性上比 Flink SQL 要好一点。
这里是做平台化，不能说直接放一个 FlinkSQL 去跑，因为我们想要在里面统计整个业务逻辑的执行情况，比如 SQL 处理的数据量，正确的和错误的，包括一些衰减，都是要做统计。
这是基本的过程，完了后我们在上面形成的一些基本场景，比如实时统计的场景， PV ， UV ，用独立的 Jar 包去算就行了，配置一下表就可以去计算。另外实时指标的服务，比如杀人书，金币的积累数，游戏的场次，王者荣耀里下路走的次数，这种数据都可以作为实时指标。
还有一种是规则触发服务，表里的某个数据满足什么条件时，触发一个接口。还有通讯实时排行榜和一些定制化的服务。
■ 1）自研 SQL
接下来说我们自研 SQL 的过程，我们早期为了避免像 Hive 一样（函数栈调用），而我们自己通过 SQL Paser 的语法抽象后，把它生成一段函数，就不需要这么多的对账调用。
这个是函数生成过程，最终生成的就是这样一段代码，它去做计算逻辑，一个函数完成，不需要函数栈的调用，这样效率就会大大提升。我们原来单核跑八万，放在现在可以跑二十多万。
整个处理的时候，我们把 SQL 编译成字节码， Flink 消费了数据后，把数据转化成 SQL 能够执行的函数，就是 roll 的方式。然后把 Roll 整个数据传到 class 里去执行，最后输出。
这种场景适合于，比如 FlinkSQL 它有状态值，我们要统计某个最大值的话，要一直把用户的最大值 hold 到内存里去。而我们自研的 SQL 呢，自己写的函数，它把数据借助第三方存储，比如刚才说的 TRedis 存储。每次只需要读取和写入数据即可，不需要做过多的内存的 hold 。
当前做到状态的实时落地，就算挂掉也能立马起来接着去执行，所以超过 10G、100G 的数据计算，都不成问题，但是 FlinkSQL 如果要算的话，它的状态值就一直要 hould 到内存里去了，而且挂掉后只能用它的 check point 去恢复。