用户您好!请先登录!

分类目录数据库

WiredTiger存储引擎原理

Mongodb-3.2已经WiredTiger设置为了默认的存储引擎,最近通过阅读wiredtiger源代码(在不了解其内部实现的情况下,读代码难度相当大,代码量太大,强烈建议官方多出些介绍文章),理清了wiredtiger的大致原理,并简单总结,不保证内容都是正确的,如有问题请指出,欢迎讨论交流。

按照Mongodb默认的配置,WiredTiger的写操作会先写入Cache,并持久化到WAL(Write ahead log),每60s或log文件达到2GB时会做一次Checkpoint,将当前的数据持久化,产生一个新的快照。Wiredtiger连接初始化时,首先将数据恢复至最新的快照状态,然后根据WAL恢复数据,以保证存储可靠性。
0102-zyd-MongoDB WiredTiger存储引擎实现原理-1

阅读更多

阿里基于HBase的大数据引擎Lindorm

注:Lindorm是阿里内部HBase分支的别称,在阿里云上对外售卖的版本叫做HBase增强版,之后文中出现的HBase增强版和Lindorm都指同一个产品。

2019年以来,Lindorm已经服务了包括淘宝、天猫、蚂蚁、菜鸟、妈妈、优酷、高德、大文娱等数十个BU,在今年的双十一中,Lindorm峰值请求达到了7.5亿次每秒,天吞吐22.9万亿次,平均响应时间低于3ms,整体存储的数据量达到了数百PB。这些数字的背后,凝聚了HBase&Lindorm团队多年以来的汗水和心血。

Lindorm脱胎于HBase,是团队多年以来承载数百PB数据,亿级请求量,上千个业务后,在面对规模成本压力,以及HBase自身缺陷下,全面重构和引擎升级的全新产品。相比HBase,Lindorm无论是性能,功能还是可用性上,都有了巨大飞跃。本文将从功能、可用性、性能成本、服务生态等维度介绍Lindorm的核心能力与业务表现,最后分享部分我们正在进行中的一些项目。

阅读更多

GridDB: The Fastest Open Source Time Serials Database for IoT and Big Data

Practical Introduction to Time Series Databases and Time Series Data

1. What is Time Series data?

Time series data is a series of values ​​where the time information (timestamp) corresponds to data recorded or an event that happened at that point in time. The data can have both regular and fluctuating intervals. For example, temperature recordings would be recorded at a set time, every minute or hour, while a stock price would be recorded every time a trade is completed.

Time Series data is usually a log or “append-only”, records are rarely updated except upon deletion when they expire. You wouldn’t update values in your web server logs and the same holds true for most Time Series data collections.

阅读更多

京东JDTX:强一致性、高性能的分布式事务中间件

导读:在分布式数据库、云原生数据库、NewSQL 等名词在数据库领域层出不穷的当今,变革——在这个相对稳定的领域已愈加不可避免。相比于完全革新,渐进式增强的方案在拥有厚重沉淀的行业则更受青睐。

同所有分布式领域的解决方案相同,分而治之的透明化数据分片方案,是新一代数据库解决海量数据的核心理念。水平拆分使得分布式事务的重要性,较之垂直拆分的业务系统进一步提升。另外,弹性扩(缩)容、HTAP 等概念也是新一代数据库的关注重点。京东数科开源的 Apache ShardingSphere 在数据分片方面已逐渐成熟,在此场景之上开发的分布式事务中间件 JDTX 与之共同组成了分布式数据库的内核拼图。

JDTX 是由京东数科的数据研发团队倾力打造的分布式事务中间件。本次分享是 JDTX 首次公开出现在大众视野面前,分享内容涵盖 JDTX 的核心设计理念及相关的技术实现难点,希望能为打造分布式事务解决方案的团队提供一些思路。

阅读更多

分布式事务原理及实现方式

一个复杂的系统往往都是从一个小而简的系统发展衍化而来,为了满足日益增长的业务需求,不断的增加系统的复杂度,从单体架构逐步发展为分布式架构,而分布式系统架构的设计主要关注:高性能,高可用,高拓展,俗称的“三高”。

分布式事务(分布式系统中数据一致性问题)

高可用是指系统无中断的执行功能的能了,代表了系统的可用程度,是进行系统设计时必须要遵守的准则之一。

