实时数据架构体系建设思路
|
首先是 Flink 等实时计算引擎预计算好的秒级实时指标，这种需求对数据的时效性要求非常高，用于实时大屏、计算维度不复杂的实时报表需求。 其次是 Spark SQL 预计算的延迟在分钟级的准实时指标， 该类指标满足一些比较复杂但对数据时效性要求不太高的数据分析场景，可能会涉及到多个事实表的join，如销售归因等需求。 最后一种则是不需要预计算，ad-hoc查询的复杂多维数据分析场景，此类需求比较个性化，灵活性比较高，如果 OLAP 计算引擎性能足够强大，也可完全满足秒级计算需求的场景; 对外提供的秒级实时数据和另外两种准实时数据的比例大致为 3：7，绝大多数的业务需求都优先考虑准实时计算或 ad-hoc 方式，可以降低资源使用、提升数据准确性，以更灵活的方式满足复杂的业务场景。 3、实时数据体系建设方式 整个实时数据体系分为两种建设方式，即实时和准实时(它们的实现方式分别是基于流计算引擎和 ETL、OLAP 引擎，数据时效性则分别是秒级和分钟级。 1)在调度开销方面，准实时数据是批处理过程，因此仍然需要调度系统支持，调度频率较高，而实时数据却没有调度开销。 2)在业务灵活性方面，因为准实时数据是基于 ETL 或 OLAP 引擎实现，灵活性优于基于流计算的方式。 3)在对数据晚到的容忍度方面，因为准实时数据可以基于一个周期内的数据进行全量计算，因此对于数据晚到的容忍度也是比较高的，而实时数据使用的是增量计算，对于数据晚到的容忍度更低一些。 4)在适用场景方面，准实时数据主要用于有实时性要求但不太高、涉及多表关联和业务变更频繁的场景，如交易类型的实时分析，实时数据则更适用于实时性要求高、数据量大的场景，如实时特征、流量类型实时分析等场景。 4、流批一体实时数据架构发展 从1990年 Inmon 提出数据仓库概念到今天，大数据架构经历了从最初的离线大数据架构、Lambda 架构、Kappa 架构以及 Flink 的火热带出的流批一体架构，数据架构技术不断演进，本质是在往流批一体的方向发展，让用户能以最自然、最小的成本完成实时计算。 1)离线大数据架构：数据源通过离线的方式导入到离线数仓中，下游应用根据业务需求选择直接读取 DM 或加一层数据服务，比如 MySQL 或 Redis，数据存储引擎是 HDFS/Hive，ETL 工具可以是 MapReduce 脚本或 HiveSQL。数据仓库从模型层面分为操作数据层 ODS、数据仓库明细层 DWD、数据集市层 DM。 2)Lambda 架构：随着大数据应用的发展，人们逐渐对系统的实时性提出了要求，为了计算一些实时指标，就在原来离线数仓的基础上增加了一个实时计算的链路，并对数据源做流式改造(即把数据发送到消息队列)，实时计算去订阅消息队列，直接完成指标增量的计算，推送到下游的数据服务中去，由数据服务层完成离线&实时结果的合并。 3)Kappa 架构：Lambda 架构虽然满足了实时的需求，但带来了更多的开发与运维工作，其架构背景是流处理引擎还不完善，流处理的结果只作为临时的、近似的值提供参考。后来随着 Flink 等流处理引擎的出现，流处理技术成熟起来，这时为了解决两套代码的问题，LickedIn 的 Jay Kreps 提出了 Kappa 架构。 4)流批一体架构：流批一体架构比较完美的实现方式是采用流计算 + 交互式分析双引擎架构，在这个架构中，流计算负责的是基础数据，而交互式分析引擎是中心，流计算引擎对数据进行实时 ETL 工作，与离线相比，降低了 ETL 过程的 latency，交互式分析引擎则自带存储，通过计算存储的协同优化， 实现高写入 TPS、高查询 QPS 和低查询 latency ，从而做到全链路的实时化和 SQL 化，这样就可以用批的方式实现实时分析和按需分析，并能快速的响应业务的变化，两者配合，实现 1 + 1 > 2 的效果;该架构对交互式分析引擎的要求非常高，也许是未来大数据库技术发展的一个重点和方向。 为了应对业务方更复杂的多维实时数据分析需求，笔者目前在数据开发中引入 Kudu这个 OLAP 存储引擎，对订单等业务数据使用 Presto + Kudu 的计算方案也是在探索流批一体架构在实时数据分析领域的可行性。此外，目前比较热的数据湖技术，如 Delta lake、Hudi 等支持在 HDFS 上进行 upsert 更新，随着其流式写入、SQL 引擎支持的成熟，未来可以用一套存储引擎解决实时、离线数据需求，从而减少多引擎运维开发成本。 三、Flink SQL 实时计算 UV 指标 上一部分从宏观层面介绍了如何建设实时数据体系，非常不接地气，可能大家需要的只是一个具体的 case 来了解一下该怎么做，那么接下来用一个接地气的案例来介绍如何实时计算 UV 数据。 大家都知道，在 ToC 的互联网公司，UV 是一个很重要的指标，对于老板、商务、运营的及时决策会产生很大的影响，笔者在电商公司，目前主要的工作就是计算 UV、销售等各类实时数据，体验就特别深刻， 因此就用一个简单demo 演示如何用 Flink SQL 消费 Kafka 中的 PV 数据，实时计算出 UV 指标后写入 Hbase。 1、Kafka 源数据解析 PV 数据来源于埋点数据经 FileBeat 上报清洗后，以 ProtoBuffer 格式写入下游 Kafka，消费时第一步要先反序列化 PB 格式的数据为 Flink 能识别的 Row 类型，因此也就需要自定义实现 DeserializationSchema 接口，具体如下代码， 这里只抽取计算用到的 PV 的 mid、事件时间 time_local，并从其解析得到 log_date 字段： public class PageViewDeserializationSchema implements DeserializationSchema { public static final Logger LOG = LoggerFactory.getLogger(PageViewDeserializationSchema.class); protected SimpleDateFormat dayFormatter; private final RowTypeInfo rowTypeInfo; public PageViewDeserializationSchema(RowTypeInfo rowTypeInfo){ dayFormatter = new SimpleDateFormat("yyyyMMdd", Locale.UK); this.rowTypeInfo = rowTypeInfo; } @Override public Row deserialize(byte[] message) throws IOException { Row row = new Row(rowTypeInfo.getArity()); MobilePage mobilePage = null; try { mobilePage = MobilePage.parseFrom(message); String mid = mobilePage.getMid(); row.setField(0, mid); Long timeLocal = mobilePage.getTimeLocal(); String logDate = dayFormatter.format(timeLocal); row.setField(1, logDate); row.setField(2, timeLocal); }catch (Exception e){ String mobilePageError = (mobilePage != null) ? mobilePage.toString() : ""; LOG.error("error parse bytes payload is {}, pageview error is {}", message.toString(), mobilePageError, e); } return null; } 2、编写 Flink Job 主程序 将 PV 数据解析为 Flink 的 Row 类型后，接下来就很简单了，编写主函数，写 SQL 就能统计 UV 指标了，代码如下： （编辑：应用网_阳江站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |