| title | author | date | summary | tags | category | url | weight | logo | customer | customerCategory | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
TiDB 助力一面数据实现消费领域的决策分析平台 |
|
2017-09-15 |
TiDB 水平扩展性、兼容 MySQL 是非常好的特性，对需要使用关系型数据库作为存储方案的业务有极大的诱惑力，避免了传统分表、分库方案带来的上层应用的复杂性，解决了我们目前迫切的关系型数据存储的需求。 |
|
case |
/case/user-case-yimian/ |
25 |
/images/blog-cn/customers/yimian-logo.png |
一面数据 |
高科技 |
作者：刘畅，一面数据高级 AI 工程师。
深圳市一面网络技术有限公司（下称：一面数据）是一家为消费领域的领导企业提供实时、精准、全面的数据洞察和决策指导的创新型企业，利用人工智能和算法，进行自然语言处理，语义情感分析，回归预测模型等，帮助客户实现精准产品运营和预测市场变化。一面数据服务于国内外一流企业，包括世界最大的对冲基金、国际一线汽车品牌、快消品龙头厂商，以及时尚鞋服大牌等。
一面数据的核心 IT 系统覆盖了从数据获取、数据清洗处理、数据建模到数据可视化的全套数据分析流程。核心系统每天有海量从互联网采集的公开数据和来自企业内部的数据，对数据存储的容量、扩展性和可用性都有很高的要求。
起初，一面数据的核心系统采用的是多个 MySQL 实例和一个 Cassandra 集群。MySQL 多实例集群主要存储指定特征的爬虫数据，Cassandra 主要存储数据量大、不适合存储 MySQL 的全页面缓存的数据。在数据量/请求量小的时候系统运行正常。下图为一面数据改造前系统构架图：
随着数据量的增长，逐渐暴露出很多问题：
-
MySQL：随着数据增长，存储容量接近单机的磁盘极限，单机的磁盘 IO 繁忙且易阻塞，查询性能难以满足业务增长的需求。数据量大了以后，传统的 MySQL 水平扩展能力弱，性能和稳定性容易产生问题，在数据量和访问量增长到一定阶段将无法满足常见的 OLAP 场景分析需求。技术团队通过诊断系统性能问题，认识到现有数据库已经成为瓶颈。
-
Cassandra：Cassandra 对磁盘 IO 和内存要求高，添加一个实例，需要从其他实例迁数据，对网络带宽、 磁盘要求特别高。另外 CQL 支持的特性太少，业务开发麻烦，例如不能联表，不支持主键之外的索引，对主键以外的查询比较困难，虽然有 Secondary Index，但是使用限制大。生态圈不完善，例如很难找到好用的监控。
为从根本上解决以上问题，一面数据的技术团队决定通过增加部署一套高性能的数据库系统，以解决当前业务的痛点。 在评估和验证了 MySQL Sharding 和 MongoDB 等传统技术手段之后，团队认识到：基于 MySQL Sharding (即利用 MySQL 中间件分库分表) 架构在高可用安全能力，业务和查询的灵活支持以及运维管理难度和成本上都不尽如人意，有着诸多架构上和技术上的缺陷；而 MongoDB 比较适合存储爬虫数据，但迁移成本高，不管是数据还是应用程序都需要做侵入性修改和调整，难度和开发成本骤升。另外，作为 NoSQL 数据库，MongoDB 不支持 SQL 和 JOIN ，对 BI 工具的支持也不完善，数据分析师们无法直接使用。 最终从满足业务需求、降低切换成本和减少运维成本等角度考虑，一面数据选择了分布式关系型数据库－TiDB 作为业务的首选事务型数据库。
TiDB 支持包括跨行事务，JOIN 及子查询在内的绝大多数 MySQL 的语法，用户可以直接使用现有的 MySQL 客户端连接。如果现有的业务已经基于 MySQL 开发，大多数情况不需要修改代码即可直接替换单机的 MySQL。同时现有的大多数 MySQL 运维工具（如 PHPMyAdmin, Navicat, MySQL Workbench 等），以及备份恢复工具（如 mysqldump, mydumper / myloader）等都可以在 TiDB 直接使用，这也让开发运维人员不用关注数据库 scale 的细节问题，专注于业务开发，极大的提升研发的生产力。下图为一面数据改造后系统构架图：
一面数据的生产环境部署了数十个 TiKV 节点及几个 TiDB 节点。迁移原有 MySQL 集群数据时使用 Percona 的 mydumper 以及 TiDB 专有优化的 loader 工具，逐个爬虫进行迁移。目前 TiDB 集群存储了接近数十 TB 的数据，把另外几个应用迁移完成后将会每日新增近亿条记录。
完成迁移以后，系统不再需要维护多个 MySQL 实例以及 Cassandra 集群，运维成本大幅缩减，监控使用 Prometheus/Grafana，并且可以通过 Prometheus 的 AlertManager 定制规则复杂的报警规则。这些改变都让一面数据的爬虫存储侧的工作便利许多，可以让一面数据的研发把精力更多放在业务研发而不是运维多个不同技术栈的复杂集群。
目前 TiDB 新增了 TiSpark 组件，并且在 TiKV 层实现了 Spark 的下推算子，使得可以直接在 TiDB 集群上跑 Spark 程序，这样可以省去 ETL 的步骤。后续一面数据也考虑深入使用 TiSpark 组件，让一面数据的整个系统增加一定的实时复杂查询的能力。长远来看，可以把现在 ElasticSearch，Impala，Hive 的业务都迁移到 Spark 集群上，这样一方面统一了分析侧的技术栈，另一方面连接了 Spark 丰富庞大的生态。下图为一面数据未来系统构架图：
在一面数据 CTO 张锦杰看来：“TiDB 水平扩展性、兼容 MySQL 是非常好的特性，对需要使用关系型数据库作为存储方案的业务有极大的诱惑力，避免了传统分表、分库方案带来的上层应用的复杂性，解决了我们目前迫切的关系型数据存储的需求。”