千亿大数据处理能力是如何炼成的？

（此文来自乐字节）

源起谷歌“三驾马车”

聊起大数据，就绕不开谷歌的“三驾马车“。早在 2003 年，谷歌发表第一篇论文——谷歌文件系统（GFS）；第二年，谷歌再次发表一篇论文——分布式计算框架 MapReduce；2006 年，谷歌发表第三篇论文——NoSQL 数据库系统 BigTable。

这三篇论文由此开启了大数据时代。

受谷歌“三驾马车”的影响，其他互联网公司也在尝试大规模分布式系统，希望构建强大的数据存储、分析和处理平台。不过，当时正处于前 Hadoop 时期，互联网公司基本上都在摸着石头过河。

2
数据收集和计算领域的先驱

在众多的互联网公司中，如乐字节公司等，成立于 2006 年的秒针系统无疑是这个领域的先行者。据秒针系统产研中心负责人刘沛介绍，2008 年 Hadoop 还没有成熟，他们从零研发了自己的大数据平台，“思路跟 Hadoop MapReduce 类似，一天也能处理几十亿数据”。

刘沛在 2007 年加入秒针，那时他还在读大三。一年后，他正式毕业，留在秒针系统。他先后领导了包括广告监测系统 AdMonitor 等核心产品的研究和开发。作为秒针系统的老人，他见证了秒针系统大数据平台从 0 到 1 的过程。

据悉，秒针系统的业务是广告监测，核心产品是 AdMonitor。在 AdMonitor 的服务链路中，前端负责收集数据。每个广告会被嵌入一个发送到秒针系统域名的代码。

一旦广告在媒体端被点击，它就会把被嵌入的代码发回到秒针系统的服务器。这样，系统就知道完成了一次广告曝光。这样的一个广告业务流程主要涉及数据采集、数据存储、数据计算和数据分析技术。

多端收集数据

那么，第一个问题来了，秒针系统怎么收集数据？据刘沛介绍，在 PC 时代，大多使用 JavaScript 来采集数据。这就要求秒针系统的产品要适配每一个浏览器，包括 Firefox、IE、傲游浏览器、海豚浏览器等。据悉，cookie 是当时数据收集使用的主要技术之一。除 cookie 之外，结合 Flash。那时，几乎所有的广告都是 Flash，因为 Flash 本身是一个可执行程序，所以能在其内部编程，把监测代码放在里面，收集数据。

刘沛表示，“Flash 也有 cookie 的概念，技术术语叫 FSO。把 FSO 和 cookie 做各种联动，实现持久化。这边删了，那边能恢复；那边删了，这边再恢复。在保护用户隐私的前提下更精准地识别出一个独立用户。”

到了 2012 年，智能手机出现，Android 和 iOS App 数量不断增多，秒针系统又在 AdMonitor 产品中增加移动端广告测量能力。SDK 技术成为当时移动端数据收集的主要方式。刘沛称，“Android、iOS 都是新事物，不仅要学习新的编程语言，还要面对新技术环境进行开发。做出一款应用后，要适配厂商不同机型的不同型号。除硬件外，还要适应手机上运行的各种 App”。

举个例子，爱奇艺、优酷和腾讯视频是三大主流视频 App。SDK 要在之上运行，前期要做各种对接测试，保证运转正常。“不能让 App 死机，也不能拖慢了它的系统运转。另外，数据采集结果要和他们上报的一致。因此，每加入一款主流 App，都得做技术对接和数据测试。”他说。

2012 年 8 月，秒针系统正式推出中国第一个移动端广告加载 SDK，“很快就被加进了主流的 App 中”。

用 RAID 5 搞定数据存储难题

时任秒针系统大数据平台运维负责人任鑫琦向 InfoQ 记者透露，秒针系统的业务量当时非常大，占到全国所有广告监测流量的 60%，收集数据的服务器每天 PV 量超过 100 亿。

