面对80%的非结构化数据，如何成为20%的数据分析专家
2019-12-05 来源：raincent
作者：贾凯强 来源：InfoQ
二八定律，一个普适与众多领域的定律，在开发行业中一样适用。
据 IDC 预测，2018 年到 2025 年之间，全球产生的数据量将会从 33 ZB 增长到 175 ZB， 复合增长率达到 27%，其中超过 80% 的数据都会是处理难度较大的非结构化数据。但开发者的数量是有限的，处理数据的能力也一样是有限的，更何况，全球能够真正能称为“数据处理专家”的开发者，也只有那 20% 的精英而已。
以人处理数据，数据量一旦爆发就必然面临能力跟不上发展速度的瓶颈。因此，技术迭代和数据智能化几乎是所有开发者必须要走的一条路。数据处理技术的发展迭代速度很快，从存储到实时处理再到智能化升级，无一不是必修课。那么如何在数据处理的大道上走的更快更稳呢?11 月 25 日，在 T11 2019 数据智能峰会上，InfoQ 采访到了在大数据领域有着丰富经验的两位 TalkingData 技术专家，来看他们如何看当下大数据发展风云。
实时非结构化数据需求，催生数据湖之争
数据与 AI 技术的发展一脉相承。尤其是在当下，在数字化程度较高的行业中 AI 技术正在迅速扩张，进而发展到整个价值链中。据分析，到 2030 年的时候，AI 技术将会带来 26% 的 GDP 增长，同时会成为越来越多企业提高生产力的首要战略。与之相对应的则是企业对数据的需求逐步增加，尤其是实时数据方面，其所占比例将会从 17% 增长至 30%。
而在这种情况下，传统的数据仓库所存在的一些问题将会进一步的暴露出来。传统意义上，数据仓库主要是用来存储有限的一部分经过加工并精心抽取剥离出来的数据。但是由于抽取剥离过程的存在，数据仓库中的数据很难做到实时可见，数据产生后要经过较高的时延才能从数据仓库中利用起来。
TalkingData 研发副总裁阎志涛回顾了数据仓库诞生的初期。数据仓库本身是从甲骨文的结构化数据库发展而来的。相比之下，数据库存储的数据量较少，可以对少量的数据记录进行查询、修改;而数据仓库则可以支撑企业所有级别的决策制定过程，是依照分析需求、分析维度和分析指标来设计的，可以用于数据挖掘和数据分析。数据仓库的数据从原有分散的数据库中的数据抽取而来的，主要面向特定主题的商业环境。但是，数据仓库对数据修改的支持度很低，而且当主题不一致时，面向数据的完整性和统一性就无法获得保障。只不过在当时固定流程条件下、应用在稳定型的商务场景中，数据仓库确实能起到很大的作用。
而随着数据量的增加及数据类型的变化，传统的关系型、结构化数据已经不再是主流，很多非结构化的数据，比如视频和语音等占据数据总量的比例越来越多。原来的数据仓库已经很难继续支撑，因此越来越多的企业希望把原始数据以真实的初始状态保留下来。在这种需求的推动下，数据湖的理念便开始成形，其可以把数据保存在原始状态，以便于企业从多个维度进行更多洞察。
在 TalkingData 看来，数据湖的理念是技术发展的选择。但这一技术在操作落地时有很大的难度，因为一方面要进行具体的数据分析操作，同时还要进行原始数据的洞察，甚至还会要求快速的计算其他正在分析的目标……这些难点并不容易突破，数据湖未来的路还很长，其形态也将会有很多变化。
三大问题困扰，导致数据湖落地艰难
既然数据湖的理念很有价值，就一定会有前沿探索者进行落地实践，那么在落地过程中会面临哪些实际难题呢?
TalkingData 首席架构师黄洋成对此颇有心得。他提到，数据湖的概念早在 2011 年就作为数据仓库的补充而被提出，在近些年的探索之中逐步明晰的。数据湖本身是一个中心化的存储，能够存储任意规模的结构化与非结构化数据。数据湖相比数据仓库有很多的优势，但大多是在理想状态下的，一旦执行起来还有很多技术挑战。
第一，数据湖的数据可能并不会真正做到实时。在业务环境下，如果把所有数据都放到数据湖里，那么从数据湖直接调用数据的过程可能比原来数据仓库更慢，因为从数据湖中提取出来的数据，依然要经过清洗实现标准化后才能更好的利用。具体能否达到需求的低时延效果，还要根据具体应用场景来进行判断。
第二，把所有的原始数据都放到数据湖，可能会提升数据的使用难度。对于大型企业而言，业务内容丰富，操作系统繁杂。数据使用者往往期望所有的数据都能平民化，就像数据仓库提供的那种经过了精心处理的数据，能够轻松调度和使用来实现对业务的指导。如果是数据湖提供的原始化数据，其本身是很复杂的，数据专家进行理解和处理时或许难度适中，但大多数的平民用户能否消化、理解并利用这些数据，将会是一个巨大的疑问。
阎志涛还提出了第三个挑战：数据治理问题。数据仓库里的数据是经过过整理、清晰易懂的。但数据湖的概念是不经处理直接进行堆砌，那么数据湖就有可能会变成“数据沼泽”，筛选难度会变大。当然，数据湖的优势就是数据可以先作为资产存放起来，问题就在于如何把这些数据在业务中利用起来。当部署了数据湖之后，数据治理问题将会接踵而至，比如从数据湖到数据池塘，如何将数据进行分流、池塘的数据如何进行整理等。
总体来看，数据在变，大家对数据的认知也在变化。在数据仓库时期，数据是经过加工的副产品;而数据湖时期，数据就是对企业非常关键的资产，这份资产带来的挑战是将来要如何更好发挥数据的价值，大部分公司都奔跑在从数据里挖掘商业价值这条路上。
流计算发展引入 Flink 业务实践
数据湖的这些弊端并非完全无解。存储技术在迭代，计算方式也在不断变化中。随着非结构化数据的增加，企业对数据处理实时性要求越来越高，计算方式也从以 Hadoop 为核心的离线计算转向到以 Spark、Storm、Flink 为核心的实时计算，这些技术也可以使数据湖能够实时接入和处理业务数据。
阎志涛表示实时计算确实是最近几年发展的焦点。以 Flink 为例，TalkingData 在 2015 年左右就开始了解和尝试使用 Flink。但在最初的两年里，Flink 整体发展并不快，落地的过程中，也遇到了维护以及扩充能力的成本不断增高的考验。2016 年，阎志涛前往美国参加大会时与跟 Flink 的 CTO 进行过一次深入会谈，在那次谈话中他感受到 Flink 整体成熟度在逐步提高，也坚定了继续发展的信念，因此也决定在更深入的调研后将其引入到 TalkingData 的平台业务中。
2017 年，TalkingData 将 Flink 应用到自研的线上的分析平台的流式处理过程，实现了真正的落地应用。而在那之后，Flink 的应用场景也越来越多，截止到目前，TalkingData 线上的分析平台里已经实现了多方面的 Flink 落地，包括游戏分析、应用统计分析、移动广告监测产品中的流式处理过程等都是使用 Flink 来做的。当然，大规模的落地也离不开开源社区的帮助，在执行的过程中遇到一些问题时，与社区密切进行问题的反馈会让落地过程事半功倍。
以平台建设拉通大数据与 AI 链路
提升大数据处理效率，AI 技术是必不可少的重要手段，而提升 AI 模型的精准度，大数据又是赖以生存的必要条件。二者如同鸡生蛋、蛋生鸡一般密不可分，但二者又毕竟都是各自独立的单独个体。那么，在大数据与 AI 技术之间有哪些异同呢?二者之间的技术链路又当如何打通呢?
黄洋成首先解读了 AI 和大数据之间的关系。他认为可以将 AI 看作是一种大数据处理方式，只不过 AI 的技术模式和传统数据处理模式有一定差异，尤其是在计算密集性层面，与传统的大数据处理和分析应用有着本质的不同。
其次，计算量和工作量的分布不同。技术应用流程一般会分成训练和生产上线这两个阶段。传统的大数据支持流程，本身的开发相对属于轻量，但生产上线消耗的资源会更多。而 AI 的开发难度较大，需要探索各种各样不同的工程以及各类建模方法并进行模型的参数调整。但上线以后总体来说它的运行会更轻量一些。
第三是对底层计算资源需求不同。以深度学习为例，其不只在图像和语音场景下广泛使用，在传统的推荐广告、营销优化等场景下，深度学习技术也被用来增强传统机器学习能力。而深度学习在训练和上线时会依赖于 GPU 或者 FPGA 等新型计算硬件资源支撑;大数据则是以 CPU 为主。这就使得整体计算资源在管理和分配上也存在一定的不同。
二者打通的解决方案目前有很多的尝试，主要思路是引入 Docker、Kubernetes 等容器技术来进行资源分配，并基于 Kubernetes 来做资源的调度和优化，根据底层的每一个容器或者计算任务，针对性的将计算资源动态分配到合适的机器节点上。
阎志涛也对大数据和 AI 这两大技术链路进行了全面解析。他认为这两个链路本身都是完整的，从解决业务问题的角度而言是非常类似的。但是从技术角度来看，无论是模型的训练、数据科学家的介入、模型版本的控制、传统的大数据分析还是新增的 AI 任务等，都会看起来有些不同甚至冲突。但如果从解决问题的角度来看，二者最终的产出都是在业务线上做大规模的部署，进行密集性计算，最终的商务分析、业务结合、自动化运营中以及数据分析等产出的角度也是一致的。
从人员方面来看，AI 人才主要是数据科学家的团队，主要使用的是 Python、R 等语言和数据科学家的技术能力以及思维方式。TalkingData 以往主要是面向大数据技术域，大数据行业习惯以工程落地为主，与 AI 产业通常需要紧密合作。好在技术和平台不断演进，TalkingData 也在不断的投入 AI 方面的平台建设，包括对数据科学家的支持等，让数据科学和大数据技术之间距离越来越近。让 AI 与大数据更好的结合，为未来的数据智能化发展铺平道路。
版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点！
本站所提供的图片等素材，版权归原作者所有，如需使用，请与原作者联系。
