随着微博业务线的疾速扩张，微博广告各类业务日志的数量也随之急剧增长。传统基于 Hadoop 生态的离线数据存储计算方案已在业界构成一致的默契，但受制于离线计算的时效性制约，越来越多的数据运用场景已从离线转为实时。微博广告实时数据平台以此为背景停止设计与构建，目前该系统已支持日均处理日志数量超过百亿，接入产品线、业务日志类型若干。
一.技术选型
相比于 Spark，目前 Spark 的生态总体更为完善一些，且在机器学习的集成和运用性暂时抢先。但作为下一代大数据引擎的有力竞争者-Flink 在流式计算上有分明优势，Flink 在流式计算里属于真正意义上的单条处理，每一条数据都触发计算，而不是像 Spark 一样的 Mini Batch 作为流式处理的妥协。Flink 的容错机制较为轻量，对吞吐量影响较小，而且拥有图和调度上的一些优化，使得 Flink 可以达到很高的吞吐量。而 Strom 的容错机制需求对每条数据停止 ack，因此其吞吐量瓶颈也是备受诟病。
这里援用一张图来对常用的实时计算框架做个对比。
Flink 特点
Flink 是一个开源的分布式实时计算框架。Flink 是有形状的和容错的，可以在维护一次运用程序形状的同时无缝地从缺点中恢复；它支持大规模计算才能，可以在数千个节点上并发运转；它具有很好的吞吐量和延迟特性。同时，Flink 提供了多种灵敏的窗口函数。
1）形状管理机制
Flink 检查点机制能保持 exactly-once 语义的计算。形状保持意味着运用可以保存曾经处理的数据集结果和形状。
2）事情机制
Flink 支持流处理和窗口事情工夫语义。事情工夫可以很容易地经过事情到达的顺序和事情能够的到达延迟流中计算出准确的结果。
3）窗口机制
Flink 支持基于工夫、数目以及会话的非常灵敏的窗口机制（window）。可以定制 window 的触发条件来支持愈加复杂的流形式。
4）容错机制
Flink 高效的容错机制允许系统在高吞吐量的状况下支持 exactly-once 语义的计算。Flink 可以准确、疾速地做到从缺点中以零数据丢失的效果停止恢复。
5）高吞吐、低延迟
Flink 具有高吞吐量和低延迟（能疾速处理大量数据）特性。下图展现了 Apache Flink 和 Apache Storm 完成分布式项目计数义务的功能对比。
二.架构演化
初期架构
初期架构仅为计算与存储两层，新来的计算需求接入后需求新开发一个实时计算义务停止上线。反复模块的代码复用率低，反复率高，计算义务间的区别次要是集中在义务的计算目的口径上。
在存储层，各个需求方所需求的存储途径都不相反，计算目的能够在不通的存储引擎上有反复，有计算资源以及存储资源上的糜费状况。并且对于目的的计算口径也是仅局限于单个义务需求里的，不通需求义务对于相反的目的的计算口径没有停止一致的限制于保障。各个业务方也是在不同的存储引擎上开发数据获取服务，对于那些专注于数据运用本身的团队来说，无疑当前形式存在一些弊端。
后期架构
随着数据体量的添加以及业务线的扩展，后期架构形式的弊端逐渐末尾显现。从当初单需求单义务的形式逐渐转变为通用的数据架构形式。为此，我们开发了一些基于 Flink 框架的通用组件来支持数据的疾速接入，并保证代码形式的一致性和维护性。在数据层，我们基于 Clickhouse 来作为我们数据仓库的计算和存储引擎，应用其支持多维 OLAP 计算的特性，来处理在多维多目的大数据量下的疾速查询需求。在数据分层上，我们参考与自创离线数仓的阅历与方法，构建多层实时数仓服务，并开发多种微服务来为数仓的数据聚合，目的提取，数据出口，数据质量，报警监控等提供支持。
全体架构分为五层：
1）接入层：接入原始数据停止处理，如 Kafka、RabbitMQ、File 等。
2）计算层：选用 Flink 作为实时计算框架，对实时数据停止清洗，关联等操作。
3）存储层：对清洗完成的数据停止数据存储，我们对此停止了实时数仓的模型分层与构建，将不同运用场景的数据分别存储在如 Clickhouse,Hbase,Redis,Mysql 等存储。服务中，并笼统公共数据层与维度层数据，分层处理紧缩数据并一致数据口径。
4）服务层：对外提供一致的数据查询服务，支持从底层明细数据到聚合层数据 5min/10min/1hour 的多维计算服务。同时最下层特征目的类数据，如计算层输入到Redis、Mysql 等也从此数据接口停止获取。
5）运用层：以一致查询服务为支撑对各个业务线数据场景停止支撑。
监控报警：对 Flink 义务的存活形状停止监控，对异常的义务停止邮件报警并根据设定的参数对义务停止自动拉起与恢复。根据如 Kafka 消费的 offset 目的对消费处理延迟的实时义务停止报警提示。数据质量：监控实时数据目的，对历史的实时数据与离线 hive 计算的数据定时做对比，提供实时数据的数据质量目的，对超过阈值的目的数据停止报警。
三.数据处理流程
1.全体流程
全体数据从原始数据接入后经过 ETL 处理, 进入实时数仓底层数据表，经过配置化聚合微服务组件向上停止分层数据的聚合。根据不同业务的目的需求也可经过特征抽取微服务直接配置化从数仓中抽取到如 Redis、ES、Mysql 中停止获取。大部分的数据需求可经过一致数据服务接口停止获取。
2.成绩与应战
原始日志数据由于各业务日志的不同，所拥有的维度或目的数据并不残缺。所以需求停止实时的日志的关联才能获取不同维度条件下的目的数据查询结果。并且关联日志的回传周期不同，有在 10min 之内完成 95% 以上回传的业务日志，也有相似于激活日志等依赖第三方回传的有义务日志，延迟窗口能够大于1天。
并且最大日志关联义务的日均数据量在 10 亿级别以上，如何疾速处理与构建实时关联义务的成绩首先摆在我们面前。对此我们基于 Flink 框架开发了配置化关联组件。对于不同关联日志的目的抽取，我们也开发了配置化目的抽取组件用于疾速提取复杂的日志格式。以上两个自研组件会在后面的内容里再做详细引见。
1）回传周期超过关联窗口的日志如何处理?
对于回传晚的日志，我们在关联窗口内未获得关结合果。我们采用实时+离线的方式停止数据回刷补全。实时处理的日志我们会将未关联的原始日志输入到另外一个暂存地(Kafka)，同时不断消费处理这个未关联的日志集合，设定超时重关联次数与超时重关联工夫，超过所设定恣意阈值后，便再停止重关联。离线部分，我们采用 Hive 计算昨日全天日志与 N 天内的全量被关联日志表停止关联，将最终的结果回写出来，交换实时所计算的昨日关联数据。
2）如何提高 Flink 义务功能？
① Operator Chain
为了更高效地分布式执行，Flink 会尽能够地将 operator 的 subtask 链接（chain）在一同构成 task。每个 task 在一个线程中执行。将 operators 链接成 task 是非常有效的优化：它能减少线程之间的切换，减少音讯的序列化/反序列化，减多数据在缓冲区的交换，减少了延迟的同时提高全体的吞吐量。
Flink 会在生成 JobGraph 阶段，将代码中可以优化的算子优化成一个算子链（Operator Chains）以放到一个 task（一个线程）中执行，以减少线程之间的切换和缓冲的开支，提高全体的吞吐量和延迟。下面以官网中的例子停止阐明。
图中，source、map、[keyBy|window|apply]、sink 算子的并行度分别是 2、2、2、2、1，经过 Flink 优化后，source 和 map 算子组成一个算子链，作为一个 task 运转在一个线程上，其简图如图中 condensed view 所示，并行图如 parallelized view 所示。算子之间能否可以组成一个 Operator Chains，看能否满足以下条件：
上下游算子的并行度分歧；下游节点的入度为 1；上下游节点都在同一个 slot group 中；下游节点的 chain 策略为 ALWAYS；下游节点的 chain 策略为 ALWAYS 或 HEAD；两个节点间数据分区方式是 forward；用户没有禁用 chain。
② Flink 异步 IO
流式计算中，常常需求与外部系统停止交互。而往往一次衔接中你那个获取衔接等待通讯的耗时会占比较高。下图是两种方式对比示例：
图中棕色的长条表示等待工夫，可以发现网络等待工夫极大地妨碍了吞吐和延迟。为了处理同步访问的成绩，异步形式可以并发地处理多个央求和回复。也就是说，你可以延续地向数据库发送用户 a、b、c 等的央求，与此同时，哪个央求的回复先前往了就处理哪个回复，从而延续的央求之间不需求阻塞等待，如上图左边所示。这也正是 Async I/O 的完成原理。
③ Checkpoint 优化
Flink 完成了一套弱小的 checkpoint 机制，使它在获取高吞吐量功能的同时，也能保证 Exactly Once 级别的疾速恢复。
首先提升各节点 checkpoint 的功能思索的就是存储引擎的执行效率。Flink 官方支持的三种 checkpoint state 存储方案中，Memory 仅用于调试级别，无法做缺点后的数据恢复。其次还有 Hdfs 与 Rocksdb，当所做 Checkpoint 的数据大小较大时，可以思索采用 Rocksdb 来作为 checkpoint 的存储以提升效率。
其次的思绪是资源设置，我们都知道 checkpoint 机制是在每个 task 上都会停止，那么当总的形状数据大小不变的状况下，如何分配减少单个 task 所分的 checkpoint 数据变成了提升 checkpoint 执行效率的关键。
最后，增量快照. 非增量快照下，每次 checkpoint 都包含了作业一切形状数据。而大部分场景下，前后 checkpoint 里，数据发生变更的部分相对很少，所以设置增量 checkpoint，仅会对上次 checkpoint 和本次 checkpoint 之间形状的差异停止存储计算，减少了 checkpoint 的耗时。
3）如何保障义务的波动性?
在义务执行过程中，会遇到各种各样的成绩，导致义务异常甚至失败。所以如何做好异常状况下的恢复工作显得异常重要。
① 设定重启策略
Flink 支持不同的重启策略，以在缺点发生时控制造业如何重启。集群在启动时会伴随一个默许的重启策略，在没有定义详细重启策略时会运用该默许策略。假如在工作提交时指定了一个重启策略，该策略会覆盖集群的默许策略。
默许的重启策略可以经过 Flink 的配置文件 flink-conf.yaml 指定。配置参数 restart-strategy 定义了哪个策略被运用。
常用的重启策略：
固定间隔(Fixed delay)；失败率(Failure rate)；无重启(No restart)。
② 设置 HA
Flink 在义务启动时指定 HA 配置次要是为了应用 Zookeeper 在一切运转的 JobManager 实例之间停止分布式协调 .Zookeeper 经过 leader 选取和轻量级分歧性的形状存储来提供高可用的分布式协调服务。
③ 义务监控报警平台
在实践环境中，我们遇见过由于集群形状不波动而导致的义务失败。在 Flink 1.6 版本中，甚至遇见过义务出现假死的状况，也就是 Yarn 上的 job 资源依然存在，而 Flink 义务虚际曾经死亡。为了监测与恢复这些异常的义务，并且对实时义务做一致的提交、报警监控、义务恢复等管理，我们开发了义务提交与管理平台。经过 Shell 拉取 Yarn 上 Running 形状与 Flink Job 形状的列表停止对比，心跳监测平台上的一切义务，并停止告警、自动恢复等操作。
④ 作业目的监控
Flink 义务在运转过程中，各 Operator 都会产生各自的目的数据，例如，Source 会产出 numRecordIn、numRecordsOut 等各项目的信息，我们会将这些目的信息停止搜集，并展如今我们的可视化平台上。目的平台如下图：
⑤ 义务运转节点监控
我们的 Flink 义务都是运转在 Yarn 上，针对每一个运转的作业，我们需求监控其运转环境。会搜集 JobManager 及 TaskManager 的各项目的。搜集的目的有 jobmanager-fullgc-count、jobmanager-younggc-count、jobmanager-fullgc-time、jobmanager-younggc-time、taskmanager-fullgc-count、taskmanager-younggc-count、taskmanager-fullgc-time、taskmanager-younggc-time 等，用于判别义务运转环境的健康度，及用于排查能够出现的成绩。监控界面如下：
四.数据关联组件
1.如何选择关联方式？
1）Flink Table
从 Flink 的官方文档，我们知道 Flink 的编程模型分为四层，sql 是最高层的 api, Table api 是中间层，DataSteam/DataSet Api 是核心，stateful Streaming process 层是底层完成。
刚末尾我们直接运用 Flink Table 做为数据关联的方式，直接将接入出去的 DataStream 注册为 Dynamic Table 后停止两表关联查询，如下图：
但尝试后发如今做那些日志数据量大的关联查询时往往只能在较小的工夫窗口内做查询，否则会超过 datanode 节点单台内存限制，产生异常。但为了满足不同业务日志延迟到达的状况，这种完成方式并不通用。
2）Rocksdb
之后，我们直接在 DataStream 上停止处理，在 CountWindow 窗口内停止关联操作，将被关联的数据 Hash 打散后存储在各个 datanode 节点的 Rocksdb 中，应用 Flink State 原生支持 Rocksdb 做 Checkpoint 这一特性停止算子内数据的备份与恢复。这种方式是可行的，但受制于 Rocksdb 集群物理磁盘为非 SSD 的要素，这种方式在我们的实践线上场景中关联耗时较高。
3）外部存储关联
如 Redis 类的 KV 存储的确在查询速度上提升不少，但相似广告日志数据这样单条日志大小较大的状况，会占用不少宝贵的机器内存资源。经过调研后，我们选取了 Hbase 作为我们日志关联组件的关联数据存储方案。
为了疾速构建关联义务，我们开发了基于 Flink 的配置化组件平台，提交配置文件即可生成数据关联义务并自动提交到集群。下图是义务执行的处理流程。
表示图如下：
下图是关联组件内的执行流程图：
2.成绩与优化
1）加入 Interval Join
随着日志量的添加，某些需求停止关联的日志数量能够达到日均十几亿甚至几十亿的量级。后期关联组件的配置化生成义务的方式的确处理了大部分线上业务需求，但随着进一步的关联需求添加，Hbase 面临着宏大的查询压力。在我们对 Hbase 表包括 rowkey 等一系列完成优化之后，我们末尾了对关联组件的迭代与优化。
第一步，减少 Hbase 的查询。我们运用 Flink Interval Join 的方式，先将大部分关联需求在程序外部完成，只要少部分仍需查询的日志会去查询外部存储(Hbase). 阅历证，以央求日志与实验日志关联为例，对于设置 Interval Join 窗口在 10s 左右即可减少 80% 的 hbase 查询央求。
① Interval Join 的语义表示图
数据 JOIN 的区间 - 比如工夫为 3 的 EXP 会在 IMP 工夫为[2, 4]区间停止JOIN；WaterMark - 比如图示 EXP 一条数据工夫是 3，IMP 一条数据工夫是 5，那么WaterMark是根据实践最小值减去 UpperBound 生成，即：Min(3,5)-1 = 2；过期数据 - 出于功能和存储的思索，要将过期数据肃清，如图当 WaterMark 是 2 的时分工夫为 2 以前的数据过期了，可以被肃清。
② Interval Join 外部完成逻辑
③ Interval Join 改造
因 Flink 原生的 Intervak Join 完成的是 Inner Join,而我们业务中所需求的是 Left Join，详细改造如下：
取消右侧数据流的 join 标志位；左侧数据流有 join 数据时不存 state。
2）关联率动态监控
在义务执行中，往往会出现意想不到的状况，比如被关联的数据日志出现缺失，或者日志格式错误引发的异常，形成关联义务的关联率下降严重。那么此时关联义务虽然继续在运转，但对于全体数据质量的意义不大，甚至是反向作用。在义务停止恢复的时，还需求肃清异常区间内的数据，将 Kafka Offset 设置到异常前的地位再停止处理。
故我们在关联组件的优化中，加入了动态监控，下面表示图：
关联义务中定时探测指定工夫范围 Hbase 能否有最新数据写入，假如没有，阐明写 Hbase 义务出现成绩，则终止关联义务；当写 Hbase 义务出现堆积时，相应的会导致关联率下降，当关联率低于指定阈值时终止关联义务；当关联义务终止时会发出告警，修复下游义务后可重新恢复关联义务，保证关联数据不丢失。
五.数据清洗组件
为了疾速停止日志数据的目的抽取，我们开发了基于 Flink 计算平台的目的抽取组件Logwash。封装了基于 Freemaker 的模板引擎做为日志格式的解析模块，对日志停止提取，算术运算，条件判别，交换，循环遍历等操作。
下图是 Logwash 组件的处理流程：
组件支持文本与 Json 两种类型日志停止解析提取，目前该清洗组件已支持微博广告近百个实时清洗需求，提供给运维组等第三方非实时计算方向人员疾速停止提取日志的才能。
配置文件部分示例：
六.FlinkStream 组件库
Flink 中 DataStream 的开发，对于通用的逻辑及相反的代码停止了抽取，生成了我们的通用组件库 FlinkStream。FlinkStream 包括了对 Topology 的笼统及默许完成、对 Stream 的笼统及默许完成、对 Source 的笼统和某些完成、对 Operator 的笼统及某些完成、Sink 的笼统及某些完成。义务提交一致运用可执行 Jar 和配置文件，Jar 会读取配置文件构建对应的拓扑图。
1.Source 笼统
对于 Source 停止笼统，创建笼统类及对应接口，对于 Flink Connector 中已有的完成，例如 kafka,Elasticsearch 等，直接创建新 class 并承继接口，完成对应的方法即可。对于需求本人去完成的 connector，直接承继笼统类及对应接口，完成方法即可。目前只完成了 KafkaSource。
2.Operator 笼统
与 Source 笼统相似，我们完成了基于 Stream 到 Stream 级别的 Operator 笼统。创建笼统 Operate 类，笼统 Transform 方法。对于要完成的 Transform 操作，直接承继笼统类，完成其笼统方法即可。目前完成的 Operator，直接按照文档运用。如下：
3.Sink 笼统
针对 Sink，我们异样创建了笼统类及接口。对 Flink Connector 中已有的 Sink 停止封装。目前可经过配置停止数据输入的 Sink。目前以完成和封装的 Sink 组件有：Kafka、Stdout、Elasticsearch、Clickhouse、Hbase、Redis、MySQL。
4.Stream 笼统
创建 Stream 笼统类及笼统方法 buildStream，用于构建 StreamGraph。我们完成了默许的 Stream，buildStream 方法读取 Source 配置生成 DataStream，经过 Operator 配置列表按顺序生成拓扑图，经过 Sink 配置生成数据写出组件。
5.Topology 笼统
对于单 Stream，要处理的逻辑能够比较简单，次要读取一个 Source 停止数据的各种操作并输入。对于复杂的多 Stream 业务需求，比如多流 Join，多流 Union、Split 流等，因此我们多流业务停止了笼统，产生了 Topology。在 Topology 这一层可以对多流停止配置化操作。对于通用的操作，我们完成了默许 Topology，直接经过配置文件就可以完成业务需求。对于比较复杂的业务场景，用户可以本人完成 Topology。
6.配置化
我们对笼统的组件都是可配置化的，直接经过编写配置文件，构造义务的运转拓扑结构，启动义务时指定配置文件。
注释文本框 Flink Environment 配置化，包括工夫处理类型、重启策略，checkpoint 等；Topology 配置化，可配置不同 Stream 之间的处理逻辑与 Sink；Stream 配置化，可配置 Source，Operator 列表，Sink。
配置示例如下：
run_env:
timeCharacteristic: "ProcessingTime" #ProcessingTime\\IngestionTime\\EventTime
restart: # 重启策略配置
type: # noRestart, fixedDelayRestart, fallBackRestart, failureRateRestart
checkpoint: # 开启checkpoint
type: "rocksdb" #
streams:
impStream: #粉丝经济曝光日志
type: "DefaultStream"
config:
source:
type: "Kafka011" # 源是kafka011版本
config:
parallelism: 20
operates:
-
type: "StringToMap"
config:
-
type: "SplitElement"
config:
...
-
type: "SelectElement"
config:
transforms:
-
type: "KeyBy"
config:
-
type: "CountWindowWithTimeOut" #Window需求和KeyBy组合运用
config:
-
type: "SplitStream"
config:
-
type: "SelectStream"
config:
sink:
-
type: Kafka
config:
-
type: Kafka
config:
7.部署
在实时义务管理平台，新建义务，填写义务称号，选择义务类型（Flink）及版本，上传可执行 Jar 文件，导入配置或者手动编写配置，填写 JobManager 及 TaskManager 内存配置，填写并行度配置，选择能否重试，选择能否从 checkpoint 恢复等选项，保存后即可在义务列表中启动义务，并观察启动日志用于排查启动错误。
七.FlinkSQL 扩展
SQL 言语是一门声明式的，简单的，灵敏的言语，Flink 本身提供了对 SQL 的支持。Flink 1.6 版本和 1.8 版本对 SQL 言语的支持有限，不支持建表语句，不支持对外部数据的关联操作。因此我们经过 Apache Calcite 对 Flink SQL API 停止了扩展，用户只需求关怀业务需求怎样用 SQL 言语来表达即可。
1.支持创建源表
扩展了支持创建源表 SQL，经过解析 SQL 语句，获取数据源配置信息，创建对应的 TableSource 实例，并将其注册到 Flink environment。示例如下：
2.支持创建维表
运用 Apache Calcite 对 SQL 停止解析，经过维表关键字辨认维表，运用 RichAsyncFunction 算子异步读取维表数据，并经过 flatMap 操作生成关联后的 DataStream，然后转换为 Table 注册到 Flink Environment。示例如下：
3.支持创建视图
运用 SQLQuery 方法，支持从上一层表或者视图中创建视图表，并将新的视图表注册到 Flink Environment。创建语句需求按照顺序写，比如 myView2 是从视图 myView1 中创建的，则 myView1 创建语句要在myView2语句后面。如下：
4.支持创建结果表
支持创建结果表，经过解析 SQL 语句，获取配置信息，创建对应的 AppendStreamTableSink 或者 UpsertStreamTableSink 实例，并将其注册到 Flink Environment。示例如下：
5.支持自定义UDF
支持自定义 UDF 函数，承继 ScalarFunction 或者 TableFunction。在 resources 目录下有相应的 UDF 资源配置文件，默许会注册全部可执行 Jar 包中配置的 UDF。直接按照运用方法运用即可。
6.部署
部署方式同 Flink Stream 组件。
八.实时数据仓库的构建
为了保证明时数据的一致对外出口以及保证数据目的的一致口径，我们根据业界离线数仓的阅历来设计与构架微博广告实时数仓。
1.分层概览
数据仓库分为三层，自下而上为：数据引入层（ODS，Operation Data Store）、数据公共层（CDM，Common Data Model）和数据运用层（ADS，Application Data Service）
数据引入层（ODS，Operation Data Store）：将原始数据几乎无处理的存放在数据仓库系统，结构上与源系统基本保持分歧，是数据仓库的数据准。
数据公共层（CDM，Common Data Model，又称通用数据模型层）：包含 DIM 维度表、DWD 和 DWS，由 ODS 层数据加工而成。次要完成数据加工与整合，建立分歧性的维度，构建可复用的面向分析和统计的明细理想表，以及汇总公共粒度的目的。
公共维度层（DIM）：基于维度建模理念思想，建立整个企业的分歧性维度。降低数据计算口径和算法不一致风险。
公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常逐一对应。
公共汇总粒度理想层（DWS，Data Warehouse Service）：以分析的主题对象作为建模驱动，基于下层的运用和产品的目的需求，构建公共粒度的汇总目的理想表，以宽表化手腕物理化模型。构建命名规范、口径分歧的统计目的，为下层提供公共目的，建立汇总宽表、明细理想表。
公共汇总粒度理想层的表通常也被称为汇总逻辑表，用于存放派生目的数据。
明细粒度理想层（DWD，Data Warehouse Detail）：以业务过程作为建模驱动，基于每个详细的业务过程特点，构建最细粒度的明细层理想表。可以结合企业的数据运用特点，将明细理想表的某些重要维度属性字段做适当冗余，也即宽表化处理。
明细粒度理想层的表通常也被称为逻辑理想表。
数据运用层（ADS，Application Data Service）：存放数据产品个性化的统计目的数据。根据 CDM 与 ODS 层加工生成。
2.详细分层模型
对于原始日志数据，ODS 层几乎是每条日志抽取字段后停止保留，这样便能对成绩的回溯与追踪。在 CDM 层对 ODS 的数据仅做工夫粒度上的数据紧缩，也就是在指定工夫切分窗口里，对一切维度下的目的做聚合操作，而不触及业务性的操作。在 ADS 层，我们会有配置化抽取微服务，对底层数据做定制化计算和提取，输入到用户指定的存储服务里。
作者引见：
吕永卫，微博广告资深数据开发工程师，实时数据项目组担任人。黄鹏，微博广告实时数据开发工程师，担任法拉第实验平台数据开发、实时数据关联平台、实时算法特征数据计算、实时数据仓库、实时数据清洗组件开发工作。林发明，微博广告资深数据开发工程师，担任算法实时特征数据计算、实时数据关联平台、实时数据仓库、Flink Stream 组件开发工作。崔泽峰，微博广告资深数据开发工程师，担任实时算法特征数据计算、实时义务管理平台、FlinkStream 组件、FlinkSQL 扩展开发工作。
|