这么多数据，如何存储？据刘沛介绍，当时使用了 RAID（独立磁盘冗余阵列）技术，具体说是 RAID 5 技术：数据在写入磁盘时，将数据分成 N-1 份，并发写入 N-1 块磁盘，校验数据螺旋式写入所有磁盘。这样保证了 RAID 5 既有较快的访问速度，又有较高的数据可靠性。

用刘沛的话解释，“一个集群中，一份数据被切片后存在不同地方。如果一块磁盘销毁了，还能从别处恢复”。

百亿规模的数据计算问题，怎么解？

数据收集上来后，关键是数据计算。任鑫琦介绍，计算分为两类：第一类是按小时进行批量计算，这要求平台具备大规模数据的处理能力。第二类是实时计算，这要保证实时计算的可靠性，否则计算延迟，“客户看到的数据就不准确”。

据悉，秒针系统当时一天有 100 多亿数据。其单台日志服务器的承载性能是“满负荷运行，一天可以处理 4 个亿的数据”。实际中，一般按照 50% 的负载使用率，即一台日志服务器一天要处理 2 亿数据。这样算下来，大概需要 50 台日志服务器。

当数据量超过一台服务器的承载能力时，前端要分成很多台服务器做负载均衡。比如，监测代码加在各种各样的媒体上，每个广告主在多个媒体上投放，而每个媒体同时又承载多个广告主，每个媒体又有不同的广告位，“所以要把这些全部用监测代码 ID 索引好”。

刘沛称，“每个广告被曝光或点击时，这条请求是发到了哪台服务器，都要有一套统一的调度规则，保证每台服务器的承压一致，保证每台服务器分工合理。这样整体性能就会最好”。

在数据计算架构上，由于 Hadoop 当时不成熟，所以秒针系统使用了一个开源的分布式文件系统 KFS。任鑫琦说：“基于 KFS，我们没有用 Hadoop 零点几版本的架构，因为不太稳定，其管理节点不是高可用的。”Hadoop 在 2.0 版本之前，其 NameNode 只有一个，一旦坏了，整个集群就会崩溃。所以，自己维护了一套分布式计算任务的调度工具，把顺序调度和背序调度相结合，再加入一些针对局部的调度技巧和优化。

Hadoop 助力，技术能力再上一层楼

2012 年，Hadoop 发布 2.0 版本。它是一套全新架构，包含 HDFS Federation 和 Yarn 两个系统。相比 1.0 版本，它更稳定，也更成熟。因此，秒针系统开始逐渐采用。但系统迁移并不是那么容易，花了一年的时间才成功切换到 Hadoop 上。

刘沛说，一方面，版本不稳定；另一方面，所有人都是新手。出现问题找不到原因时，刘沛他们就到 Hadoop 开源社区去问，有没有人遇到同样问题。如果其他人也遇到这个问题，大家就一起讨论怎么办。而有的问题，”没有其他人遇到，就只能自己看源代码，想办法解决，解决不了的，再找别的解决方案，用别的东西来实现或自己写代码实现“。后来，随着故障的不断减少，技术人员的经验越来越丰富，迁移到 Hadoop 上的大数据平台也愈加成熟和稳定，能力变得更强。

2014 年，秒针系统达到一个新高度——实现日均最高千亿级广告请求处理能力。

3
站在秒针系统肩上的明略

2012 年，大数据的概念开始火起来。此时，Hadoop 生态圈的重要角色都已入局，包括 Facebook、LinkedIn 和 Twitter 以及 Hadoop 三大发行商 Cloudera、MapR、Hortonworks。整个生态的蓬勃发展和日益完善让 Hadoop 的市场前景变得更美好。于是，从秒针系统孵化出一个小团队，目标是做定制化大数据平台。这样，明略诞生了。

任鑫琦被抽调到明略，开发大数据平台。相比以前，开发一个大数据平台相对更容易，因为秒针系统的实践积累了一些经验，并且 Hadoop 生态发展越来越完善，有更多的工具可以利用。

