文|智能相对论作者|leo陈攀登珠峰,传统路线有两条:一条是中国西藏的北坡,另一条是尼泊尔的南坡。不管选择从南坡还是从北坡攀登,最终都将到达同一个顶峰。这其实与自动驾驶行业的发展路径之间存在相似之处。对攀登珠峰的人而言,无论走哪条路线都不是容易的事。北坡一开始没有登山的感觉,更像是高海拔徒步,边走边欣赏风景;南坡会遇到昆布冰川,路线有时接近垂直,落石和雪崩的风险不小。相比于北坡,南坡冲顶时间短、攀登强度大,爬升和下降的海拔更高。这其实对应着自动驾驶行业的两条大的研发路径:一条是以车企为主的渐进式策略,一般从L1、L2开始,再逐步叠加高阶功能;另一条是以科技互联网企业为代表的跨越式策略,直接从L...... Last article READ

一文了解基于Flink构建全场景实时数仓

本文目录:

一. 实时计算初期

二. 实时数仓建设

三. Lambda架构的实时数仓

四. Kappa架构的实时数仓

五. 流批结合的实时数仓

实时计算初期

虽然实时计算在最近几年才火起来,但是在早期也有不少公司有实时计算的需求,但数据量不成规模,所以在实时方面形成不了完整的体系,基本所有的开发都是具体问题具体分析,来一个需求做一个,基本不考虑它们之间的关系,开发形式如下:

早期实时计算

如上图所示,拿到数据源后,会经过数据清洗,扩维,通过Flink进行业务逻辑处理,最后直接进行业务输出。把这个环节拆开来看,数据源端会重复引用相同的数据源,后面进行清洗、过滤、扩维等操作,都要重复做一遍,唯一不同的是业务的代码逻辑是不一样的。

随着产品和业务人员对实时数据需求的不断增多,这种开发模式出现的问题越来越多:

数据指标越来越多,“烟囱式”的开发导致代码耦合问题严重。

需求越来越多,有的需要明细数据,有的需要 OLAP 分析。单一的开发模式难以应付多种需求。

每个需求都要申请资源,导致资源成本急速膨胀,资源不能集约有效利用。

缺少完善的监控系统,无法在对业务产生影响之前发现并修复问题。

大家看实时数仓的发展和出现的问题,和离线数仓非常类似,后期数据量大了之后产生了各种问题,离线数仓当时是怎么解决的?离线数仓通过分层架构使数据解耦,多个业务可以共用数据,实时数仓是否也可以用分层架构呢?当然是可以的,但是细节上和离线的分层还是有一些不同,稍后会讲到。

实时数仓建设

从方法论来讲,实时和离线是非常相似的,离线数仓早期的时候也是具体问题具体分析,当数据规模涨到一定量的时候才会考虑如何治理。分层是一种非常有效的数据治理方式,所以在实时数仓如何进行管理的问题上,首先考虑的也是分层的处理逻辑。

实时数仓的架构如下图:

实时数仓架构

从上图中我们具体分析下每层的作用:

数据源:在数据源的层面,离线和实时在数据源是一致的,主要分为日志类和业务类,日志类又包括用户日志,埋点日志以及服务器日志等。

实时明细层:在明细层,为了解决重复建设的问题,要进行统一构建,利用离线数仓的模式,建设统一的基础明细数据层,按照主题进行管理,明细层的目的是给下游提供直接可用的数据,因此要对基础层进行统一的加工,比如清洗、过滤、扩维等。

汇总层:汇总层通过Flink的简洁算子直接可以算出结果,并且形成汇总指标池,所有的指标都统一在汇总层加工,所有人按照统一的规范管理建设,形成可复用的汇总结果。

我们可以看出,实时数仓和离线数仓的分层非常类似,比如 数据源层,明细层,汇总层,乃至应用层,他们命名的模式可能都是一样的。但仔细比较不难发现,两者有很多区别:

与离线数仓相比,实时数仓的层次更少一些:

从目前建设离线数仓的经验来看,数仓的数据明细层内容会非常丰富,处理明细数据外一般还会包含轻度汇总层的概念,另外离线数仓中应用层数据在数仓内部,但实时数仓中,app 应用层数据已经落入应用系统的存储介质中,可以把该层与数仓的表分离。

应用层少建设的好处:实时处理数据的时候,每建一个层次,数据必然会产生一定的延迟。

汇总层少建的好处:在汇总统计的时候,往往为了容忍一部分数据的延迟,可能会人为的制造一些延迟来保证数据的准确。举例,在统计跨天相关的订单事件中的数据时,可能会等到 00:00:05 或者 00:00:10 再统计,确保 00:00 前的数据已经全部接受到位了,再进行统计。所以,汇总层的层次太多的话,就会更大的加重人为造成的数据延迟。