而高可用的实现方案,无外乎就是冗余,就存储的高可用而言,问题不在于如何进行数据备份,而在于如何规避数据不一致对业务造成的影响。

对于分布式系统而言,要保证分布式系统中的数据一致性就需要一种方案,可以保证数据在子系统中始终保持一致,避免业务出现问题,这种实现方案就叫做分布式事务,要么一起成功,要么一起失败,必须是一个整体性的事务。

阅读更多

KeyDB: Low TCO Redis™ Compatible Key Value Store

What is KeyDB?

KeyDB is an in-memory, high performance database with support for numerous data types, on-disk persistence and high availability. Compatible with Redis™ API and protocols, KeyDB is a drop-in replacement for your existing Redis™ deployments with numerous enhancements, higher performance, and lower Total Cost of Ownership (TCO).

Designed for use as both a cache as well as use as a primary database, KeyDB is a fast and versatile NOSQL database useful in many applications. Its low resource requirements and high-speed mean fewer instances to manage and much lower costs. KeyDB looks to fully utilize the hardware provided to your instances enabling a higher throughput and efficiency.

阅读更多

Youtube开源的高性能水平扩展MySQL平台

一、什么是Vitess?

vitness.jpg

Vitess是用于部署,扩展和管理MySQL实例的大型群集的数据库解决方案。它在架构上可以像在专用硬件上一样有效地在公共或私有云架构中运行。它结合了NoSQL数据库的可伸缩性,并扩展了许多重要的MySQL功能。Vitess可以帮助我们解决以下问题:

  1. 通过允许您对MySQL数据库进行分片来扩展规模,同时将应用程序更改降至最低。
  2. 从裸机迁移到私有云或公共云。
  3. 部署和管理大量MySQL实例。

Vitess包括使用本机查询协议的兼容JDBC和Go数据库驱动程序。另外,它实现了MySQL服务器协议,该协议实际上与任何其他语言兼容。

阅读更多

MySQL与PostgreSQL的选择

如果打算为项目选择一款免费、开源的数据库,那么你可能会在MySQL与PostgreSQL之间犹豫不定。

MySQL与PostgreSQL都是免费、开源、强大、且功能丰富的数据库。你主要的问题可能是:哪一个才是最好的开源数据库?MySQL还是PostgreSQL呢?该选择哪个开源数据库呢?

在选择数据库时,你所做的是个长期的决策,因为后面如果再改变决定将是非常困难且代价高昂的,你希望一开始就选择正确。

两个流行的开源数据库MySQL与PostgreSQL常常成为最后要选择的产品,本文对这两个数据库的高层次概览将会有助于你选择最适合自己需要的。

阅读更多

GraphQL 的工具库

GraphQL 是 Facebook 内部从 2012 年开始开发的项目,于 2015 年公开发布。2018 年 11 月 7 日,GraphQL 的控制权被移交给由 Linux 基金会托管的 GraphQL 基金会。随后 GraphQL 日益普及,一个富有活力的生态系统也随之迅速成长。

GraphQL 本质上是“API 的查询语言,以及使用你为数据定义的类型系统执行查询的服务端运行时”。它不依赖任何数据库或存储,而是由你的代码和数据来支持。GraphQL 查询是发送到运行时的字符串,它向客户端返回 JSON。

这种简单有效的设计催生了一个充满活力生态系统,社区有大批关于它的内容、演讲和指南,当然还有一系列开源工具、客户端、编辑器和库,增强并完善实践中的 GraphQL 工作流程。

这里收集了一些最出色的 GraphQL 工具和库,内容涵盖客户端库、IDE 及好用的集成。

1. Apollo 服务器和客户端

APOLLO 平台是 GraphQL 的一个实现,帮助用户管理从云到 UI 的各类数据。它可以渐进引入,可以在包括 REST API 和数据库在内的现有服务上另起一层运行。

阅读更多

微服务分布式事务中的Saga模式

该文是基于《微服务模式》作者Chris Richardson的QCONSF 2017会议上的PPT文章(这里)和其 Eventuate Tram Saga框架之上,对Saga模式进行的原理性解说,其中包含banq个人经验总结和见解,请从批判性视角看待。Chris Richardson的另外一本书籍《POJO in Action》曾经是帮助Spring成功挑战了EJB2。