技术选型

据任鑫琦介绍，技术选型的一个标志是 Hadoop 在 2.0 时提出了 NameNode HA 框架，加入选举机制和控制组件，可以实现大于 3 的奇数个管理节点的配置。当一个管理节点宕掉，马上会选出第二个管理节点，这是一个真正的高可用状态。

此前，他们虽然一直关注 Hadoop，但是却没采用，原因之一是 Hadoop 1.0、1.1 版本，只有一个核心管理节点 NameNode。后来，它引入 Second NameNode，即有一个主活管理节点，有一个备用节点，这两个节点实时同步。如果主节点服务宕掉了，备用节点会提醒并继续管理这个集群。但是，它其实并非高可用，“因为服务要切换，并且 Second NameNode 也会有问题”。

他说：“在 Hadoop 2.0 时，我们认为它达到一个基本工业级可用的状态。只要整个集群不出太严重的问题，一些细节问题，比如计算效率问题、任务调度问题等，我们可以通过修改开源代码，或调整执行任务，优化任务策略，慢慢改进。”
因此，明略就把所有的技术体系切到 Hadoop 上面。

2014 年 7 月，明略发布大数据平台 1.0 版本。据悉，1.0 版本已经相当成熟，“在集群上架的服务器系统装完情况下，网都通了，不能说完全一键部署，但是点几键就能搞定部署。半小时左右就可以完成一个大数据整个生态体系的部署和安装“。

这一年，明略数据成功中标中国银联项目，这是它在国内第一个大的企业级客户。任鑫琦称，“当时，任何成熟的（大数据）部署体系都无法做到半小时完成整个集群的部署安装和配置工作。这是我们成熟的一个标志”。

发力知识图谱

基于已有的大数据技术，明略在 2015 年继而研发出知识图谱，核心产品是 SCOPA。

自己的大数据发展蒸蒸日上，为什么要去做知识图谱？现任明略科技集团副总裁任鑫琦解释，第一，知识图谱技术源于搜索引擎，它把所有网页和内容做知识化管理，这样能更好地理解用户搜索意图，提供用户想要的内容和结果。第二，差异化竞争。他说：“如果能把大量的结构化数据，从原来简单数仓的计算一些报表，做一些查询，转换思路，从中抽出它本身的含义，组织成业务知识，更有效地组织数据，并且实现数据增值。这就可以跟业界很多做通用大数据处理的公司实现差异化。“

不过，他也坦承，基于大量数据做知识图谱有着不小的难度。

难度一，数据量非常大，这涉及到整个的实时数据处理能力，包括数据融合问题、数据冲突问题。同时，业界也没有参考的。

难度二，每个行业要建立领域知识图谱。“这与过去的专家系统很像。知识图谱的价值有多大，关键在于行业领域知识图谱的定义，每个行业都要跟业务专家探讨知识图谱的设计，同时不停地迭代，做各种改进，这很难“。

难度三，知识图谱要与一些 AI 技术相结合。知识图谱的主力场景是“从大数据里捞知识”，最基础的是实体与关系。据任鑫琦介绍，针对实体要做两件事：一是数据融合，二是给实体打上明确标签。但是实体种类非常多，怎么打标签，要使用很多 AI 技术。而关系的质量和数量决定了整个知识图谱组织形式的质量，”关系没有处理好，整个知识图谱的可用性就会降低，它的推荐、推理、交叉分析就用不起来。关系的处理也要用到很多的 AI 技术“。

更重要的是，与之前相比，知识图谱对背后支撑的技术平台要求更高。为此，任鑫琦他们在 2015 年决定做一个混合型知识图谱数据库。那么，这个混合型知识图谱要解决三个核心问题：

一是知识图谱要能实现全文式的定位式索引查询，比如根据一个关键词定位到知识图谱的某个点，这需要有一个全文的检索系统；

