依托数据库生态，AnalyticDB for MySQL可以给用户提供分析场景下的标准解决方案，尤其是在大数据和性能要求较高的情况下AnalyticDB for MySQL的价值可以更好的体现。
MySQL用户为什么要单独构建数据仓库
为什么要单独构建数据仓库，而不是直接在MySQL数据库上运行分析查询？这个问题我上面文章提到过，为了回答这个问题，我们先来看下数据仓库与OLTP数据库之间的差别。数据仓库主要是针对批量写入和大量数据的读取操作，而OLTP数据库是针对持续写入操作以及大量的小规模读取操作。通常，数据仓库会因较高的数据吞吐量要求而使用非规范化模型，如星型模型和雪花模型。星型架构包含多个引用大量维度表的大型事实数据表。雪花型架构是星型架构的扩展，包含更加规范化的维度表。而OLTP数据库则使用高度规范化的模型，更适合高事务吞吐量的要求，对于复杂查询的性能很难满足用户要求。
规范化操作是一定要把分析查询拆分到数据仓库中，达到“臃肿”状态时再构建数据仓库是会付出迁移成本。直接在MySQL数据库上运行分析查询的缺点总结为：
- 很容易影响在线业务，只读实例扩展难，无法做到实时分析；
- 每月新增数据比较大情况下，需要定期手动做分库操作，从多个库检索数据进行分析，查询性能无法满足需求；
- 把数据统一抽取到大数据平台，技术门槛高，改造难度大耗时长。
什么是AnalyticDB for MySQL
几年前阿里云就意识到实时数据仓库的必要性，2015年AnalyticDB for MySQL肩负着阿里云实时数据仓库的使命上线公共云。AnalyticDB for MySQL是阿里云上唯一经过核心业务和超大数据量验证的实时数据仓库，其稳定性、规模性和性能是不容置疑的。AnalyticDB for MySQL是全球最快的数据仓库。全球最知名的数据管理系统评测标准化TPC组织公布了数据库领域分析性能基准测试最新排名：阿里云自研超大规模分析型数据库AnalyticDB正式荣登榜首，成为全球第一家通过TPC第三方严格审计认证的云上数仓产品。
AnalyticDB采用行列混存MPP技术，突破OLTP和传统数据仓库技术壁垒，最大优势是可以构建PB数据量下高性能和经济实用的数据仓库。全面兼容MySQL协议以及SQL:2003 语法标准，用户只需对现有业务进行少量更改，甚至不需要进行任何更改，即可把业务全部迁移到AnalyticDB for MySQL上来。因此，它已成为当今企业构建数据仓库和OLAP系统的理想选择。
解决方案架构图
架构简单，组件少，效率高。只需通过DTS把MySQL业务库数据实时同步到AnalyticDB for MySQL中，数据在AnalyticDB for MySQL实时数据仓库中进行加工处理和计算。
解决方案优势
- 实时性
AnalyticDB for MySQL同时具有计算的实时性（计算在用户查询时发生，查询速度快，毫秒级返回）和数据的实时性（数据产生插入数仓后马上就可以查询到）； - 低成本和易扩展
单节点最低1.30/小时，作为云上企业级数据仓库还易扩展的特性，高峰期实现秒级扩容。 - 简单易用
全量+增量自动同步，数据入库简单、安全可靠； - 高度兼容
完全兼容MySQL，用户无须修改SQL，迁移成本极低； - 生态丰富
兼容常用BI、ETL和客户端工具，完备适配用户场景。
AnalyticDB for MySQL 典型应用场景
AnalyticDB for MySQL客户案例
递四方构建物流行业实时数仓
无他相机移动APP运营平台
写在最后
相比于大数据方案构建数仓，AnalyticDB for MySQL除了在实时性上有绝对优势外，使用简单也是不可或缺的优势。无需要储备大数据人才，数据库团队即可轻松玩转实时数据仓库，帮助公司节约至少百万成本。 AnalyticDB for MySQL 1元购活动正在火热进行中，限时续费包月八折，包年七折。你还等什么，赶紧来试用吧！
原文链接
本文为云栖社区原创内容，未经允许不得转载。