在微服务环境下为什么不能使用ACID事务?因为每个微服务都拥有自己的私有数据库,比如订单服务有自己的订单数据库,而客户服务有自己的客户数据库,如果有一个业务操作需要跨订单和客户一起操作,那么一般使用JTA+XA方式跨订单数据库和客户数据库操作:

@ Transactional //事务元注解
public void crossAction(XX){
    //事务开始

    //这里ORDERS是属于订单服务的私有数据库
    SELECT ORDER_TOTAL FROM ORDERS WHERE CUSTOMER_ID = ?

    //这里CUSTOMERS是属于客户服务的私有数据库
    SELECT CREDIT_LIMIT FROM CUSTOMERS WHERE CUSTOMER_ID=?

    INERT INTO ORDERS .....

    //提交事务

}
<p>

以上JTA操作如果结合XA数据源配置,将会实现2PC两段事务提交。

阅读更多

Mycat: MySql的最佳伴侣

Mycat 是什么?从定义和分类来看,它是一个开源的分布式数据库系统,是一个实现了 MySQL 协议的的 Server,前端用户可以把它看作是一个数据库代理,用 MySQL 客户端工具和命令行访问,而其后端可以用 MySQL 原生(Native)协议与多个 MySQL 服务器通信,也可以用 JDBC 协议与大多数主流数据库服务器通信, 其核心功能是分表分库,即将一个大表水平分割为 N 个小表,存储在后端 MySQL 服务器里或者其他数据库里。

Mycat 发展到目前的版本,已经不是一个单纯的 MySQL 代理了,它的后端可以支持 MySQL、SQL Server、 Oracle、DB2、PostgreSQL 等主流数据库,也支持 MongoDB 这种新型 NoSQL 方式的存储,未来还会支持更 多类型的存储。

阅读更多

蚂蚁金服OceanBase的高可用及容灾方案

众所周知,作为生产系统中极为关键的核心软件,数据库产品的高可用性一直是使用者极为关注的功能点。尤其是在金融这样一个特殊的领域里,无论是从监管的要求来看,还是从业务需求本身来看,都需要提供24*7持续不间断的服务,这就对金融行业中数据库产品的高可用性提出了很高的要求,不但需要应对个别硬件故障的情况,还必须能够应对机房整体故障和城市灾难等极端情况,保证数据库在各种意外情况下都能持续提供服务,即具备机房级容灾能力和城市级容灾能力。

本文的主要目的,是总结和回顾一下传统数据库产品常用的高可用及容灾方案,并向读者介绍一下以OceanBase为代表的分布式数据库常用的方案,希望能够起到抛砖引玉的作用,引发读者关于新型分布式架构下高可用及容灾方案的思考。

阅读更多

ETCD 简介及使用场景

随着CoreOS和Kubernetes等项目在开源社区日益火热,它们项目中都用到的etcd组件作为一个高可用强一致性的服务发现存储仓库,渐渐为开发人员所关注。在云计算时代,如何让服务快速透明地接入到计算集群中,如何让共享配置信息快速被集群中的所有机器发现,更为重要的是,如何构建这样一套高可用、安全、易于部署以及响应快速的服务集群,已经成为了迫切需要解决的问题。etcd为解决这类问题带来了福音,本文将从etcd的应用场景开始,深入解读etcd的实现方式,以供开发者们更为充分地享用etcd所带来的便利。

经典应用场景

要问etcd是什么?很多人第一反应可能是一个键值存储仓库,却没有重视官方定义的后半句,用于配置共享和服务发现。

A highly-available key value store for shared configuration and service discovery.

实际上,etcd作为一个受到ZooKeeper与doozer启发而催生的项目,除了拥有与之类似的功能外,更专注于以下四点。

阅读更多

数据仓库与OLAP实现

数据仓库建模是数据仓库开发中最核心的部分,但就工程化而言,完整的数据仓库系统还会涉及其他一些组件的开发,其中最主要的是ETL工程,在线分析处理工具(OLAP)和商务智能(BI)应用等。这里将对这些方面做一个总体性的介绍包括OLAP相关知识。

创建数据仓库

数据仓库的创建方法和数据库类似,也是通过编写DDL语句来实现。在过去,数据仓库系统大都建立在RDBMS上,因为维度建模其实也可以看做是关系建模的一种。但如今随着开源分布式数据仓库工具如Hadoop Hive,Spark SQL的兴起,开发人员往往将建模和实现分离。使用专门的建模软件进行ER建模、关系建模、维度建模,而具体实现则在Hive/Spark SQL下进行。