二是知识图谱会有很多的条件查询，比如常规的大数据计算，按照哪一个 Key 和 ID，做查询、统计分析；

三是知识图谱要有图，要完成关系的推演，包括关系存储。

这就要求既有全文，又有大数据，还有图。同时，还要把这三个存储融合在一起，做好统一索引和管理。

据任鑫琦透露，他们的解决办法是把 Elasticsearch、HBase 和图数据库 Titan 做了一致性索引的融合，包括统一的数据存储的路由、性能优化。

他说：“这个问题解决后，像怎么做业务定义、怎么描述图谱的语义等问题都可以用这个混合型数据库实现。大规模数据的融合、实时数据计算或高性能计算，这个混合型知识图谱数据库都可以用不同的特性支持每天更新，甚至是实时更新。”
明略知识图谱的技术架构

这个架构体系中，前端有数据接入、数据汇总。之后，数据清洗，进行知识图谱构建。在知识图谱里，还有实体构建、实体标签的构建、关系构建等。同时，还有图谱事件类或者行为类数据的构建。这是一整套数据处理的基础流程。

往后，把这些数据加载到图数据库。在这之上是基于知识图谱的可视化交互分析系统。

知识图谱的技术架构仍以 Hadoop 为核心，数据接入上，最早用 Flume（现已切换到 Kafka）。据任鑫琦介绍，”如果对接的是数据库系统，用的是 Scoop 1.0 和 2.0。数据抽取上来后，如果不属于日志型、库表型，用脚本方式抽取到平台上，落地到 HDFS；如果是结构化数据，直接落成 Hive 表。基于 Hive 层完成整个数据清洗、融合、转换和知识图谱构建工作，基本上用 Spark 实现整个的数据治理过程。如果是实时计算，用的是准实时 Spark Streaming 的技术选型，因为这可以减少更多相关组件的引入”。

简言之，核心图谱库的架构和支撑基本是一个以 Elasticsearch、HBase 和 Titan 三个库为核心的综合混合型数据库。

据悉，2015 年底，明略知识图谱就在国内一个省会市级公安局落地，为公安做数据分析，包括线索挖掘、团伙预警，协助公安破案。

2016 年到 2017 年，任鑫琦带领团队探索知识图谱在更多行业的落地和应用，目前，明略知识图谱在公安、金融、工业和数字城市等领域得到广泛应用。

4
回看大数据 15 年发展

2019 年，大数据进入后 Hadoop 时代，各种实时架构和组件大规模发展，大数据技术也与云原生、人工智能深度融合。

回顾大数据过去几年的发展，任鑫琦把它概括成三个阶段：

阶段一，大数据初期，以卖硬件和炒作概念为主。2010 年左右，很多大型企业受市场和宣传影响建设了大数据平台，但没有发挥出作用，因为脱离业务。
阶段二，大数据进一步发展，以分析型为主。2014 年，企业对大数据的认识进一步深入，通过收集更多数据，帮助业务决策。

阶段三，大数据发展成熟和稳定，以实时性分析为主。架构上，Lambda 架构和 Kappa 架构广受欢迎， Flink、Kafka 的使用越来越广，业务对实时性要求越来越高。“实时分析意味着实时性的决策和实时的价值，这对业务系统直接产生影响”。以银行为例，一个人申请贷款，是否放贷，银行要做大数据风控，进行实时分析。因此，这个阶段要求大数据的实时性更高，更轻量级的组件和更先进的技术。

任鑫琦说：“现在，大数据已经发展到一个精细化阶段。”

以前，人们对数据的认识是单点的、孤立的，理解很浅，比如先汇总数据，再慢慢挖掘和分析，但这可能汇总大量无效、无关的数据，这些数据对整个数据体系的业务价值会有负面影响。这些年，人们对数据有了新认识，比如数据并非越多越好，要规划好数据怎么存、怎么用、怎么产生更大价值。这就要求大数据越来越精细化和精准化！

