美团点评 焦向 - 《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