共计 1408 个字符,预计需要花费 4 分钟才能阅读完成。
互联网诞生之初尽管数据量暴增,单日事实表条数达千万级别,
但客户需要场景更多是“t+1”模式,只需对当日、当周、当月数据进行剖析,这些诉求仅离线剖析就可满足。
随着大数据畛域一直倒退,企业对于业务场景的诉求也从离线的满足转到高实时性的要求,数栈产品也在这一过程中进行着一直的迭代降级,随之诞生了 kafka+flink 组合,同时 kafka + etl-engine(交融计算的加持)组合也实现了轻量级的流式计算引擎。
流计算与批计算比照
- 数据时效性
流式计算实时、低提早,流式计算适宜以“t+0”的模式出现业务数据;
批计算非实时、高提早,批计算适宜以“t+1”的模式出现业务数据; - 数据特色
流式计算数据个别是动态数据,数据是随时产生的;
批计算数据个别是静态数据,数据当时曾经存储在各种介质中。 - 利用场景
流式计算利用在实时场景,如:业务监控、实时举荐等。
批计算利用在离线计算场景,如:数据分析、离线报表等。 -
运行形式
流式计算的工作是阻塞式的,始终继续运行中。
批计算的工作是一次性实现即完结。etl-engine 实现流式计算
etl-engine 反对通过本身提供的”kafka 生产节点“进行音讯生产,并在生产数据流(音讯流)的同时调用本身提供的“交融查问 API”,实现将多种数据源的维表数据读取到内存中,而后将音讯流与多个维表数据进行各种关联查问,最初输入交融查问后果集到指标源,罕用在将多个维表数据与实时音讯流关联后转换成一个大宽表的场景。
交融查问语法
交融查问语法遵循 ANSI SQL 规范,与惯例 MySQL 查问语法很类似。
- 反对对多种类别数据库之间读取的数据进行交融查问。
- 反对音讯流数据传输过程中动静产生的数据与多种类型数据库之间的流计算查问。
- 交融查问语法遵循 ANSI SQL 规范。
select 反对
SELECT
[DISTINCT] field [, field ...]
FROM table [, table ...]
[WHERE condition]
[GROUP BY field [, field ...] ]
[HAVING condition]
[ORDER BY order_item [, order_item ...] ]
[LIMIT number_of_records [OFFSET number_of_records] ]
table 反对
INNER JOIN
LEFT JOIN
RIGHT JOIN
OUTER JOIN
CROSS JOIN
后续会具体介绍交融查问反对的内容。
参考资料
[收费下载](https://github.com/hw2499/etl-engine/releases)
[etl-engine 使用手册](https://github.com/hw2499/etl-engine)
[etl-crontab 使用手册](https://github.com/hw2499/etl-engine/wiki/etl-crontab%E8%B0%83%E5%BA%A6)
[嵌入脚本开发](https://github.com/hw2499/etl-engine/wiki/%E5%B5%8C%E5%85%A5%E8%84%9A%E6%9C%AC%E5%BC%80%E5%8F%91)
[etl-engine 配置样例](https://github.com/hw2499/etl-engine/wiki/etl-engine%E4%BD%BF%E7%94%A8%E6%A0%B7%E4%BE%8B)
正文完