阅读更多

数据仓库那点事(1)

阅读本文前,请先回答下面两个问题:

  1. 数据库和数据仓库有什么区别?
  2. 某大公司Hadoop Hive里的关系表不完全满足完整/参照性约束,也不完全满足范式要求,甚至第一范式都不满足。这种情况正常吗?

如果您不能五秒内给出答案,那么本文应该是对您有帮助的。

注:如果您还不清楚完整参照性约束,请参考《数据库关系建模》,如果您还不了解范式,请参考《更新异常与规范化设计》。

数据库的”分家”

随着关系数据库理论的提出,诞生了一系列经典的RDBMS,如Oracle,MySQL,SQL Server等。这些RDBMS被成功推向市场,并为社会信息化的发展做出的重大贡献。然而随着数据库使用范围的不断扩大,它被逐步划分为两大基本类型:

1. 操作型数据库

主要用于业务支撑。一个公司往往会使用并维护若干个数据库,这些数据库保存着公司的日常操作数据,比如商品购买、酒店预订、学生成绩录入等;

2. 分析型数据库

主要用于历史数据分析。这类数据库作为公司的单独数据存储,负责利用历史数据对公司各主题域进行统计分析;

那么为什么要”分家”?在一起不合适吗?能不能构建一个同样适用于操作和分析的统一数据库?

阅读更多

分布式系统中的唯一id生成策略及实现

系统唯一ID是我们在设计一个系统的时候常常会遇见的问题,也常常为这个问题而纠结。生成ID的方法有很多,适应不同的场景、需求以及性能要求。所以有些比较复杂的系统会有多个ID生成的策略。

简单分析一下需求

所谓全局唯一的 id 其实往往对应是生成唯一记录标识的业务需求

这个 id 常常是数据库的主键,数据库上会建立聚集索引(cluster index),即在物理存储上以这个字段排序。这个记录标识上的查询,往往又有分页或者排序的业务需求。所以往往要有一个time字段,并且在time字段上建立普通索引(non-cluster index)。普通索引存储的是实际记录的指针,其访问效率会比聚集索引慢,如果记录标识在生成时能够基本按照时间有序,则可以省去这个time字段的索引查询。

这就引出了记录标识生成的两大核心需求:

  • 全局唯一
  • 趋势有序

阅读更多

图数据库 Nebula Graph简介

Nebula Graph:一个开源的分布式图数据库。作为唯一能够存储万亿个带属性的节点和边的在线图数据库,Nebula Graph 不仅能够在高并发场景下满足毫秒级的低时延查询要求,还能够实现服务高可用且保障数据安全性。

简介

Nebula Graph 是开源的第三代分布式图数据库,不仅能够存储万亿个带属性的节点和边,而且还能在高并发场景下满足毫秒级的低时延查询要求。不同于 Gremlin 和 Cypher,Nebula 提供了一种 SQL-LIKE 的查询语言 nGQL,通过三种组合方式(管道、分号和变量)完成对图的 CRUD 的操作。在存储层 Nebula Graph 目前支持 RocksDB 和 HBase 两种方式。

Nebula Graph 整体架构

图数据库 Nebula Graph 的安装部署

阅读更多

幂等性设计那点事

前言

小伙伴们有没有遇到过生产环境经常出现过重复的数据?在排查问题的时候,数据又是正常的。这个是何解呢?怎么会出现这种情况,而且还很难排查问题。要知道重复数据的出现在电商和支付领域是很可怕的事情。

罪魁祸首

产生重复数据或数据不一致(假定程序业务代码没问题),绝大部分就是发生了重复的请求重复请求是指同一个请求因为某些原因被多次提交。导致这个情况会有几种场景

1)微服务场景,在我们传统应用架构中调用接口,要么成功,要么失败。但是在微服务架构下,会有第三个情况【未知】,也就是超时。如果超时了,微服务框架会进行重试。

2)用户交互的时候多次点击。如:快速点击按钮多次。

3)MQ消息中间件,消息重复消费

4)第三方平台的接口(如:支付成功回调接口),因为异常也会导致多次异步回调

5)其他中间件/应用服务根据自身的特性,也有可能进行重试。

我们知道了发生的原因,本质就是多次请求了,那如何解决呢?

阅读更多

亿级架构之存储与计算(石杉的架构笔记)

一、背景引入

