武汉的开发者们注意啦!AI技术战略、框架以及最佳实战尽在Azure OpenAI Day 了解详情
写点什么

一个数据挖掘者的自我修养:数据科学家头衔很光鲜,但全栈工程师才是本质

专访索信达首席科学家张磊博士

  • 2020-07-20
  • 本文字数:6151 字

    阅读完需:约 20 分钟

一个数据挖掘者的自我修养:数据科学家头衔很光鲜,但全栈工程师才是本质

真正的革命并不在于分析数据的机器,而在于数据本身和我们如何运用数据。

——《大数据时代》维克托·迈尔-舍恩伯格


二十年,是一个什么概念?


对于大数据领域来说,过去二十年经历了从新兴到炒作巅峰再到实质生产高峰期的过程,并开启了一次重大的时代转型。被业界广泛认可的“大数据”定义由著名咨询公司 Gartner 的高级分析师道格拉斯·兰尼 (Douglas Laney)在 2001 年提出;大数据经典框架 Hadoop 则诞生于 2006 年;如今,大数据技术已经从 Hadoop 推动的第一代向更智能、更实时、面向交互的技术方向转变。


而数据挖掘的历史比大数据要长得多,在数据量还远远没有今天如此庞大的时候,人们就已经想方设法从中挖掘价值。对索信达首席科学家张磊博士来说,过去二十年是见证数据挖掘和分析技术与应用高速发展的二十年。



张磊从读研开始进入数据挖掘和分析领域,博士毕业后一直在提供企业级大数据解决方案的知名厂商工作,从 Teradata 到 IBM、SAS,他参与了横跨运营商到金融行业的数十个项目,有着丰富的从业经历。今年年初,张磊选择加入专注金融数字化服务的索信达,担任首席科学家,希望推动国内金融大数据行业朝着“拥抱开源、自主可控、信息融合、智能化”的方向前行。经过大量项目实践的磨练,他对于 To B 大数据业务和技术方案有哪些经验和独到的思考?他怎样看待金融大数据的过去和未来?做企业级大数据面临哪些难点和挑战?大数据人才团队该如何搭建?带着这些问题,InfoQ 对张磊博士进行了独家专访,一探这位 20 年资深数据人对 To B 大数据的思考。

数据分析的变与不变

翻看张磊的履历,可以看到他接近一半的人生都在跟数据打交道。唯有一段,本科毕业后在中科院等离子体物理研究所担任研究实习员的经历看似与数据无关。其实,正是这段经历让张磊有了跟数据挖掘的“第一次亲密接触”,这比他接触到数据挖掘这个专业术语还早了四年。


1993 年大学毕业后,张磊去了中国科学院等离子体物理研究所,在理论室工作,工作内容是数值计算,也就是协助理论室的老师们完成计算机上的各种数值分析和模拟工作。当时研究室的朱思铮老师找到他,希望能用神经网络来建模分析托卡马克装置中等离子体的位置和形状,于是张磊就一头扎进了 BP 神经网络算法之中。他清晰地记得,当时在图书馆里唯一能找到的一本教科书是焦李成老师编写的《神经网络系统理论》,在这本书的帮助下,他理解了 BPNN 算法,实现了 C 语言编写的程序,还尝试解决了 BPNN 算法中的一些问题(陷入局部最优、隐层神经元数量等),最终和朱思铮老师一起把研究结果写了篇文章发表在 1996 年的《计算物理》杂志上。


1997 年读研的时候,张磊选择了数据挖掘方向,后来又在中科院计算技术研究所攻读数据挖掘与信息检索方向的工学博士,师从国内数据库权威王珊教授和杜小勇教授。


从初次“触电”到现在,二十多年过去了,幸运的是,对张磊而言数据挖掘一直是件很有意思的事情。其中 1999~2002 年的读博时期和之后在外企工作的十多年对他尤为重要:前者让他更体系化、更有针对性地博览数据挖掘领域的科研成果,后者则让他在大量项目实践中不断去验证和思考什么才是真正合理有效的挖掘方式。


数据挖掘的本质即从数据里找规律,张磊认为这个本质从未改变,改变的是找规律的方法。


