前言
“数据智能”(DataIntelligence)有一个必须且基础的环节，就是数据仓库的建设，同时，数据仓库也是公司数据发展到一定规模后必然会提供的一种基础服务。
从智能商业的角度来讲，数据的结果代表了用户的反馈，获取结果的及时性就显得尤为重要，快速的获取数据反馈能够帮助公司更快的做出决策，更好的进行产品迭代，实时数仓在这一过程中起到了不可替代的作用。
本文主要讲述知乎的实时数仓实践以及架构的演进。
这包括以下几个方面：
实时数仓1.0版本，主题：ETL逻辑实时化，技术方案：SparkStreaming。
实时数仓2.0版本，主题：数据分层，指标计算实时化，技术方案：FlinkStreaming。
实时数仓未来展望：StreamingSQL平台化，元信息管理系统化，结果验收自动化。
实时数仓1.0版本
1.0版本的实时数仓主要是对流量数据做实时ETL，并不计算实时指标，也未建立起实时数仓体系，实时场景比较单一，对实时数据流的处理主要是为了提升数据平台的服务能力。实时数据的处理向上依赖数据的收集，向下关系到数据的查询和可视化，下图是实时数仓1.0版本的整体数据架构图。
第一部分是数据采集，由三端SDK采集数据并通过LogCollectorServer发送到Kafka。
第二部分是数据ETL，主要完成对原始数据的清洗和加工并分实时和离线导入Druid。
第三部分是数据可视化，由Druid负责计算指标并通过WebServer配合前端完成数据可视化。
其中第一、三部分的相关内容请分别参考：知乎客户端埋点流程、模型和平台技术，Druid与知乎数据分析平台，此处我们详细介绍第二部分。
由于实时数据流的稳定性不如离线数据流，当实时流出现问题后需要离线数据重刷历史数据，因此实时处理部分我们采用了lambda架构。大数据架构系列--Lambda架构初体验。
Lambda架构有高容错、低延时和可扩展的特点，为了实现这一设计，我们将ETL工作分为两部分：StreamingETL和BatchETL。
StreamingETL
这一部分我会介绍实时计算框架的选择、数据正确性的保证、以及Streaming中一些通用的ETL逻辑，最后还会介绍SparkStreaming在实时ETL中的稳定性实践。
计算框架选择
在年年初，业界用的比较多的实时计算框架有Storm和SparkStreaming。Storm是纯流式框架，SparkStreaming用MicroBatch模拟流式计算，前者比后者更实时，后者比前者吞吐量大且生态系统更完善，考虑到知乎的日志量以及初期对实时性的要求，我们选择了SparkStreaming作为实时数据的处理框架。
数据正确性保证
SparkStreaming的端到端Exactly-once需要下游支持幂等、上游支持流量重放，这里我们在SparkStreaming这一层做到了At-least-once，正常情况下数据不重不少，但在程序重启时可能会重发部分数据，为了实现全局的Exactly-once，我们在下游做了去重逻辑，关于如何去重后面我会讲到。
通用ETL逻辑
ETL逻辑和埋点的数据结构息息相关，我们所有的埋点共用同一套ProtoBufferSchema，大致如下所示。
messageLogEntry{
optionalBaseInfobase=1;
optionalDetailInfodetail=2;
optionalExtraInfoextra=3;
}
BaseInfo：日志中最基本的信息，包括用户信息、客户端信息、时间信息、网络信息等日志发送时的必要信息。
DetailInfo：日志中的视图信息，包括当前视图、上一个视图等用于定位用户所在位置的信息。
ExtraInfo：日志中与特定业务相关的额外信息。
针对上述三种信息我们将ETL逻辑分为通用和非通用两类，通用逻辑和各个业务相关，主要应用于Base和Detail信息，非通用逻辑则是由需求方针对某次需求提出，主要应用于Extra信息。
这里我们列举3个通用逻辑进行介绍，这包括：动态配置Streaming、UTM参数解析、新老用户识别。
动态配置Streaming
由于Streaming任务需要7*24小时运行，但有些业务逻辑，比如：存在一个元数据信息中心，当这个元数据发生变化时，需要将这种变化映射到数据流上方便下游使用数据，这种变化可能需要停止Streaming任务以更新业务逻辑，但元数据变化的频率非常高，且在元数据变化后如何及时通知程序的维护者也很难。动态配置Streaming为我们提供了一个解决方案，该方案如下图所示。
我们可以把经常变化的元数据作为StreamingBroadcast变量，该变量扮演的角色类似于只读缓存，同时针对该变量可设置TTL，缓存过期后Executor节点会重新向Driver请求最新的变量。通过这种机制可以非常自然的将元数据的变化映射到数据流上，无需重启任务也无需通知程序的维护者。
UTM参数解析
UTM的全称是UrchinTrackingModule，是用于追踪网站流量来源的利器，下图是我们解析UTM信息的完整逻辑。
流量数据通过UTM参数解析后，我们可以很容易满足以下需求查看各搜索引擎导流情况以及这些流量来自于哪些热门搜索词。
市场部某次活动带来的流量大小，如：页面浏览数、独立访问用户数等。从站内分享出去的链接在各分享平台（如：