首先简单介绍一下项目背景,公司对合作商家提供一个付费级产品,这个商业产品背后涉及到数百人的研发团队协作开发,包括各种业务系统来提供很多强大的业务功能,同时在整个平台中包含了一个至关重要的核心数据产品,这个数据产品的定位是全方位支持用户的业务经营和快速决策。

这篇文章就聊聊这个数据产品背后对应的一套大型商家数据平台,看看这个平台在分布式、高并发、高可用、高性能、海量数据等技术挑战下的架构演进历程。

因为整套系统规模过于庞大,涉及研发人员很多,持续时间很长,文章难以表述出其中各种详细的技术细节以及方案,因此本文主要从整体架构演进的角度来阐述。

二、商家数据平台的业务流程

下面几点,是这个数据产品最核心的业务流程:

  • 每天从用户使用的大量业务系统中实时的采集过来各种业务数据
  • 接着存储在自己的数据中心里
  • 然后实时的运算大量的几百行~上千行的SQL来生成各种数据报表
  • 最后就可以提供这些数据报表给用户来分析。

基本上用户在业务系统使用过程中,只要数据一有变动,立马就反馈到各种数据报表中,用户立马就可以看到数据报表中的各种变化,进而快速的指导自己的决策和管理。

整个过程,大家看看下面的图就明白了。

三、从0到1的过程中上线的最low版本

看着上面那张图好像非常的简单,是不是?

似乎数据平台只要想个办法把业务系统的数据采集过来,接着放在MySQL的各种表里,直接咔嚓一下运行100多个几百行的大SQL,然后SQL运行结果再写到另外一些MySQL的表里作为报表数据,接着用户直接点击报表页面查询MySQL里的报表数据,就可以了!

其实任何一个系统从0到1的过程,都是比较low的,刚开始为了快速开发出来这个数据平台,还真的就是用了这种架构来开发,大家看下面的图。

其实在刚开始业务量很小,请求量很小,数据量很小的时候,上面那种架构也没啥问题,还挺简单的。

直接基于自己研发的数据库binlog采集中间件(这个是另外一套复杂系统了,不在本文讨论的范围里,以后有机会可以聊聊),感知各个业务系统的数据库中的数据变更,毫秒级同步到数据平台自己的MySQL库里;

接着数据平台里做一些定时调度任务,每隔几秒钟就运行上百个复杂大SQL,计算各种报表的数据并将结果存储到MySQL库中;

最后用户只要对报表刷新一下,立马就可以从MySQL库里查到最新的报表数据。

基本上在无任何技术挑战的前提下,这套简易架构运行的会很顺畅,效果很好。然而,事情往往不是我们想的那么简单的,因为大家都知道国内那些互联网巨头公司最大的优势和资源之一,就是有丰富以及海量的C端用户以及B端的合作商家。

论C端用户,任何一个互联网巨头推出一个新的C端产品,很可能迅速就是上亿用户量;

论B端商家,任何一个互联网巨头如果打B端市场,凭借巨大的影响力以及合作资源,很可能迅速就可以聚拢数十万,乃至上百万的付费B端用户。

因此不幸的是,接下来的一两年内,这套系统将要面临业务的高速增长带来的巨大技术挑战和压力。

四、海量数据存储和计算的技术挑战

其实跟很多大型系统遇到的第一个技术挑战一样,这套系统遇到的第一个大问题,就是海量数据的存储。

你一个系统刚开始上线也许就几十个商家用,接着随着你们产品的销售持续大力推广,可能几个月内就会聚拢起来十万级别的用户。

这些用户每天都会大量的使用你提供的产品,进而每天都会产生大量的数据,大家可以想象一下,在数十万规模的商家用户使用场景下,每天你新增的数据量大概会是几千万条数据,记住,这可是每天新增的数据!这将会给上面你看到的那个很low的架构带来巨大的压力。

如果你在负责上面那套系统,结果慢慢的发现,每天都要涌入MySQL几千万条数据,这种现象是令人感到崩溃的,因为你的MySQL中的单表数据量会迅速膨胀,很快就会达到单表几亿条数据,甚至是数十亿条数据,然后你对那些怪兽一样的大表运行几百行乃至上千行的SQL?其中包含了N层嵌套查询以及N个各种多表连接?

