IOTA架构、数据湖、Metric Platform，终于有人讲清楚了！
点击上方蓝色字关注置顶我们！
热文推荐：Hive 分析函数进阶指南
☞ 关注公众号『数据仓库与Python大数据』，获取更多优质资源与干货文章。
作者： 憋七
编辑： 紫霞仙子
正文
前言
Metric Platform是由数据湖和IOT潮流引申出来的，数据湖和IOT概念可能是下一个数据时代的重大变革。
#IOTA架构
先回顾一下lambda架构，lambda架构分为两条线，一条实时流数据，另一条是离线批处理数据,最终合并输出。
Lambda优点是稳定、实时和离线计算高峰错开，数据较准确，但是它有一些致命缺点，其缺点主要有：
1.维护成本高，要维护两套逻辑，离线和实时两套都要改动，同样新指标要开发两套，开发成本较高
2.服务器存储大，数据仓库的典型设计，会产生大量的中间结果表，造成数据急速膨胀，加大服务器存储压力。
3.数据计算时长，随着业务扩展越来越多，计算任务越来越多，离线数据的计算时长也会随之越来越长。
IOTA架构是在物联网浪潮下所产生的，下面是一张网图。
SDKs和Servers：数据生产端，这步主要是规范埋点数据，以”主-谓-宾“或”对象-事件“的数据模型进行规范化修正，如果埋点数据很规范，那之后就很轻松了。
Common Data Model：最核心模块，数据模型是”主-谓-宾“或者”对象-事件“，以提供最抽象的数据模型进行查询，并在此阶段进行指标统一。
Real-Time Data：为保证实时数据吞吐，轻量Buffer机制对下游进行数据缓冲。整体最核心部分为实时增量计算。
Dumper：将缓存区的数据以最终格式进行汇总整理，并创建数据索引。
Historical Data Storage：通过实时数据ETL之后沉淀下来的历史数据。但为保证之后TB或者PB级数据秒级响应，需要提前选好存储方式，HDFS是个不错的选择。
**数据落地后始终保持和最初SDKs同样的数据模型**
Query Engine：进行Real-Time Data和Historical Data Storage的合并查询，可以使用除hue外的计算引擎Presto、Impala、Clickhouse。
Realtime Model Feedback：SDKs和Servers输出的数据，可以经过实时计算后再进行实时反馈，通过Edge computing进行和用户的更多交互。
#数据湖
数据仓库和数据湖的区别：
数据仓库是优化后的数据库，主要用于分析业务系统的关系数据，事先定义好数据结构和schema来满足SQL快速查询，数据在数据仓库中经过了充分的清洗、丰富和转换，对用户很友好。
数据湖在维基百科中的定义是一个以原始格式存储数据的系统或存储库，数据湖通常是企业数据的单一存储。存储不仅限于关系数据，还有Edge SDK的非关系数据，不提前定义schema和数据结构，而更明显的优势在于数据湖不仅可以供BI和报表分析，还适用于机器学习。
还是那句话，没有最好的架构，只有最适用于当前业务发展的架构才是最好的。
公司前中期数据的主要用途是BI、可视化报表，需要结构化的数据，因此放在数据仓库中是最合适的。到了中后期，机器学习兴起，需要对数据更加灵活的处理，如果还从数仓中提取会有一些问题和困难。
| 特性 | 数据仓库 | 数据湖 |
|---|---|---|
| 数据 | 关系数据 | 非关系数据 |
| Schema | 提前设计好(写入型schema) | 在分析时写入(读取型schema) |
| 性价比 | 查询快但存储成本较高 | 查询快存储成本低 |
| 对象用户 | 业务分析师和数据组 | 算法工程师、数据开发和业务分析师 |
| 应用 | BI、报表可视化 | 机器学习、预测分析、数据挖掘 |
#数据模型
详细说下IOTA架构的数据模型，遵循”主-谓-宾“或者”对象-事件“这两种抽象的方式提供查询。
用户事件模型
0.1事件
事件主要出发用户的一些行为，例如注册，约课，付费等
每条event是每次用户行为
| Event要素 | 要素说明 | 数据 |
|---|---|---|
| Who | 事件的用户 | 用户id |
| When | 事件发生的时间 | 事件发生时间 |
| Where | url | 事件触发的url |
| How | 事件产生方式 | 设备类型，版本 |
| What | 事件内容 | key-value，事件动作 |
0.2用户
唯一标识，用主体作为分析维度时，此处的主体可以是用户id，家庭id，员工id，课标，课件等等，根据业务实际需求使用。
#Metric Platform
Metric Platform背后引用IOTA和数据湖概念，将公司业务指标统一化、可视化，更方便的管理现有指标，打破tracking data和database data独立性，实现轻维护，形成数据闭环。
设计数据模型
将每个业务指标抽象成0和1的方式，举例支付事件中，每个用户的支付记录，从中计算出每笔订单是否为首次订单。
key_type：事件主体说明，value的名称订单id
key_value：事件主体，实际的订单id
timestemp：事件发生时间，时间戳，订单创建时间
metric_name：指标，是否首次订单
metric_value：指标值，是为1，否为0
这样的设计保证了单一存储和高灵活度，实现了按需开发，在数据字典中更容易维护信息，这是上层使用最大的一种改变，对于底层会有更深的实现方式。
思考
同时也有需要我们思考的：
1.若表中2000个字段，如何能保证快速的ad-hoc查询呢？
2.如何增加现阶段TPC-DS的效率呢？
3.如何考虑数据安全问题？
4.数据质量如何保障？
接下来对优化和完善上会越来越完善，比如在IOTA架构中选择更加适用索引，例如Bitmap索引；增加布隆过滤器；等等
但也需要很完善的管理方式，还有调度机制，更多功能还需再探索和优化。
希望这篇文章能给你对Metric Platform理解带来帮助。
如果您喜欢本文，欢迎点击右上角，把文章分享到朋友圈~~
还想看点啥？
2. Flink 完美搭档：开源分布式流存储 Pravega
4. 实践 | 物化视图在 SparkSQL 中的实践
5. 万字大数据实时同步方案(附代码及架构图)(建议收藏！)
截图仅为文章部分示例
戳文末“阅读原文”,到公众号菜单栏 即可直达上面干货优质文章
学习小密圈 限50人
Q: 关于数据仓库，你还想了解什么？
更多精彩，请戳"阅读原文"到"大厂案例"查看
！关注不迷路~ 各种福利、资源定期分享！