未来数据开发技术方向，我认为有三个，首先是流批一体成为主流开发模式，其次是代码自动化技术走向成熟，第三是 OLAP Cubes 终将衰落。
先说说我看到的数据开发的历史。
从单机 OLAP 到 Lambda 到Kappa 的演进，数据链路上的问题、数据计算层面的问题得到了很好解决。那未来一切皆流式，一切皆实时是否可行？是否经济？我们的数据架构还存在什么问题？列举几个数据领域常见的问题：
数据产品实时和离线模块同一指标数值不同，因为指标计算离线、实时是单独开发，单独存储的，口径有差异；
同一口径的数据指标，需要离线和实时各开发一份代码，因为彼此的计算引擎不同，编程范式不同，即使都用 SQL 编写，也很难完全复用；
离线数仓和实时数仓彼此独立存在，带来双重的存储和维护成本，因为离线和实时任务有不同的数仓分层及存储体系。
要解决这些问题，需要实时和离线计算的融合，称作流批一体架构。这里说的融合不是用实时计算替代所有离线计算，离线和实时计算有各自适用的场景，而是对于数据的下游应用来说，不用去关注数据来自实时还是离线，对于数据开发工程师来说，不用去关注开发的是实时还是离线代码，实时、离线只是调度层面的概念。融合过程根据现状的不同可以分两个阶段，第一是存储统一，第二是代码统一。
这个阶段，实时和离线任务还是单独开发和执行的，但不再区分存储介质，比如常见的离线结果存 MySQL，实时结果存 HBase 方案，改成统一存储到海量数据高频读写皆优的存储计算引擎，如 Apache Kudu & Impala，Alibaba Hologres 等。存储统一可以解决下游应用需要通过不同逻辑对接实时、离线数据的问题，例如统一后，同一张表取当天的数据就是截止目前为止的实时数据，取昨天的数据，就是 T-1 的离线数据。另外，也为后续第二阶段的代码统一做了铺垫，因为已经做到实时、离线统一存储，代码统一过程对下游是无感知的。
实时和离线代码被统一为一份，通过调度设置来区分是实时还是离线批处理。这个阶段存在两个挑战。
第一个挑战是对计算引擎的，需要实时计算引擎兼具批任务执行能力，且做到流批 API 的统一，这块能力在 Flink Roadmap 里，Blink当前已经支持的不错。
第二个挑战是对数仓架构的，实时和离线数仓需要统一，存在两个问题:（1）新流批一体任务如何和所替代的老的离线任务保持统一的上游依赖？这个问题在存储、计算分离的计算平台架构下比较容易解决，打通元数据，不同计算引擎访问统一存储；（2）流批一体任务依赖的上游任务可能未做流批一体，比如为了更精准的反作弊，需要独立开发离线任务通过长周期历史数据做计算，即如何解决流批一体任务依赖双重上游数据输入的问题？这个问题可以通过对该上游任务的结果表在 Schema 层面做统一来解决，如构建镜像表，根据调度模式的不同来映射依赖上游哪份数据。
代码自动化，有两个方向，一是代码的自动生成，二是代码的自动优化。
数仓模型设计的实施工作流包含业务和需求调研，架构设计，规范定义，数据建模四个过程。
架构设计指以维度建模为理论基础，基于业务和需求调研的结果，进行整体数仓设计，包含确定数据域，定义每个数据域下面的业务过程及相关维度两件事情；
规范定义指定义指标体系，包括原子指标，业务限定如修饰词、时间周期，以及派生指标，由原子指标和业务限定组合而成；
数据建模主要包括维度及属性的规范定义，维表、明细事实表和汇总事实表的模型设计。
现在已经有数据研发平台可以做到可视化数据模型设计：配置化定义维度、业务过程和事实表元数据，自动生成维表和事实表；可视化关联字段的原子指标和业务限定，配置化定义派生指标口径，自动生成汇总表。整个模型设计过程代码是自动生成的，当然，一些复杂指标计算逻辑是通过代码片段的形式作为配置项提交。
代码的自动生成除了提升开发效率外，还带来额外的好处，因为计算代码是动态生成的，汇总表是否生成真正的物理表，对用户是透明的，平台可以根据成本、性能、效率等的考虑，来动态决定是构建物理表（也就是OLAP Cube），还是只是一个视图，背后是直接下发查询到事实明细表。
大家有兴趣可以了解下阿里的 Dataphin 产品。
实时/离线计算引擎的不断发展演进，越来越多人肉在做的优化最佳实践会被集成到引擎里，做到在线识别、自动优化。
比如 Join 长尾（倾斜）问题，有一个优化方式是把热点数据提取出来，然后拆分任务，用大小表的 mapjoin 机制来提速；比如 count distinct 倾斜问题，可以基于热点字段做数据的二次分发，将查询拆成两层，内层子查询基于二次分发的数据做聚合，外层查询再按热点字段聚合。后者已经被 Flink partialAgg 机制所支持，开发人员使用普通SQL 开发任务即可。相信这些有规可循的优化“套路“会越来越多地被集成到计算引擎中。
OLAP Cube 又称 Data Cube，工程实践上是对（明细）数据表基于合适的维度组合（基于业务确定的维度组合或基于重要维度的笛卡尔积组合）做预先聚合计算，典型的计算机领域以空间换时间案例。
这种预计算模式，通过为下游应用提供稳定的查询性能，长久来促进了数据仓库的发展，我们通常说的集市层“百花齐放”，快速响应业务诉求，指的就是 OLAP Cubes 的建设。数据仓库建模理论，如 Kimball 的维度建模理论，本质上就是解决如何基于业务的分析诉求，科学的定义数据仓库中数据的组织方式，让数据开发工程师更好更容易的构建 OLAP Cubes。
技术的限制让这种模式存在并流行，这种模式反过来又在塑造数据团队的组织形式和职能，成为一种行业标准。做个假设，如果我们当前拥有极为充足的计算能力，很便宜的内存资源，还有能高效利用它们提供足够优秀查询性能的数据库，我们是否还需要花费大量人力基于明细数据去开发一个个应用层汇总表来解决多样的数据查询诉求？
第一个因素是摩尔定律，带来了计算和存储成本的不断降低，公有云的高速发展，按需购买，按量付费的模式，进一步降低了数据的存储和计算成本。
第二个因素是类MPP计算架构，列存储模式数据查询引擎的技术突破和成熟，同等资源下，能提供成倍甚至几十倍的查询性能提升。
从技术上来看，停止建设 OLAP Cubes，所有请求直连明细数据是可能的。但从业务上来看，所有的数据查询请求直连明细数据，存在两个潜在问题：1）查询请求过于复杂，不易理解，且容易出错；2）数仓汇总层会变得很薄，业务人员要从明细层取数，效率变低。
数据应用端的两个发展趋势一定程度上可以解决上述潜在问题。
第一个趋势是BI工具的演化，从提供优秀的报表制作及数据可视化能力，到兼具高级分析的”计算“能力。用户不再需要费脑力去思考如何写复杂的取数 SQL，而是通过 BI 工具的拖拽可视化，以及简单易用的计算字段配置来进行数据的分析和探索，如 YoY/MoM/DoD 对比、年/月/日汇总和趋势分析、字段级联组织和下钻分析等，都是通过系统配置自动支持，不用写 SQL。
第二个趋势是交互式/对话式查询在数据产品上的应用越来越多。这类数据产品模式的目标是提供更大的灵活性给用户，数据产品不仅仅只是看数，而是用户参与其中，定义自己的看数视角。以用户行为转化漏斗分析举例，常规数据产品会首先根据业务诉求定义转化过程重要节点，数据开发进行需求开发，然后通过数据的可视化展现服务用户。而交互式分析模式首先是对转化分析方式进行抽象：转化漏斗分析是对漏斗窗口期内，所有满足限制条件的用户行为，按既定步骤顺序的转化计算，以漏斗图的可视化形式展现。产品模块定义如下：1）漏斗名称设置组件，2）漏斗窗口周期设置组件，3）漏斗步骤设置模块，其中每项步骤包含用户行为选择和限制条件配置，4）漏斗图展现组件。至于对哪些行为做分析，是否需要对该行为再做条件筛选，关联多长时间的数据做时间序列追踪等，交由用户选择，即席查询。
概括来说，就是使用可视化分析工具替代取数 SQL 开发，产品化构建交互式分析场景替代集市主题表建设。
前面讲了数据开发技术的三个方向：1）流批一体成为主流开发模式，2）代码自动化技术走向成熟，3）OLAP Cubes 终将衰落。对于数据开发从业者而言，在技术的发展中，如何持续保持个人竞争力，我认为最重要的是如下三项能力。
只有深入理解业务，才能真正知道当前业务处在什么阶段，碰到了什么问题，重点目标是什么。对应到企业的数据建设，一定要先解决“为什么”的问题，当前数仓服务的业务现状是什么，为了解决业务什么问题，期望达到什么目标，这些是无法靠技术自动化解决的。然后才是模型设计、实施落地。
数据会被用来搭建一个个分析报表，服务一个个数据产品，好像数据产生后，就和数据开发从业者无关了，以至于从业者很多自嘲是“人肉SQL机器”，是“数据搬运工”，也经常被合作方称做“ETL工程师”。把数据做深的能力是指生产数据之外，能持续去思考从这些数据里能获取什么，不管是通过数理统计还是机器学习，探索能否挖掘出推动业务增长的洞察，以及行动指引，是做“数据掘金者”。
数据链路的全局观不仅仅是清楚整个数据架构是什么样子，熟悉数据是如何流转的，更是能做数据链路的全局优化。如整个数据链路的稳定性保障，数据资产的组织和管理机制设计，数据的全链路价值评估、成本治理，数据的质量管理及测试、监控机制的建设等。