美团点评 焦向 - 《SnappyData+在美团酒店实时数据分析中的应用》

展开查看详情

1.《SnappyData在美团酒店实时数据分析中的应用》 演讲 / 焦向

2.

3.

4.This talk is ‘opinionated’ • How so? o 特定业务问题出发找方案 o 基于自己总结的方法论 • Why? • 分布式存储及业务出身

5.业务 交互式报表、实时情报分析

6.• 交互式报表(Interactive Reporting) o 实时数仓 • 实时情报分析(Intelligence analysis) o 类似日志流场景,但复杂得多

7.交互式报表( Interactive Reporting ) • 供给侧、售卖侧、流量数据多维度查询 ᖌଶ ᲀࠓࢫᴚ ࣈऒ ŏŏ ᕟᕢຝ຅ ӱ‫ۓ‬හഝପ ‫׀‬ᕳ ҁ32,̵*RRGV҂ ࠓ‫ܕ‬ ҁᦈ‫׏̵ܔ‬ᲀ҂ " ग़ᖌັᧃ 'DVKERDUG ၞᰁ q 数据新鲜度 q 低延迟(<3s) q 研发效率

8.交互式报表( Interactive Reporting ) • 初期 • 基于MySQL,人肉lambda架构 • 以支持业务的思路实现 ၞᰁ MQ ‫׀‬ᕳ ग़ᖌັᧃ ҁ32,̵*RRGV҂ 0\64/ 'DVKERDUG ࠓ‫ܕ‬ Databus ҁᦈ‫׏̵ܔ‬ᲀ҂ හഝՙପ ETL Job ҁᕟᕢᖌଶᤒᒵ҂

9.交互式报表( Interactive Reporting ) • 初期 逐渐失控 • 基于MySQL,人肉lambda架构 • 以支持业务的思路实现 • 指标一致性 • 可维护性 ၞᰁ • 数据准确度 MQ ‫׀‬ᕳ • MySQL容量、性能瓶颈 ग़ᖌັᧃ ҁ32,̵*RRGV҂ 0\64/ 'DVKERDUG ࠓ‫ܕ‬ Databus ҁᦈ‫׏̵ܔ‬ᲀ҂ හഝՙପ ETL Job ҁᕟᕢᖌଶᤒᒵ҂

10.情报分析(Intelligence analysis) • 对比美团&友商数据,实时分析战况,自动跟进 ᖌଶ ᲀࠓࢫᴚ ࣈऒ ŏŏ ᕟᕢຝ຅ ಬ‫ݐ‬ᔮᕹ ᒋ੒හഝ ‫܃‬ᯈ ‫௳מ‬ᤑ‫ق‬ ܻতၾ௳ " ग़ᖌັᧃ ᗦࢫᯌମ ᗦࢫහഝ ӱ‫ۓ‬ᔮᕹ ࣁᕚଫአ ҁᤑᩂഴ‫ګ‬ᒵ҂ q 原始消息6~120亿/天 q 8大类维度, 120亿种组合 q 实时+30天历史 q 低延迟(<3s)

11.情报分析(Intelligence analysis) • 从批处理开始,Job + MySQL + Hive + Kylin • 15min滑动窗口 ӱ‫ۓ‬ ჶۖᑻ‫ ݗ‬PLQ • 定时任务 ܻতၾ௳ • 计算逻辑复杂,Java实现 Պॠ • 多维查询基于该结果 ᭦ᬋ॔๥෫ဩSQLṛපᤒᬡ PLQ PLQ PLQ PLQ ŏŏ ᕮຎ ᕮຎ ᕮຎ ᕮຎ ჶۖᑻ‫ݗ‬ SHUPLQ ܻতၾ௳ ᶼ॒ቘ-RE 0\64/ +LYH .\OLQ ग़ᖌັᧃ ᯈᗝ JavaդᎱ ‫ڠ‬ୌෛᤒ JavaդᎱ ᯈᗝ ᒵஇ ٟ‫ف‬᭦ᬋ හഝ໊ḵ ັᧃ᭦ᬋ ս۸ᛆᙡሲ