回顾数据分析的发展史,从十九世纪下半叶高尔顿、皮尔森开创描述统计学,到 1956 年人工智能和机器学习的诞生与发展,再到 2006 年深度学习的异军突起,人们一直在尝试各种方法努力从数据中发现隐藏的规律。而近些年计算能力的飞速提升和大数据的崛起,推动数据挖掘方法和分析算法不断进化。


以业界常用的一些算法来说,二十年前传统简单的 BP 神经网络似乎已经走到尽头开始没落,二十年后 AlexNet、VGG16、Inception、RNN、LSTM、GAN 等深层神经网络模型层出不穷让人眼花缭乱;二十年前业界还在为决策树在行业应用中的简洁有效而欢欣鼓舞,二十年后随机森林、GBDT、XGBoost、LightGBM 已经实现了全面超越;二十年前大家还在使用向量空间模型、朴素贝叶斯、SVM 来分析文本,二十年后 BERT、XLNet 已经大行其道。


虽然数据、算力、算法三个因素对于人工智能新一轮浪潮的推动同样功不可没,但张磊认为,以深层神经网络为代表的深度学习算法并未超越传统神经网络的基本框架,算法的发展还是落后于数据发展的速度,当然终究还是会水到渠成实现同步。

金融大数据演进的四个阶段

每一朵浪花,都有可能变成泡沫,也有可能形成大潮,大数据属于后者。经过二十年的演进,大数据已经脱离技术炒作巅峰,进入实质生产的高峰期,并进一步成为其他技术(如人工智能)的底层支撑。


据工信部、赛迪网等相关数据,2020 年国内大数据市场总体预计达到万亿元规模,硬件、软件和服务是其中的三大部分,而对分析人才和分析服务的需求最为迫切。


除了互联网行业,金融业可以说是跟进和采用大数据、人工智能等前沿技术最快的行业。无论是国外还是国内,金融行业的数据分析成熟度都位居前列。从银行、保险到证券业,大数据平台已经成为企业越来越倚重的系统,数据中台的呼声让它不断拉近与核心系统的距离。从数据大集中、数据仓库、云平台、数据湖,到商业智能、数据挖掘、人工智能,再到个人金融、公司金融、风险部、客服中心,大数据的架构、技术和应用已经逐步在金融业特别是银行得到普及。


对于过去十年金融业大数据的发展和演进,张磊认为可以借鉴托马斯·H·达文波特教授对数据分析成熟度的划分方式将其划分为四个阶段,他用自己的话对其做了翻译,分别是星星之火(Localized Analytics)、开始燎原(Analytics Aspirations)、江山一统(Analytic Companies)、傲视群雄(Analytic Competitors)。这四个阶段形象地展示了企业或行业在数据分析应用上的发展阶段,从早期少量人员开始使用数据分析的星星之火,到部门级搭建一些分析系统,再到整个企业形成全面统一的分析体系,最终的目标是将分析作为核心竞争力的傲视群雄。而目前国内的金融企业大多处于第二阶段向第三阶段转变的 2.5 阶段。

To B 大数据的经验和思考

在很多人看来,To B 大数据都是脏活苦活累活,入行以来与众多金融企业、银行打过交道的张磊却有不同看法。


从技术视角出发,张磊觉得 To B 的大数据分析其实比 To C 的好做。首先数据量要小得多,不会因为性能压力而放弃必要的分析尝试;另外,数据质量也比较可控,很少会怀疑数据的来源是否可信,这些都让 To B 的大数据分析相对简单。在他看来,做 To B 大数据最大的障碍还是在企业文化形成的壁垒上,有些企业多年来已经养成了依赖人的经验而不相信数据的习惯,部分岗位人浮于事提不出对企业真正有价值的业务问题,这些都会给数据分析项目蒙上阴影。


正处于新时代的转型中场,金融业数据分析难免遇到新问题,比如引入了更多外部数据不知道怎么利用,看到互联网企业的业务创新却不知道如何应对。To B 大数据到底该如何做?基于在大量数据分析项目中的实践,张磊分享了一些自己的经验与思考。

数据应用方法论

没有方法论就像“盲人骑瞎马,夜半临深池”,越努力反而结果越差,因为可能走在与目标相反的方向而不自知。


