1、发展历史
从业务团队和大数据团队烟囱式的开发，到构建大数据平台，18年开始行动，速度还是可以的。18年Flink不太成熟，使用Sparkstreaming属于正常的选择范畴，同时，构建了任务调度平台+SQL开发平台，降低开发难度，提升开发效率，是一个不错的选择。
随着任务增大，对于延迟、状态的管理、多任务的稳定性都有非常大的挑战，19年转向Flink，社区非常活跃，成果也非常多。
在FLink的基础上，基于之前的SQL平台功能，基于Flink1.8 快速构建了SQL2.0的功能，从此开启了实时数仓的建设。
随着公司的事件越来越多，为了满足公司事件流处理场景，20年底基于Flink1.11构建了SQL3.0的事件处理平台。
目前支持了30+个产品，1000+个任务（2019.5~2020.12），数据量达2500亿/日（所有流量、行业日志、数仓建设的数据），峰值达300万/秒，数据的支撑度还是蛮可观的。
2、平台架构
从功能特征层面，分4个维度
1）任务托管：支持任务托管的能力，包括任务的编辑发布、任务启停、版本管理、监控报警等；
2）多语言开发：支持Java、Scala、Python各类实时任务的开发，方便各种实时任务的接入；
3）多种任务类型：自定义任务、模板任务、场景任务（SQL），SQL任务占比比较高达到80%左右；
4）资源隔离：对于数据量大且稳定的任务，提供专有队列，确保稳定可靠；对于数据量小，可以使用公共队列；
从分层架构来看，整个平台架构分为四层：
1）计算&存储层：消息队列、Flink/SparkStreaming、Hive、Redis、RMDB、Hbase、ClickHouse、Doris、HDFS、YARN；
2）引擎层：StreamSQL、DataStream、StreamCEP；
3）开发管理层：分场景、自定义、模板3类任务处理。包括模板管理、任务管理、实例管理、数据源管理、连接管理、项目管理、资源管理、监控报警；
4）应用场景：ETL、监控、BI、推荐、风控、运营等；
从整体架构来看，底层是计算和存储，计算支持FLink和Spark，存储支持消息队列、各种OLAP、同时支持Mysql、Hive实时落盘，维表支持Redis、Hbase存储。ClickHouse主要是实时OLAP的存储，由于Doris支持update且关联查询支持的比较好，也引入了Doris做为实时的OLAP的存储。
引擎层主要是封装SQL引擎、DataStream的通用性操作，事件处理方面，Flink的CEP做了普通规则的封装。
开发管理层提供了3种场景的任务开发、监控、资源管理。
对于大数据平台来说，可用性方面，一个是计算的可持续，一个是任务调度运行的稳定性，一个是预警监控，3者为平台成功的核心要素，支撑整个业务的稳定运行；
任务调度是一个比较关键的内容，从任务的状态来看，主要是启动任务，创建实例，实例创建后，则有启动状态（成功、失败）、运行状态（成功、失败），不管是启动还是运行，都可以手动开启和手动停止，也可以通过定时任务启动或重试。在整个的运行过程中，需要设置延迟、心跳的阈值、重试的次数，如果不能在重试次数内完成，则要通知任务负责人介入处理。
再说一下预警监控。所有的监控日志都存入influxDB，进行可视化的处理，可以通过大屏或图表，展示系统运行的实际情况。同时通过依赖注入和Flink 任务支持自定义 Reporter 的 metrics 获取日志信息，在拿到监控信息后，可以实时的进行延迟报警、心跳报警，同时也可以基于血缘关系进行流量分析，还可以支撑起状态及任务的恢复。
监控整体的技术处理流程为，基于Spark的SDK、Flink的自定义 Reporter 的 metrics 、Java agent的依赖注入3种方式完成日志的采集，将所有日志推入Kafka，然后基于预警监控平台，实时计算进行监控预警，并将结果存入influxDB进行可视化展示和报告的呈现，为研发人员提供强有力的技术监控信息，为架构的优化、系统的稳定运行提供强有力的技术支撑。
3、实时数仓
从功能特征包括了元数据管理，数据分层架构，其中数据分层架构有以下几个原则：
1）实时，分层越少越好，中间环节太多，出问题的概率越大；
2）SQL层面，支持标准语法，维表关联，提供图形化的SQL开发环境，支持丰富的内置函数和UDF；
3）血缘，平台支持图形化和完善的链路分析，实时标准数据流的变化和异常；
4）多源支持，不管是前端日志，还是后端日志，还是各种DB都做到了很好的支撑；
架构层面，整体来看依然是Lambda架构，实时与离线分离，离线对实时进行覆盖修复。
整体来说，行业日志，后端日志、DB数据采集统一到Kafka，再送入到ODS层，同时维度数据会存储到Redis或Hbase中，在计算过程中做维度关联使用；DWD层会进行维度关联的处理，然后将结果存入ClickHouse中，以满足部分业务查询场景诉求；DWS也会做一些汇总聚合，结果也会存入ClickHouse中，以满足部分业务的查询场景诉求；但不管是基于DWD还是DWS的查询，ClickHouse支持关系查询时都力不从心，引入Doris，支持Update和关联查询，更好的提供查询服务。
4、实时开发平台
实时开发平台主要是SQL的编辑器、调试器、SQL引擎、血缘管理等。
编辑器的整体界面，包括编辑器、执行计划查看器、任务调试，同时也可以定义源表、维表、输出表，也可以定义流表并自动生成DDL（DDL也支持SQL编辑）。
对于开发来说，调试是非常核心的一个功能。一般调试分析自动和手动2种方式。手动需要准备样例数据，复制到开发界面；自动方式则会从上游的SQL任务获取校例数据。元数据信息（Kafka、Hbase、Clickhouse等）是动态获得的，元信息与样例共同生成DebugSQL去调用 SQL引擎的公共服务。SQL引擎得到样例数据后，如果有关联维表的操作，则会关联线上维表，在SQL引擎中执行调试，将结果送给UI端展示，展示时分为样例数据和下游结果数据。
血缘关系，是非常有价值的，从溯源分析、问题排查、差异分析、提升用户体验、变动/异常预警方面都大有可为。建立在元数据定义的基础上，在元数据管理方面需要有很好的设计，支撑起相关的分析，确保上述能力的高效兑现。
SQL引擎是抹平开发人员与大数据各种数据源的鸿沟的利器，能够大大提升开发及运维效率，要确定SQL的标准语法，然后通过解释转换器转换为标准语法，基于标准语法进行执行计划的分析生成，最终对接Flink引擎进行实际计算，完成数据处理的过程。比如源上面，支持多种源比如Kafka；对于维表支持Hbase、Redis、ClickHouse多种源；对于数据存储支持Redis、Hbase、ClickHouse、Kafka、Doris、Mysql等；
最新版本中Flink1.11 支持DDL，所以这部分我们不会再做，而是直接使用其新特性：
解析模块（Parse Model）将用户原始的 SQL 解析成内部的执行计划，完全依赖于 Flink SQL。Connector Model 完成目前 Flink 尚未支持的 Connector 开发。
Format Model 实现数据源字段的序列化和反序列化。
执行模块（Execute Model）基于 Flink1.11 SQL API 执行解析后的执行计划。
UDF 模块是专门处理 UDF 的解析，如参数调用的合法验证、权限验证、细致的数据权限限制。
SDK Model 是对外提供的标准化服务，如 SQL 文本开发的验证，debug 功能等。
以上是关于BK的实时数仓的学习总结，整体架构紧跟潮流，并且在FlinkSQL的实践上，有很好的经验。特别是任务调度引擎、SQL引擎，很好的支撑起业务的运行；同时实时开发编辑器、调试器，大大降低了资产开发人员的难度和学习成本；存储查询引擎也引入了Mysql、Redis、Hbase、ClickHouse、Doris组件，很好的满足了不同场景的数据查询要求；这些维度都是可以借鉴。