5
写在最后：

从 2003 年谷歌的“三驾马车”到现在，大数据技术历经十余年发展，我也见证了它从风口到落地再到大规模的普及应用。2007 年，就投身大数据行业，从零到一研发出一套成熟的大数据平台，解决了大数据存储和大数据计算问题。此后，基于秒针系统积累的大数据能力，明略成功研发出知识图谱平台，并在行业里得到广泛应用。今天，大数据技术正与云原生、AI 技术相融合，数据驱动成为共识，作为行业先行者，明略一直深耕技术，从未止步，让数据产生更大价值、发挥更大作用。

PS：推荐个很不错的SpringBoot+Vue前后端分离项目实战自学课程 B站：BV1zN411f7ha

千亿大数据处理能力是如何炼成的？相关推荐

重磅！共掘千亿大数据市场智领云2021年合作伙伴招募计划正式启动
2021年3月26日,在春暖花开,万物复苏之际,智领云将在武汉光谷凯悦酒店举办"数据驱动智领未来"合作伙伴沙龙,我们诚邀您来参加本次会议,了解智领云领先的产品.技术理念及合作伙伴 ...
大数据高地，这样炼成！
游客行走在贵州贵安新区,仿佛来到了一个"云上的城市". 为守住青山绿水,走出一条新的经济发展道路,贵州将大数据领域作为经济增长点之一,一直在发力--从最接地气的数据中心.呼叫中心, ...
想创业成功？先看看这25家千亿美金的公司是如何炼成的！
如果将世界上所有1000亿美元市值以上的企业罗列出来,这个名单将要很长.如果从1900年开始做一个划分,我们看到,绝大部分的欧洲顶尖企业都消失了,而美国的顶尖企业绝大部分仍然保留在榜单上.这是什么样的 ...
大数据权威是怎样炼成的
满脑子自由,无所不知,知识之于他就像一颗红通通的太阳,在他炙热的话语中,好像说了一整个浩瀚宇宙的故事:细致精湛的金丝框眼镜,完全藏不住渴切的灵魂,怎么有人可以对这个世界如此好奇,像和宇宙宣战的心跳声如 ...
一个大数据应用是如何炼成的？
经历了多年的BI专题应用建设,有幸能在一个传统企业里探索大数据应用的建设过程,发现了很多不一样的地方,获得了不同的感受,在此以一个真实的案例的建设过程来品味其中的不同,也许能获得一些启示. 课题是怎么 ...
轻量型模型比肩千亿大模型，新一代中文语言模型孟子，刷新CLUE纪录！
转自:机器之心近日,澜舟科技 - 创新工场团队与上海交通大学.北京理工大学等单位联合研发的中文语言模型-孟子轻量型模型,超越腾讯.搜狗等公司,在中文语言理解评测 CLUE 榜单上登顶第一,刷新业界记 ...
轻量型「孟子」模型比肩千亿大模型！AI大牛周明率队刷新CLUE新纪录
AI 科技评论报道编辑 | 陈大鑫近日,澜舟科技-创新工场团队与上海交通大学.北京理工大学等单位联合研发的中文语言模型-孟子轻量型模型,超越腾讯.搜狗等公司,在中文语言理解评测CLUE榜单上登顶第 ...
全球首个知识增强千亿大模型鹏城-百度·文心发布
作为当前人工智能发展的重要方向,预训练大模型已成为 AI 领域的技术新高地. 12月8日,鹏城实验室与百度联合召开发布会,正式发布双方共同研发的全球首个知识增强千亿大模型--鹏城-百度·文心(模型版本 ...
DeepSpeed Chat: 一键式RLHF训练，让你的类ChatGPT千亿大模型提速省钱15倍
DeepSpeed is a deep learning optimization library that makes distributed training and inference easy ...

千亿大数据处理能力是如何炼成的？

千亿大数据处理能力是如何炼成的？相关推荐

最新文章

热门文章