金融业经过最近二十年在数据应用上的丰富实践,已经形成了很成熟的大数据应用方法论,无论是系统架构、应用框架,还是分析平台和团队建设等方面,都有成熟的体系化经验可供借鉴。张磊将其总结为如下几条:


  • 坚定的心:时刻坚持业务导向,业务目标永远是大数据应用的终极方向;

  • 融入血液:形成“从数据中挖掘价值,数据驱动业务”的企业文化,只有从管理层到一线员工形成数据价值的统一认知,才能真正把数据用起来;

  • 锻炼肌肉:通过培训竞赛知识分享,提升员工的数据分析能力,只有为分析人员赋能之后,才可以利用数据为企业赋能;

  • 数据质量:一方面要强化数据质量管理,好的数据才能分析出有用的结论;另一方面要对企业的数据有信心,有人总担心自己的数据太差分析不出结果,大量的实践证明金融业的数据可以开花结果;

  • 稳中有进:金融业缺乏互联网企业允许试错的基因,注定了系统架构和业务应用等规划都要一步一个脚印去走,以成熟技术为基础来建设,同时适度进行创新;

  • 思辨精神:不盲从于算法的神奇,不拒绝实用的查询统计,没有包打天下的终极算法,但是可以找到最适合企业自身的分析套路,注重分析所带来的效果以及分析思路的合理性;

  • 大道至简:最准确的模型未必就是最好的模型,它常常是昙花一现的过度拟合,真正能长期稳定有效的模型总是简单易懂的,坚持奥卡姆剃刀原则,坚持数据分析的极简主义。

问题和数据比算法更重要

百货商店之父约翰·沃纳梅克(John Wanamaker)曾说过一句在数字化营销领域赫赫有名的话:“我知道花费在广告上的投入有一半是无用的,但问题是我不知道是哪一半。”


数据分析包含三个要素:问题、数据、算法。其中,业务问题和业务目标是数据分析的起点和终点,数据是分析的基础和原料,算法是用于加工这些数据原料的工具。大部分项目的成功,这三个要素缺一不可,而前两者更是重中之重。在张磊以往参与建设的那些项目实施中,给他留下深刻印象的并非一个个神奇的模型,而是一些大家耳熟能详的名词:业务问题、数据加工、模型评估、应用策略。


找到真正对企业有价值的业务问题,制定合理可行的具体目标,及时提供真正可用的高质量数据,加工出更具业务含义的数据特征,这些工作都依赖于业务岗、数据岗和分析岗的紧密合作来完成。

数据团队角色分工

张磊曾经与咨询公司一起帮国有大型银行规划其分析团队,国外领先实践中也把这个团队称为“业务分析能力中心”(BACC)。这个团队的理想组成是分三类岗位:业务岗、数据岗和分析岗,人员配比通常是 2:3:5,而分析建模的工作量占比通常不超过项目总工作量的 10%。业务岗是分析团队和业务部门沟通的桥梁,通常是从业务部门或分行抽调的业务骨干,他们熟悉业务流程和业务问题,能够把分析团队的成果与业务应用结合起来;数据岗是传统的数据库管理和 ETL 岗位,要求熟悉数据库理论与技术、SQL 语言玩得滚瓜烂熟、ETL 脚本稳定高效;分析岗的人力配比最高,但并非每个人都是建模高手,实际上这部分人更像是万金油的角色,除了熟悉常用的算法,还要同时能承担业务岗和数据岗的部分工作,换句话说,一旦需要他们就可能变成数据岗或业务岗。


张磊强调,有太多分析建模人员把自己视为高端人才,只愿意做算法建模的工作,不愿意做数据整理这些体力活,不愿意深入了解业务知识,就如同一位厨师既不愿意了解食材的特性,又不愿意了解顾客的口味,怎么能指望他做出一道美味佳肴呢?数据科学家这个头衔很光鲜,但全栈工程师才是它的本质。因此,从职业发展的角度来说,岗位轮换是一项很好的制度,一方面能让员工掌握更多更全面的技能,另一方面也有利于团队的稳定。

开源的挑战