12.情报分析(Intelligence analysis) •问题从批处理开始,Job + MySQL + Hive + Kylin • 15min滑动窗口 • 研发效率低 • 定时任务 ӱ‫ۓ‬ ჶۖᑻ‫ ݗ‬PLQ ܻতၾ௳ •• 计算逻辑复杂,Java实现 链条长,调试周期长,大量等待 Պॠ • 多维查询基于该结果 • 需求变化频繁 ᭦ᬋ॔๥෫ဩSQLṛපᤒᬡ PLQ PLQ PLQ PLQ ŏŏ ᕮຎ ᕮຎ ᕮຎ ᕮຎ • 流程相似,体力活 • 浪费资源,每个需求一套流程 ჶۖᑻ‫ݗ‬ SHUPLQ • 无法支持实时多维分析 ܻতၾ௳ ᶼ॒ቘ-RE 0\64/ +LYH .\OLQ ग़ᖌັᧃ ᯈᗝ JavaդᎱ ‫ڠ‬ୌෛᤒ JavaդᎱ ᯈᗝ ᒵஇ ٟ‫ف‬᭦ᬋ හഝ໊ḵ ັᧃ᭦ᬋ ս۸ᛆᙡሲ 30PD

13.情报分析(Intelligence analysis) • 而且,这样的流程还有N个…… …… $ ᶼ॒ቘ-RE 0\64/ +LYH .\OLQ ग़ᖌັᧃ % ᶼ॒ቘ-RE 0\64/ +LYH .\OLQ ग़ᖌັᧃ & ᶼ॒ቘ-RE 0\64/ +LYH .\OLQ ग़ᖌັᧃ ܻতၾ௳ ' ᶼ॒ቘ-RE 0\64/ +LYH .\OLQ ग़ᖌັᧃ ( ᶼ॒ቘ-RE 0\64/ +LYH .\OLQ ग़ᖌັᧃ ) ᶼ॒ቘ-RE 0\64/ +LYH .\OLQ ग़ᖌັᧃ

14. 问题回顾 • 交互式报表( Interactive Reporting ) • 情报分析(Intelligence analysis) ᖌଶ ᖌଶ ᲀࠓࢫᴚ ᲀࠓࢫᴚ ࣈऒ ŏŏ ࣈऒ ŏŏ ᕟᕢຝ຅ ᕟᕢຝ຅ ӱ‫ۓ‬හഝପ ‫׀‬ᕳ ҁ32,̵*RRGV҂ ࠓ‫ܕ‬ ҁᦈ‫׏̵ܔ‬ᲀ҂ " ग़ᖌັᧃ 'DVKERDUG ܻতၾ௳ " ग़ᖌັᧃ ၞᰁ q 可变数据,保证数据新鲜度 q 复杂业务逻辑

15.选型之路 调研、问题剖析、总结方法论

16.大数据生态 • Google大数据的脉络完整清晰,业界鱼龙混杂错综复杂 Spanner:《Spanner: Google’s Globally-Distributed Database》 F1:《F1: A Distributed SQL Database That Scales》 Dremel :《Dremel: Interactive Analysis of Web-Scale Datasets》 PowerDrill :《Processing a Trillion Cells per Mouse Click》 Mesa:《Mesa: Geo-Replicated, Near Real-Time, Scalable Data Warehousing》 Shasta:《Shasta: Interactive Reporting at Scale》 FlumeJava:《FlumeJava: Easy, Efficient Data-Parallel Pipelines》 MillWheel:《MillWheel: Fault-Tolerant Stream Processing at Internet Scale》 DataFlow:《The Dataflow Model》

17.解构 • 全都是trade-off • OLAP vs OLTP • 流式处理 vs 批处理(Streaming vs Batch) • 预处理 vs 后处理(Pre-processing vs Post-processing) • 快照 vs 变更记录(Snapshot vs Changelog) • 平台 vs 业务 • 第一步是解构问题

18.数据处理简化模型 ᬌ‫ف‬හഝ ᶼᦇᓒ ਂ‫ؙ‬ ‫ᦇݸ‬ᓒ ᬌ‫ڊ‬හഝ

