小红书使用 TiDB 历史可以追溯到 2017 年甚至更早,那时在物流、仓库等对新技术比较感兴趣的场景下应用,在 2018 年 5 月之后,我们就开始逐步铺开,延展到其他适合 TiDB 的场景中去。截止目前,小红书使用的 TiDB 节点数在 200+ 个,未来也有更大扩展空间。
字节跳动早期为了快速支持业务,对于电商流量数据采用Lambda的设计架构,由于当前电商流量数据随着建设的深入和精细化的运营,设计架构的弊端也愈发凸显。
数据仓库是一个面向主题的(Subject Oriented)、集成的(Integrate)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合,用于支持管理决策。
在数字化转型浪潮中,如何存储和利用好数据,是企业面临的首要问题。相比于传统互联网全面拥抱云,产业互联网在数字化转型过程中,通常第一步是利用云存储来归档数据。
数仓建设是公司数据发展到一定规模后必然会提供的一种基础服务,其中数仓建设也是“数据智能”中必不可少的一环。本文将从数据仓库的简介、经历了怎样的发展、如何建设、架构演变、应用案例以及实时数仓与离线数仓的对比六个方面全面分享关于数仓的详细内容。
本文主要是整理博主收集的 Flink 高频面试题。之后每周都会有一篇,助力大家拿下面试。
从整体的资源角度看,有赞数据中台机器数量在 1500 台左右,其中大部分是物理机,也有一部分是虚拟机,同时有 100 个左右的应用、4 万个核,数据规模在 15 PB 左右。
当前,随着电商节日的增多(6.18、双十一、双十二)、平台拉新趋于频繁,大促活动也越来越普遍。作为一个电商平台,每年都会有一次,甚至几次的流量“大考”。数据库作为系统的重要节点,其稳定性和性能格外重要,数据库的全力保障是一个大的挑战。电商大促,这场没有硝烟的战争很多人已有体会,在此不再赘述。现在,我们直接切入主题--数据库如何 积极应对,全力保障 大促活动。这个题目分解为三个部分进行讲解: 第一部分,准备工作;第二部分,大促进行时;第三部分,大促后复盘。
企业降本增效是越来越热门的话题,除去较为粗暴的“毕业”之外,企业还可以在许多地方下功夫,例如降低大数据成本、营销成本、运营成本等等。在 ArchSummit 全球架构师峰会深圳站上,我们邀请了货拉拉大数据架构负责人王海华,他为我们分享了《货拉拉基于混合云的大数据成本管控体系建设实践》,本文为其演讲整理,期待你可以有所收获。 大家好,我是王海华,货拉拉基础架构负责人,我将从以下几方面展开分享。首先是背景与挑战;其次是大数据成本管理体系;接着是存储成本优化和计算成本优化技术细节;最后是总结与展望。 背景与挑
每年都要买衣服,有的衣服旧了,有的衣服破了,所以总是要将旧衣服放在一边,进行归档,新的衣服放在一边,是正在使用的。
一、概述 数据一致性是指关联数据之间的逻辑关系是否正确和完整。问题可以理解为应用程序自己认为的数据状态与最终写入到磁盘中的数据状态是否一致。比如一个事务操作,实际发出了五个写操作,当系统把前面三个写操作的数据成功写入磁盘以后,系统突然故障,导致后面两个写操作没有写入磁盘中。此时应用程序和磁盘对数据状态的理解就不一致。当系统恢复以后,数据库程序重新从磁盘中读出数据时,就会发现数据再逻辑上存在问题,数据不可用。 二、Cache引起的数据一致性问题 引起数据一致性问题的一个主要原因是位于数据I/O路径上的各种Cache或Buffer(包括数据库Cache、文件系统Cache、存储控制器 Cache、磁盘Cache等)。由于不同系统模块处理数据IO的速度是存在差异的,所以就需要添加Cache来缓存IO操作,适配不同模块的处理速度。这些Cache在提高系统处理性能的同时,也可能会“滞留”IO操作,带来一些负面影响。如果在系统发生故障时,仍有部分IO“滞留”在IO操作中,真正写到磁盘中的数据就会少于应用程序实际写出的数据,造成数据的不一致。当系统恢复时,直接从硬盘中读出的数据可能存在逻辑错误,导致应用无法启动。尽管一些数据库系统(如Oracle、DB2)可以根据redo日志重新生成数据,修复逻辑错误,但这个过程是非常耗时的,而且也不一定每次都能成功。对于一些功能相对较弱的数据库(如SQL Server),这个问题就更加严重了。 解决此类文件的方法有两个,关闭Cache或创建快照(Snapshot)。尽管关闭Cache会导致系统处理性能的下降,但在有些应用中,这却是唯一的选择。比如一些高等级的容灾方案中(RPO为0),都是利用同步镜像技术在生产中心和灾备中心之间实时同步复制数据。由于数据是实时复制的,所以就必须要关闭Cache。 快照的目的是为数据卷创建一个在特定时间点的状态视图,通过这个视图只可以看到数据卷在创建时刻的数据,在此时间点之后源数据卷的更新(有新的数据写入),不会反映在快照视图中。利用这个快照视图,就可以做数据的备份或复制。那么快照视图的数据一致性是如何保证的呢?这涉及到多个实体(存储控制器和安装在主机上的快照代理)和一系列的动作。典型的操作流程是:存储控制器要为某个数据卷创建快照时,通知快照代理;快照代理收到通知后,通知应用程序暂停IO操作(进入 backup模式),并flush数据库和文件系统中的Cache,之后给存储控制器返回消息,指示已可以创建快照;存储控制器收到快照代理返回的指示消息后,立即创建快照视图,并通知快照代理快照创建完毕;快照代理通知应用程序正常运行。由于应用程序暂停了IO操作,并且flush了主机中的 Cache,所以也就保证了数据的一致性。 创建快照是对应用性能是有一定的影响的(以Oracle数据库为例,进入Backup模式大约需要2分钟,退出Backup模式需要1分钟,再加上通信所需时间,一次快照需要约4分钟的时间),所以快照的创建不能太频繁。 三、时间不同步引起的数据一致性问题 引起数据不一致性的另外一个主要原因是对相关联的多个数据卷进行操作(如备份、复制)时,在时间上不同步。比如一个Oracle数据库的数据库文件、 Redo日志文件、归档日志文件分别存储在不同的卷上,如果在备份或复制的时候未考虑几个卷之间的关联,分别对一个个卷进行操作,那么备份或复制生成的卷就一定存在数据不一致问题。 此类问题的解决方法就是建立“卷组(Volume Group)”,把多个关联数据卷组成一个组,在创建快照时同时为组内多个卷建立快照,保证这些快照在时间上的同步。之后再利用卷的快照视图进行复制或备份等操作,由此产生的数据副本就严格保证了数据的一致性。 四、文件共享中的数据一致性问题 通常所采用的双机或集群方式实现同构和异构服务器、工作站与存储设备间的数据共享,主要应用在非线性编辑等需要多台主机同时对一个磁盘分区进行读写。
Flink Forward Asia 2020 三天的分享已经结束,在这次分享上,自己也收获到了很多。这里写一篇文章来记录下自己这次的收获和总结,从个人的视角以及理解,和大家一起分享下,当然,如果有理解错误的地方,也欢迎大家指出。
一年一度的双十一又双叒叕来了,给技术人最好的礼物就是大促技术指南! 而经过这些年的发展,大促早已不仅仅局限于电商行业,现在各行各业其实都会采用类似方式做运营活动,汽车界有 818,电商有 618 、11.11 等等,各种各样的大促场景,对包括数据库在内的基础软件提出了很多新挑战,同时也积累了诸多最佳实践。
云服务器、云数据库特惠,服务更稳,速度更快,价格更优 前往地址> 云服务器年付3折起 所有机型免费分配公网IP,50G高性能云硬盘(系统盘) 。 英特尔Ⓡ至强处理器 CPU负载无限制,利用率最高为100% 搭配网络增强,包转发能力最高可达30w 个人建站,轻量APP,企业用户等各应用场景均可适用 云数据库年付3折起 MySQL高可用版 提供备份,恢复,监控,数据迁移等产品功能 双机热备,自动容灾 采用高性能SSD硬盘 按需使用,弹性扩展 Redis 提供备份,恢复,监控,按需升级等产品功能 适用所用高
随着计算力的不断提升和智能算法的快速演进,以及云计算、物联网和人工智能与传统产业更加密集的渗透,如今的世界正在加速进入一个全新的数据时代。
本文主要介绍Apache Doris在京东广告报表查询场景下的应用。文章将从我们原有系统开始讲述,包括我们遇到的问题,面临的挑战,以及我们为何选择使用Apache Doris。最后将介绍Doris在我们在生产环境下的使用情况,包括Apache Doris在京东“618”,“双11”大促中的表现。希望通过我们的使用实践为大家提供一些经验参考,也欢迎大家对我们的不足之处提出建议。
摘要:在 Flink Forward Asia 大会实时数仓专场中,菜鸟数据&规划部高级数据技术专家贾元乔从数据模型、数据计算、数据服务等几个方面介绍了菜鸟供应链数据团队在实时数据技术架构上的演进,以及在供应链场景中典型的实时应用场景和 Flink 的实现方案。
摘要:实时数仓以提供低延时数据指标为目的供业务实时决策,本文主要介绍基于Flink的广告实时数仓建设,主要包括以下内容:
从 2009 年到 2021 年,从千万交易额到千亿交易额,双 11 已经开展了 12 年。如今,每年的双 11 以及一个月后的双 12,已经成为真正意义上的全民购物狂欢节。刚刚过去的 2021 年双 11,就有超过 8 亿消费者参与。
2022年,搜狐智能媒体完成了迁移腾讯云的弹性计算项目,其中大数据业务整体都迁移了腾讯云,上云之后的整体服务性能、成本控制、运维效率等方面都取得了不错的效果,达到了预期的降本增效目标。
随着唯品会业务的快速发展,订单量的不断增长,原有的订单存储架构已经不能满足公司的发展了,特别是在大促高峰期,原订单库已经成为抢购瓶颈,已经严重制约公司的发展。
编辑|邓艳琴 完整 PPT 下载: https://qcon.infoq.cn/2023/guangzhou/presentation/5269 JuiceFS GitHub 地址: https://github.com/juicedata/juicefs
每年 Shopee 会在五至十二月的每个大促节点举行电视直播活动。每次大促活动时,各市场的运营人员会与当地电视台合作,在节目直播过程中插入一段玩 Shopee 小游戏的互动环节。
Weiyi,携程资深数据开发,关注大数据相关技术,对大数据实时计算、流批一体等方面有浓厚兴趣;
对于企业来说,数据保护是将大量数据存储在云端的关键原因。最终所有数据都需要备份和归档,很多IT组织将云计算视为本地存储的最具成本效益的替代方案。 这一策略的最大问题是,本地存储的大部分数据都在与云服务
全链路压测是以全链路业务模型为基础,将前端系统、后端应用、中间适配层、DB等整个系统环境,完整得纳入到压测范围中,以http请求为载体,模拟真实的用户行为,在线上构造出真实的超大规模的访问流量,以全链路压测模型施压,直至达到目标峰值,在压测过程中发现系统瓶颈和验证系统能力。全链路压测自2013年诞生至今,一直稳居大促质量保障核武器地位。
业务背景 作业帮成立于2015年,一直致力于用科技手段助力教育普惠,运用人工智能、大数据等前沿技术,为学生、老师、家长提供更高效的学习、教育解决方案,智能硬件产品等。作为大数据中台架构团队,我们一直探索利用有限的资源,较低的开发维护成本、高时效的数据更新和查询,为业务团队提供基础支持。 问题&痛点 ODS层数据就绪时间晚,DWS/ADS等上层数据和业务报表构建时间少。 作业帮ODS层表大概有几千张,TP90就绪时间大概在4点30左右,不同业务团队因工作时间不同,看数时间会有些差异,总体上来说基本都要求数
数栈是云原生—站式数据中台PaaS,我们在github和gitee上有一个有趣的开源项目:FlinkX,FlinkX是一个基于Flink的批流统一的数据同步工具,既可以采集静态的数据,也可以采集实时变化的数据,是全域、异构、批流一体的数据同步引擎。大家喜欢的话请给我们点个star!star!star!
背景:5月23-24日,以“焕启”为主题的腾讯“云+未来”峰会在广州召开,广东省各级政府机构领导、海内外业内学术专家、行业大咖及技术大牛等在现场共议云计算与数字化产业创新发展。 来自腾讯TEG技术工
全球分布式云大会是分布式云技术和商业交流的旗舰级平台,2023全球分布式云大会·北京站将于6月28日-29日正式召开,本次大会以“云智筑基”为主题,探究人工智能(AI)在大模型全新的发展风口,构建新型泛在算力网络的趋势,如何利用分布式云、分布式数据库、分布式存储、边缘云等构建新型算力网络,打造更强大的数字经济价值引擎。
现在业务系统设计中,存储设计扮演着至关重要的角色。随着数据量的爆炸性增长和业务需求的不断变化,如何高效、安全地存储和管理数据成为了每个业务系统设计必须面对的挑战。
对大多数人而言,今年的双十一可谓是无感而过。然而,这个「无感」正是今年支付宝技术团队的一个重要目标。
首先,数据湖可存储海量、低加工的原始数据。在数据湖中开发成本较低,可以支持灵活的构建,构建出来的数据的复用性也比较强。
在电商大促时,为了能够合理地制定KPI、高效地商品备货和营销资源的安排,都通常都需要对这次大促的GMV和订单规模做预测,避免出现诸如产品断货或者过剩、人员效率不高等问题,导致客户流失未能成交。
首先,我们在做数据开发的过程中涉及到一些基本要素:时效性保障、质量保障、稳定性保障,此外还有敏捷性、可管理性等其他要素。根据公司业务场景和重要性不同,重点也有所侧重。
究竟什么是中台, 业界并没有一个标准答案, 各个厂商都有自己的定义. 笔者比较认可的一个定义是 ThoughtWorks 提出的"企业级能力复用平台". 各个领域涌现出很多中台产品, 如业务中台, 搜索中台, 数据中台等. 其中数据中台这个词汇越来越多的出现在视野中, 从百度指数中可以看到这一趋势.
一、iOS数据持久化方式 (1)XML属性列表(plist)归档 (2)Preference(偏好设置),本质还是通过“plist”来存储数据, 但是使用更简单(无需关注文件、文件夹路径和名称) (3)NSKeyedArchiver归档(NSCoding),可以把任何对象, 直接保存为文件的方式。 (4)SQLite3,当非常大量的数据存储时使用 (5)Core Data,就是对SQLite的封装 关于bundle路径和sandbox沙河路径: (1)bundle路径:应用程序 (APP) 在手
移动端重点是移动端,支持IOS/Android系统,包括IM App,嵌入消息功能的瓜子App,未来还可能接入客服系统。
快手的传统离线链路和很多公司是一致的,基于 Hive做离线分层数仓的建设。在入仓环节和层与层之间是基于 Spark 或者 Hive做清洗加工和计算。这个链路有以下四个痛点:
本文节选自《基础软件之路 - 企业级实践及开源之路》一书,该书集结了中国几乎所有主流基础软件企业的实践案例,由 28 位知名专家共同编写,系统剖析了基础软件发展趋势、四大基础软件(数据库、操作系统、编程语言与中间件)的领域难题与行业实践以及开源战略、生态建设与人才培养。
爆发式增长的红利过去了,要想持续的营收增长,精细化的营销是必须的,巨大的流量主,广告主要精准触达用户,对长效ROI的需求日益增长,提高投放效果,那么RTA新的玩法就出现了,其实不难理解,个性化的精准投放实现在广告主侧实现。
有赞搜索中台作为有赞企业级搜索能力复用平台,在解决各个业务域搜索问题时是如何探索与实践的,这个过程中有哪些心得,本文与大家一起分享探讨下。
《一个海量在线用户即时通讯系统(IM)的完整设计》(以下称《完整设计》)这篇文章发出来之后有不少读者咨询问题,提出意见或建议。主要集中在模块拆分、协议、存储等方面。针对这些问题做个简单说明。
当Oracle写数据文件遇到错误时,该如何应对呢?是离线文件还是崩溃实例?这个简单问题的技术变化跨度超过了20年。 自Oracle 11.2.0.2版本开始,一个新的隐含参数 - _datafile_write_errors_crash_instance 被引入到数据库中,通过这个参数名就可以了解到其含义:当发生数据文件写错误时,Crash数据库实例。 为什么要引入这个参数呢?这个参数后台解决的是什么问题呢?我在《数据安全警示录》一书上曾经写过多个案例,在归档模式下当发生文件(非SYSTEM文件)写错误
1、前言 京麦实时消息推送是京东的京麦商家开放平台的核心组成部分。从消息源到消息中心再到触达用户,以及最终根据消息协议呼起操作页面,京麦实时消息推送是一个完整且健康的生态闭环。下面我会详细的介绍下京
今年的 618 前夕,何小锋显然没有以前那么紧张,人更放松,说话也更淡定。一方面,作为京东科技京东云云原生平台负责人,他已经参加过 19 次大促备战,积累了丰富的经验;另一方面,从 2014 年使用 Docker 到 2018 年建成全球最大规模 Kubernetes (以下简称 K8s)集群再到全面拥抱云原生,京东在容器和云原生领域有着多年的技术实践与经验积累。这些无疑给了他十足的信心! 根据最新消息,6 月 18 日凌晨,京东云发布 618 当天首份战报,在从容应对高并发数亿级流量洪峰的同时创下多项纪录
时光如白驹过隙,坐在时代的列车里,我们一路向前;近三十年来,无数事物在车窗前掠影而过,一度流行,又一度黯淡。磁带,就是一个时代的符号。彼时,磁带因其低廉、可靠及易用等特性,一度成为音乐最主流的载体,将流行音乐传遍大街小巷。后来,随着 CD 和 MP3走进大众视野,磁带逐步退出历史舞台。如今,磁带作为音乐载体早被时代淘汰.....但磁带作为存储载体,近几十年却从未过时:在冷数据场景,磁带存储凭借其极低的成本和极长的寿命,在企业存储市场始终占有一席之地。今天的故事就此展开,来聊聊腾讯的深度归档存储与磁带的那些事。欢迎阅读~
领取专属 10元无门槛券
手把手带您无忧上云