开源正在吞噬软件,对金融行业也不例外。聚焦金融数字化转型这些年,张磊见证了技术的变迁,在他看来,如今企业级大数据解决方案所采用的核心技术和架构,和过去相比已经有很大的不同。其中最为突出的一点是开源的吸引力越来越大,企业在技术选择上逐渐向开源倾斜。


  • 十年前:金融行业还是数据仓库的天下,屈指可数的几家国外知名厂商牢牢占据了这部分市场份额,十大数据主题/ETL/报表查询和 OLAP 是数据分析平台建设的核心,以 MPP 架构为主流,分析软件采用 C/S 架构;

  • 十年后:数据仓库的地位日趋微弱,Hadoop 集群(Spark、Flink 可视作 Hadoop 生态圈的一部分)成为数据管理平台的核心,以 Python 为代表的开源软件引领分析工具的潮流,技术的选择强调生态圈,分析结果的应用更多基于 Web 服务调用。


从 2006 年 Doug Cutting 开源大数据经典框架 Hadoop 到现在,大数据领域已经形成了一整套相当活跃的开源生态,有非常多成熟的开源工具。张磊坦言,开源给商用解决方案带来了很大的挑战,这种挑战态势已经从十多年前的“小荷才露尖尖角”变成了现在的“楚汉相争”。


十年前张磊与大部分银行客户交流,偶尔能碰到一两个用户使用开源的 R、MySQL 等工具来做数据分析;最近一两年在国有大型银行的分析团队里,使用 Python、Spark 等开源工具来做数据分析的甚至占到了一半。


张磊认为开源日益强大最主要的原因还是在于“生态圈”。正如乔布斯借助 iPhone 让苹果公司再次辉煌一样,全球亿万用户成为 iPhone 忠实粉丝的关键原因并非手机外形酷炫和性能强大,AppStore 所打造的生态圈才是真正能圈住用户的那个圈子。如果你想到和没想到的功能,都有人给你开发出来,而且还有越来越多的人加入开发的行列,就像拥有数百万人为你提供支持,这是每位用户梦寐以求的情景。对于数据分析人员来说,开源社区带来的也是这种效应。当你碰到一个业务问题不知如何下手时,当你遇到一个程序 Bug 不知如何解决时,当程序运行太慢不知道如何提高性能时,当你碰到中文乱码如读天书时,当你需要一个新的软件功能时……你都能很轻松地通过搜索引擎、GitHub、Kaggle 等网站快速得到解答。解决问题变得格外快捷和方便,这是使用商用解决方案无法比拟的。


生态圈一旦打造起来,就会出现强者愈强弱者愈弱的场面,而且通常很难扭转。众人拾柴火焰高,好汉架不住群狼,仅靠一两家商业公司是无法和庞大的开源社区力量抗衡的。


那提供企业级数据解决方案的公司要怎么去应对开源带来的挑战呢?人们面对挑战常常会采取两种对策:要么打,要么逃。在张磊看来,还有第三条路,就是化敌为友。为什么不可以考虑将商用解决方案与开源平台相融合呢?接受开源发展的潮流,取长补短,商业公司依然会有自己的容身之地。


张磊目前任职的索信达就一直紧跟开源技术的发展,无论是 MySQL、Hadoop 等开源数据平台,还是 TensorFlow、PyTorch 等开源分析框架,都融入到其对外提供的一系列解决方案之中,覆盖精准营销、规则引擎、场景库、模型工厂、客户微细分、可解释机器学习等多个领域。此外,今年索信达积极投身国产数字化生态,与华为积极展开合作,在华为云 ModelArts 平台上发布了首个金融营销模型——客户微细分,树立行业标杆并得到了华为和头部金融客户的认可。

未来展望

二十年间,大数据已经从星星之火变成燎原之势,而“新基建”会让大数据的火越烧越旺。


张磊表示,“新基建”和大数据行业密不可分,要实现信息融合,大数据基础设施和数据生产必不可少,要实现智能化,也需要基于大数据的深入分析。因此,随着“新基建”等国家战略的推行,大数据行业会越来越重要,发展也会越来越快,高速度和高加速度都是可预期的。


他强调道,大数据技术未来还有很大的发展潜力,现在的一些技术过于强调应用层的表现,模型算法变得越来越复杂脆弱,根源在于底层理论体系需要新的突破。“欧几里得的《几何原本》在上千年内未有发展,似乎已经足够成熟,笛卡尔把代数和几何相结合,立刻为世界打开另一扇窗。底层理论的突破才是真的突破,才能带来真正革命性的变革。”


