为什么需要
不同的角色有不同的关注点，因此可以引申抽象出不同的业务场景：
综合以上三种常见的角色对应的需求，会发现在分析和判断的时候，需要借助实时查询，同时由于时间范围大部分跨度比较大，因此数据规模也需要考虑。数据规模大的同时，满足实时查询是一个具有挑战性的工作。
大数据方案怎么选
不同角色需要快速获取不同的维度信息，在数据实时性方面又有一定的要求，用户（无论内部还是外部）已经无法满足针对离线数据进行分析，他们需要更新鲜的数据，甚至可能对正在发生的交易数据直接进行分析，因此需要一套专业的架构来支持。同时只能由专业的团队来完成，一般情况下需要组建专业的数据团队来支撑各个负责人的需求，并需考虑成本的问题，包括人力成本、时间成本以及引入各种技术栈的成本。也就是说， 在已有的 TP 业务场景下，需要考虑或者构建偏 AP 的数仓架构来满足实时查询的需求 。
已有解决方案
传统以 Hadoop 分析型数据库为基础的数据分析 / 数据仓库方案都存在着无法良好支持实时分析的障碍；类似 HBase 等 NoSQL 方案虽然可以支持很好的扩展性和实时性，但无法提供所需的分析能力；而传统单机数据库则无法提供数据分析所需的扩展性。传统的交易型数据库提供了完整的数据库事务特性支持，但是缺少可扩展性，同时使用的行存储，对分析型场景来说，性能不够理想。除此之外，传统大数据技术平台本身也存在一些问题，如下图：
从图中可以看到，已有的解决方案存在以下问题：
成本支出
完整数据团队的组建包括数据开发组和数据产品运营组。其中数据开发组又可以细分为：
数据产品运营组细分为：
根据以上信息，仅人力成本粗略计算下来，团队账面成本将是一笔不小的开支，核心人才难获取。除了人力成本之外，因核心人才难获取，导致团队组建时间成本在 0.5-1 年；产品设计迭代到产出需要 1-2 年左右时间；同时引入多种技术栈，维护复杂。因此人力成本高、时间成本高，维护复杂。
为什么选 TiDB
TiDB 特性
TiDB 是一款 HTAP 为特点的数据库，定位于在线事务处理/在线分析处理 HTAP（Hybrid Transactional / Analytical Processing）的融合型数据库产品，实现了一键水平伸缩，强一致性的多副本数据安全，分布式事务，实时 HTAP 等重要特性，同时高度兼容 MySQL 协议和生态，迁移便捷，运维成本极低。
周边生态
综合以上介绍，在使用 TiDB 之后， 基本上可以替换到由各种技术栈构成的大数据架构，解决传统大数据平台的诸多问题，比如 ETL 逻辑复杂、数据链路长，技术栈多样，数据分析与 TP 场景分离问题。同时通过学习培训之后，可以快速有效的掌握 TiDB 使用，运维成本低，性能满足要求，性价比极高。
TiDB 应用成效
基于 TiDB 的 HTAP 架构，目前已有多家用户在 AP 场景使用。