我跟你打赌,如果你愿意试一下,你会发现你的数据平台系统直接卡死,因为一个大SQL可能都要几个小时才能跑完。然后MySQL的cpu负载压力直接100%,弄不好就把MySQL数据库服务器给搞宕机了。

所以这就是第一个技术挑战,数据量越来越大,SQL跑的越来越慢,MySQL服务器压力越来越大。

我们当时而言,已经看到了业务的快速增长,因此绝对要先业务一步来重构系统架构,不能让上述情况发生,第一次架构重构,势在必行!

五、离线计算与实时计算的拆分

其实在几年前我们做这个项目的时候,大数据技术已经在国内开始运用的不错了,而且尤其在一些大型互联网公司内,我们基本上都运用大数据技术支撑过很多生产环境的项目了,在大数据这块技术的经验积累,也是足够的。

针对这个数据产品的需求,我们完全可以做到,将昨天以及昨天以前的数据都放在大数据存储中,进行离线存储和离线计算,然后只有今天的数据是实时的采集的。

因此在这种技术挑战下,第一次架构重构的核心要义,就是将离线计算与实时计算进行拆分。

大家看上面那张图,新的架构之下,分为了离线与实时两条计算链路。

一条是离线计算链路:每天凌晨,我们将业务系统MySQL库中的昨天以前的数据,作为离线数据导入Hadoop HDFS中进行离线存储,然后凌晨就基于Hive / Spark对离线存储中的数据进行离线计算。

Hadoop与Spark作为世界上最优秀、运用最广泛的大数据技术,天然适合PB级海量数据的分布式存储和分布式计算。

在离线计算链路全面采用大数据相关技术来支撑过后,完美解决了海量数据的存储,哪怕你一天进来上亿条数据都没事,分布式存储可以随时扩容,同时基于分布式计算技术天然适合海量数据的离线计算。

即使是每天凌晨耗费几个小时将昨天以前的数据完成计算,这个也没事,因为凌晨一般是没人看这个数据的,所以主要在人家早上8点上班以前,完成数据计算就可以了。

另外一条是实时计算链路:每天零点过后,当天最新的数据变更,全部还是走之前的老路子,秒级同步业务库的数据到数据平台存储中,接着就是数据平台系统定时运行大量的SQL进行计算。同时在每天零点的时候,还会从数据平台的存储中清理掉昨天的数据,仅仅保留当天一天的数据而已。

实时计算链路最大的改变,就是仅仅在数据平台的本地存储中保留当天一天的数据而已,这样就大幅度降低了要放在MySQL中的数据量了。

举个例子:比如一天就几千万条数据放在MySQL里,那么单表数据量被维持在了千万的级别上,此时如果对SQL对应索引以及优化到极致之后,勉强还是可以在几十秒内完成所有报表的计算。

六、持续增长的数据量和计算压力

但是如果仅仅只是做到上面的架构,还是只能暂时性的缓解系统架构的压力,因为业务还在加速狂飙,继续增长。

你老是期望单日的数据量在千万级别,怎么可能?业务是不会给你这个机会的。很快就可以预见到单日数据量将会达到几亿,甚至十亿的级别。

如果一旦单日数据量达到了数十亿的级别,单表数据量上亿,你再怎么优化SQL性能,有无法保证100多个几百行的复杂SQL可以快速的运行完毕了。

到时候又会回到最初的问题,SQL计算过慢会导致数据平台核心系统卡死,甚至给MySQL服务器过大压力,CPU 100%负载后宕机。

而且此外还有另外一个问题,那就是单个MySQL数据库服务器的存储容量是有限的,如果一旦单日数据量达到甚至超过了单台MySQL数据库服务器的存储极限,那么此时也会导致单台MySQL数据库无法容纳所有的数据了,这也是一个很大的问题!

第二次架构重构,势在必行!

七、大数据领域的实时计算技术的缺陷

在几年前做这个项目的背景下,当时可供选择的大数据领域的实时计算技术,主要还是Storm,算是比较成熟的一个技术,另外就是Spark生态里的Spark Streaming。当时可没有什么现在较火的Flink、Druid等技术。

在仔细调研了一番过后发现,根本没有任何一个大数据领域的实时计算技术可以支撑这个需求。

因为Storm是不支持SQL的,而且即使勉强你让他支持了,他的SQL支持也会很弱,完全不可能运行几百行甚至上千行的复杂SQL在这种流式计算引擎上的执行。

