php建设网站用什么软件,做网站在线视频如何添加,网架生产公司,兰州网站建设推荐q479185700顶你作者介绍OPPO 数据分析与解决方案团队主要负责 OPPO 全集团的大数据分析和解决方案提供#xff0c;团队成员多来自一线互联网公司及著名高校#xff0c;在 OPPO 众多场景的大数据应用方面有很深经验#xff0c;极大的支撑了业务迅速发展。文章具体作者#xff1a;羊欢… 作者介绍OPPO 数据分析与解决方案团队主要负责 OPPO 全集团的大数据分析和解决方案提供团队成员多来自一线互联网公司及著名高校在 OPPO 众多场景的大数据应用方面有很深经验极大的支撑了业务迅速发展。文章具体作者羊欢代凯柳青陈英乐。OPPO 大数据中心在 2019 年初承接了接入某业务线核心数据的重要任务一期目标是建立一个能提供准实时大数据查询服务的数据仓库。我们选用了之前从未在公司大规模正式使用过的 TiDB 作为核心数据库引擎。本文记录这次吃螃蟹的一些经验和教训供大家参考。前期工作核心挑战经过需求调研阶段我们发现面临以下核心的挑战1. 大数据能力支持。从业务数据量看当前虽然尚在 TB 级别但增长速度非常快业务本身有进行全量整合分析查询的需求。2. 数据接入困难。数据分散且多样跨国多种 DB 类型多网络环境接入难度较大。3. 数据变动频繁。核心数据存在生命周期在生命周期内变动频繁这与互联网的核心数据一旦生成就不再变化有较大不同。4. 服务实时性较高。数据整合的速度和查询结果越实时对业务价值就越大。现有技术架构体系公司数据中心目前承载着公司各业务系统积累的数据。数据仓库方面的技术体系离线数据的存储和应用架构是主流的 HadoopHive/Spark/Presto。实时数据服务则基于 Kafka/Flink/SparkStreaming 等流行的框架。离线数据平台可以提供 T1 及小时级别的数据计算服务而实时数据服务主要适用于互联网应用场景即大多行为数据生成后不再发生变化。这也是业界非常典型的基础技术架构。技术选型考量一开始我们打算采用业界常用的办法即利用数据中心现有的基础设施开发出离线和实时两套体系的数据并进行整合后提供给报表查询接口。但其实这个方案其实有一个最致命的问题大部分此业务数据在完整的生命周期里是经常发生变动的。而项目里一个重要的需求是要能近实时(最多半个小时)的查询出结果。离线任务运行后的结果很可能很快就失效了需要重新计算。而离线计算耗时较长根本无法满足准实时需求如果把大部分计算交给实时引擎也要进行较为复杂的代码设计和框架的修改适配。事实上我们已经做好了服务降级的打算。我们面临困境的实质是接入频繁变动的行业数据对于主要源自互联网的大数据技术体系是一种新的挑战。因此我们继续不断的寻找更好的方案。我们的目标是找到具有以下特点的体系1. 能近实时的对所有层级的数据进行更新(主要是原始数据和各层聚合数据)。2. 秒级的查询性能。3. 不再有实时和离线的界限只需要同一套代码。4. 方便的存储扩展支持大数据。5. 较低的技术栈要求。在这种背景下我们关注到了已经在 OPPO 内部进行着少量测试(作为备份从库等)的 TiDB。它的主要特点及带来的好处是1. 完全兼容 MySQL 协议。低技术栈在合理的索引设计下查询性能优异到秒级出结果对小批量的数据的更新和写入也相对优秀。2. 水平弹性扩展。能支持大数据存储扩容成本仅为机器成本。3. 支持大数据情况下的复杂查询(TiSpark 组件可使用 Spark 引擎)。4. 可用性高。Raft 协议保证数据强一致且在不丢失大多数副本的前提下能自动恢复。5. 完全开源社区活跃。开源约 4 年GitHub Star 数 2 万Fork 数 3 千。根据官方数据截止 19 年 8 月已经有约 3 千家企业建立了规模不一的测试集群500 家企业有线上集群其中包括数家银行(北京银行微众银行)的核心交易系统。网络上也能看到众多一线互联网公司的案例分享。6. 作为 HTAP未来将可以方便的对接 TP 类系统。当前离线架构的数据经常需要再次出库到诸如 MySQL 库里以便 TP 系统快速读取无疑增加了系统复杂度。HTAP 将交易和分析系统的界限消除交易数据生成即可用于分析而分析结果生成后即可以用于交易没有了 ETL 过程非常便利而且让 IT 架构逻辑更近似业务逻辑。对于这次的项目来说我们最看重的三点是1. 可以很方便的支持数据频繁更新。2. 优秀的查询响应速度。3. 支持方便的无限扩容。由于并不可见的重大缺陷且阅读了许多比此次项目数据量级大得多的成功案例我们正式开始了吃螃蟹的征程。实践过程项目架构和实施项目一期的架构和实施相对简单。主要是集群建设数据同步模型建设任务调度。下面简要介绍一下。集群建设TiDB集群的架构图及部署文档参考官方网站即可不再赘述以下是项目配置供参考关于存储官方推荐采用 NVME SSD这样能最大发挥 TiKV 的 IO 能力 。目前由于某些原因暂时退而求其次采用 SATA SSD通过把磁盘分成 2 组 TiKV 数据盘每一组 3 块盘做 RAID0最后剩余 2 块盘做 RAID1 作为系统盘将磁盘 IO 能力提升。然后每组数据磁盘上部署一个 TiKV 节点。TiDB 的部署采用官网推荐的 TiDB Ansible 部署方式这里不再赘述大家可以去 PingCAP 官网查看。数据同步项目采用了定期(每 10 分钟可调整)调度 Python 脚本以实现增量抽取数据。源数据库是 Oracle/SQLServer目标数据库是 TiDB 集群。数据同步脚本是自研的代码简洁但非常强大核心是采用 pyodbc 开源库并具有以下特点1. 支持多种数据目标/源 DB丰富的自定义 DDL 支持(包括自动建表添加字段注释自定义字段处理)自定义抽取 SQL(既可以完整同步数据亦可以同步前就进行一些预处理灵活性强)。2. 便捷的读写并发量控制(读写依赖数据队列沟通还可以平衡数据源并发查询压力及目标库的写压力以及历史数据同步)。同步脚本要求有增量抽取的控制字段比如 update_time 等一般规范的表设计均能满足但项目中确实遇到一些因历史原因导致我们不得不进行全表覆盖同步部分表还存在“硬删除”的情况 。最后通过开发新的删除服务以记录删除的主键进行同步删除同步。对于普通的一次增量同步比如同步最近 10 分钟的数据。我们是定义好同步脚本传入时间周期及合理的并发数发起查询请求并将返回的数据返回到临时队列中写进程则按 5 千条一次读队列中的数据按主键先删后插实现了增量的数据新增或者更新。另外出于项目周期及成本等考虑项目并未采用读取 Oracle Redo Log 的方式。这种方式的优点是最小化地减少读写操作缺点是需要付费组件支持需要单独开发以及日志容量问题导致的系统运维难度高等。数据同步看起来简单但实际上还是遇到了以下困难并进行了相应的解决1. 由于是多进程同步部分异常捕获在初期被忽略了在后来验证的过程中一一补齐最后保证了只要任务正常完成同步即无误。2. 数据并发写压力较大(初始化时数据同步量非常大)的情况下会出现 TiDB 承压存在 TiKV 写失败的情况需要控制并发量并在实践中得到最佳的配置。3. 连接频繁失败问题用 Proxy 解决以及高可用方案。由于 TiDB 在遇到超大 SQL 请求时会一直申请内存直到 OOM最后 TiDB 重启最后采用 HAPROXY 来解决 TiDB 的高可用性。这样一个节点重启尽量不影响其他 SQL 的运行。另外 HAPROXY 本身也需要保证高可用最后是借助运维的 OGW 集群来负责HAPROXY的高可用。4. 联合索引设置不合理导致索引浪费未来需要进行索引优化。5. 国外数据库与国内网络连接不稳定主从库同步延迟导致无法完整同步数据。最后采取了实时监控主从同步延迟及获取数据业务时间最大值等双重措施保证数据同步的准确性和及时性。6. 数据同步缺少监控机制对同数据同步过程中是否有数据丢失或者说怎么保证两边数据库是一致的时间久了会不会出现不一致的情况怎么快速修复等目前是通过脚本定期统计两边表记录数的方式进行监控。模型建设一期项目主要目标是将分散的数据统一存储起来以及进行一些大量数据明细表之间的关联查询。当时面临两种选择方案一仅对源数据进行基础性的处理然后使用复杂的 SQL 完成业务模型的定义(OPPO 自研报表平台 InnerEye 支持按 SQL 语句自定义查询接口)每次用户查询的时候都通过这个模型 SQL 即时的运算并返回结果(可设置缓存时间)。这个做法的好处是几乎没有任何的中间甚至结果数据的开发工作坏处是对算力的极大浪费而且后期并发度变大后性能将是瓶颈。方案二进行常规的分层模型开发按周期更新数据。由于一期项目较少聚合类报表多是明细级数据查询我们仅仅将模型主要分为共享层和应用层。查询接口直接使用应用层单表查询可以通过优化索引实现秒查数据共享层则是为各个应用层的结果表提供一些公共的基础数据支持。这种做法将面临的挑战将是如何在 10 分钟内将所有的数据模型都完成相应的增量更新或者插入。评估方案一的时候使用了 TiSpark 进行了验证然而结果并不是很好响应时间达数分钟当然原因可能是集群算力不够也可能是 SQL 不够优化。最终考虑到未来并发的压力很快把这个偷懒的方案最终否决了。在实施方案二的过程中发现有良好的索引的情况下只要遵循增量更新的原则完全能满足性能需求。模型建设的输出是一系列的 SQL 计算脚本。最后根据此业务系统目前的数据情况将数据模型设计为三层设计基础数据共享数据应用数据。另外有独立的维表数据层及系统数据层。以上各层的数据没有进行分库分表(在 TiDB 的技术框架中不需要进行分库分表来提升性能)数据生成后的一段时间(一般最长一个月)内都会发生变更。由于采用的是增量更新因此能很快的完成。唯一的缺点是在系统初始化或者要修复很长时间段的数据时由于索引的存在导致写入速度较慢(相对无索引的文件表)但依然可以通过一定技术方案来规避。任务调度目前 OPPO 的分布式调度系统是基于 airflow 开源项目搭建。同步任务与计算任务分属独立的 DAG这样虽然会多一些体力活(建立跨 DAG 依赖任务)但减少了不同类型/国家的任务的耦合度方便了运维提高了数据服务的可用性。调度系统的使用过程中需要注意的点主要有1. 队列数量。合理设置任务队列的总数保证任务执行的及时性及机器负载的平衡。2. 多机器。由于系统的准实时性至少准备两台计算和同步的物理服务器以保证数据服务不中断。3. 优化 airfow 本身。由于 airflow 本身存在一些问题因此需要建立独立于 airflow 的运行监控机制。比如通过对其 db 表的查询来监控其是否出现任务长时间阻塞等异常情况另外需要定时清除历史运行记录以提升 airflow 的 web 服务体验。4. 时差问题。由于各国家地区数据库存在时差问题最后采用了脚本共用、调度分离的方式减少耦合带来的调度堵塞问题。遇到的问题从最开始的 2.x 版本到现在稳定运行的 2.1.13主要遇到了以下几个重要的问题1. 提交事务大小限制问题TiDB 本身是 TP 系统因此出于对事务稳定性的考虑对每次提交事务涉及的数据量大小有所限制。但由于项目本身每个任务涉及的数量有可能高达千万行因此需要打开TiDB的允许批量插入/删除设置项。TiDB 特意对事务大小设置了一些限制以减少这种影响单个事务包含的 SQL 语句不超过 5000 条(默认)。每个键值对不超过 6MB。键值对的总数不超过 300,000。键值对的总大小不超过 100MB。为了避免在运行中出现过大事务在项目中采取以下配置SET SESSION TiDB_batch_insert 1;SET SESSION TiDB_batch_delete 1;set autocommit1;同时由于索引的存在在进行数据的写入过程中过多的索引会加大事务的开销可以通过减少批次大小来降低单次事务(默认是 20000)set session.TiDB_dml_batch_size 5000;2. Proxy 连接失败的问题项目运行过程中多次应用端出现 connect timeout 的情况除去 TiDB Server 本来实例重启的问题haproxy 的连接超时时间设置过短导致执行时间稍长的 SQL 就会被断开连接这个时候需要调整 haproxy 的超时参数timeout queue 30mtimeout connect 30mtimeout client 30mtimeout server 30m3. TiDB Server 服务重启问题在项目过程中曾出现了多次 TiDB Server 服务重启的现象主要原因及措施如下TiDB Server 节点出现了 OOM。由于前期负载较低将 TiSpark 服务直接部署在了 TiDB Server 节点导致有大查询时经常出现 OOM 情况。后面将 TiSpark 服务和 TiDB Server 服务进行了分开部署并调整 OOM 相关配置为oom-action: cancel。机器故障问题。更换相关硬件设施。4. 无法锁表问题为了解决“硬删除”问题对小表同步的时候采取了覆盖更新的模型即先删除全表再写入新数据。但由于目前 TiDB 没有锁表的功能(锁写或者读)导致这个小小的空档如果被其他任务读取就会造成数据错误。虽然由于有任务依赖关系的存在这种情况非常少发生但在数据修复或者人工运行任务的时候还是会造成问题。目前的解决方案是手工实现简单的锁表机制另外就是可以使用临时表然后 replace into 来解决。至于 TiDB 的系统级别的锁表功能已经在规划中了。5. 与 Hadoop 数据湖的打通项目受到了上级的一个重大的挑战在 TiDB 中的数据无法与现有数据(主要以 hive 表形式存储于 Hadoop 集群中)形成协同作用项目价值会因此大打折扣。 针对这个挑战最开始打算再同步一份数据到 Hadoop 集群中但这样做其实是存储的极大浪费但在当时似乎是唯一的办法。在项目快接近尾声的时候发现可以通过在 TiSpark 集群上通过 thriftServer(最后进化到使用 Livy 服务)的方式打通两个体系的数据实现 hdfs 和 TiKV 两个数据源的混合查询。最后也确实取得了成功并已经服务了数个需求。相关的技术细节未来将以另外的文章进行说明和分享。6. 脏数据处理假设要插入 20 万条数据但由于事务限制系统只能 5000 行条提交一次一共需要提交 40 次。现在的问题是这 40 次可能在任一一次提交中失败这样先前提交的数据就成了脏数据因此在重试的时候需要删除这些数据后再做。因为数仓任务经常有重跑的需求而目前 TiDB 体系下没有分区覆盖因此这是一个需要注意的点。运行性能目前系统上线约三个月暂未出现任何较大的技术问题运行非常平稳。以下是抽取的一些日常运行数据或压测数据供参考。1. 集群 OPS 和 QPS在现有环境上集群 OPS 最大可达到 61KQPS 最大可达到 12.11K查询性能比较稳定。2. 高可用主要基于 TiDB Server 之上负载均衡组件 Haproxy 和 TiKV 的多副本机制实现。3. 查询稳定性上图中除了有部分整机信息聚合查询外耗时较长(主要使用 TiSpark 组件)外可以看到 99% 的查询在 4S 内进行了返回而 95% 的查询在 104ms 内返回可以说性能是非常不错。目前表的数据行量主要处于百万到百亿行级别而且索引数量并不多因此能获得当前的性能可以说超出预期。升级 3.0.5由于 2.X 版本在达到 250 万个 region 左右出现了一些性能问题IO/CPU 负载接近满负荷。跟官方沟通后我们决定升级到 3.0.5 这一稳定版本。升级后在没有任何硬件变更的情况下性能有了接近翻倍的提升目前系统的核心资源都出现大幅空闲。TiDB 技术体系的限制项目结束后现在回过头来看 TiDB我们认为有以下一些比较重要的点需要注意1. TiDB 首先是一个 TP 系统。即目前来看 TiDB 主要是为了 TP 系统设计的AP 方面的功能有待加强。事实上 PingCAP 已经认识到了 AP 的重要性在 3.x 中AP 的功能将会通过引入 TiFlash 组件而大大加强从而成为真正的 HTAP。2. TiDB 存储成本相对 Hadoop 集群来说较高。目前至少要求是 SSD加上未来 TiFlash 的引入1 份数据将会存 4 份存储成本相对更大。3. TiDB 目前(截止 2019 年 9 月)尚未有 PB 级别的生产集群。因此可能直接应用于海量数据的互联网数据应用可能会遇到其他一些问题。其他经验教训1. 不要在一个可能包含很长字符串的列上创建索引在 TiDB 建立索引可以极大提高查询性能但要避免在一个可能包含很长字符串的列建索引否则在创建和使用索引时都会花费较大的代价。而且当大小超过默认的 3072 byte 时TiDB 会报错。2. 确保开启位置标签机制当一个机器部署多个 TiKV 实例未提高系统稳定性和可用性一定要确保开启了位置标签机制。前期部署集群服务时虽然在 inventory.ini 文件中设置了以下内容 location_labels [host]但是后来发现并没有生效导致一个机器 down 了以后集群中某些数据查询出现了严重问题:究其原因是因为位置标签机制没有生效导致同一个节点上存在同一个 region 的两个副本(一共 3 副本)导致不能再正常对外提供相关服务了。可以通过 pd-ctl 确认位置标签机制生效如 config show all 的时候有如下内容代表已生效如果没有生效可通过以下方式使得生效config set location-labels host总结一台机器部署多个 TiKV 实例的场景要充分利用 location_labels 机制将副本部署到不同的机器上以增强系统的稳定性。3. 不支持三段式查询目前 TiSpark 还不支持如下的三段式查询。dbname.tablename.columnname如以下 sql 会执行失败select dbname.tablename.columnname from dbname.tablename可以通过别名的方式加以解决select A.columnname from dbname.tablename as A4. 主键变更目前在 TiDB 上进行变更主键(增加或者删除字段)是不被支持的唯一的办法只有重建表。这在某些场景会成为一个较为痛苦的经历。因此在表设计阶段需要非常的小心争取一次做对。总结项目以极小的人力投入较为成功的实现了预定目标也陆续服务到了许多其他部门和项目产生了良好的数据协同效应。从此次实践中我们认为随着 AP 能力的加强TiDB 几乎可以做为大多数亚 PB 级别数据应用的存储引擎。因为它的 HTAP 优雅架构能大大简化运维和开发人员的工作让他们集中到业务逻辑表达和处理上。当前的主流大数据技术主要源于互联网平台大多在某些方面有妥协因而需要相互补充导致系统整体架构越来越复杂最终让运维及开发门槛也越来越高这也是目前没有更好办法的办法。但最优的数据系统架构应该是将业务逻辑无关的技术工作尽可能掩藏起来交给数据库引擎来打理。在这个话题上我看一篇非常不错的文章大家可以参阅《从大数据到数据库》。事实上随着越来越多的非互联网业务越来越信息化其系统数据增长虽然尚达不到互联网动辄就PB级但也很轻易的达到TB级别这个级别的TP/AP系统技术选型其实还是一个较大的空白。目前看TiDB是该领域的一个非常好的选择。项目中 PingCAP 团队给予了大量的直接帮助在此致谢典型实践知乎 | 万亿量级业务数据下的实践和挑战平安科技 | 核心系统的引入及应用北京银行 | 1. 两地三中心实践 2. 在线缩容迁移微众银行 | 数据库架构演进及 TiDB 实践经验华泰证券 | TiDB 在华泰证券的探索与实践丰巢 | 支付平台百亿级数据美团点评 | 深度实践之旅贝壳金服 | 在线跨机房迁移实践易果生鲜 | 实时数仓小红书 | 从 0 到 200 节点的探索和应用小米 | TiDB 在小米的应用实践58 集团 | 应用与实践爱奇艺 | 边控中心/视频转码/用户登录信息系统Shopee | 东南亚领先电商 Shopee 业务升级转转二手交易网 | TiDB 在转转的应用实践同程艺龙 | 1. 票务项目 2.自研 TiDB 运维工具 Thor 今日头条 | 核心 OLTP 系统摩拜单车 | 1. 深度实践及应用 2. 在线数据业务更多https://pingcap.com/cases-cn/