与离线数仓相比,实时数仓的数据源存储不同:

在建设离线数仓的时候,基本整个离线数仓都是建立在 Hive 表之上。但是,在建设实时数仓的时候,同一份表,会使用不同的方式进行存储。比如常见的情况下,明细数据或者汇总数据都会存在 Kafka 里面,但是像城市、渠道等维度信息需要借助 Hbase,MySQL 或者其他 KV 存储等数据库来进行存储。Lambda架构的实时数仓

Lambda和Kappa架构的概念已在前文中解释,不了解的小伙伴可点击链接:一文读懂大数据实时计算

下图是基于 Flink 和 Kafka 的 Lambda 架构的具体实践,上层是实时计算,下层是离线计算,横向是按计算引擎来分,纵向是按实时数仓来区分:

Lambda架构的实时数仓

Lambda架构是比较经典的架构,以前实时的场景不是很多,以离线为主,当附加了实时场景后,由于离线和实时的时效性不同,导致技术生态是不一样的。Lambda架构相当于附加了一条实时生产链路,在应用层面进行一个整合,双路生产,各自独立。这在业务应用中也是顺理成章采用的一种方式。

双路生产会存在一些问题,比如加工逻辑double,开发运维也会double,资源同样会变成两个资源链路。因为存在以上问题,所以又演进了一个Kappa架构。

Kappa架构的实时数仓

Kappa架构相当于去掉了离线计算部分的Lambda架构,具体如下图所示:

Kappa架构的实时数仓

Kappa架构从架构设计来讲比较简单,生产统一,一套逻辑同时生产离线和实时。但是在实际应用场景有比较大的局限性,因为实时数据的同一份表,会使用不同的方式进行存储,这就导致关联时需要跨数据源,操作数据有很大局限性,所以在业内直接用Kappa架构生产落地的案例不多见,且场景比较单一。

关于 Kappa 架构,熟悉实时数仓生产的同学,可能会有一个疑问。因为我们经常会面临业务变更,所以很多业务逻辑是需要去迭代的。之前产出的一些数据,如果口径变更了,就需要重算,甚至重刷历史数据。对于实时数仓来说,怎么去解决数据重算问题?

Kappa 架构在这一块的思路是:首先要准备好一个能够存储历史数据的消息队列,比如 Kafka,并且这个消息队列是可以支持你从某个历史的节点重新开始消费的。接着需要新起一个任务,从原来比较早的一个时间节点去消费 Kafka 上的数据,然后当这个新的任务运行的进度已经能够和现在的正在跑的任务齐平的时候,你就可以把现在任务的下游切换到新的任务上面,旧的任务就可以停掉,并且原来产出的结果表也可以被删掉。

流批结合的实时数仓

随着实时 OLAP 技术的发展,目前开源的OLAP引擎在性能,易用等方面有了很大的提升,如Doris、Presto等,加上数据湖技术的迅速发展,使得流批结合的方式变得简单。

如下图是流批结合的实时数仓:

流批结合的实时数仓

数据从日志统一采集到消息队列,再到实时数仓,作为基础数据流的建设是统一的。之后对于日志类实时特征,实时大屏类应用走实时流计算。对于Binlog类业务分析走实时OLAP批处理。

我们看到流批结合的方式与上面几种架构使用的组件发生了变化,多了数据湖 Iceberg 和 OLAP 引擎 Presto。Iceberg是介于上层计算引擎和底层存储格式之间的一个中间层,我们可以把它定义成一种“数据组织格式”,底层存储还是HDFS,Iceberg的ACID能力可以简化整个流水线的设计,降低整个流水线的延迟,并且所具有的修改、删除能力能够有效地降低开销,提升效率。Iceberg可以有效支持批处理的高吞吐数据扫描和流计算按分区粒度并发实时处理。OLAP查询引擎使用Presto,Presto是一个分布式的采用MPP架构的查询引擎,本身并不存储数据,但是可以接入多种数据源,并且支持跨数据源的级联查询。擅长对海量数据进行复杂的分析。

曾经暧昧回应荣耀手机交易,如今正面承认华为合作。只是,未透露合作具体细节文/智物近期,神州数码与华为深度合作的传闻再起,7月2日上午,神州数码强势涨停。此番,神州数码与华为之间是否会有结果?2020年年中,当华为计划出售荣耀手机,真正第一个冲在前台的意向买家没有露面。最终的深圳国资系主导的买方方案,是个意外。而神州数码当时也一直是传闻中的参与方。二级市场股价闻风而动,一度冲高至36元。当时,神州数码公司一纸暧昧回应:与华为未就荣耀一事达成任何协议。此言一出,引来外界诟病不已。想来,神州数码与手机业务注定无缘。此前,神州数码曾经两度在手机份销业务重挫,一轮是分销,一轮是因为与黑莓手机的深度合作。......Next article READ