19.引擎特性解构 • 存储和计算分离考虑 ᬌ‫ف‬හഝ ᶼᦇᓒ ਂ‫ؙ‬ ‫ᦇݸ‬ᓒ ᬌ‫ڊ‬හഝ ⁃PHGLDғᶎ‫̵ਂٖݻ‬ᶎ‫ݻ‬ᏺፏ ⁃ඪ೮-RLQ ັᧃള‫ݗ‬ ⁃&XEHҁ୚ක҂ ⁃OD\RXWғ‫̵ਂڜ‬ᤈਂ ⁃ӧඪ೮-RLQ ⁃ᶋ64/ ⁃ᶼᘸ‫ݳ‬ҁ୚ක҂ ⁃VFKHPDғᕮ຅۸̵ᶋᕮ຅۸ ⁃ᔄ64/ ⁃හഝ಑ଘҁӱ‫ۓ‬҂ ⁃PXWDEOHғඪ೮ๅෛ̵ӧඪ೮ๅෛ ⁃ӧਠෆ64/ ⁃ၞୗ॒ቘ ⁃ਠෆ64/ ⁃ਠෆ64/8') 举例:Druid、Kylin、Hbase、Spark、Linkedin Pinot

20.The trade-offs

21.OLAP vs OLTP • OLAP:扫表性能,列存储 • OLTP:随机读写,行存储,索引 • 交互式报表是典型的HTAP(OLAP+OLTP)场景

22.Pre-processing vs Post-processing හഝ ᦇᓒ ਂ‫ؙ‬ ᦇᓒ ັᧃ ᶼᦇᓒ ਂ‫ؙ‬ ᦇᓒ ᦇᓒ ਂ‫ؙ‬ ‫ᦇݸ‬ᓒ 预处理优先 后处理优先 o 面向查询需求生成结果 o 在线计算需求数据 o 灵活性低:需求变更需要重新生成数据 o 灵活性高 o 查询性能高 o 查询性能难以保证 o 耗存储资源、人力 o 耗计算资源

23.Pre-processing vs Post-processing හഝ ᦇᓒ ਂ‫ؙ‬ ᦇᓒ ັᧃ ᶼᦇᓒ ਂ‫ؙ‬ ᦇᓒ ᦇᓒ ਂ‫ؙ‬ ‫ᦇݸ‬ᓒ 预处理优先 后处理优先 需求不稳定(ad hoc查询),选后处理优先方案 人 vs 机器

24.Streaming vs Batch • The Dataflow Model by Google • 理论层面大一统 • Flink, Spark Streaming • 主要是预处理

25.Snapshot vs Changelog • 历史数据如何保存? • 数据量 • 信息损耗(数据更新) • 易用性

26.平台 vs 业务 • 平台关注通用,业务多特化需求 • 通用方案 vs 专有方案 • 资源利用率未必高 • 研发效率与deadline

27.业务场景解构 ꧋ᦜഖ०ᔜଶ ‫ٵ‬Ꮯ ‫ٵ‬Ꮯଶ 牺牲少量精度,可实现巨大性能提升 *% *% 7% 3% හഝᰁ 单机 or 分布式,全内存 or 磁盘 ֗ ṛ ‫ݺރ‬ 低吞吐、低延迟比较容易 PV V V PLQ KRXU 高吞吐、低延迟比较困难 ୊᬴ • 分析场景下,高吞吐意味着预处理和Cache V V PLQ PLQ KRXU GD\ ෛẌଶ 流式 or 批处理 or 在线计算 ੝ ग़ ᵱ࿢ᰁ 预处理 or 后处理

28.我们的场景 业务类型 分析型 列存储 准确度 100% 无法使用近似计算 数据量 1TB~3TB,热数据500GB 分布式,全内存 吞吐要求 低,<1qps 低吞吐 延迟要求 高,3s 低延迟 新鲜度 高,多维度,数据可更新 后处理,需要高效分布式Join 需求特点 量大、变更频繁 后处理

29.SnappyData