对于这些年大数据领域涌现的各种新概念,张磊认为很多只是一种发展趋势,并不意味着实现了质变。比如这两年格外火爆的中台,其实是运营端和分析端发展到一定阶段的彼此融合,并不会带来翻天覆地的变化,也不是包治百病的灵丹妙药。对于符合发展趋势的新概念,当然要了解熟悉和探索,但真的要在金融行业变成现实完成华丽的转身,还有很长的一段路要走。




想深入了解人工智能在银行业的应用,张磊博士将在《人工智能与银行业》的直播中带来更多精彩分享,点击此链接预约线上直播。


2020-07-20 14:002672
用户头像
蔡芳芳 InfoQ主编

发布了 778 篇内容, 共 488.2 次阅读, 收获喜欢 2745 次。

关注

评论

发布
暂无评论
发现更多内容

某业务升级5.0解决慢SQL问题

TiDB 社区干货传送门

实践案例 故障排查/诊断

SQL只是CRUD?

TiDB 社区干货传送门

TiDB 底层架构

招募体验官!构建实时数仓 - 当 TiDB 遇见 Pravega

TiDB 社区干货传送门

写冲突场景下的悲观/乐观事务模型选择

TiDB 社区干货传送门

实践案例

TiDB 集群的可用性详解及 TiKV Label 规划

TiDB 社区干货传送门

TiDB 底层架构

TiKV 集群部署 注意事项

TiDB 社区干货传送门

【TiDB DevCon 2020】金融专题论坛演讲视频汇总

TiDB 社区干货传送门

几分钟读懂 TiDB HTAP

TiDB 社区干货传送门

TiDB 数据库开发规范

TiDB 社区干货传送门

tidb开发规范

TiDB 社区干货传送门

【精选实践】TiDB 在马上消费金融核心账务系统归档及跑批业务下的实践

TiDB 社区干货传送门

实践案例

【技术专题】如何做数据库选型?

TiDB 社区干货传送门

实践案例

常见问题排查之 -- DM 主键冲突的原因及排查思路

TiDB 社区干货传送门

tiup目录冲突检测不健全导致的节点被destroy问题以及解决

TiDB 社区干货传送门

PD 分配 TS 的 QPS 上限揭密

TiDB 社区干货传送门

【TiDB 4.0 新 Feature 原理及实践】 Dashboard 触手体验

TiDB 社区干货传送门

TiDB 5.0 异步事务特性体验——基于X86和ARM混合部署架构

TiDB 社区干货传送门

AskTUG 论坛迁移实战:Discourse 从 PostgreSQL 到 MySQL 到 TiDB

TiDB 社区干货传送门

移动云基于 TiDB 实现 serverless 数据库服务

TiDB 社区干货传送门

NewSQL 在微众银行核心批量场景的应用

TiDB 社区干货传送门

实践案例

【TiDB 最佳实践系列】开发 Java 应用使用 TiDB 的最佳实践

TiDB 社区干货传送门

实践案例

TiDB at ZaloPay Infrastructure & Lesson Learned

TiDB 社区干货传送门

【热门问题】关于近期签名过期的处理合集

TiDB 社区干货传送门

如果你的 kubelet 运行在容器中,使用 local static provisioner 要注意一个问题

TiDB 社区干货传送门

【TiDB 最佳实践系列】乐观锁事务

TiDB 社区干货传送门

实践案例

基于阿里云ECS部署的TiDB 2.1.14升级到4.0.0-rc实践

TiDB 社区干货传送门

管理与运维 安装 & 部署

从内容角度看看TUG小伙伴都在关注些啥

TiDB 社区干货传送门

版本测评

TIDB 3.0.5 性能压测

TiDB 社区干货传送门

数据库架构选型

Flink + TiDB,体验实时数仓之美

TiDB 社区干货传送门

实践案例

日本大型移动支付软件 PayPay 的 TiDB 迁移实践

TiDB 社区干货传送门

从抓包发现并解决 Navicat 编辑 TiDB 视图报错的问题

TiDB 社区干货传送门

实践案例 TiDB 底层架构

一个数据挖掘者的自我修养:数据科学家头衔很光鲜,但全栈工程师才是本质_文化 & 方法_蔡芳芳_InfoQ精选文章