Spark Streaming也是同理,当时功能还是比较弱小的,虽然可以支持简单SQL的执行,但是完全无法支持这种复杂SQL的精准运算。

因此很不幸的是,在当时的技术背景下,遇到的这个实时数据运算的痛点,没有任何开源的技术是可以解决的。必须得自己根据业务的具体场景,来从0开始定制开发自己的一套数据平台系统架构。

八、分库分表解决数据扩容问题

首先我们要先解决第一个痛点,就是一旦单台数据库服务器无法存储下当日的数据,该怎么办?

第一个首选的方案当然就是分库分表了。我们需要将一个库拆分为多库,不用的库放在不同的数据库服务器上,同时每个库里放多张表。

采用这套分库分表架构之后,可以做到每个数据库服务器放一部分的数据,而且随着数据量日益增长,可以不断地增加更多的数据库服务器来容纳更多的数据,做到按需扩容。

同时,每个库里单表分为多表,这样可以保证单表数据量不会太大,控制单表的数据量在几百万的量级,基本上性能优化到极致的SQL语句跑起来效率还是不错的,秒级出结果是可以做到的。

同样,给大家来一张图,大家直观的感受一下:

九、读写分离降低数据库服务器的负载

此时分库分表之后,又面临着另外一个问题,就是现在如果对每个数据库服务器又是写入又是读取的话,会导致数据库服务器的CPU负载和IO负载非常的高!

为什么这么说呢?因为在此时写数据库的每秒并发已经达到几千了,同时还频繁的运行那种超大SQL来查询数据,数据库服务器的CPU运算会极其的繁忙。

因此我们将MySQL做了读写分离的部署,每个主数据库服务器都挂了多个从数据库服务器,写只能写入主库,查可以从从库来查。

大家一起来看看下面这张图:

十、自研的滑动窗口动态计算引擎

但是光是做到这一点还是不够的,因为其实在生产环境发现,哪怕单表数据量限制在了几百万的级别,你运行几百个几百行复杂SQL,也要几十秒甚至几分钟的时间,这个时效性对付费级的产品已经有点无法接受,产品提出的极致性能要求是,秒级!

因此对上述系统架构,我们再次做了架构的优化,在数据平台中嵌入了自己纯自研的滑动窗口计算引擎,核心思想如下:

  1. 在数据库binlog采集中间件采集的过程中,要将数据的变更切割为一个一个的滑动时间窗口,每个滑动时间窗口为几秒钟,对每个窗口内的数据打上那个窗口的标签
  2. 同时需要维护一份滑动时间窗口的索引数据,包括每个分片的数据在哪个窗口里,每个窗口的数据的一些具体的索引信息和状态
  3. 接着数据平台中的核心计算引擎,不再是每隔几十秒就运行大量SQL对当天所有的数据全部计算一遍了,而是对一个接一个的滑动时间窗口,根据窗口标签提取出那个窗口内的数据进行计算,计算的仅仅是最近一个滑动时间窗口内的数据
  4. 接着对这个滑动时间窗口内的数据,可能最多就千条左右吧,运行所有的复杂SQL计算出这个滑动时间窗口内的报表数据,然后将这个窗口数据计算出的结果,与之前计算出来的其他窗口内的计算结果进行合并,最后放入MySQL中的报表内
  5. 此外,这里需要考虑到一系列的生产级机制,包括滑动时间窗口如果计算失败怎么办?如果一个滑动时间窗口计算过慢怎么办?滑动窗口计算过程中系统宕机了如何在重启之后自动恢复计算?等等

通过这套滑动窗口的计算引擎,我们直接将系统计算性能提升了几十倍,基本上每个滑动窗口的数据只要几秒钟就可以完成全部报表的计算,相当于一下子把最终呈现给用户的实时数据的时效性提升到了几秒钟,而不是几十秒。

同样,大家看看下面的图。

十一、离线计算链路的性能优化

实时计算链路的性能问题通过自研滑动窗口计算引擎来解决了,但是离线计算链路此时又出现了性能问题。。。

因为每天凌晨从业务库中离线导入的是历史全量数据,接着需要在凌晨针对百亿量级的全量数据,运行很多复杂的上千行复杂SQL来进行运算,当数据量达到百亿之后,这个过程耗时很长,有时候要从凌晨一直计算到上午。

关键问题就在于,离线计算链路,每天都是导入全量数据来进行计算,这就很坑了。

之所以这么做,是因为从业务库同步数据时,每天都涉及到数据的更新操作,而hadoop里的数据是没法跟业务库那样来进行更新的,因此最开始都是每天导入全量历史数据,作为一个最新快照来进行全量计算。

在这里,我们对离线计算链路进行了优化,主要就是全量计算转增量计算:每天数据在导入hadoop之后,都会针对数据的业务时间戳来分析和提取出来每天变更过的增量数据,将这些增量数据放入独立的增量数据表中。

同时需要根据具体的业务需求,自动分析数据计算的基础血缘关系,有可能增量数据需要与部分全量数据混合才能完成计算,此时可能会提取部分全量历史数据,合并完成计算。计算完成之后,将计算结果与历史计算结果进行合并。

在完成这个全量计算转增量计算的过程之后,离线计算链路在凌晨基本上百亿级别的数据量,只要对昨天的增量数据花费一两个小时完成计算之后,就可以完成离线计算的全部任务,性能相较于全量计算提升至少十倍以上。

十二、阶段性总结

到此为止,就是这套系统在最初一段时间做出来的一套架构,不算太复杂,还有很多缺陷,不完美,但是在当时的业务背景下效果相当的不错。

在这套架构对应的早期业务背景下,每天新增数据大概是亿级左右,但是分库分表之后,单表数据量在百万级别,单台数据库服务器的高峰期写入压力在2000/s,查询压力在100/s,数据库集群承载的总高峰写入压力在1万/s,查询压力在500/s,有需要还可以随时扩容更多的数据库服务器,承载更多的数据量,更高的写入并发与查询并发。

而且,因为做了读写分离,因此每个数据库服务器的CPU负载和IO负载都不会在高峰期打满,避免数据库服务器的负载过高。

而基于滑动时间窗口的自研计算引擎,可以保证当天更新的实时数据主要几秒钟就可以完成一个微批次的计算,反馈到用户看到的数据报表中。

同时这套引擎自行管理着计算的状态与日志,如果出现某个窗口的计算失败、系统宕机、计算超时,等各种异常的情况,这个套引擎可以自动重试与恢复。

此外,昨天以前的海量数据都是走Hadoop与Spark生态的离线存储与计算。经过性能优化之后,每天凌晨花费一两个小时,算好昨天以前所有的数据即可。

最后实时与离线的计算结果在同一个MySQL数据库中融合,此时用户如果对业务系统做出操作,实时数据报表在几秒后就会刷新,如果要看昨天以前的数据可以随时选择时间范围查看即可,暂时性是满足了业务的需求。

早期的几个月里,日增上亿数据,离线与实时两条链路中的整体数据量级达到了百亿级别,无论是存储扩容,还是高效计算,这套架构基本是撑住了。

阅读更多

数据脱敏如何避免系统重构或修改

背景

安全控制一直是治理的重要环节,数据脱敏属于安全控制的范畴。对互联网公司、传统行业来说,数据安全一直是极为重视和敏感的话题。

数据脱敏是指对某些敏感信息通过脱敏规则进行数据的变形,实现敏感隐私数据的可靠保护。涉及客户安全数据或者一些商业性敏感数据,如身份证号、手机号、卡号、客户号等个人信息按照相关部门规定,都需要进行数据脱敏。

在真实业务场景中,相关业务开发团队则往往需要针对公司安全部门需求,自行实行并维护一套加解密系统,而当脱敏场景发生改变时,自行维护的脱敏系统往往又面临着重构或修改风险。此外,对于已经上线的业务,如何在不修改业务逻辑、业务SQL的情况下,透明化、安全低风险地实现无缝进行脱敏改造呢?

阅读更多

从MySQL高可用架构看高可用架构设计

高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。

假设系统一直能够提供服务,我们说系统的可用性是100%。如果系统每运行100个时间单位,会有1个时间单位无法提供服务,我们说系统的可用性是99%。很多公司的高可用目标是4个9,也就是99.99%,这就意味着,系统的年停机时间为8.76个小时。

百度的搜索首页,是业内公认高可用保障非常出色的系统,甚至人们会通过www.baidu.com 能不能访问来判断“网络的连通性”,百度高可用的服务让人留下啦“网络通畅,百度就能访问”,“百度打不开,应该是网络连不上”的印象,这其实是对百度HA最高的褒奖。

阅读更多